Print

EDIT Program (2005-ongoing)

Effects-driven IT development attempts to provide a sustained focus on the effects to be achieved by users through their adoption and use of an IT system.

Simply put, the overall idea is to capture the purpose of a system in terms of effects that are both measurable and meaningful to the customer, and to systematically evaluate whether these effects are attained during real use of the system. A sustained focus on effects accentuates that the functionality of a system is merely a means to an end, but it also entails that effects must not only be specified but also evaluated in the course of the development process. That is, effects-driven IT development blurs the distinction between design and organizational implementation – between design and use. Working systematically with effects involves specification of desired effects and formative evaluation of effects

Since 2005 we have worked with 5 research questions, using action research projects with industrial partners:

  1. How can desired effects be specified and specified effects measured?
  2. How can pilot implementations create the conditions for measuring the effects of using a system?
  3. How can effects that are specific to the users’ work processes be related to overarching strategic and political effects?
  4. How can the partnership that is necessary for effects-driven IT development be established between customer and vendor?
  5. How can an effects-driven approach be incorporated in the contractual regulation of IT projects, and what are the consequences of doing it?

 

Some key publications outlining the program include:


Pilot Implementations - a key activity in Effects-Driven IT Development

2.15: Hertzum, M., J. Bansler, E. Havn, and J. Simonsen (2012): ”Pilot Implementation: Learning from Field Tests in IS Development,” Communications of the Association for Information Systems, Vol. 30,No. 1, Article 20, pp. 313-328.
   Abstract
   Full text

We define Pilot Implementation as:

a field test of a properly engineered, yet unfinished system, in its intended environment, using real data, and aiming—through real-use experience—to explore the value of the system, improve or assess its design, and reduce implementation risk.

Abstract

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 five-element 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.

 

Effects-Driven IT Development: Introduction to the research program

2.14: Hertzum, M., and J. Simonsen (2011): ”Effects-Driven IT Development: Specifying and Measuring Usage Effects”, Scandinavian Journal of Information Systems, Vol. 23 , No. 1, pp. 1-26.

   Full text

Abstract. For customers information technology (IT) is a means to an end. This tight association between IT systems and their use is, however, often absent during their development and implementation, resulting in systems that may fail to produce desired ends. Effects-driven IT development aims to avoid the chasm between development and implementation through a sustained focus on the effects to be achieved by users through their adoption and use of a system. This involves iteratively (a) specifying the purpose of the system in terms of effects, (b) developing an IT system and associated organizational change that realize the specified effects, and (c) measuring the absence or presence of the specified effects during pilot use of the system while also remaining alert to the emergence of beneficial but hitherto unspecified effects. In this paper we explore effects-driven IT development and discuss the possibilities and challenges involved in making it an instrument for managing IT projects. Two main challenges are that effects must be measured while development is still ongoing, making pilot implementations a central activity, and that vendor and customer must extend their collaboration, particularly concerning organizational implementation. Empirically, the paper is based on three cases from the Danish healthcare sector.

6.14: Hertzum, M., and J. Simonsen (2011): “Effects-Driven IT Development: Status 2004-2011,” in M. Hertzum, and C. Jørgensen: Balancing Sourcing and Innovation in Information Systems Development, Tapir Academic Publishers, Trondheim, NO, pp. 165-192

Full text

Abstract: Information technology (IT) is a means to an end, yet many IT projects assign primacy to technical development and attend comparatively less to the organizational change effort that is required to attain a good fit between organization and IT system. This entails a risk of not capturing the benefits of the deployed system. Effects-driven IT development aims to counter this risk by providing an instrument for managing IT projects through a sustained focus on the effects desired from the use of the IT system. A sustained focus on effects entails that the specification, realization, and assessment of effects become central systems-development activities. In this chapter, we describe the six empirical projects we have conducted in our work on effects-driven IT development during the period 2004–2011 and we discuss the experiences gained so far. The empirical projects indicate that the desired effects can be specified and measured, though we have mixed experiences with ensuring that effects are measured. An effects hierarchy has been devised and appears suitable for working with effects at different levels of abstraction. A key challenge with which we still have insufficient experience concerns how a partnership with close relations between a customer and a vendor can be established. Finally, we have yet to address whether and how to incorporate an effects-driven approach in the contractual regulation of IT projects.