ied classification avison & taylor

Introduction

Avison and Fitzgerald (1995) de® ned an informationsystems development methodology as `a system ofprocedures, techniques, tools and documentation aids,usually based on some philosophical view, which helpthe system developers in their efforts to implement a new information system’ (abridged from p. 10). Many different development methodologies exist andBubenko (1986) suggested that there are hundreds.Nevertheless, Structural Systems Analysis and DesignMethodology (SSADM) (now version 4) has beenselected as the mandatory methodology for UKGovernment projects since 1981 (Ashworth andGoodland, 1990). Despite the many methodologiesexisting, on the one hand and the SSADM `UK stan-dard’ , on the other, many information systems aredeveloped without the use of a standard informationsystems development methodology. This is due in partto the inappropriateness of some methodologies insome situations so that, even in one organization, astandard’ approach may not be used in all situations.The ® rst purpose of this paper is to identify types ofsituation and to match these types of situation withinformation systems development approaches.

The conventional way of classifying informationsystems development approaches is according to themeor by way of a feature analysis. Thus, Wood-Harper and Fitzgerald (1982) described six main themes:

traditional, general systems, human activity systems,participative, structural and data. Avison and Fitzgerald(1988) suggested that it is unrealistic to include generalsystems theory as an approach (although it has beenin¯ uential), but added planning and prototyping to thelist of themes. Maddison (1983), Fitzgerald et al. (1985)and Olle et al. (1991) classi® ed information systemsdevelopment approaches according to their features,including the stages of the life cycle that they encom-pass, deliverables and the techniques used.

For most practical purposes, however, the problemfor practitioners is about which methodology or combi-nation of methodologies to use in particular problemsituations. The classi® cations mentioned above do not help much in these decisions. An attempt is made in this paper to classify information systemsdevelopment approaches according to the characteris-tics of the problem situations to which they are mostapplicable.

Classifying information systems development methodologies

In this section, a classi® cation for information systemsdevelopment methodologies is suggested. Four classesare suggested to re¯ ect four different types of problemsituation. However, a ® fth class is later proposed whichre¯ ects `complex problem situations’ .

Journal of Information Technology (1997) 12, 73± 81

Information systems development methodologies:a classi® cation according to problem situationD.E. AVISONSchool of Management, Southampton University, Southampton SO17 1BJ, UK

V. TAYLOROrdnance Survey, RomseyRoad, Southampton SO16 4GU, UK

Information systems development methodologies are frequently classi® ed according to themes or features.Yet potential users are more concerned with the situations in which different approaches are appropriate.In this paper, ® ve problem situation types are identi® ed: (1) well-structured problem situations with a well-de® ned problem and clear requirements, (2) well-structured problem situations with clear objectives butuncertain user requirements, (3) unstructured problem situations with unclear objectives, (4) situations wherethere is a high user interaction with the system and (5) complex problem situations. Typical informationsystems development methodologies are placed in each of these groups. Some strengths and weaknesses ofthis classi® cation are discussed. One conclusion is that most projects will fall within the category of complexproblem situations, for organizations (and therefore their information systems needs) are invariably complexin terms of the human and social aspects at least as much as any technological ones. The Multiview approachis discussed in more detail because the authors claim it is suitable for such situations.

The classi® cation divides the methodologies intofour main types for four different problem situationsas follows.

(1) Class 1. Well-structured problem situations with a well-de® ned problem and clear require-ments. The appropriate methodologies for thesesituations include methodologies based on thetraditional systems development life cycle(SDLC), frequently referred to as the waterfallmodel.

(2) Class 2. Well-structured problem situations withclear objectives but uncertain user requirements.Methodologies such as those based on datamodelling, process modelling or prototyping arelikely to be appropriate in these situations.

(3) Class 3. Unstructured problem situations withunclear objectives. Soft systems approaches, inwhich the perspectives of those involved arestressed, are likely to be appropriate in thesesituations.

(4) Class 4. Situations where there is a high userinteraction with the system. These situationsrequire approaches that stress the needs of thepeople who will interact with the system.Sociotechnical approaches will be most appro-priate in these situations.

We will look at each of these classes in more detailin this paper, along with a brief description of thoseapproaches appropriate to each situation. Of course,as with any classi® cation, some methodologies cannotbe neatly ® tted into one of the classes given above.For example, prototyping has been included as suit-able for the class of problems with clear objectives butuncertain requirements. This is the right classi® cationfor prototyping in its purist form. However, it has alsobeen argued that prototyping could be used duringcertain stages of the traditional SDLC (Dearnley andMayhew, 1983). It may also be a useful tool to usealongside participative methodologies.

Many problem situations will have characteristics oftwo or more of the classes above and will thereforerequire parts of several methodologies to be used. Asthis is often the case in systems development, someauthors have suggested a contingency approach wherea framework for choosing the methodologies and/ortools and techniques is suggested. For this reason weadd a ® fth class of methodologies of informationsystems development to be used in situations asfollows.

(5) Class 5. Complex problem situations, com-bining two or more of classes 1± 4, requiring acontingency approach to information systemsdevelopment.

Class 1: methodologies applicable to well-

de® ned, well-structured problem situations with

clear objectives

Tradition information systems development method-ologies, often described as `hard’ approaches, attemptto ® nd the `best’ solution for a clearly de® ned problem.The earliest computer system development method-ologies fall into this category. The traditional systemdevelopment life cycle approach, for example that ofthe National Computing Centre in the UK (Danielsand Yeates, 1971), is typical of these approaches andhas the following steps: feasibility study, systems inves-tigation, systems analysis, systems design, implemen-tation and review and maintenance.

Such approaches have proved useful for well-structured problem situations with clear objectives.Typically this has involved `computerizing’ manual systems or recomputerizing’ operational computerapplications where radical changes are not desired. Theapproach tends to be limited to routine operationalproblem situations and is much less suitable for sup-porting management decision making. The approachmodels processes and is therefore applicable only to situations where these processes are fairly stable. Suchsystems tend to be developed by data-processing peoplein larger organizations or consultants, perhaps using offthe shelf’ packages on microcomputers, in smallerorganizations or departments within larger organiza-tions. The requirements need to be well known andunderstood and easily communicated. Users are onlygiven a limited say in the decision making and analystsare not expected to question why a system should bedeveloped or its objectives as the new computer systemis expected to re¯ ect the status quo.

Class 2: methodologies applicable to well-

structured problem situations with clear

objectives but uncertain user requirements

This class of approaches attempts to resolve some ofthe limitations of the traditional approach and thereforeis more appropriate to many of the problem situationsfound today. There are also `hard’ approaches, in thatstress is placed on the technical aspects of informationsystems, but no assumption is made that the require-ments are straightforward and easy to communicate to system developers. This opens up the possibility ofmore ambitious computer applications than thosefeasible using the approaches of class 1.

The methodologies in this class may be divided intofour groups. These are structured methodologies suchas STRADIS ± Structured Analysis and Design ofInformation Systems (Gane and Sarson, 1979) andYSM (Yourdon, 1989), data analysis methodologies,

74 Avison and Taylor

such as information engineering (Martin, 1989) or theapproach found in Avison (1992), blends of the twosuch as MerISE (Quang and Chartier-Kastler, 1991)and SSADM (Ashworth and Goodland, 1990) and,® nally, prototyping (for example, Martin, 1991).Dearnley and Mayhew (1983) discussed prototypingas part of the SDLC and Schoval and Pliskin (1988)described prototyping in the context of structuredmethodologies.

Structured methodologies stress the tasks that needto be performed in order to achieve a given objective.They make use of diagrammatic techniques such asdata ¯ ow diagrams, decision tables and decision trees.Along with structured walk-throughs, these techniqueshelp to improve the understanding of the requirementsby providing better communications with users and toverify the analysts’ understanding of the needs of theusers. Yourdon (1988) suggested that a well-structuredapproach to documenting someone’ s thoughts about aproblem or a situation can aid both that person’ sthinking and his or her ability to convey this under-standing to others. Daniels and Yeates (1988) statedthat the aims of structured analysis are to involve theuser more in the speci® cation of the problem and tocarry out the analysis and to present the results in aclearer and more formal way. Structured approachesare suitable to the group of problem situations in class2 where the processes that the system is to performare fairly stable.

Where the processes that the system is to perform areless stable, data analysis approaches may be more appro-priate. These approaches emphasize data modellingrather than process modelling. Their proponents arguethat even if the applications change, the fundamentalbuilding blocks of the data will still be appropriate. Themain technique used is entity-relationship modelling(Chen, 1976). The data model is useful as it gives aframework from which to develop systems and results inan understanding of the data attributes, the entities andthe relationships between the entities. A data modellingmethodology (Systems Documentation) aims to build aconceptual data model to determine and specify therequirements of the information system. More roundeddata approaches are to be found in Avison (1992) andMacdonald (1986). Although there are strong advocatesof the data approach, Benyon and Skidmore (1987)pointed out that the emphasis on data and the rigour ofits techniques can lead to the development of neat tech-nical systems that ignore or contradict the politicalreality. In other words, in the context of this paper, theymay be suitable for well-structured problem situationswith clear objectives but uncertain user requirements.However, where there is a high degree of con¯ ict, theapproach may be less suitable and the approaches foundunder classes 3, 4 and 5 may be more applicable.

Some methodologies that fall into this generalcategory, such as SSADM and MerISE, are a mixture ofstructured and data analysis approaches. This wouldseem to be a natural progression as systems developerssee the need for both process and data modelling andalso see the usefulness of the techniques of bothapproaches, such as data-¯ ow diagrams and entity-relationship diagrams, respectively. Many informationsystems development methodologies started as `pure’data modelling or process modelling approaches, but have developed to a more blended approach as they ® lled the gaps’ noticed by systems developers and users alike. SSADM developed in this fashion,though its original emphasis is data oriented. It has three views: logical data structures (entity-relationshipdiagrams), data-¯ ow diagrams and entity life histories,which show how entities change over time (and to someextent combine a data and process diagram in one).MerISE, on the other hand, set out as a combination ofthe data-oriented and process-oriented approaches andthe separate treatment of data and processes is equallythorough and as the data view is modelled on threestages from conceptual and logical through to physical,so is the equivalent process-oriented view. However,although such blended approaches combine the advan-tages of the two underlining themes, they do not addresssome basic situations, in particular, those where there isa high degree of con¯ ict.

The ® nal group of approaches relevant to situationswhere requirements are unclear is prototyping. This isa strategy for determining requirements wherein theuser needs are extracted, presented and developed bybuilding a working model of the ultimate system ±quickly and within context (Boar, 1984). From rudi-mentary statements of requirements, a simple systemmay be built using such tools as CASE (ComputerAssisted Systems Engineering), fourth generationsystems and the like. Users can learn what is the poten-tial of the system to be designed, the analysts can learnwhat are the users’ needs and management, users andanalysts together can become clearer about what arethe system requirements. This process of developingthe prototype is usually made iteratively. Once all thesestakeholders are `happy’ with the system, the proto-type `becomes’ the operational system. Prototypingfacilitates experimenting with the user, but not at the expense of the user (Avison and Wilson, 1991).However, a survey of developers and users byMahmood (1987) suggested that improved communi-cation between the developers and Myers (1988),among many others, emphasized the use of prototypingfor user interface design. This may suggest incorpo-rating prototyping into the SDLC or other approachesas an improved way of systems investigation, ratherthan viewing prototyping as a systems development

Information system development methodologies 75

approach in its own right. Where the problem is wellstructured, the objectives and requirements fairly clearand the environment stable, prototyping within theSDLC can ensure that the exact requirements aredetailed and various design options tried. How-ever, `pure’ prototyping is a useful methodology whenuser requirements are unclear, the project is small and conventional systems development is likely to taketoo long.

Class 3: methodologies applicable to

unstructured problem situations where the

objectives are unclear

The two classes of situation discussed above call for`hard’ methodologies. In many situations where infor-mation systems are to be developed, the objectives of thesystem may be unclear or may be clear to some individ-uals or groups but con¯ ict with the objectives of others.In such situations soft’ approaches are more appro-priate as they do not assume an agreed objective nor thatan `optimal’ solution may be found. The most wellknown is Checkland’s soft systems methodology (SSM)(Checkland and Scholes, 1990) which is expressed in aninformation systems context in Wilson (1990). In manymanagerial situations, the questions what are the objec-tives?’ and what are we trying to achieve?’ are part of theproblem. Checkland recognized that human activitysystems only exist in the minds of individuals and there-fore the perspective (Weltanschauung) of a particularindividual will affect his or her view of the problemsituation and system objectives.

Through the development of a rich picture, possiblyexpressed in a rich-picture diagram (Avison et al.,1992), an attempt is made to model all the aspects of theproblem situation including issues, problems, con¯ ictsand so on. Such a process will not resolve the con¯ ict,but aims to identify it. When formulating the root de® -nition, which is used to identify problems and systemsand building conceptual models, which show theminimum activities required by the system described bythe root de® nition, we can compare the real world andthis systems world, identifying feasible and desirablechanges and suggesting potential action to improve the problem situation. The analysis and subsequentunderstanding of the problem situation leads to thisimprovement. In the context of this paper, such actioncould be the development of information systems.

Class 4: methodologies applicable to situations

where there is a high user interaction with the

system and/or user acceptance is important

Many potential information systems will involve manyusers who will be greatly affected by the new system.

In such circumstances, technically viable systems canfail because of `people problems’ . ETHICS ± EffectiveTechnical and Human Implementation & Computer-based Systems (Mumford, 1995) is one methodologywhich encourages user involvement. If users areinvolved in the decision making related to the newproject, then they are more likely to be committed toit. As Land and Hirschheim (1983) argued, althoughinformation systems are usually seen as technicalsystems which have behavioural and social conse-quences, they are really social systems which rely toan increasing extent on information technology.Through participation, (1) the interests of the indi-viduals using the system are protected, (2) individualscan use the systems as a basis for the redesign of theirjobs and working environment, (3) they are more likelyto support the system, motivating them, leading tohigher productivity and (4) the various skills andknowledge of people to be incorporated into the systemis enabled.

ETHICS is based on the sociotechnical view that,to be effective, information systems must ® t closelywith both the social and technical factors. Theapproach concentrates on providing tools for partici-pative analysis and objective setting, leaving the moretechnical work of design to computer professionals (the`facilitators’ ). Alternative participative approachesinclude sociotechnical systems (STS) (Paddock, 1986)and information systems work and analysis of change(ISAC) (Lundeberg, 1982).

Participative approaches may not work in situationswhere people do not wish to participate or in coercivesituations where the objectives of the system includethe reduction of costs and redundancies (Mumford,1995). The ease with which participation may beaccomplished will be dependent on the culture andpolitics of the organization as well as the individualsthemselves (see also Avison and Myers, 1995). It willbe more dif® cult to obtain true participation betweendifferent users at different levels of a bureaucratic hier-archical organization where people are very consciousof their position or grade and power than more organicorganizations where these are much less explicit.However, many organizations are attempting to moveaway from bureaucratic structures so as to make themmore ¯ exible and, therefore, participative approachesmay become more widespread.

Problems with single situation approaches

Many authors have suggested, as we do in this paper,that there is no best methodology for all situations(Jackson and Keys, 1984; Avison and Wood-Harper,1991). It would seem dif® cult, if not impossible, for


example, to design an appropriate system using a `hard’approach when the problem is ill-de® ned or use aparticipative approach in cohersive situations. Davis(1982) suggested that a methodology should be chosendepending on the particular characteristics of thesystems development project. Episkopou and Wood-Harper (1986) also suggested that a suitable approachshould be determined by examining certain variablesin and around the problem situation. They devised aframework to select an approach based, in the main,on assessing the characteristics of the problem solverand problem owner.

The classi® cation of methodologies in this papercould be used to help in the process of choosing amethodology. However, there are problems associatedwith using certain characteristics of the problem tochoose an appropriate methodology. For example,many problem situations and information systemsdevelopment projects are multifaceted, suggesting that methodologies in more than one class would beappropriate. Furthermore projects take on differentcharacteristics as they progress. A project may be ill-structured at the outset, demanding softer techniques,but a well-structured objective set and requirementsde® nition may result, at which time harder techniqueswill be appropriate. One view, therefore, is thatdifferent methodologies are complementary. However,analysts may not know a number of methodologiessuf® ciently well to choose and use the `appropriate’ones as the situation merits. For this reason, a singlecontingency approach may be the most useful in morecomplex situations.

Class 5: complex problem situations requiring a

contingency approach to information systems

development

Re¯ ecting on the classi® cation given, many readersmight argue that most information systems develop-ment projects will fall within class 5. Of course this mayre¯ ect the bias of the author or the roughness of theclassi® cation itself. There certainly needs to be furtherwork on the classi® cations of problem situations ratherthan the methodology themes or features. But, as Avisonet al. (1988, p. 379) argued `Every situation is differentand the analyst should have the opportunity to exploreand create a unique method for each situation.’ We willtherefore discuss Multiview, which provides a frame-work for developing information systems. It has beendesigned for such complex problem situations.

A contingency approach, such as Multiview, is more appropriate than one where analysts choose amethodology from the number available (Davis, 1982),for reasons given above, or one where analysts choosetools and techniques from a tool box’ (Benyon and

Skidmore, 1987). The latter approach lacks a guidingframework, documentation and other standards.Although it could be argued that very skilled analystsmay successfully employ such an approach, this isnormally not appropriate because of a fear that suchskilled staff would be dif® cult to control, a lack of suchskilled staff being available and dif® culties concerningcontracts and compliance with quality standards. Themethod engineering movement (see, for example,Brinkkemper et al., 1996), which does suggest usingtechniques, such as entity-relationship modelling andtools, in particular CASE tools, according to situation,might also be deemed inappropriate because of itslargely technological viewpoint. Complex situations are usually so because of the mix of human, social andorganizational complexity, as well as technical dif® culty.

Avison and Wood-Harper (1986) described Multi-view as an exploration in information systems develop-ment. Multiview provides a framework guiding analystsin their choice of techniques and tools in any particularproblem situation and also recommends documentationand other standards, these being one of the main forcesfor using an information systems development method-ology in the ® rst place. There are many situations inwhich Multiview has been used successfully.

Multiview (Avison and Wood-Harper, 1990, 1991)is a ¯ exible framework where the techniques and toolsare chosen according to the particular problem situa-tion and the stage in the development of the infor-mation system. In the original de® nition, it has ® vephases (see Figure 1): (1) analysis of the human activitysystem, (2) analysis of the information (entities andfunctions), (3) analysis and design of the sociotech-nical system, (4) design of the human± computer inter-face and (5) design of the technical aspects.

The approach is described in full in Avison andWood-Harper (1990), but suf® ce it to say in thecontext of this paper that stage 1 is heavily in¯ uencedby the work of Checkland (class 3 above), stage 2 by


1 Human-Activity2 Information

3Socio-Technical

4H

uman

-Computer Interf ac

e

5 Technical

Q1–How is the information Systemsupposed to futher the aims of the organisation using it?Q2–How can it be fitted into the working lives of the people in the organisation using it?Q3–How can the individuals concearned best relate to the compuin terms of operating it and using the output from it?Q4 –What information processing function is the system to perform?Q5–What is the technical specificatioof a system that will come close enouto meeting the identified requirement

Figure 1 The Multiview1 framework

the methodologies described in class 2 of this paper,stage 3 by Mumford, described in their latest versionsin Checkland and Scholes (1990) and Mumford(1995), (class 4 above) and stage 5 by those itemsoutlined in classes 1 and 2 above.

The authors argue that to be complete in human aswell as in technical terms, the methodology mustprovide help in answering the following questions.

(1) How is the computer system supposed to furtherthe aims of the organization installing it?

(2) How can it be ® tted into the working lives ofthe people in the organization that are going touse it?

(3) How can the individuals concerned best relateto the machine in terms of operating it andusing the output from it?

(4) What information system processing function isthe system to perform?

(5) What is the technical speci® cation of a systemthat will come close enough to doing the thingsthat have been written down in the answers tothe other four questions?

These questions would seem to cover complex situ-ations. Whereas a strategic approach (for example,Business Systems Planning) might address question 1,participative approaches, such as ETHICS (Mumford,1995), might address questions 2 and 3, a prototypingapproach, such as rapid applications development(Martin, 1991) might address questions 3 and 4 andthe conventional and structured approaches, such asSSADM (Ashworth and Goodland, 1990) addressquestions 4 and 5, Multiview attempts to address allthese questions and to involve all the role players orstakeholders in answering these questions.

Although we have stated that phases might be omit-ted or reduced in scope or executed in a differentsequence, the description of Multiview is in terms of thelayers in an onion’ (as in Figure 1) or as a series of ® vebroad steps. However, this is described as an ideal type’which will guide the analyst who will redesign it for anypractical situation. Although Avison and Wood-Harper(1990) argued that the waterfall model is inappropri-ate’ (p. 265), the earlier description in the book givesthe impression of a waterfall model, despite furtherdenials from the methodology authors using Multiviewin practice. This led to dif® culties where, for example,users required further explanation on how to go fromstage 1 (essentially a description of the problem situa-tion using SSM rich pictures, root de® nitions and con-ceptual models) to stage 2 (a combination of the datamodelling used in information engineering and theprocess modelling used in STRADIS). A further re® n-ing of Multiview has led to another de® nition and thisis described in the next section. It is more explicitly an

antithesis of the waterfall model and explicit in address-ing class 5 problem situations.

The development of Multiview

In Multiview2 (Avison et al., in press), the ® ve stageshave been reduced to a four-box structure of organi-zational analysis, information analysis and modelling,


Organisationalanallysis

Informationanalysis &modelling

Socio-technicalanalysis & design

Technical designand construction

Informationsystemsdevelopment

Figure 2 The Multiview framework (version 2)

Figure 3 Constructing the information systems develop-ment methodology (adapted from Checkland and Scholes,1990, Wood-Harper and Avison, 1990, and Avison andWood-Harper, 1995)

Organisationalanallysis

Informationmodelling

Socio-technicalanalysis & design

Technical designand construction

Analyst

Situation

Perceived world

Methodology

Contingent socially-constructed ISD method

LOGIC-BASEDSTREAM OF ANALYSIS

STREAM OF CULTURALANALYSIS

Reflecting andmodifying (method must besystemically desirableand culturally feasible)

CULTURE

HistoryWould-bedevelopersof an IS

Issues, needsand expectations

Analysis of :1. Intervention2. Social context3. Political aspects

sociotechnical analysis and design, and technical designand construction. This proposed new framework forMultiview is given in Figure 2 and it shows the fourparts of the methodology mediated through the actualprocess of information systems development. The fourparts of human activity systems analysis or organiza-tional analysis (which examines organizational behav-iours), sociotechnical systems analysis and design(which examines work systems) and technical designand construction (which examines technical artefacts)are integrated through the information analysis andmodelling stage which acts as a bridge between theother three, communicating and enacting the outcomesin terms of each other. In this way Multiview offers an exploratory though perhaps not systematic guide toany information systems development intervention,together with a re¯ exive, learning methodologicalprocess. The emphasis placed on each of the four partsof Multiview will change as the information system isbeing developed and is contingent on the particularsituation.

There are also differences in the details between thetwo versions of Multiview which re¯ ect publishedresearch over the intervening years and, more impor-tantly, experience in using Multiview during thisperiod. Thus, for example, (1) stakeholder analysisstrengthens the conceptual analysis of SSM and ethicalanalysis in organizational analysis, (2) there is a migra-tion from structured methods to object-orientedanalysis in formation analysis and modelling, (3) ethno-graphic approaches supplement the tenets of ETHICSin sociotechnical systems analysis and design and (4)prototyping, CASE, evolutionary and rapid develop-ment approaches are more strongly suggested in tech-nical design and construction.

However, although the authors recommend a contin-gent approach to information systems development,Multiview2 should not be used to justify random oruncontrolled development. The terms `methodology’and `method’ tend to be used interchangeably,although they can be distinguished insofar as a methodis a concrete procedure for getting something donewhile a methodology is a higher-level construct whichprovides a rationale for choosing between differentmethods (Oliga, 1988). In this sense, an informationsystems methodology, such as Multiview2, provides abasis for constructing a situation-speci® c method(Figure 3), which arises from a genuine engagementof the analyst with the problem situation (Wastell,1996).

This paper should not be interpreted as suggestingthat a contingency approach such as Multiview is theanswer to all problem situations. In any case,Multiview is not a simple approach for a complex situ-ation. The analyst has to decide on the emphasis to

place on each of the major aspects shown in Figure 2and when to give them particular emphasis. There isa major learning process for the analyst in having tochoose between techniques and tools. There are alsoproblems of quality, control and planning when usinga contingency approach.

Nevertheless, Multiview may be considered for usein complex unstructured information system develop-ment projects involving many users as, in such cases,the investigation needs soft analysis. Hard structuredtechniques, such as process and data modelling, willalso be required. Furthermore, the balance betweenthe social and technical designs in Multiview is likelyto give the correct emphasis in such projects.

Conclusions

Systems analysts need to identify the basic character-istics of the environment in which they are to developan information system and choose a methodology orcontingency approach for the development of thatparticular system. To facilitate this process, ® veproblem situation types have been identi® ed: (1) well-structured problem situations with a well-de® nedproblem and clear requirements, (2) well-structuredproblem situations with clear objectives but uncertainuser requirements, (3) unstructured problem situationswith unclear objectives, (4) situations where there is ahigh user interaction with the system and (5) complexproblem situations, combining two or more of classes1± 4.

Many if not most situations in organizations arelikely to be closer to the class 5 complex problem situ-ations than the others and a rede® nition of Multiviewis proposed as being particularly appropriate for suchsituations because of its broad scope and contingency`philosophy’ .

This attempt at a classi® cation is rudimentary atpresent. Some methodologies or problem situationsmay ® t into more than one category of the classi® ca-tion; only a limited number of problem situation char-acteristics have been included and many features ofproblem situations that may be important to themethodology choice have not been included in the clas-si® cation. One major omission, for example, is theculture of the organization and this may greatly in¯ u-ence the effectiveness of an approach in a particularsituation. People have different cognitive styles and asa result may work more effectively with some method-ologies than others. Other characteristics of theproblem situation, such as the development time scaleand constraints on the way development can take place,may also be important factors in in¯ uencing themethodology choice.


We are therefore aware of the dangers of beingsimplistic, both in our judgements of the different typesof problem situation and the appropriate methodolo-gies for each type, but we believe that further researchinto different situation types and the appropriatenessof approaches for each of these types is particularlyrelevant to the real situation confronted by systemsanalysts and groups of users as they search for anappropriate approach for their particular problem situation.

Acknowledgements

I wish to thank Richard Vidgen, Bob Wood and inparticular Trevor Wood-Harper who are working withme on a new de® nition of Multiview.

References

Ashworth, C. and Goodland, M. (1990) SSADM: A Practical

Approach (McGraw Hill, Maidenhead).Avison, D.E. (1992) Information Systems Development: A

Database Approach, 2nd edn (McGraw-Hill, Maiden-head).

Avison, D.E. and Fitzgerald, G. (1988) Information systemsdevelopment: current themes and future directions.Information and Software Technology, 30, 458± 466.

Avison, D.E. and Fitzgerald, G. (1995) Information Systems

Development: Methodologies, Techniques and Tools, 2ndedn (McGraw-Hill, Maidenhead).

Avison, D.E. and Myers, M. (1995) Information systemsand anthropology: an anthropological perspective on ITand organizational culture. Information Technology &People, 8, 43± 56.

Avison, D.E. and Wilson, D. (1991) Controls for effectiveprototyping. Journal of Management Systems, SA± 58,41± 53.

Avison, D.E. and Wood-Harper, A.T. (1990) Multiview: AnExploration in Information Systems Development (McGraw-Hill, Maidenhead).

Avison, D.E. and Wood-Harper, A.T. (1991) Informationsystems development research: an exploration of ideasin practice. Computer Journal, 34, 98± 112.

Avison, D.E. and Wood-Harper, A.T. (1995) Experience ofusing Multiview: some re¯ ections, in Information Systems

Provision: The Contribution of Soft Systems Methodology,

Stowell, F.A. (ed.) (McGraw-Hill, Maidenhead) pp.102± 117.

Avison, D.E., Fitzgerald, G. and Wood-Harper, A.T. (1988)Information systems development: a tool-kit is notenough. Computer Journal, 31, 458± 466.

Avison, D.E., Golder, P.A. and Shah, H.U. (1992) An SSMtoolkit: rich picture diagramming. European Journal of

Information Systems, 1, 397± 407.Avison, D.E., Wood-Harper, A.T., Vidgen, R.T. and Wood,

J.R.G. (in press) Multiview: An Exploration in Informa-

tion Systems Development, 2nd edn (McGraw-Hill,Maidenhead).

Benyon, D. and Skidmore, S. (1987) Towards a tool-kit forthe systems analyst. Computer Journal, 30, 2± 7.

Boar, B.H. (1984) Application Prototyping: A Requirements

De® nition Strategy for the 80’ s (Wiley, New York).Brinkkemper, S., Lyytinen, K. and Welke, R.J. (eds) (1996)

Method Engineering: Principles of Method Construction and

Tool Support (Chapman & Hall, London).Bubenko, J.A., Jr, (1986) Information system methodologies ±

a research view, in Information Systems Design Metho-

dologies: Improving the Practice, Olle, T.W., Sol, H.G. andVerrijn-Stuart, A.A. (eds) (North Holland, Amsterdam).

Checkland, P.B. and Scholes, J. (1990) Soft Systems

Methodology in Action (John Wiley, Chichester).Chen, P.P.S. (1976) The entity-relationship model ± toward

a uni® ed view of data. ACM Transactions on Database

Systems, 1, 1.Daniels, A. and Yeates, D.A. (1971) Basic Training in Systems

Analysis, 2nd edn (Pitman, London).Daniels, A. and Yeates, D.A. (1988) Basic Systems Analysis

(Pitman, London).Davis, G.B. (1982) Strategies for information requirements

determination. IBM Systems Journal, 21, 4± 30.Dearnley, P.A. and Mayhew, P.J. (1983) In favour of system

prototypes and their integration into the systems devel-opment cycle. Computer Journal, 26, 36± 42.

Episkopou, D.M. and Wood-Harper, A.T. (1986) Towardsa framework to choose appropriate IS approaches.Computer Journal, 29, 222± 228.

Fitzgerald, G., Stokes, N. and Wood, J.R.G. (1985) Featureanalysis of contemporary information systems method-ologies. Computer Journal, 28, 223± 230.

Gane, C.P. and Sarson, T. (1979) Structured Systems

Analysis: Tools and Techniques (Prentice-Hall, EnglewoodCliffs, NJ).

IBM (1975) Business systems planning, in Advanged Systems

Development/Feasibility Techniques, Cougar, J.D., Cotter,M.A. and Knapp, R.W. (eds) (Wiley, New York) pp. 236± 314.

Jackson, M.C. and Keys, P. (1984) Towards a system of sys-tems methodologies. Journal of Operations Research, 35,473± 486.

Land, F.F. and Hirschheim, R. (1983) Participative systemsdesign: rationale, tools and techniques. Journal of Applied

Systems Analysis, 10, 91± 107.Lundeberg, M. (1982) The ISAC approach to speci® cation

in information systems and its application to the orga-nization of an IFIP working conference, in InformationSystems Design Methodologies: A Comparative Review,Olle, T.W. Sol, H.G. and Verrijn-Stuart, A.A. (eds)(North Holland, Amsterdam) pp.173± 234.

Macdonald, I.G. (1986) Information Engineering, inInformation Systems Design Methodologies: A Comparative

Review, Olle, T.W., Sol, H.G. and Verrijn-Stuart, A.A.(eds) (North Holland, Amsterdam).

Maddison, R.N. (ed.) (1983) Information System

Methodologies (Wiley, Heyden).Mahmood, M.A. (1987) Systems development methods ± a

comparative investigation. MIS Quarterly, 11, 293± 311.


Martin, J. (1989) Information Engineering: A Trilogy (Prentice-Hall, Englewood Cliffs, NJ).

Martin, J. (1991) Rapid Application Development (Prentice-Hall, Englewood Cliffs, NJ).

Mumford, E. (1995) Effective Requirements Analysis and

Systems Design: The ETHICS Method (Macmillan,Basingstoke).

Myers, B.A. (1988) Creating User Interfaces by Demonstration

(Academic Press, New York).Oliga, J. (1988) Methodological foundations of systems

methodologies, in Critical Systems Thinking: Directed

Readings, Flood, R.L. and Jackson, M.C. (eds) (Wiley,Chichester).

Olle, T.W., Sol, H.G. and Verijn-Stuart, A.A. (eds) (1982)Information Systems Design Methodologies: A ComparativeReview (North Holland, Amsterdam).

Paddock, C.E. (1986) A critical view of factors affectingsuccessful application of normative socio-technicalsystems development approaches. Information and

Management, 10, 49± 57.Quang, P.T. and Chartier-Kastler, C. (1991) Merise in

Practice (Macmillan, Basingstoke) (translated by D.E.and M.A. Avison (1989) from the French MeriseAppliqu ‚ e (Eyrolles, Paris).

Schoval, P. and Pliskin, N. (1988) Structured prototyping:integrating prototyping into structural systems develop-ment. Information and Management, 14, 19± 30.

Wastell, D. (1996) The fetish of technique: methodology asa social defence. Information Systems Journal, 6, 1.

Wilson, B. (1990) Systems: Concepts, Methodologies and

Applications, 2nd edn (Wiley, Chichester) pp. 25± 40.Wilson, J. and Rosenberg, D. (1988) Rapid prototyping for

user interface design, in Handbook of Human± Computer

Interaction, Helender, M. (ed.) (North Holland,Amsterdam).

Wood-Harper, A.T. and Fitzgerald, G. (1982) A taxonomyof current approaches to systems analysis. ComputerJournal, 25, 12± 16.

Yourdon, E. (1988) Managing the Systems Life Cycle (PrenticeHall, Englewood Cliffs, NJ).

Yourdon, E. (1989) Modern Structured Analysis (PrenticeHall, Englewood Cliffs, NJ).

Biographical notes

David Avison is Professor of Information Systems andHead of the Department of Management atSouthampton University. He also has considerableexperience in information systems practice. He isPresident of the UK Academy of Information Systemsand Vice-chair of the International Federation ofInformation Processing (IFIP) working group 8.2.David is joint editor of the McGraw-Hill series of textsin information systems and is also joint editor ofBlackwell Scienti® c’ s Information Systems Journal nowin its seventh volume. He has published 16 books (plusone translation from the French) as well as a largenumber of papers in learned journals, edited texts andconference papers. He has given the plenary addressesat recent information systems conferences in TheNetherlands, Australia, Bahrain, the UK and the USA. His research areas include information systemsdevelopment and he is one of the co-authors of theMultiview methodology.

Vicky Taylor is Senior Policy Researcher at OrdnanceSurvey, Southampton. She did her MSc in ManagementScience at the University of Southampton and is agraduate member of the Institute of Personnel andDevelopment. Her main research interests are now inthe area of human resource policy and systems.

Address for correspondence: Department ofManagement, Southampton University, SouthamptonSO17 1BJ, UK.
