Towards Structured Flexibility in Information Systems Development: Devising a Method for Method Configuration

Introduction

Ineffective development practice is a perennial problem for many Information Systems (IS) development organizations (Brancheau, Janz, & Wetherbe, 1996; Riemenschneider, Hardgrave, & Davis, 2002; Roberts, Gibson, Fields, & Rainer, 1998). In response to this problem, many IS Development Methods (ISDMs) have been developed (Fitzgerald, Russo, & Stolterman, 2002; Roberts et al., 1998). There is clearly a need for structured and standardized ways of working in IS development. At the same time, there is a need for flexible work practices (Bajec, Vavpotič, & Krisper, 2006; Fitzgerald et al., 2002; Riemenschneider et al., 2002; Xiping & Osterweil, 1998).

A standardized way of working makes projects effective and predictable and increases the likelihood of meeting deadlines, staying within budget constraints, and achieving a desired quality (Fitzgerald et al., 2002). Standardization of IS development practice occurs at three different levels. At the individual level, project members choose ISDMs and specific techniques for use in specific tasks to improve their personal and collaborative practice. At the project level, a wider agreement can be made concerning the use of a particular ISDM. Finally, at the organizational level, a specific ISDM can be chosen as the organization-wide ‘standard’ method to be used in all projects. The expected benefits from implementing a standard ISDM across an organization include effective communication and reduced training costs due to a common modeling language, lowered maintenance costs, and the utilization of industry standards and existing tools. The search for organization-wide ISDMs has resulted in ‘off-the-shelf’ ISDMs such as the Unified Process. Such ISDMs are often fully comprehensive, aimed at covering every aspect of IS development, and bundled with training, support and various development tools from a specific vendor.

However, practical experience reveals that all projects are unique and require unique methodological support (van Slooten & Hodes, 1996). Some have also criticized organization-wide ISDMs, suggesting that they are too inflexible and hard to comprehend (Beck, 2000). The various parts of an ISDM are developed and included in the ISDM to minimize risks and to maximize the probability of success (Ropponen & Lyytinen, 2000). Because ISDMs aim to cover many different aspects of software practice, they will contain parts and address risks that are not of interest to every project. Hence, organization-wide ISDMs must be tailored to suit the particular development context (Fitzgerald, Russo, & O’Kane, 2003; Fitzgerald et al., 2002). To this end, different approaches have been suggested, ranging from formalized ones (Fitzgerald et al., 2003; Harmsen, 1997; Rolland, Prakash, & Benjamen, 1999; van Slooten & Hodes, 1996) to informal guidelines (Cameron, 2002; Cockburn, 2000). A rigorous approach to creating and tailoring ISDMs is that of Method(ology) Engineering (ME; Brinkkemper, 1996; Kumar & Wellke, 1992). ME concerns methods for developing ISDMs, also known as ‘metamethods.’ Traditionally, metamethods support the selection and integration of ISDM parts that together form consistent ‘situational methods.’ This approach to situational ME is therefore assembly-based, whereby new methods are constructed for each new project. Such an approach does not take advantage of any existing organization-wide method.