IED Classification Avison & Taylor

1. Journal of Information Technology (1997) 12, 73± 81
Information systems development methodologies:
a classi® cation according to problem situation
D.E. AVISON
School of Management, Southampton University, Southampton SO17 1BJ, UK
V. T AYLOR
Ordnance 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 but
uncertain user requirements, (3) unstructured problem situations with unclear objectives, (4) situations where
there is a high user interaction with the system and (5) complex problem situations. Typical information
systems development methodologies are placed in each of these groups. Some strengths and weaknesses of
this classi® cation are discussed. One conclusion is that most projects will fall within the category of complex
problem situations, for organizations (and therefore their information systems needs) are invariably complex
in terms of the human and social aspects at least as much as any technological ones. The Multiview approach
is discussed in more detail because the authors claim it is suitable for such situations.
Introduction traditional, general systems, human activity systems,
participative, structural and data. Avison and Fitzgerald
Avison and Fitzgerald (1995) de® ned an information (1988) suggested that it is unrealistic to include general
systems development methodology as `a system of systems theory as an approach (although it has been
procedures, techniques, tools and documentation aids, in¯ uential), but added planning and prototyping to the
usually based on some philosophical view, which help list of themes. Maddison (1983), Fitzgerald et al. (1985)
the system developers in their efforts to implement and Olle et al. (1991) classi® ed information systems
a new information system’ (abridged from p. 10). development approaches according to their features,
Many different development methodologies exist and including the stages of the life cycle that they encom-
Bubenko (1986) suggested that there are hundreds. pass, deliverables and the techniques used.
Nevertheless, Structural Systems Analysis and Design For most practical purposes, however, the problem
Methodology (SSADM) (now version 4) has been for practitioners is about which methodology or combi-
selected as the mandatory methodology for UK nation of methodologies to use in particular problem
Government projects since 1981 (Ashworth and situations. The classi® cations mentioned above do
Goodland, 1990). Despite the many methodologies not help much in these decisions. An attempt is
existing, on the one hand and the SSADM `UK stan- made in this paper to classify information systems
dard’ , on the other, many information systems are development approaches according to the characteris-
developed without the use of a standard information tics of the problem situations to which they are most
systems development methodology. This is due in part applicable.
to the inappropriateness of some methodologies in
some situations so that, even in one organization, a
`standard’ approach may not be used in all situations. Classifying information systems
The ® rst purpose of this paper is to identify types of development methodologies
situation and to match these types of situation with
information systems development approaches. In this section, a classi® cation for information systems
The conventional way of classifying information development methodologies is suggested. Four classes
systems development approaches is according to theme are suggested to re¯ ect four different types of problem
or by way of a feature analysis. Thus, Wood-Harper situation. However, a ® fth class is later proposed which
and Fitzgerald (1982) described six main themes: re¯ ects `complex problem situations’ .

2. 74 Avison and Taylor
The classi® cation divides the methodologies into Class 1: methodologies applicable to well-
four main types for four different problem situations de® ned, well-structured problem situations with
as follows. clear objectives
(1) Class 1. Well-structured problem situations Tradition information systems development method-
with a well-de® ned problem and clear require- ologies, often described as `hard’ approaches, attempt
ments. The appropriate methodologies for these to ® nd the `best’ solution for a clearly de® ned problem.
situations include methodologies based on the The earliest computer system development method-
traditional systems development life cycle ologies fall into this category. The traditional system
(SDLC), frequently referred to as the waterfall development life cycle approach, for example that of
model. the National Computing Centre in the UK (Daniels
(2) Class 2. Well-structured problem situations with and Yeates, 1971), is typical of these approaches and
clear objectives but uncertain user requirements. has the following steps: feasibility study, systems inves-
Methodologies such as those based on data tigation, systems analysis, systems design, implemen-
modelling, process modelling or prototyping are tation and review and maintenance.
likely to be appropriate in these situations. Such approaches have proved useful for well-
(3) Class 3. Unstructured problem situations with structured problem situations with clear objectives.
unclear objectives. Soft systems approaches, in Typically this has involved `computerizing’ manual
which the perspectives of those involved are systems or `recomputerizing’ operational computer
stressed, are likely to be appropriate in these applications where radical changes are not desired. The
situations. approach tends to be limited to routine operational
(4) Class 4. Situations where there is a high user problem situations and is much less suitable for sup-
interaction with the system. These situations porting management decision making. The approach
require approaches that stress the needs of the models processes and is therefore applicable only to
people who will interact with the system. situations where these processes are fairly stable. Such
Sociotechnical approaches will be most appro- systems tend to be developed by data-processing people
priate in these situations. in larger organizations or consultants, perhaps using `off
the shelf’ packages on microcomputers, in smaller
We will look at each of these classes in more detail organizations or departments within larger organiza-
in this paper, along with a brief description of those tions. The requirements need to be well known and
approaches appropriate to each situation. Of course, understood and easily communicated. Users are only
as with any classi® cation, some methodologies cannot given a limited say in the decision making and analysts
be neatly ® tted into one of the classes given above. are not expected to question why a system should be
For example, prototyping has been included as suit- developed or its objectives as the new computer system
able for the class of problems with clear objectives but is expected to re¯ ect the status quo.
uncertain requirements. This is the right classi® cation
for prototyping in its purist form. However, it has also
been argued that prototyping could be used during Class 2: methodologies applicable to well-
certain stages of the traditional SDLC (Dearnley and structured problem situations with clear
Mayhew, 1983). It may also be a useful tool to use objectives but uncertain user requirements
alongside participative methodologies.
Many problem situations will have characteristics of This class of approaches attempts to resolve some of
two or more of the classes above and will therefore the limitations of the traditional approach and therefore
require parts of several methodologies to be used. As is more appropriate to many of the problem situations
this is often the case in systems development, some found today. There are also `hard’ approaches, in that
authors have suggested a contingency approach where stress is placed on the technical aspects of information
a framework for choosing the methodologies and/or systems, but no assumption is made that the require-
tools and techniques is suggested. For this reason we ments are straightforward and easy to communicate
add a ® fth class of methodologies of information to system developers. This opens up the possibility of
systems development to be used in situations as more ambitious computer applications than those
follows. feasible using the approaches of class 1.
The methodologies in this class may be divided into
(5) Class 5. Complex problem situations, com- four groups. These are structured methodologies such
bining two or more of classes 1± 4, requiring a as STRADIS ± Structured Analysis and Design of
contingency approach to information systems Information Systems (Gane and Sarson, 1979) and
development. YSM (Yourdon, 1989), data analysis methodologies,

3. Information system development methodologies 75
such as information engineering (Martin, 1989) or the Some methodologies that fall into this general
approach found in Avison (1992), blends of the two category, such as SSADM and MerISE, are a mixture of
such as MerISE (Quang and Chartier-Kastler, 1991) structured and data analysis approaches. This would
and SSADM (Ashworth and Goodland, 1990) and, seem to be a natural progression as systems developers
® nally, prototyping (for example, Martin, 1991). see the need for both process and data modelling and
Dearnley and Mayhew (1983) discussed prototyping also see the usefulness of the techniques of both
as part of the SDLC and Schoval and Pliskin (1988) approaches, such as data-¯ ow diagrams and entity-
described prototyping in the context of structured relationship diagrams, respectively. Many information
methodologies. systems development methodologies started as `pure’
Structured methodologies stress the tasks that need data modelling or process modelling approaches,
to be performed in order to achieve a given objective. but have developed to a more blended approach as
They make use of diagrammatic techniques such as they `® lled the gaps’ noticed by systems developers
data ¯ ow diagrams, decision tables and decision trees. and users alike. SSADM developed in this fashion,
Along with structured walk-throughs, these techniques though its original emphasis is data oriented. It has
help to improve the understanding of the requirements three views: logical data structures (entity-relationship
by providing better communications with users and to diagrams), data-¯ ow diagrams and entity life histories,
verify the analysts’ understanding of the needs of the which show how entities change over time (and to some
users. Yourdon (1988) suggested that a well-structured extent combine a data and process diagram in one).
approach to documenting someone’ s thoughts about a MerISE, on the other hand, set out as a combination of
problem or a situation can aid both that person’ s the data-oriented and process-oriented approaches and
thinking and his or her ability to convey this under- the separate treatment of data and processes is equally
standing to others. Daniels and Yeates (1988) stated thorough and as the data view is modelled on three
that the aims of structured analysis are to involve the stages from conceptual and logical through to physical,
user more in the speci® cation of the problem and to so is the equivalent process-oriented view. However,
carry out the analysis and to present the results in a although such blended approaches combine the advan-
clearer and more formal way. Structured approaches tages of the two underlining themes, they do not address
are suitable to the group of problem situations in class some basic situations, in particular, those where there is
2 where the processes that the system is to perform a high degree of con¯ ict.
are fairly stable. The ® nal group of approaches relevant to situations
Where the processes that the system is to perform are where requirements are unclear is prototyping. This is
less stable, data analysis approaches may be more appro- a strategy for determining requirements wherein the
priate. These approaches emphasize data modelling user needs are extracted, presented and developed by
rather than process modelling. Their proponents argue building a working model of the ultimate system ±
that even if the applications change, the fundamental quickly and within context (Boar, 1984). From rudi-
building blocks of the data will still be appropriate. The mentary statements of requirements, a simple system
main technique used is entity-relationship modelling may be built using such tools as CASE (Computer
(Chen, 1976). The data model is useful as it gives a Assisted Systems Engineering), fourth generation
framework from which to develop systems and results in systems and the like. Users can learn what is the poten-
an understanding of the data attributes, the entities and tial of the system to be designed, the analysts can learn
the relationships between the entities. A data modelling what are the users’ needs and management, users and
methodology (Systems Documentation) aims to build a analysts together can become clearer about what are
conceptual data model to determine and specify the the system requirements. This process of developing
requirements of the information system. More rounded the prototype is usually made iteratively. Once all these
data approaches are to be found in Avison (1992) and stakeholders are `happy’ with the system, the proto-
Macdonald (1986). Although there are strong advocates type `becomes’ the operational system. Prototyping
of the data approach, Benyon and Skidmore (1987) facilitates experimenting with the user, but not at
pointed out that the emphasis on data and the rigour of the expense of the user (Avison and Wilson, 1991).
its techniques can lead to the development of neat tech- However, a survey of developers and users by
nical systems that ignore or contradict the political Mahmood (1987) suggested that improved communi-
reality. In other words, in the context of this paper, they cation between the developers and Myers (1988),
may be suitable for well-structured problem situations among many others, emphasized the use of prototyping
with clear objectives but uncertain user requirements. for user interface design. This may suggest incorpo-
However, where there is a high degree of con¯ ict, the rating prototyping into the SDLC or other approaches
approach may be less suitable and the approaches found as an improved way of systems investigation, rather
under classes 3, 4 and 5 may be more applicable. than viewing prototyping as a systems development

4. 76 Avison and Taylor
approach in its own right. Where the problem is well In such circumstances, technically viable systems can
structured, the objectives and requirements fairly clear fail because of `people problems’ . ETHICS ± Effective
and the environment stable, prototyping within the Technical and Human Implementation & Computer-
SDLC can ensure that the exact requirements are based Systems (Mumford, 1995) is one methodology
detailed and various design options tried. How- which encourages user involvement. If users are
ever, `pure’ prototyping is a useful methodology when involved in the decision making related to the new
user requirements are unclear, the project is small project, then they are more likely to be committed to
and conventional systems development is likely to take it. As Land and Hirschheim (1983) argued, although
too long. information systems are usually seen as technical
systems which have behavioural and social conse-
quences, they are really social systems which rely to
Class 3: methodologies applicable to
an increasing extent on information technology.
unstructured problem situations where the
Through participation, (1) the interests of the indi-
objectives are unclear
viduals using the system are protected, (2) individuals
The two classes of situation discussed above call for can use the systems as a basis for the redesign of their
`hard’ methodologies. In many situations where infor- jobs and working environment, (3) they are more likely
mation systems are to be developed, the objectives of the to support the system, motivating them, leading to
system may be unclear or may be clear to some individ- higher productivity and (4) the various skills and
uals or groups but con¯ ict with the objectives of others. knowledge of people to be incorporated into the system
In such situations `soft’ approaches are more appro- is enabled.
priate as they do not assume an agreed objective nor that ETHICS is based on the sociotechnical view that,
an `optimal’ solution may be found. The most well to be effective, information systems must ® t closely
known is Checkland’ s soft systems methodology (SSM) with both the social and technical factors. The
(Checkland and Scholes, 1990) which is expressed in an approach concentrates on providing tools for partici-
information systems context in Wilson (1990). In many pative analysis and objective setting, leaving the more
managerial situations, the questions `what are the objec- technical work of design to computer professionals (the
tives?’ and `what are we trying to achieve?’ are part of the `facilitators’ ). Alternative participative approaches
problem. Checkland recognized that human activity include sociotechnical systems (STS) (Paddock, 1986)
systems only exist in the minds of individuals and there- and information systems work and analysis of change
fore the perspective (Weltanschauung) of a particular (ISAC) (Lundeberg, 1982).
individual will affect his or her view of the problem Participative approaches may not work in situations
situation and system objectives. where people do not wish to participate or in coercive
Through the development of a rich picture, possibly situations where the objectives of the system include
expressed in a rich-picture diagram (Avison et al., the reduction of costs and redundancies (Mumford,
1992), an attempt is made to model all the aspects of the 1995). The ease with which participation may be
problem situation including issues, problems, con¯ icts accomplished will be dependent on the culture and
and so on. Such a process will not resolve the con¯ ict, politics of the organization as well as the individuals
but aims to identify it. When formulating the root de® - themselves (see also Avison and Myers, 1995). It will
nition, which is used to identify problems and systems be more dif® cult to obtain true participation between
and building conceptual models, which show the different users at different levels of a bureaucratic hier-
minimum activities required by the system described by archical organization where people are very conscious
the root de® nition, we can compare the real world and of their position or grade and power than more organic
this systems world, identifying feasible and desirable organizations where these are much less explicit.
changes and suggesting potential action to improve However, many organizations are attempting to move
the problem situation. The analysis and subsequent away from bureaucratic structures so as to make them
understanding of the problem situation leads to this more ¯ exible and, therefore, participative approaches
improvement. In the context of this paper, such action may become more widespread.
could be the development of information systems.
Problems with single situation approaches
Class 4: methodologies applicable to situations
where there is a high user interaction with the
Many authors have suggested, as we do in this paper,
system and/or user acceptance is important
that there is no best methodology for all situations
Many potential information systems will involve many (Jackson and Keys, 1984; Avison and Wood-Harper,
users who will be greatly affected by the new system. 1991). It would seem dif® cult, if not impossible, for

5. Information system development methodologies 77
example, to design an appropriate system using a `hard’ Q1– How is the information System
uman-Activity
approach when the problem is ill-de® ned or use a 1 H orma supposed to futher the aims of the
nf ti
2 I -Tec on organisation using it?
participative approach in cohersive situations. Davis cio hnic
So al Q2– How can it be fitted into the
3 u working lives of the people in the
(1982) suggested that a methodology should be chosen -Comp ter
organisation using it?
n
Int
depending on the particular characteristics of the
H uma
Q3 – How can the individuals
erf a c e
5 Technical
systems development project. Episkopou and Wood- concearned best relate to the compu
in terms of operating it and using the
Harper (1986) also suggested that a suitable approach
4
output from it?
should be determined by examining certain variables Q4 –What information processing
in and around the problem situation. They devised a function is the system to perform?
Q5 –What is the technical specificatio
framework to select an approach based, in the main, of a system that will come close enou
on assessing the characteristics of the problem solver to meeting the identified requirement
and problem owner.
The classi® cation of methodologies in this paper Figure 1 The Multiview1 framework
could be used to help in the process of choosing a
methodology. However, there are problems associated
with using certain characteristics of the problem to
choose an appropriate methodology. For example, Skidmore, 1987). The latter approach lacks a guiding
many problem situations and information systems framework, documentation and other standards.
development projects are multifaceted, suggesting Although it could be argued that very skilled analysts
that methodologies in more than one class would be may successfully employ such an approach, this is
appropriate. Furthermore projects take on different normally not appropriate because of a fear that such
characteristics as they progress. A project may be ill- skilled staff would be dif® cult to control, a lack of such
structured at the outset, demanding softer techniques, skilled staff being available and dif® culties concerning
but a well-structured objective set and requirements contracts and compliance with quality standards. The
de® nition may result, at which time harder techniques method engineering movement (see, for example,
will be appropriate. One view, therefore, is that Brinkkemper et al., 1996), which does suggest using
different methodologies are complementary. However, techniques, such as entity-relationship modelling and
analysts may not know a number of methodologies tools, in particular CASE tools, according to situation,
suf® ciently well to choose and use the `appropriate’ might also be deemed inappropriate because of its
ones as the situation merits. For this reason, a single largely technological viewpoint. Complex situations
contingency approach may be the most useful in more are usually so because of the mix of human, social and
complex situations. organizational complexity, as well as technical dif® culty.
Avison and Wood-Harper (1986) described Multi-
view as an exploration in information systems develop-
Class 5: complex problem situations requiring a
ment. Multiview provides a framework guiding analysts
contingency approach to information systems
in their choice of techniques and tools in any particular
development
problem situation and also recommends documentation
Re¯ ecting on the classi® cation given, many readers and other standards, these being one of the main forces
might argue that most information systems develop- for using an information systems development method-
ment projects will fall within class 5. Of course this may ology in the ® rst place. There are many situations in
re¯ ect the bias of the author or the roughness of the which Multiview has been used successfully.
classi® cation itself. There certainly needs to be further Multiview (Avison and Wood-Harper, 1990, 1991)
work on the classi® cations of problem situations rather is a ¯ exible framework where the techniques and tools
than the methodology themes or features. But, as Avison are chosen according to the particular problem situa-
et al. (1988, p. 379) argued `Every situation is different tion and the stage in the development of the infor-
and the analyst should have the opportunity to explore mation system. In the original de® nition, it has ® ve
and create a unique method for each situation.’ We will phases (see Figure 1): (1) analysis of the human activity
therefore discuss Multiview, which provides a frame- system, (2) analysis of the information (entities and
work for developing information systems. It has been functions), (3) analysis and design of the sociotech-
designed for such complex problem situations. nical system, (4) design of the human± computer inter-
A contingency approach, such as Multiview, is face and (5) design of the technical aspects.
more appropriate than one where analysts choose a The approach is described in full in Avison and
methodology from the number available (Davis, 1982), Wood-Harper (1990), but suf® ce it to say in the
for reasons given above, or one where analysts choose context of this paper that stage 1 is heavily in¯ uenced
tools and techniques from a `tool box’ (Benyon and by the work of Checkland (class 3 above), stage 2 by

6. 78 Avison and Taylor
the methodologies described in class 2 of this paper,
stage 3 by Mumford, described in their latest versions
in Checkland and Scholes (1990) and Mumford Organisational Information
anallysis analysis &
(1995), (class 4 above) and stage 5 by those items modelling
outlined in classes 1 and 2 above.
The authors argue that to be complete in human as Information
well as in technical terms, the methodology must systems
provide help in answering the following questions. development
(1) How is the computer system supposed to further
the aims of the organization installing it? Socio-technical Technical design
(2) How can it be ® tted into the working lives of analysis & design and construction
the people in the organization that are going to
use it?
(3) How can the individuals concerned best relate Figure 2 The Multiview framework (version 2)
to the machine in terms of operating it and
using the output from it?
(4) What information system processing function is
Would-be
the system to perform? History developers
(5) What is the technical speci® cation of a system of an IS
that will come close enough to doing the things
Perceived Analyst
that have been written down in the answers to world
the other four questions?
Issues, needs
and expectation s
These questions would seem to cover complex situ-
CULTURE
ations. Whereas a strategic approach (for example, Organisational Information
Situation
Business Systems Planning) might address question 1, anallysis modelling
participative approaches, such as ETHICS (Mumford, Analysis of : Methodology
1995), might address questions 2 and 3, a prototyping 1. Interventio n
2. Social context
approach, such as rapid applications development 3. Political aspects Socio-technical Technical design
(Martin, 1991) might address questions 3 and 4 and analysis & design and construction
the conventional and structured approaches, such as
SSADM (Ashworth and Goodland, 1990) address
questions 4 and 5, Multiview attempts to address all
Reflecting and
these questions and to involve all the role players or modifying
stakeholders in answering these questions. (method must be
systemically desirable
Although we have stated that phases might be omit- and culturally feasible) Contingent socially-
ted or reduced in scope or executed in a different constructed ISD method
sequence, the description of Multiview is in terms of the
`layers in an onion’ (as in Figure 1) or as a series of ® ve STREAM OF CULTURAL LOGIC-BASED
ANALYSIS STREAM OF ANALYSIS
broad steps. However, this is described as an `ideal type’
which will guide the analyst who will redesign it for any
Figure 3 Constructing the information systems develop-
practical situation. Although Avison and Wood-Harper ment methodology (adapted from Checkland and Scholes,
(1990) argued that `the waterfall model is inappropri- 1990, Wood-Harper and Avison, 1990, and Avison and
ate’ (p. 265), the earlier description in the book gives Wood-Harper, 1995)
the impression of a waterfall model, despite further
denials from the methodology authors using Multiview
in practice. This led to dif® culties where, for example, antithesis of the waterfall model and explicit in address-
users required further explanation on how to go from ing class 5 problem situations.
stage 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 data The development of Multiview
modelling used in information engineering and the
process modelling used in STRADIS). A further re® n- In Multiview2 (Avison et al., in press), the ® ve stages
ing of Multiview has led to another de® nition and this have been reduced to a four-box structure of organi-
is described in the next section. It is more explicitly an zational analysis, information analysis and modelling,

7. Information system development methodologies 79
sociotechnical analysis and design, and technical design place on each of the major aspects shown in Figure 2
and construction. This proposed new framework for and when to give them particular emphasis. There is
Multiview is given in Figure 2 and it shows the four a major learning process for the analyst in having to
parts of the methodology mediated through the actual choose between techniques and tools. There are also
process of information systems development. The four problems of quality, control and planning when using
parts of human activity systems analysis or organiza- a contingency approach.
tional analysis (which examines organizational behav- Nevertheless, Multiview may be considered for use
iours), sociotechnical systems analysis and design in complex unstructured information system develop-
(which examines work systems) and technical design ment projects involving many users as, in such cases,
and construction (which examines technical artefacts) the investigation needs soft analysis. Hard structured
are integrated through the information analysis and techniques, such as process and data modelling, will
modelling stage which acts as a bridge between the also be required. Furthermore, the balance between
other three, communicating and enacting the outcomes the social and technical designs in Multiview is likely
in terms of each other. In this way Multiview offers to give the correct emphasis in such projects.
an exploratory though perhaps not systematic guide to
any information systems development intervention,
together with a re¯ exive, learning methodological Conclusions
process. The emphasis placed on each of the four parts
of Multiview will change as the information system is Systems analysts need to identify the basic character-
being developed and is contingent on the particular istics of the environment in which they are to develop
situation. an information system and choose a methodology or
There are also differences in the details between the contingency approach for the development of that
two versions of Multiview which re¯ ect published particular system. To facilitate this process, ® ve
research over the intervening years and, more impor- problem situation types have been identi® ed: (1) well-
tantly, experience in using Multiview during this structured problem situations with a well-de® ned
period. Thus, for example, (1) stakeholder analysis problem and clear requirements, (2) well-structured
strengthens the conceptual analysis of SSM and ethical problem situations with clear objectives but uncertain
analysis in organizational analysis, (2) there is a migra- user requirements, (3) unstructured problem situations
tion from structured methods to object-oriented with unclear objectives, (4) situations where there is a
analysis in formation analysis and modelling, (3) ethno- high user interaction with the system and (5) complex
graphic approaches supplement the tenets of ETHICS problem situations, combining two or more of classes
in sociotechnical systems analysis and design and (4) 1± 4.
prototyping, CASE, evolutionary and rapid develop- Many if not most situations in organizations are
ment approaches are more strongly suggested in tech- likely to be closer to the class 5 complex problem situ-
nical design and construction. ations than the others and a rede® nition of Multiview
However, although the authors recommend a contin- is proposed as being particularly appropriate for such
gent approach to information systems development, situations because of its broad scope and contingency
Multiview2 should not be used to justify random or `philosophy’ .
uncontrolled development. The terms `methodology’ This attempt at a classi® cation is rudimentary at
and `method’ tend to be used interchangeably, present. Some methodologies or problem situations
although they can be distinguished insofar as a method may ® t into more than one category of the classi® ca-
is a concrete procedure for getting something done tion; only a limited number of problem situation char-
while a methodology is a higher-level construct which acteristics have been included and many features of
provides a rationale for choosing between different problem situations that may be important to the
methods (Oliga, 1988). In this sense, an information methodology choice have not been included in the clas-
systems methodology, such as Multiview2, provides a si® cation. One major omission, for example, is the
basis for constructing a situation-speci® c method culture of the organization and this may greatly in¯ u-
(Figure 3), which arises from a genuine engagement ence the effectiveness of an approach in a particular
of the analyst with the problem situation (Wastell, situation. People have different cognitive styles and as
1996). a result may work more effectively with some method-
This paper should not be interpreted as suggesting ologies than others. Other characteristics of the
that a contingency approach such as Multiview is the problem situation, such as the development time scale
answer to all problem situations. In any case, and constraints on the way development can take place,
Multiview is not a simple approach for a complex situ- may also be important factors in in¯ uencing the
ation. The analyst has to decide on the emphasis to methodology choice.

8. 80 Avison and Taylor
We are therefore aware of the dangers of being tion Systems Development, 2nd edn (McGraw-Hill,
simplistic, both in our judgements of the different types Maidenhead).
of problem situation and the appropriate methodolo- Benyon, D. and Skidmore, S. (1987) Towards a tool-kit for
gies for each type, but we believe that further research the systems analyst. Computer Journal, 30, 2± 7.
Boar, B.H. (1984) Application Prototyping: A Requirements
into different situation types and the appropriateness
De® nition Strategy for the 80’ s (Wiley, New York).
of approaches for each of these types is particularly
Brinkkemper, S., Lyytinen, K. and Welke, R.J. (eds) (1996)
relevant to the real situation confronted by systems Method Engineering: Principles of Method Construction and
analysts and groups of users as they search for an Tool Support (Chapman & Hall, London).
appropriate approach for their particular problem Bubenko, J.A., Jr, (1986) Information system methodologies ±
situation. a research view, in Information Systems Design Metho-
dologies: Improving the Practice, Olle, T.W., Sol, H.G. and
Verrijn-Stuart, A.A. (eds) (North Holland, Amsterdam).
Acknowledgements Checkland, P.B. and Scholes, J. (1990) Soft Systems
Methodology in Action (John Wiley, Chichester).
I wish to thank Richard Vidgen, Bob Wood and in Chen, P.P.S. (1976) The entity-relationship model ± toward
a uni® ed view of data. ACM Transactions on Database
particular Trevor Wood-Harper who are working with
Systems, 1, 1.
me on a new de® nition of Multiview.
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
References (Pitman, London).
Davis, G.B. (1982) Strategies for information requirements
Ashworth, C. and Goodland, M. (1990) SSADM: A Practical determination. IBM Systems Journal, 21, 4± 30.
Approach (McGraw Hill, Maidenhead). Dearnley, P.A. and Mayhew, P.J. (1983) In favour of system
Avison, D.E. (1992) Information Systems Development: A prototypes and their integration into the systems devel-
Database Approach, 2nd edn (McGraw-Hill, Maiden- opment cycle. Computer Journal, 26, 36± 42.
head). Episkopou, D.M. and Wood-Harper, A.T. (1986) Towards
Avison, D.E. and Fitzgerald, G. (1988) Information systems a framework to choose appropriate IS approaches.
development: current themes and future directions. Computer Journal, 29, 222± 228.
Information and Software Technology, 30, 458± 466. Fitzgerald, G., Stokes, N. and Wood, J.R.G. (1985) Feature
Avison, D.E. and Fitzgerald, G. (1995) Information Systems analysis of contemporary information systems method-
Development: Methodologies, Techniques and Tools, 2nd ologies. Computer Journal, 28, 223± 230.
edn (McGraw-Hill, Maidenhead). Gane, C.P. and Sarson, T. (1979) Structured Systems
Avison, D.E. and Myers, M. (1995) Information systems Analysis: Tools and Techniques (Prentice-Hall, Englewood
and anthropology: an anthropological perspective on IT Cliffs, NJ).
and organizational culture. Information Technology & IBM (1975) Business systems planning, in Advanged Systems
People, 8, 43± 56. Development/Feasibility Techniques, Cougar, J.D., Cotter,
Avison, D.E. and Wilson, D. (1991) Controls for effective M.A. and Knapp, R.W. (eds) (Wiley, New York)
prototyping. Journal of Management Systems, SA± 58, pp. 236± 314.
41± 53. Jackson, M.C. and Keys, P. (1984) Towards a system of sys-
Avison, D.E. and Wood-Harper, A.T. (1990) Multiview: An tems methodologies. Journal of Operations Research, 35,
Exploration in Information Systems Development (McGraw- 473± 486.
Hill, Maidenhead). Land, F.F. and Hirschheim, R. (1983) Participative systems
Avison, D.E. and Wood-Harper, A.T. (1991) Information design: rationale, tools and techniques. Journal of Applied
systems development research: an exploration of ideas Systems Analysis, 10, 91± 107.
in practice. Computer Journal, 34, 98± 112. Lundeberg, M. (1982) The ISAC approach to speci® cation
Avison, D.E. and Wood-Harper, A.T. (1995) Experience of in information systems and its application to the orga-
using Multiview: some re¯ ections, in Information Systems nization of an IFIP working conference, in Information
Provision: The Contribution of Soft Systems Methodology, Systems Design Methodologies: A Comparative Review,
Stowell, F.A. (ed.) (McGraw-Hill, Maidenhead) pp. Olle, T.W. Sol, H.G. and Verrijn-Stuart, A.A. (eds)
102± 117. (North Holland, Amsterdam) pp.173± 234.
Avison, D.E., Fitzgerald, G. and Wood-Harper, A.T. (1988) Macdonald, I.G. (1986) Information Engineering, in
Information systems development: a tool-kit is not Information Systems Design Methodologies: A Comparative
enough. Computer Journal, 31, 458± 466. Review, Olle, T.W., Sol, H.G. and Verrijn-Stuart, A.A.
Avison, D.E., Golder, P.A. and Shah, H.U. (1992) An SSM (eds) (North Holland, Amsterdam).
toolkit: rich picture diagramming. European Journal of Maddison, R.N. (ed.) (1983) Information System
Information Systems, 1, 397± 407. Methodologies (Wiley, Heyden).
Avison, D.E., Wood-Harper, A.T., Vidgen, R.T. and Wood, Mahmood, M.A. (1987) Systems development methods ± a
J.R.G. (in press) Multiview: An Exploration in Informa- comparative investigation. MIS Quarterly, 11, 293± 311.

9. Information system development methodologies 81
Martin, J. (1989) Information Engineering: A Trilogy (Prentice- Biographical notes
Hall, Englewood Cliffs, NJ).
Martin, J. (1991) Rapid Application Development (Prentice- David Avison is Professor of Information Systems and
Hall, Englewood Cliffs, NJ). Head of the Department of Management at
Mumford, E. (1995) Effective Requirements Analysis and
Southampton University. He also has considerable
Systems Design: The ETHICS Method (Macmillan,
experience in information systems practice. He is
Basingstoke).
Myers, B.A. (1988) Creating User Interfaces by Demonstration President of the UK Academy of Information Systems
(Academic Press, New York). and Vice-chair of the International Federation of
Oliga, J. (1988) Methodological foundations of systems Information Processing (IFIP) working group 8.2.
methodologies, in Critical Systems Thinking: Directed David is joint editor of the McGraw-Hill series of texts
Readings, Flood, R.L. and Jackson, M.C. (eds) (Wiley, in information systems and is also joint editor of
Chichester). Blackwell Scienti® c’ s Information Systems Journal now
Olle, T.W., Sol, H.G. and Verijn-Stuart, A.A. (eds) (1982) in its seventh volume. He has published 16 books (plus
Information Systems Design Methodologies: A Comparative one translation from the French) as well as a large
Review (North Holland, Amsterdam). number of papers in learned journals, edited texts and
Paddock, C.E. (1986) A critical view of factors affecting
conference papers. He has given the plenary addresses
successful application of normative socio-technical
systems development approaches. Information and
at recent information systems conferences in The
Management, 10, 49± 57. Netherlands, Australia, Bahrain, the UK and the
Quang, P.T. and Chartier-Kastler, C. (1991) Merise in USA. His research areas include information systems
Practice (Macmillan, Basingstoke) (translated by D.E. development and he is one of the co-authors of the
and M.A. Avison (1989) from the French Merise Multiview methodology.
Appliqu‚ e (Eyrolles, Paris).
Schoval, P. and Pliskin, N. (1988) Structured prototyping: Vicky Taylor is Senior Policy Researcher at Ordnance
integrating prototyping into structural systems develop- Survey, Southampton. She did her MSc in Management
ment. Information and Management, 14, 19± 30. Science at the University of Southampton and is a
Wastell, D. (1996) The fetish of technique: methodology as graduate member of the Institute of Personnel and
a social defence. Information Systems Journal, 6, 1.
Development. Her main research interests are now in
Wilson, B. (1990) Systems: Concepts, Methodologies and
Applications, 2nd edn (Wiley, Chichester) pp. 25± 40.
the area of human resource policy and systems.
Wilson, J. and Rosenberg, D. (1988) Rapid prototyping for
user interface design, in Handbook of Human± Computer Address for correspondence: Department of
Interaction, Helender, M. (ed.) (North Holland, Management, Southampton University, Southampton
Amsterdam). SO17 1BJ, UK.
Wood-Harper, A.T. and Fitzgerald, G. (1982) A taxonomy
of current approaches to systems analysis. Computer
Journal, 25, 12± 16.
Yourdon, E. (1988) Managing the Systems Life Cycle (Prentice
Hall, Englewood Cliffs, NJ).
Yourdon, E. (1989) Modern Structured Analysis (Prentice
Hall, Englewood Cliffs, NJ).