Although local method development steps may seem straightforward, there are great differences in how ISD methods are selected and developed locally, and how they can be introduced. To highlight some of these differences we have analyzed the literature on methods, their selection and development (Davis 1982, Sullivan 1985, Olle et al. 1991, Kumar and Welke 1992, Brinkkemper 1996, Odell 1996, Harmsen 1997). Based on this analysis we distinguish three basic strategies for local method development. These are: a text-book approach, a contingency approach and a method engineering approach, either at the organizational level or at the project level.

These strategies can be considered as ideal types in different situations. They differ in the extent of the changes that are made to methods to meet the situation specific needs (cf. Figure 1-2). In a text-book approach a whole method is chosen; in a contingency approach selection is largely made by choosing individual techniques from a large set; in method engineering selection is made by choosing components of techniques (or methods) and by constructing unique components. Hence, the method development strategy applied in an organization can be identified by studying how different the resulting method is when compared to other known methods. It must be noted that these strategies are not mutually exclusive; indeed they are often combined. For example, some modeling techniques may be chosen as text-book techniques because they are considered de facto standards whereas other techniques are be developed from scratch or by extending existing techniques (e.g. in Jaaksi 1997). These differences will be discussed in more detail in Section 2.5.

Each method development strategy extends the scope of modifying methods for local situations. Thus, the text book approach and contingency approach portray a limited adaptation possibility whereas the ME approach suggests that ISD methods should be constructed for the use situation. Hence, organizations which apply text-book methods believe that development situations are generally alike, and thus can be solved with standard solutions. Standardization efforts of methods, like SSADM (CCTA 1995), IDEF (FIPS 1993a) and UML (Booch et al. 1997) are examples of this approach, although they also aspire to other objectives such as communication between different ISD tools. In contrast, organizations which develop their own methods are examples of a different opinion. They believe that development situations in the organization or in projects are very different and furthermore this difference influences the applicability of methods. Different method development strategies also have implications about the maturity of the organization’s ISD process (Humphrey 1989) because ME and detailed modification and use of methods necessitates that an organization is first able to understand its ISD processes, and second measure them to develop better ISD procedures and guidelines. This means that organizations which successfully modify their methods to meet their situational requirements can not be at low maturity levels. An organization must have at least defined their ISD process (Humphrey 1989): successful modification of methods in an organization or in its projects is not possible if their use process is not known. In the following we shall study these three strategies in more detail.

FIGURE 1-2 Strategies for local method development.

The most common approach to select and introduce methods is probably simple trial and error (Smolander et al. 1990). Organizations choose their methods, either consciously by selecting one of the well known “text-book” methods often backed by consultants, or indirectly by introducing a CASE tool that applies a specific method. A new methodical approach is then introduced without modification. The text-book approach offers a simple strategy for local method development: the method construction and tool adaptation steps do not take place.

The underlying rationale behind this approach is that situations and problems in ISD are similar, or at least similar enough to be analyzed and solved by applying general methods applicable to “almost” all situations. This text-book approach to ISD methods can be characterized as what Schön (1983) calls “technical rationality”. According to this approach, situations of practice can be scientifically categorized, problems are firmly bounded, and most importantly they can be solved by using standardized principles. From the technical rationality point of view, we can see ISD methods as universally valid techniques for instrumental problem solving. It must be noted that although the need for flexibility is recognized in some methods (cf. Wood-Harper et al. 1985, CCTA 1995, Booch 1994, Coleman et al. 1994), they do not include mechanisms to modify them according to the various characteristics of ISD.

An alternative approach for method selection is based on contingency theory. It suggests that there is no universally acceptable method which is applicable in all circumstances. Hence, a contingency approach is based on the observation that situations of practice can be classified, but are more situation bound than the text-book approach expects. Because current methods do not offer general rules for considering situational expectations and deviations (Iivari and Kerola 1983, Vlasblom et al. 1995), contingency frameworks for method selection try to establish this connection by relating methodical needs and available methods. Researchers following a contingency approach (e.g. Davis 1982, Kotteman and Konsynski 1984, Sullivan 1985, Naumann et al. 1980) have tried to identify prominent characteristics (i.e. situation dependencies) which control outcomes of the use of methods and predict their suitability. These characteristics can be technical, such as the type of an IS or the programming language applied; organizational, such as the development culture and maturity; or human, such as the level of experience and learning.

Although the contingency approach in method research is mostly used to analyze situational features of methods, it is also applied for method selection and development (e.g. Vlasblom et al. 1995, Punter and Lemmen 1996, Savolainen 1992). For example, a contingency framework developed in the HECTOR project proposed several situational characteristics, like the type of project activities, ISD environment properties and method/tool properties for tool selection (Savolainen 1992). In contingency frameworks for method selection new methods are not necessarily developed; rather they are selected from those available. Thus, in contrast to the steps of local method development (cf. Figure 1-1), the contingency approach focuses on the selection of an available, appropriate method rather than on more detailed method construction (Kumar and Welke 1992). This bias towards selecting methods from those available leads to “bounded” construction and selection of methods.
Page: 12

Although contingency theory has considerably expanded our understanding of methods suitability, its a priori assumptions, once applied as a method selection framework, neglect possibilities for method choices other than those already prescribed. Moreover, contingency-based method selection ignores the impact of organizational learning. Both these problems are addressed in local method development. The first one deals with the insufficient competence to find situation dependencies (cf. Kumar and Welke 1992, Grant et al. 1992). This observation is supported by empirical studies of method use (cf. Hardy et al. 1995, Russo et al. 1995, Wijers 1991, Fitzgerald 1995). They show that situations at an organization, project or individual level often cause changes in methods. Simply, understanding of methods increases while methods are being used. However, this type of knowledge is not usually included in the contingency-based method selection.

The second problem comes from selecting methods (Kumar and Welke 1992). Because varying contingencies will cause changes in methods during their adaptation with new tools, their learning becomes expensive, or even impossible. If research has indicated that ISD professionals do not have enough knowledge and experience of methods (Aaen et al. 1992), how could they be competent to choose between methods? Hence, method selection and development should be considered in relation to both a priori contingencies and cumulated organizational experience.

To complement contingency-based method selection researchers have proposed an idea of a detailed method construction in close connection with the use situations (cf. Brinkkemper 1996, Kumar and Welke 1992). Instead of selecting a method purely from an available library according to contingencies, ISD methods should be constructed to meet a particular IS development’s needs. This approach is called method engineering (ME, Kumar and Welke 1992) as it aims to construct or “engineer” an ISD method according to stakeholders’ requirements. Simply, the idea behind ME is the same as behind building any system: just as ISD develops and maintains systems supporting business processes, ME aims to develop and maintain systems for ISD. This is an alternative approach since ME assumes that ISD can often not be carried out solely according to a set of available methods. In fact, according to the ME approach ISD methods should be adapted to local situations even if it requires detailed modification of methods. Here, the fundamental assumptions are uniqueness and difference in ISD situations which can not be solved solely by using general and universally valid methods or general contingency-based selection principles. This approach also necessitates more detailed and systematic steps of method development (cf. Figure 1-1). In particular, the steps of method construction and tool adaptation are emphasized.

ME approaches can be further distinguished by whether they aspire towards an organization-specific or a project-specific method. This division can be also found in practice as described in more detail in Section 2.5. The first one, organization-based ME, is based on an assumption that development situations - and thus also supported methods - are alike in an organization and the method can be developed to meet these requirements. In the organization this method is then believed to be appropriate for all projects. Baskerville (1996) calls these methods contingency methods, as they are situation specific for certain types of bounded organizational settings. Numerous examples of these approaches can be found. For example, the Pandata corporation has developed various versions of the SDM method and supporting tool (SDW) to be used in the company (cf. Turner et al. 1988).

Another ME approach is project-based ME, which assumes that methods should be “engineered” on a project basis. Because this approach copes with the uniqueness of each ISD setting (Baskerville 1996), it focuses on advancing method knowledge in the context of a single ISD project. Thus, it is believed that development situations differ between various projects. An example of local method development effort in this category is Nokia Telecommunications, whose OMT++ internal method has been developed to be used for designing network management systems for mobile phones (cf. Aalto and Jaaksi 1994, Jaaksi 1997). Although this method might be applicable in other divisions or projects of Nokia it has been developed from one application and a project point of view.

Although there can be an in-house method in the organization, according to project-based ME there is also a possibility to adapt it, or even to develop various project variants. For example, a questionnaire based study (Wynekoop and Russo 1993, Russo et al. 1995) claims that over 2/3 of the companies have developed their methods in-house. It also shows that half of the respondents believed that the organization should use a single method for all projects (i.e. follow an organization-wide method). At the same time, however, 89% of respondents claimed that methods should be adapted on a project level in contrast to using the same method in the whole organization (i.e. follow project based ME). These results clearly show a lack of knowledge of local method development and adaptation. This may be due to the fact that the question of whether an organization has or has not developed an in-house method can be understood differently. Thus, the question should not only be whether or not methods are developed in-house, but also to what extent they are modified, or adapted, and how the modification is done. Unfortunately, the study neither explains the variation to different answers, nor does it reveal whether organizations that have purchased methods from outside are more willing to follow the method than those which have developed a local method. However, the study raises several questions that remain largely unanswered. For example, to what extent do organizations adapt methods? How are these efforts organized? Are ME efforts project-driven or organization-driven? How is knowledge related to methods gathered and organized? How are method refinements carried out, and what is the role of method-related tools in method evolution. In the following section we shall analyze the state of ME research in relation to these questions. This will lead us to formulate our research questions and research approach.