Scandinavian research in systems development can be grouped into three major traditions, based on quite different ideologies and theories: the systems theoretical school, the socio‐technical school and the critical school. The differences between these schools are closely related to the historical and social contexts in which they developed. External political, economic and cultural factors have strongly influenced research in this field. In particular, the basic theoretical differences between the schools reflect their different interpretations of the relationship between capital and labour.

A recurrent problem in information-systems development (ISD) is that many design shortcomings are not detected during development, but first after the system has been delivered and implemented in its intended environment. Pilot implementations appear to promise a way to extend prototyping from the laboratory to the field, thereby allowing users to experience a system design under realistic conditions and developers to get feedback from realistic use while the design is still malleable. We characterize pilot implementation, contrast it with prototyping, propose a fiveelement model of pilot implementation and provide three empirical illustrations of our model. We conclude that pilot implementation has much merit as an ISD technique when system performance is contingent on context. But we also warn developers that, despite their seductive conceptual simplicity, pilot implementations can be difficult to plan and conduct. It is sometimes assumed that pilot implementations are less complicated and risky than ordinary implementations. Pilot implementations are, however, neither prototyping nor small-scale versions of full-scale implementations; they are fundamentally different and have their own challenges, which will be enumerated and discussed in this article.

We review Structured Analysis as presented by Yourdon and DeMarco. First, we examine the implicit assumptions embodied in the method about the nature of organizations, work processes, and design. Following this we present the results of an exploratory study, conducted to find out how the method is applied in practice. This study reveals that while some of the tools of Structured Analysis—notably the data flow diagrams—are used and combined with other tools, the designers do not follow the analysis and design procedures prescribed by the method. Our findings suggest that there is a gap between the way systems development is portrayed in the normative technical literature and the way in which it is carried out.

The design of patient-centred e-health services embodies an inherent tension between the concerns of clinicians and those of patients. Clinicians' concerns are related to professional issues to do with diagnosing and curing disease in accordance with accepted medical standards. In contrast, patients' concerns typically relate to personal experience and quality of life issues. It is about their identity, their hopes, their fears and their need to maintain a meaningful life. This divergence of concerns presents a fundamental challenge for designers of patient-centred e-health services. We explore this challenge in the context of chronic illness and telecare. Based on insights from medical phenomenology as well as our own experience with designing an e-health service for patients with chronic heart disease, we emphasise the importanceand difficultyof aligning the concerns of patients and clinicians. To deal with this, we propose a set of concepts for analysing concerns related to the design of e-health services: A concern is (1) meaningful if it is relevant and makes sense to both patients and clinicians, (2) actionable if clinicians or patientsat least in principleare able to take appropriate action to deal with it, and (3) feasible if it is easy and convenient to do so within the organisational and social context. We conclude with a call for a more participatory and iterative approach to the design of patient-centred ehealth services.

No abstract