TESTIMONIO DE VIDA

The theme being implicitly communicated in section 2.3 is the link between technology and methodology development.

This thesis argues that the methods required to develop a computer system are intrinsically tied to the type of system being developed and the available technology; along with other factors. The following sections illustrate this view, using organisational learning models to illustrate paradigm shifts - both in the types of application being developed and the methods used to create them.

Rockart's model of application evolution (Rockart 1983; Scott Morton & Rockart, 1983) defines three 'eras’ that categorise the changing role of IT in organisations:

• Era 1: Administrative era: Basic accounting and other routine supportive tasks, like payroll administration, are automated. The development of applications are based on simple languages (Cobol etc.), the applications are primarily terminal based, with links to a central mainframe, and the applications are likely to be batch processed.

• Era 2: The extent o f IT usage is increased. Operational applications, like process and production control and inventory checking are automated. There is a corresponding shift from batch-processed to on-line capability.

• Era 3: Rockart's 'Information era'. Many highly interactive systems are introduced. These are built on top of existing transaction technologies.

Rockart (1983) presumes that as the technologies change, so do the methods needed to create them and the management structures required to enact change (Rockart, 1983). Saarinen (1989) and others (e.g. Eason, 1988) see this change as a move towards the use of more evolutionary, incremental IS development strategies, a finding that is supported by the overview of the historical trends in methodology outlined in Section 2.3.

While Rockart (1983) may suggest a strict categorisation between eras of computing and the type of skills, techniques and methods employed, there is little evidence to say that revolutionary changes in approach are necessary, or indeed (at least in the short term) if such dramatic changes are possible. Neither is there any strong evidence to suggest that the current crop of methodologies are extendible to cover problems relating to all three eras. Although some of the more novel approaches are particularly useful for ‘information era’ projects, there is still no one methodology or philosophical paradigm that can claim to be universally applicable:

“ ...we arg^e that it is unreasonable to rely on one approach. Each o f the themes^ has strengths and weaknesses and our practical work suggests that tools and

* Avison and Wood-Harper define six themes that they feel have been instrumental to the continuing development of methodologies, from systems approaches to prototyping and data analysis.

techniques appropriate fo r one set o f circumstances may not be appropriate for others."'' p. 98 (Avison & Wood-Harper, 1991).

Organisational learning plays an important part in determining the growth in the use of a particular development strategy, and moving from a development strategy based on Era 1 characteristics to development strategies based on Era 3 characteristics is not a simple task. McFarlen et al.’s (1983) model of technology assimilation illustrates this process in four stages:

• Stage 1: An initial investment in the technology is made. Effort is expended in learning about the technology, its uses, and how it can be used.

• Stage 2: Pilot projects are carried out in order to make interested parties aware of the possibilities of a technology.

• Stage 3: Control is exerted by the organisation and guidelines for the use of the technology are made.

• Stage 4: The technology is now in widespread use.

My position on McFarlen et al. (1983) is that the adoption of methodologies is very much like the adoption of technologies, with some provisos, which I will detail later in this section. The slow examination, exploration, interpretation and dissemination (organisational learning) model applies to methodologies as long as the context is stable and the methodologies are used for simple projects were the requirements are known in advance. Bubenko’s (1986) observations on the development of organisational methodologies can be equated with stage 3 of McFarlen et al.’s model, when an organisation may customise a methodology to suit its own needs.

If we accept both models, we could, by association, argue that the demand for evolution in methodologies, like the applications created with them, are technology-led and have been originated because of changes in technological eras. The arrival of more reflective design philosophies like the Scandinavian approach to design (Bjerknes et al., 1987) and more flexible software engineering approaches, like object-oriented design and Theory and Practice of System Development Methodologies: A Conceptual Framework 45

programming, can be traced to the arrival of new highly-interactive technologies (like high-resolution graphical capabilities on PC’s) and more powerful computers. The gradual evolution of some of the more mature structured methodologies (like SSADM) - introduced when era 1 technology dominated - can be also be traced to greater demands for on-line interactive systems replacing the need for batch-processed financial systems.

Section 2.3 illustrated the link between methodology and technology. The proliferation of iterative evolutionary approaches to the development of information systems over the last few years can be interpreted as a confirmation of the arrival of Rockart’s information era within a number of organisations. The reasons why such approaches are required are to do with the ‘uncertainties’ involved in developing interactive systems. Figure 2.5 illustrates this problem.

Clearly Understood

STAGE 1 STAGE 2

e.g., payroll systems e.g., word-

processing packages Poorly Defined STAGE 3 e.g., collaborative working systems Poorly Understood

Figure 2.5: The Growth of uncertainty in systems development

The two dimensions in Figure 2.5 are used to illustrate the growth in uncertainty in system development. The vertical axis refers to the degree to which we understand and are familiar with the system being developed. The horizontal axis refers to the degree to which we can define the workings of the system to be developed. The diagram shows

that Stage 3 applications® are poorly understood - mainly because of their novelty - and poorly defined - making it difficult to define requirements in detail. But the implications go far beyond requirements. Iterative approaches are needed to develop requirements over time, and more importantly, Jayaratnas (1994) What?How? Why? criteria for identifying a methodology are even more tenuously applied to these problems; the structure, toolset and protocol of a methodology will be contingent on the characteristics of the development situation.

One aspect of the information era that both Rockart (1983) and McFarlen et al. (1983) would not have been in a position to predict was the massive change in organisational structure and processes that accompanied it. Fundamental changes in the way in which work is carried out have resulted from the adoption of innovative new technologies as part of the information era. The world we live in has become more complex and dynamic - even turbulent (Maclaren et al, 1991). There have been major changes in IT usage brought about by changes in international trade, labour relations, and increased competitiveness between firms. Organisations are re-structuring at a dramatic rate, concentrating on their core proficiencies, relying to a lesser extent on full-time permanent staff, relying far more on project-based work, and are more likely to sub­ contract major pieces of work.

Again, the result of this ‘uncertainty’ in both the novel areas in which computing power is being applied and the rate of organisational turbulence or change can be major problems in fulfilling stage 1, 2 and stage 3 of McFarlen et al.’s (1983) model. While the technologies themselves (computers, output devices etc.) have some permanence within the organisation, organisational learning about the methods and methodologies it uses to develop IT systems is hampered by the fact that:

• Applications based on that technology will have a limited shelf-life (i.e., they will be relevant to the work that the organisation carries out for only a short period of time.)

’ Referring to Rockart (1983).

Seemingly accurate predictions of current and future business environments have only recently been developed (e.g. Drucker, 1988).

• Mutable requirements (requirements brought about by changes to organisational processes and structures) will have a major impact on projects. Likewise, changes in staff are likely to be more frequent (themselves a source of unpredictable problems if those people fill an important role on the project - like being a user specialist).

The lack of permanence within an organisation damages organisational learning, particularly when the object of the learning exercise is an idea-based or knowledge based entity like a method for developing computer-based systems rather than a physical entity like an application or a technology. While the organisation will still leam more about the technologies it is using, and be able to move from stage 3 to stage 4, learning about the methods it is using is a slightly more difficult task, and the results of stage 1 & 2 are likely to far too unreliable and non-generalisable in order to help an organisation ‘control’ or standardise the use of methods - the use of a method is contingent on too many factors. The result is that methodologies can or will often be customised on a project-by-project basis; their interpretation will be contingent even if the theoretical base is static.

The major impact of the proliferation of highly interactive systems has been in the proliferation of many different types of highly interactive product and a corresponding evolution and fragmentation in the methods used to create them. The use of methodologies is increasingly contingent on the development situation, and attempts to rigidly standardise practice are doomed to failure:

''The ...[problem] concerns difficulties relating to the consistency o f standards in organisations that adopt a contingency approach. Because o f the nature o f contingency approaches, information systems will he developed using different techniques and tools and in different ways, dependent on the particular situation. This does mean a loss o f common standards to some extent and this is one o f the practical benefits that the use o f an information systems development

methodology is supposed to provide. " p. 109 (Avison & Wood-Harper, 1991). Section 2.3 illustrated some of the major deterministic influences on the growth and development in information systems methodology usage. This section vdll be concluded with an illustration of the major changes this has brought about in the information systems methodology field.

An issue that has been re-iterated within this chapter is that the proliferation and differentiation o f methods and methodologies is exactly what would be predicted given the increasing size and complexities o f new technologies, and the pressure for more effective processes and systems (Maclaren et ah, 1991). Three overlapping determinants for customisation of methodologies have been identified; the methodology itself and the values it incorporates, the organisation and the degree o f rigidity in its structure and the uncertainty of its processes, and finally, the situation; which details the type o f system being developed, our understanding of it and our knowledge o f suitable definitions. Figure 2.6 shows our modef ‘ of these three factors.

Organisation M ethodology Values Context/ Communicath Hierarchic; Technical Social Uncertain Problem Situation

Figure 2.6: Determinants of Methodology customisation

Figure 2.6 shows that when the values of a methodology, the culture o f an organisation and the situational context are all in alignment, then the extent of customisation required is negligible. If not, then the development group will develop a strategy that interprets a methodology in a particular way, and this is something that Figure 2.7 hints at. This research project aims to identify some o f the determinants and relationships between the three elements o f methodology customisation.

" A vison & W ood-H arper (1991) produce a sim ilar model - with the three entities being m ethodology, situation and analyst/user group. Their definition o f situation subsum es inform ation about the

2 .6 T h e Role of Process in the Fram ew ork

In section 1.3, the importance of the concept o f process within this research study was highlighted. The role of process within the conceptual framework is to highlight how the

formal process embodied by a methodology is combined with other major factors, like the characteristics o f the host organisation and situation, in order to reflect the types of pressures for methodology customisation, if any, that a project is under. The concept o f ‘strategy’ becomes crucial as a label for these resultant processes. The conceptual framework needs to reference different types o f processes in order to reflect the relative influence of methodology and other factors. This requires efforts to categorise different types o f strategy or process, and is an issue covered in section 6.6.

2 .7 R esearch Issues

Figure 2.7 illustrates the fact that the interpretation of a methodology is dependent on a number of factors. Identifying some of these factors is part of the problem that this research study seeks to tackle, and Figure 2.6 helps to point this research in the right direction.

D eterministic Factors

' M ethodology

Figure 2.7: Strategy as an interpretation of methodology

A number of research issues need to be raised in order to make sure that the research does produce interesting, informative and valid results. Critical evaluation of approaches

organisational context. My definition o f situation includes user/analyst experience and know ledge, w hich they define as a separate section.

to development of suitable strategies need to be produced, and these will be covered in the next chapter. There is also the need to show that a disciplined approach to developing research material has been followed; this research is of little consequence if the results cannot be reproduced or verified. Chapter 4 lists the research method followed.

The final issue to be dealt with concerns the reasons why similar research studies have not been carried out in the past. As Chapter 1 argues, this is partly due to the lack of empirical evidence (provided through case studies) of methodology use. The second problem concerns the difficulties in giving guidance on methodology customisation. For the rationalistic school, customisation of methodologies provided a threat to the consistency and standardisation of practice with methodologies. They also threatened the rigid structure of a methodology (as illustrated in Figure 2.1). Techniques used by structured methodologies are highly coupled - that is, the results from the use of one technique would feed into the use of another. Allowing a methodology to be customised, either by the choice of new tools or the addition or deletion of stages would threaten the linear transformation of design information. Only recently have limited attempts been made to give guidance on the customisation of structured methodologies; with SSADM users being the first beneficiaries (CCTA, 1994).

In the reflective schools, the customisation of methodologies is often seen as necessary, but authors shy away from being too prescriptive about the choices or criterion that need to be considered. In their promotion of participative approaches to design in the book Design in Action\ Greenbaum & Kyng (1993) explain their reservations about giving guidance on tool usage:

While we didn’t intend to write a ‘how to ’ book, we are sometimes frustrated by the fact that in this volume we have given you a fair number o f examples o f what we did, with very little guidance on how we did it. In earlier drafts, in fact, most authors wrote about what they did and gave suggestions fo r doing it. But we found that this approach was too general, and that, fo r the most part, people reading the early drafts still felt confused about how to go out and do it. Indeed, i f we take our own writing seriously, we repeatedly point out that describing work practice is a difficult and risky venture and that choosing the language game to communicate it in is a matter between the users and designers themselves!’’ p.277

In conclusion, the reason why similar work has not been carried out is because it is unreasonable to expect either school to compromise their core values.

2.8 Summary

This chapter has explored some of the reasons for the fundamental philosophical differences between schools of thought on methodology and highlighted the defining characteristics of each. Technical innovation in the ways in which IT can be utilised was highlighted as a major driving force in methodology development, and organisational learning strategies have been identified as an important factor in methodology adoption. Finally, some of the key issues in interpretation of practice were highlighted.

One of the main results of this review is to reveal the complexity of the original description of the problem, as described in Figure 1.1, even further. While Figure 1.1 gave the impression that the link between practice and theory was a closed loop, a number of other influencing factors are now evident, as Figure 2.8 illustrates.

Changes in the tasks to which IT is applied Changes in Technology f P r a c tic e Changes in organisational behaviours Influences from other disciplines

Theory Technocratic_Idealism

Libertarian Idealism

Figure 2.8: Factors Influencing Practice and Theory of System Development

The problems in addressing the deterministic factors affecting methodology interpretation are the clear research issue in this instance:

“Ways need to be found to help the analyst to make educated but practical choices on how to fit a method to the specific demands o f each project. I f the contribution o f a method to the end result can be understood, then it may be possible to ensure that the qualities desired in the end result can be specified to

help the analyst plan their workl^ p.318 (Hughes & Reviron, 1996)

The loop between practice and theory illustrated in Figure 2.8 is further complicated by the fact that there is a time-lag between the two poles. Fitzgerald (1996) suggests that we are using theoretical approaches to development that reflect an image of development problems and practice ten years ago. The danger here is that the concept of ISM theory may be abandoned altogether, as developers work around problems they have without resorting to finding solutions in research. If the gap between practice and theory is to be managed, this problem needs to be dealt with. Change needs to be made to peoples skills and attitudes. As Eva & Guilford (1996) note, the viewpoints and expectations of those