The two paradoxes above raise several questions about the acceptance and applicability of methods in general, and commercial text-book methods in particular. For example, why develop commercial methods or yet another modeling approach (known as the YAMA syndrome, Oei et al. 1992) if hardly anyone is going to use it? Based on the paradoxes we take a different starting point and re-evaluate the prevailing view of method use. Instead of viewing methods as universal, fixed, and readily applicable mechanisms for instrumental problem solving we view methods more as being situation-bound and describing only part of the knowledge necessary for ISD. Methods are related to an organization’s current level of expertise, and they are under constant evolution in organizations which apply them. Thus, the re-evaluation of method use describes a new understanding of methods and seeks to explain the popularity of local methods.

The re-evaluation does not mean that methods should not be standardized or situation-independent, or that commercial text-book methods should not be developed. At least 14% of organizations are still using text-book or commercial methods as specified and without adaptation (Fitzgerald 1995). These methods also provide a starting point for development of local methods. In this study we are, however, concerned with the rest of the organizations: those which develop their own methods, those which adapt available methods, and those organizations which could benefit from methodical support once methods have been defined and constructed to meet their contingencies. Accordingly, in the two following sections we shall define and discuss methods from a different angle suggesting a complementary view of methods - especially of their development and use.

Instead of viewing methods as universally applicable, we advocate that method knowledge is situational. Deriving partially from the popularity of local method development, this is by no means a new claim: several researchers (Wood-Harper 1985, Checkland 1981, Parkinson 1996) also emphasize the importance of situational awareness. For example, Wood-Harper (1985) claims that since method use takes place in real-life situations “a method can not be separated from the problem situation and the analyst’s intention and beliefs”. As a result, the applicability of method knowledge is always determined in the use situation.

Similarly several method developers (e.g. Yourdon 1992, Walden and Nerson 1995, Booch et al. 1996) argue for situation-dependency and modifiability of methods. Yourdon (1992) supports user-driven method selection by proposing that each developer should use the method that best supports the given situation. Walden and Nerson (1995, p 122) make remarks on extending the use of object-oriented methods to enterprise modeling: “enterprise modeling needs more than the basic object-oriented concepts to be expressive enough. This may very well be true for complicated cases, but the additional needs are probably quite different for different types of organizations”. Similarly, although UML (Booch et al. 1996) seeks to standardize object-oriented modeling techniques, its developers have recognized the need to modify the techniques, in particular to better serve different target programming languages. This is especially relevant to UML since it seeks to provide a design-oriented language that provides one level of abstraction over programming languages. Also, methods which are maybe best known for their fixed and standardized approach, namely IDEF (FIPS 1993a, 1993b) and SSADM (CCTA 1995), have abandoned the idea of applying them strictly as specified, and even recommend modifications (Fitzgerald 1996).

Similarly, organizations which have introduced methods have found situational adaptation a necessity. It must be noted that situations affecting the applicability of a method can occur at different levels of an ISD organization: organization, project, or even individual level. For example, in the context of IS planning, Pyburn (1983) states that IS planning must be adapted to the specific organizational context. In the context of software development and use of object-oriented methods Jaaksi (1997, p 71) claims that “every method needs adaptation when taken into use”. This means that ISD projects should not be considered as all being the same, as in practice each is to some degree unique (Parkinson 1996). Finally, at the individual level, Wijers (1991) conducted laboratory studies on method use and showed that individual developers tend to change the method while using it.

Although the situations in which methods are used can be different and even opposite between the levels of an ISD organization, the more general levels set conditions on the situational adaptability at the lower levels. For example, an organization-wide method can influence the adaptations made at the project or at the individual level. Unfortunately, there is not much knowledge on how situations at different levels influence local method development. We acknowledge situations from different levels, but like in most ME literature, we emphasize situations which are project specific. This does not mean that we exclude other type of situations; rather the project focus is stressed for relating the developed ME principles to other ME approaches. As discussed in Section 3.2, most ME approaches start by defining methods for the ISD project.

A main problem addressed in this thesis is how to make method development happen according to situational requirements. Methods as described in the literature offer few “built-in” possibilities for modification, and do not provide mechanisms for carrying out required modifications. For example, the methods analyzed in Chapter 4 do not define how customization can be carried out, which are the situational dependencies having an bearing on method modifications, and which parts of method knowledge (e.g. technique, process, etc.) should be a target for modifications. For example, one major difference in the newest version of SSADM (CCTA 1995) compared to its predecessors is that it allows and even recommends method adaptation (earlier, adaptation was not allowed). However, little if any guidance is given on how different parts of the method knowledge should be modified. Typically, guided adaptation includes selecting a full or a limited version of a method (e.g. Booch 1994). This approach offers, however, very limited adaptability in terms of method knowledge. This is not a criticism of “standard” methods, but shows how difficult it is to adapt a standard. One can also claim that build-in adaptation guidelines would not solve the problem because they would make methods even more complex, difficult to learn, introduce and use, and thus decrease their acceptance even further.

To summarize, situation-independent and universal methods are not possible because ISD situations are so different. Applicability of a method in one situation does not mean that it provides successful results in other situations. Similarly, contingency theories (Davis 1982, Kotteman and Konsynski 1984, Sullivan 1985) suggest that the creation of a method which can give the best support in all situations is impossible. This also partly explains why text-book methods are not widely used and why organizations use their own locally developed methods. As a result, the YAMA syndrome, mostly used in a negative meaning, is a natural consequence of the need for situation-dependent methods. If organization or project-specific methods work better and their users are more satisfied with them (cf. Hardy et al. 1995) then why apply third-party methods? In fact, one could even state that we should have more methods and variety in method knowledge to cover various situational characteristics of ISD. It must be noticed that different situations do not necessarily explain all local method development efforts and the YAMA syndrome, since organizations can develop their own methods for marketing purposes, or then because they do not have time to learn from outside. Similarly, an organization’s own methods can be promoted to sell consulting or tools (e.g. Frost 1994).

The underlying paradigm behind many ISD methods is scientific reductionism (Baskerville et al. 1992). This rests on the assumption that the solution can be achieved through a sequence of steps, decisions, and deliverables pre-defined in the method knowledge (Fitzgerald 1996). The expectation of a complete and explicit set of methodical knowledge is, however, too narrow.

The dominant approach underpinning many methods can be characterized as what Schön (1983) calls “technical rationality”: situations in practice can be scientifically categorized, problems are firmly bounded, and they can be solved by using standardized principles (Tolvanen 1995, Fitzgerald 1996). This view of development and use of methods is by no means wrong or “bad”: it has produced a great deal of knowledge about ISD and led to the development of useful routine procedures which are generally known and used (Fitzgerald 1995). In fact, the main principle of method development can be said to be to provide knowledge about ISD which is explicit and applicable for future ISD efforts. However, not all tasks of ISD fit the view of scientific reductionism. In other words, it is not possible to have full knowledge about the problem (and thus the applicable method) beforehand, nor can pre-defined method knowledge cover all possible situations. Moreover, part of the knowledge related to ISD in general and to methodical knowledge in particular is tacit and thus can not be expressed. Therefore, we claim that the technical rationality is too narrow to address and explain the use of methods as it takes place in practice. As a result, it is our belief that system development can not be completely carried out by following pre-defined methods.

A liberating perspective to support method development is what Schön (1983) calls “reflection-in-action”. Here, the fundamental assumptions are uniqueness of situations and tacit, intuitive knowledge (Nonaka 1994). Part of our knowledge of ISD is based on our reflection on the situations in which we find ourselves, rather than being found solely by using predefined methods. Thus, methods need to be maintained based on reflections from practice, transforming tacit knowledge into explicit knowledge. The importance of tacit knowledge partly explains the low acceptance and use of methods, and why successful ISD efforts can be carried out a-methodically (Baskerville et al. 1992) without the use of any “explicit” method. Hence, method is not everything. On the other hand, all ISD efforts can not be carried out based on pure intuition and tacit knowledge (Jaaksi 1997). Therefore, we see the views of reflection-in-action and technical-rationality as complementary views of method development and use: both explicit and tacit knowledge are necessary and useful for successful ISD. Accordingly, a good method should take both aspects into account, on the one hand, providing knowledge which can be rigidly followed as routines, and on the other hand allowing human creativity and spontaneous.

The other assumption behind scientific reductionism (Fitzgerald 1996) is that the developer can obtain detailed knowledge about the problem situation and about applicable methods. This view expects that all necessary knowledge about the method, whether it is tacit or explicit, is available beforehand. In addition to this expectation of complete and explicit methodical knowledge the introduction of methods as readily available “routines” is seen as being easy, and the use of a method assumed to lead to solutions which are repeatable. For example, one of the goals of JSD (Cameron 1989) is to eliminate personal differences and even creativity from the development process. According to this view the key problem for IS developers would be to select the right method rather than to use it.

We question this by emphasizing that method use is a learning process in which the current level of expertise is crucial to successful ISD (Curtis 1992, Hughes and Reviron 1996). The learning process occurs at two levels; in the domain of IS, and in the domain of ISD. The former means learning about successful (or unsuccessful) ISs. The latter means that any organization that builds ISs, not only delivers systems - they also learn how to carry out ISD, and use methods. This learning about methods means that they gain experience about the applicability of methods. This experience can complement the method knowledge they already possess.

The importance of learning about ISD and methods over time was already recognized by Vitalari and Dickson (1983) and Davis and Olsen (1985). According to Argyris and Schön (1978, p 2-3) this forms a double loop of learning in which “error is detected and corrected in ways that involve the modification of an organization’s underlying norms, policies and objectives”. Single-loop learning is related to immediate tasks, in which error detection “permits the organization to carry on its present policies”. In the context of ISD the double-loop learning means modification of the ISD methods. Because ME aims to improve ISD methods, it can be viewed as a learning process in which an individual (Schön 1983), or even an organization (Nonaka 1994), creates new knowledge about methods and how to apply them. Similarly, Curtis et al. (1988) have suggested that both the developer and user learn through the dialectic approach, and Floyd (1987) has advocated a second-order learning process in which past experiences are guidelines for using a method.

The emphasis on learning is important in our discussion because it allows us to explain the low acceptance and use of methods. Although experience is known to be crucial to ISD it is not easy to build up and maintain. In fact, we claim that knowledge about methods can be mostly achieved only by using them. This means that a long time is needed for introducing methods into organizations (Bubenko 1986, Lundeberg et al. 1981), which partly explains why organizations do not use methods: the introduction of methods is a long standing investment which bears fruit only after a relatively long time. For example, Lundeberg et al. (1981) estimated that at least one year is required to introduce a method into an organization. In fact, the first projects where methodical principles are used can often show a decrease in productivity (Aaen et al. 1992).

Another factor explaining the low use of methods is organizations’ surprisingly shallow knowledge and experience of methods (see Aaen et al. 1992), and their poor capability to manage ISD (see Humprey 1988). For example, a survey by Aaen et al. (1992) observed that more than half of the organizations considered their knowledge and experience of methods small. Similar results have been found in other surveys (cf. Smolander et al. 1990). Research on software process maturity (Humprey 1988) has shown that understanding of one’s own work must precede any further steps in method definition and improvement.

Instead of viewing methods as finished articles, a view which few method promoters take, methods must be viewed from an evolutionary perspective. Shifts in method knowledge are known (Joosten and Schipper 1996) and an examination of current developments in the field of object-oriented methods, workflow methods or business process re-engineering methods gives no reason to expect that this would change in the near future. An indication of method evolution is that organizations must deal with different method versions, as for example with SSADM (CCTA 1995), introduce new method types, such as object-oriented methods, and abandon old methods which have been found inapplicable for new technologies and applications (Bubenko and Wangler 1992).

Basically, two different types of evolution exist: those reflecting general requirements of technical evolution and business needs, and those relevant to the ISD situation at hand. The former deals with the general historical perspective and the latter with how these general requirements are adapted into local situations and how they affect the method evolution.

The method literature includes several reviews of the development and use of ISD methods (e.g. Welke and Konsynski 1980, Bubenko 1986, Norman and Chen 1992, Moynihan and Taylor 1996). Most of these explain method evolution though an interaction with available or emerging technologies which are used either in the developed systems or in the ISD tools.

Bubenko (1986) analyzed methods from a historical perspective: the need for methods has grown while the complexity and size of ISs has increased. The earliest methods were developed in the 1960’s when the first large scale batch and transaction-processing systems were developed. Furthermore, the emergence of databases in the 1970’s lead to the introduction of data modeling techniques. At the same time structured design and analysis methods derived their origins from structured approaches and from the evolution in programming languages. Similarly, Welke and Konsynski (1980) characterize advances in technologies, such as database management systems, which were reflected in ISD methods. Likewise, today these surveys could be extended to object-oriented technologies, mobile phones, business process changes, and multimedia. As a result, Welke and Konsynski emphasize that method developers should be aware of technological developments, as they form one key factor in improving and maintaining methods.

Likewise, Norman and Chen (1992) explain method evolution in terms of an evolution of applications developed. They also relate method evolution to CASE tools. Although they primarily discuss the evolution of CASE, a close connection to parallel advances in methods are recognized. For them new applications drive the creation of methods and later lead to the development of CASE tools. Thus, method developers should follow advances in technologies which could support new forms of ISD methods. For example, the emergence of graphical user interfaces and CASE tools supported the introduction and use of methods (Chikofsky and Rubenstein 1988).

Another indication of a method’s historical evolution can be found by studying different versions of commercial methods such as SDM (Turner et al. 1988), and SSADM (CCTA 1995). These were developed over long periods of time. For example, SDM (System Development Method), has been developed and updated since 1974 because of the changes in software tools, organizational impact of ISs, and the need to support system maintenance (Turner et al. 1988). Even the newer object-oriented methods have a history of different versions, such as OOD/UML by Booch (1991, 1994, Booch et al. 1997) or MOSES (Henderson-Sellers 1992, Henderson-Sellers and Edwards 1994). Accordingly, some efforts have been made to identify evolution paths between different type of methods, or even to construct a family tree of methods (Smolander et al. 1989). Similarly, there are plenty of studies available which extend methods to support some useful or required design or analysis task, such as distribution (Olle 1994), client-server architecture (Frost 1994), or information systems planning (Stegwee and van Waes 1993).

Another viewpoint on method evolution can be taken by analyzing how organizations develop their methods. This viewpoint is also relevant to our research question about incremental ME. Although organizations’ local methods are relatively common we do not know why and how organizations develop their methods, or how frequently methods are refined or updated (Wynekoop and Russo 1993). Since ME is not studied empirically enough (Tolvanen et al. 1996) we must rely on reported cases (cf. Aalto 1993, Jaaksi 1997, Kronlöf 1993, Vlasblom et al. 1995, Russo et al. 1995, Nissen et al. 1996, Tollow, 1996, Kurki 1996, Cronholm and Goldkuhl 1994, Bennetts and Wood-Harper 1996).

In the following the evolution of local methods is inspected by analyzing the “end-products” of ME efforts. This analysis is carried out by focusing on two dimensions of method evolution: the first dimension analyzes how much the locally developed method has changed, and the second dimension how often the method modifications have taken place. These dimensions are illustrated in Figure 2-3 and their measures are discussed below. These dimensions along with the analyzed ME cases allow us to partly explain what method development or adaptation involves.

FIGURE 2-3 Characterizing local method development: the degree and frequency of modifications.

The degree of modifications defines how large the changes are that are made to the local method to improve its applicability. These modifications can be (cf. Harmsen et al. 1994):

1) tied to the selection paths provided by a method,

This classification allows us to distinguish how much a method used in an organization differs from other methods. The degree of modifications could also compare two changes at different times in the same local method by analyzing the number of method components changed at each time. This alternative dimension is excluded here because ME cases are not reported in such detail that categories could be formed. Hence, in the following each degree of method modifications is discussed by analyzing the current method in use (instead of the current changes).

1) Selection paths within a method describe one extreme of ME. Here the only possible modification alternatives are those provided by the method (i.e. built-in flexibility), and thus are limited to a few contingency factors. Examples of these contingencies include development of small versus large systems, the use of prototyping, and the use of application packages (e.g. in SDM, Turner et al. 1988). It is, however, unrealistic to expect that methods should include a much larger set of contingencies and condense them into modification guidelines (Hardy et al. 1995). One clear reason for this is the vast amount of possible contingencies, and even if these could be identified, the growing size of methods.

2) A combination of methods for internal use occurs when a chosen method, and its possible selection paths, do not meet the situational contingencies. In a combination (or integration as defined in Krönlof 1993) the local method is based on the constructs offered by several commercial methods, and partly based on modified or totally new constructs. A study by Russo et al. (1996) shows that 37% of the methods used in organizations are combinations of commercial and in-house methods. Accordingly, the adaptation can be carried out either by combining available methods (or method parts, sometimes called fragments, e.g. Harmsen 1997), or by modifying a single method for internal use (e.g. Bennetts and Wood-Harper 1996, Nuseibah et al. 1996). An example of the former is Object-TT (Kurki 1996), which is a company specific method developed by combining available techniques from a larger set of text-book methods. As Object-TT focuses on modeling, it is heavily dictated by the available notations and their underlying concepts. An example of the latter is the modification of the Information Engineering (Martin and Finkelstein 1981) method reported in Russo et al. (1995).

3) An organization or a project which develops its own methods faces situations which are outside the set of situations to which known methods are suited. Minor modifications into known methods are no longer sufficient, and thus the developed method does not have any close “relative” among other methods. Ryan et al. (1996) characterizes this category as an effort to develop new conceptual structures (models in their terminology) and related notations. An example of a company which has developed its own methods is USU, a consulting company (reported in Nissen et al. 1996). The method developed, called PFR, focused on rapid requirements capture in team workshops and individual interviews.

Locally developed methods are often considered propriety and information about them is difficult to obtain. Many of the methods which can today be characterized as commercial have a background in an organization’s internal needs. For example, Business Systems Planning (IBM 1984) was originally developed to solve the problems which IBM noticed in the management of its own ISs. Similar histories are shared by Objectory (Jacobson 1992) and Octopus (Awad et al. 1996).

The second dimension, the frequency of method modifications, explains how often a method is changed (Hardy et al. 1995). More specifically, it measures how often changes in ISD situations are reflected in methods. From the available cases four basic categories can be found:

1) advances and changes in external methods,

2) changes in an organization’s ISD situations,

3) a project-by-project basis (once ISD project starts), or

4) continuous refinements within a project.

In the following each category is discussed in more detail.

1) Method modifications based on advances in external method knowledge are typical in organizations where methods follow a national or industry standard (e.g. SSADM (CCTA 1995), IDEF (FIPS 1993a), OMG-UML (OMG 1997)), or a method-dependent CASE tool. Thus, new versions are the result of externally decided modifications. Because of the slow standardization process such modifications are carried out infrequently, and do not necessarily relate to organization specific situations. Similarly, if the method is supported by a method-dependent CASE tool, the vendor can dictate the frequency of new versions. Method changes in this category do not normally occur more often than once a year.

2) Method modifications based on changes in an organization’s ISD situations deal with local method development in which contingencies related to the whole organization change and are reflected in methods. Examples of such changes are outsourcing ISD, introducing new technologies (e.g. Bennetts and Wood-Harper 1996), or starting to develop new type of IS. Hence, the relevant contingencies here are the same for the whole organization. Examples of organization-wide ME initiatives are reported in Cronholm and Goldkuhl (1994) and Kurki (1996). This type of organization-wide method change can occur many times a year. The possibility for in-house method modifications may also be restricted by the CASE tool, as most tools demand a one-shot adaptation (Cronholm and Goldkuhl 1994). Partly for this reason larger organizations have also implemented their own tools (e.g. SDW in Pandata (Turner et al. 1988)) or even applied metamodels to achieve flexibility in changes (e.g. the TDE environment in Nokia (Taivalsaari and Vaaraniemi 1997)).

3) Method modifications on a project-by-project basis are considered in ME research to be the most typical. Each project is characterized by individual features which need to be mapped to methods. Modifications are not made during the method use but only at the beginning of every project[11]. Because each project is dealt with individually this approach is relevant to project-based ME (cf. Section 1.4.3). For example, in a case reported by Bennetts and Wood-Harper (1996) the successful use of a local method has encouraged an organization to adapt methods for individual projects. Hence, the changes in methods are always based on the schedules of the projects (i.e. a timeframe of months in general).

4) Continuous method refinement happens when ISD contingencies are uncertain or change rapidly, e.g. when a new method or methods are used in a new area. Although methods are typically introduced as a whole, the ME efforts analyzed show that method adaptations occur frequently during an ISD project. These modifications do not occur only at the individual level, but also in ISD projects, and in the longer run in the whole organization.

Studies on individual developers’ method use (e.g. Wijers 1991) show that methods are gradually changed during their use: e.g. new concepts and new rules are added to the modeling techniques. These personal modifications are, however, often tacit and not shared with other developers. Method modifications are also performed in team-based method use. In this case method modifications are documented and available for others. For example, in Nissen et al. (1996) method modifications related to a supporting tool caused modifications to the method, to the supporting tool, or to both: after the initial method was developed, modifications were made based on feedback from method introduction during internal workshops, during and after the pilot project, and finally after running a few application projects. Third, method modifications also occur in organizations’ methods, although not as frequently as in project-dependent methods. For example, clear method modification phases can be found from the ME practices related to the development of one method in Nokia (Aalto 1993, Aalto and Jaaksi 1994, Jaaksi 1997): OMT as a text-book version in 1991, modifications resulting in OMT+ in 1993, and further modifications to create OMT++ in 1994. Moreover, the OMT variant had several smaller and more frequent modifications which were made during its development (Jaaksi 1997).

Table 2-3 summarizes the analysis of ME efforts based on the two dimensions discussed above: degree and frequency of method modifications. The table includes ME cases which have been reported adequately enough to be classified. It would be of great interest to also analyze the degree and comprehensiveness of each individual method modification step, rather than looking at the end-product. Unfortunately this is not possible because most of the cases do not describe the method development processes. Furthermore, they usually describe only one or two types of method knowledge which have been modified, like the modeling technique or the ISD process. This naturally makes the classification of ME cases in the Table 2-3 difficult. For example, the method engineers can describe the method developed as a combination of available methods (e.g. Jaaksi 1997), but a more detailed analysis of method knowledge can reveal that the method includes many aspects which are not covered by other methods. A simple combination of methods would not lead to such a large modification.

TABLE 2-3 Examples of local method development efforts.

The analysis of the cases reveals that different approaches for local method development are applied. It must be noted that the sample of ME cases is small and thus no firm conclusions can be made, but the analysis does provide some hints about local method development. In some cases it seems to be applicable to follow a standard method and limited adaptation, whereas in other cases larger and more frequent method changes are required. Because of the paucity of empirical research on local method development, the reasons behind these choices are largely unknown. The analysis of method development practices, however, reveals which approaches are not used at all, and can be considered unlikely in ME. None of the organizations has developed its own and radically different method in a short period of time. All the reported cases indicate a more gradual method development process. This is also a reason for developing principles for incremental ME.

[11] It must be noted that organizational units other than a whole company or an ISD project can be identified, such as a department, teams related to developing and maintaining a certain IS, and an individual. Because of the lack of empirical studies on local method development already mentioned, we can not focus here on method modifications occurring in organizational units other than a whole organization or an individual ISD project.