A Steady-State Framework for Integrated Business Change and Information Systems Development and Maintenance

A Steady-State Framework for Integrated Business Change and Information Systems Development and Maintenance

Simon McGinnes
DOI: 10.4018/978-1-4666-0170-3.ch009
(Individual Chapters)
No Current Special Offers


Success models often treat Information Systems (IS) as static. Yet most IS evolve continuously, and most development effort occurs during the so-called maintenance phase. For an IS to succeed, its evolutionary process must also remain successful. Unfortunately many IS projects fail, particularly when outsourced. This chapter argues that the practice of managing IS work in project form may itself be implicated in IS failure. The project model is critically examined, identifying mismatches with the reality of IS work as a component of business change. The results suggest that merely trying harder to make projects succeed may be ineffective. An alternative framework for “steady state” development is proposed, which characterises IS work as evolutionary and inseparable from its context of business change, providing a blueprint for IS development without the need for projects, and offering improved chances of success when “big bang” project management would otherwise be the only option.
Chapter Preview

Background: Competing Views Of Is Development

The engineering project is today the dominant structural metaphor for thinking about IS development. Metaphors shape perception, particularly in IT which has re-purposed many existing ideas including record, file and even computer (Ezhkova, 2005; Light, 1999). “Good” engineering is a scientific and formal process rather than a fuzzy, intuitive one, and its product is technology. The engineering project metaphor indicates that IS requirements must be specified clearly before construction commences, and design must proceed according to established principles. IS development is characterised as bursts of focused activity (IT projects) in which technology is manipulated (system design) in a planned manner (project management) by experts (developers) on behalf of non-experts (end users) using analytical techniques (IS methodologies) to derive solutions (IS) to known problems (requirements). This engineering project view of IS development falls into a wider set of approaches to problem-solving characterised by the top-down application of external expertise and analytical thinking; Operational Research (OR) is one example. Its goal is to build an IT system; any associated business change is considered a separate concern, to be managed independently. Messy real-life issues, such as poor communication, fuzzy requirements and shifting priorities, are treated as aberrations; despite the high incidence of these problems, it is assumed that they can be avoided in well-run projects (Liu et al., 2010).

Complete Chapter List

Search this Book: