An Empirical Model of the Information Systems Development Process: A Case Study of an Automotive Manufacturer Jim Hughes Trevor Wood-Harper Information Systems Research Centre. University of Salford Salford. M5 4WT. UK and School of Accounting and Information Systems University of South Australia Adelaide, Australia
[email protected] [email protected] Abstract This paper challenges the often-perceived view that the systems development process is almost exclusively technical and predominantly rational. This prevalent position is often coupled with a view of information systems methodology as providing common standards of practice and documentation. Whilst the authors are aware of other challenges to this prevailing paradigm this paper investigates the information systems development process from the viewpoints of those directly involved. The authors used Grounded Theory procedures to elicit a local empirical model of the information systems development process to discover what happens in practice. Keywords IB01 IS Research Methodologies
INTRODUCTION The process of information systems development is predominantly associated with the methodologies adopted in that process. The view being that successfully pursuing ‘good’ methodologies will lead to ‘good’ systems development. This suggests a static view of methodology. However it is worth considering some seminal work in this area. Churchman (1971) opened his discourse on the design of inquiring systems by exploring the nature of design and methodology. His essential premise was that design moves from the specific to the general, and having achieved generality might then be adopted as a methodology for a class of problems. He maintained that the general methodology has its status because of its success in use, but that every future use of the methodology would adapt, test and evaluate with a view to improvement. More recently this concept of ‘methodology in action’ (Jayaratna 1994; Fitzgerald 1998) has been explored in the information systems domain and the concept confirms Churchman’s premise and continues to challenge the traditional view of information systems development. Further empirical research is required to explore the concept of methodology in action since much of the understanding to be derived is likely to be situated in systems development domains. Hence the motivation for the case study presented in this paper. We present a case study of the information systems development domain in a UK automotive manufacturer. We aim to elicit from interview transcripts a local empirical model of the process. This leads us to a discussion about the role of the systems
Proc. 10th Australasian Conference on Information Systems, 1999
1181
developers and supports the concept of a situated methodology in action being the perspective through which the information systems development process may be better understood. The paper is structured as follows. In the next section we summarise the arguments against the traditional view of the systems development process as four propositions. These help to provide a fuller understanding of the strengths and limitations of the application of formalised methodologies as an aid to the development process. This is followed by a description of the research methodology followed by the case study findings. The paper concludes with a discussion of the findings as they relate to the research area and some conclusions are drawn with respect to lessons learnt.
PROPOSITIONS RELATING TO THE SYSTEMS DEVELOPMENT PROCESS In this section we present four propositions based on the available literature which provide the basis for understanding the limitations of the traditional view of the systems development process (Howcroft and Hughes 1999). The tradition is predicated on the assumption that the process is rational and predominantly technical. Each of the propositions is presented in terms of the role of the systems developer. Developers have Various Levels of Experience (Wastell 1996) argues that ‘novice’ developers rigidly adhere to the reductionist framework which methodologies provide, opting for ‘adaptive reaction’ as they become more skilled and experienced. (Wastell 1996) also confirms the view that methodologies may act as a useful crux for the novice developer, particularly given the stressful nature of systems development (Wastell and Newman 1993). Yet as their experience develops, there is a real danger that the methodology becomes a fetish at the expense of personal and critical reflection. Empirical studies reveal that as developers evolve over time, they adopt methodologies in a far more pragmatic way (Fitzgerald 1997). This view of skill levels in systems development is similar to that provided by the Dreyfus brothers in their critique of artificial intelligence (Dreyfus and Dreyfus 1986). They present a 5-stage model of skill acquisition, beginning with the inexperienced novice and graduating to the expert. Their view is based on a holistic approach to situational understanding and they present a strong case for tacit knowledge and intuition, both of which are identified as critical features of expertise in unstructured problem areas. This re-orientation towards a ‘knowing how rather than a knowing what’ strongly centres upon intuition and experience, as opposed to a knowledge of facts and the rules for relating them. (Hughes 1998) echoes these themes when he stresses that systems developers should be encouraged to articulate tacit knowledge rather than simply focus upon learning the theory of methodologies. Developers form ‘Mental Constructs’ to influence use of methodologies Jayaratna (1994) identifies four elements that are present within any problem-solving context: the problem situation, the problem solver (developer), the problem solving process (methodology), and the evaluation. In any given context in the problem solving process, the problem solver will utilise their mental constructs to influence their thinking processes and actions. These mental constructs influence their own sense-making and decision-making activities and thus explain the ways in which a methodology is used differently by one person as compared with another, and indeed as compared with the original proponents of the methodology.
1182
Methodologies are Tailored to the Contingencies of a Situation Most of the currently available systems development methodologies are founded on outdated concepts which emerged in the period from about 1967 to 1977 (Fitzgerald 1997). Empirical research supports the contention that the profile of the development environment is very different from that faced in the past when these methodologies were first promoted. For example, the faster ‘metabolism’ of today’s business environment means that developers do not have the luxury of being able to follow all the detailed steps in a monolithic methodology. Consequently, many methodologies are neither followed rigorously nor uniformly (Fitzgerald 1996), rather they are tailored to the contingencies of the particular organisational context and problem situation. Methodologies Serve as a ‘Comfort Factor’ Fitzgerald (1994) noted that methodologies might well be used “as a comfort factor to reassure participants that ‘proper’ practices are being followed”. Wastell (1996) develops this point further by considering that methodologies operate as a social defence, providing security for systems developers operating within the acute stresses of systems development. He compares the learning of methodologies with the psychoanalytic concept of transitional objects: they provide psychological support until the novice gains sufficient confidence to tackle problems independently. As experience develops, the methodology becomes internalised and the novice graduates to expert, discarding the transitional object en route. As discussed in the introduction it is clearly important that these propositions be explored in practice. It remains problematic to investigate a moving target. Goguen (1994) suggests that there are six ‘qualities of situatedness based on Suchman’s (1987) work in this area. These are emergence, locality, contingency, embodiment, openness and vagueness. It is therefore critical that an appropriate research methodology is used to explore these situated concepts and this is covered in the next section.
RESEARCH METHODOLOGY Data collection and analysis proceeded based on the Grounded Theory approach (Glaser and Strauss 1967; Strauss and Corbin 1990). Initially a set of semi-structured questions were conducted with practitioners from the pools of systems developers pools and also two IS managers with overall responsibility of the systems development area. These were recorded and the resulting transcripts enabled an understanding of the situation to be derived. Subsequent coding and categorisation of the transcripts helped to form an inductive framework relating to the interviewees’ own ‘theory’ of the IS development process. Theory is therefore used in the sense that it refers to empirical models devised on the basis of data. As analysis proceeded emerging categories were saturated – that is to say interviewees were asked to clarify or explain responses until the category was fully explored. The result of the analysis is a hierarchy of categories each of which has an analytical text – memo - associated with it. At the highest level the core category is a summary of the grounded theory. The categories that emerged through the analysis of the transcripts are presented below in the sub-headings of the case study. In the analysis, words used by the interviewees are delimited by single quotation marks. From these major categories an empirical local framework for systems development at Autoco emerged (figure 1). This is given at the end of the case study section and is followed by discussion of the lessons that may be derived from the framework for the general IS community.
1183
Although Grounded Theory procedures have been criticised for their positivistic tendencies the authors would argue that the procedures could legitimately be used in interpretive research. Although they would recognise that for research into situated practices the procedures allow the researcher only a snapshot in time. For a further discussion of these issues and further examples see the review by Howcroft and Hughes (1999)
CASE STUDY Background The IS Department of Autoco employs one hundred and seven IS professionals. The department is divided up into two areas, Systems Development and Technical Support Services. The Systems Development area is responsible for writing in-house applications supported and maintained on AS/400, VAX, Mainframes and PC platforms. The IS staff comprise Systems Analysts, Business Analysts, Change Management Analysts and Oracle/database practitioners. Technical Support Services on the other hand is chiefly concerned with the support of the technological infrastructure of the business to ensure that it is in line with the companies objectives and Information Services strategy. It is the Systems Development teams of the company that were used as the domain for the six-month study. The Systems development area is further subdivided into developer pools and these are shown in table 1 Development pool / number of practitioners
Development platform(s)
Development tools utilised by the pool
Tools/ Methodology recommended by Autoco management
System development, implementation and evaluation in accordance with manufacturing needs. / 6
VAX, PC's, Mainframe
CA Generator(4Gl) Powerbuilder Infomaker 5.0 RDB database tools.
Tool selection dependent on platform and practitioner.
System development and maintenance of 'core' marketing systems and Logistics system. / 7
AS400's, PC's
Cobol (RPG400) Personal Oracle Oracle Developer 2000 Lotus Approach/script.
Oracle Developer 2000 and Personal Oracle.
Development and support of financial systems and development of bespoke RAD systems. / 7
Mainframe, PC's
Personal Oracle Oracle Developer 2000 Infomaker 5.0 Lotus Approach/Script STRIVE methods.
Oracle Developer 2000 and personal Oracle. Infomaker to be used for bespoke report writing.
Mapping of business processes and quality. Some method evaluation conducted. / 2
PC's
IDEF SSADM bespoke techniques. STRIVE methods.
IDEF for mapping of all business processes. SSADM for bespoke diagrams.
Table 1: Autoco Systems development area - practitioner pools For the purpose of the analysis a distinction is made between those who are managers with responsibility for the systems development area in terms of strategy and those who work in the systems development teams who we refer to as practitioners.
1184
The major analytical categories Systems Development managers’ perspective For Autoco managers a clear gap exists between practitioner and management involvement in the systems development process. Practitioner involvement terminated after the initial systems analysis and 'ground work' had been completed. Practitioners may be called upon again to formulate alternative solutions if management felt the solution was inappropriate after evaluation. The management approach to IS evaluation considered factors such as risks, skill sets and costs. However assumptions were sometimes made to 'paper over' areas of uncertainty. Management tended to perceive the practitioners’ involvement in this process as a technical resource they could 'tap into' as and when required. User involvement was seen as an activity that should occur after the go ahead for a project had been decided. Management suggested that user involvement was important and often determined the success or failure of a particular project. As a result of this concern techniques such as focus groups or steering groups were often put in place after the project was underway. Autoco management suggested that strategic evaluation was important and that users should have some involvement in the process, however the general attitude of the management group seemed to suggest that achieving an effective and well balanced steering group was often a difficult task to accomplish in practice. The management role centres on strategic decision making and acting as a 'controller' or communication channel between the practitioner domain and senior executives. Managers indicated that they did have some involvement with certain users (or customers) however this was dependent on the importance and size of the project. Managers perceived the development process as a customer/supplier relationship. External influences such as 'business partners' and 'consultants' helped to influence the understanding of specific methodologies and development tools. Other sources of understanding such as 'internal influences' or 'word of mouth' were also suggested to be of value. Interaction with the practitioner community was seen as an important step in understanding the overall development process. In measuring the 'effectiveness' of a particular methodology or tool the approach adopted by management tends to be based on informal metrics. Management interviewees indicated that as long as the development tools allowed the practitioner to do their work then they are effective. Concepts relating to CASE and RAD were also identified as a major contribution to the effectiveness of a particular tool or methodology. Development tools that promoted self-documenting facilities were also seen as important by the interviewees. The developers’ perspective - practitioner The main role of the practitioner within the context of the Autoco domain is concerned with developing and maintaining existing and future IS systems. The IS practitioners that participated in the research tended to perceive their development roles as being 'proactive' and 'reactive' in practice with the latter being explicitly relevant to legacy systems practitioners. The interviewees tended to be dismissive about the development activity being labelled as a 'process' and subsequently perceive themselves as 'suppliers' and the user community as 'consumers' or 'customers' that they support and assist in turn for the users commitment and co-operation in particular development projects. The practitioners that participated in the research indicated that the most difficult task they have to undertake in practice is that of requirements elicitation. The general attitudes of the
1185
interviewees indicated that the requirements gathering process was 'error prone', 'time consuming' and 'not worth the effort' in practice. Practitioners claimed that 'users don't always know what they require from a system' and the specification formulation should left to the discretion of the practitioner. The approach adopted in practice to the requirements gathering process tended to be of a formal nature with concepts such as 'sit down meetings' to elicit functional requirements and business problems being very popular methods adopted by many practitioners. Traditional concepts such as 'sign offs' were also very common techniques used by many of the practitioners to obtain the full co-operation and commitment of a particular user group. Many interviewees said they felt more secure and comfortable when a functional specification had been 'signed off' and 'early commitment' to the specification was essential to ensure the success of a particular project had been given. The analysis indicated that prototyping was a dominant approach to Information Systems development. The common consensus amongst the interviewees was the 'GUI' and 'event driven' approaches of such development tools allowed for greater practitioner productivity and the subsequent flexibility and 'freedom' offered by such approaches allowed the practitioner to tailor their particular development style to meet the end user's (or customer's) requirements. Many felt the development tools like Oracle helped them address the lack of participation from certain user groups because it provided a ‘quick’ interface that could be used for discussion. Many of the interviewees had 'regular customers' (or specific users) that they formed working relationships with. The practitioners identified the need for the customers (or users) to 'come back in the future'. What is evident from the interview transcripts is that the perceptions of certain customers influence greatly the practitioner's particular way of working or selection of a specific development tool. Many interviewees suggested that certain customers and commissioning departments had 'phobias' or 'stigmas' about certain development tools and this influenced how they conducted the development process in practice. The main themes that emerged overall for this particular category were that the development process in practice was often intuitively driven. Practitioner experience and knowledge of the business culture seems to be a major factor and input into the development process. Many of the less experienced interviewees indicated that they try to follow a particular methodology that underpins a development tool like Oracle 'slavishly' or prescriptively. Furthermore the interviewees at this level of experience suggested that most of their time was spent trying to fit the methodology or tool to the context of the project even if common sense suggested that it did not seem feasible in practice. The value of ‘knowing how to do something’ tends to increase in importance as the level of practitioner experience and knowledge increases. Many of the more experienced practitioners did not see methodology as prescriptive guidance but as a 'toolbox' or resource that they can 'dip into' as and when required. This particular behaviour only appears to be common practice when a certain level of confidence has been built up and the knowledge becomes instantiated into working practices. The experienced practitioner who 'knows the user domain inside out' appears to capitalise by using this embedded tacit knowledge to adjust their development styles. This approach in practice appears to help avoid potential conflicts and problems that many of the less experienced practitioners often meet head on and subsequently have to learn to deal with through a trial and error learning cycle. The developers’ perspective - domain and constraints The domain or scope in which the development process is conducted includes a number of constraints that have practical ramifications on the practitioner's style and approach to the development process. Many of the interviewees described these constraints as 'being out of
1186
our hands' and subsequently adopted their development style and approach in a manner that would allow them to conform to such standards in a way they personally felt was acceptable. Management pressures were identified as being major constraints that inhibited creativity. Common themes emerged from the interviewees in respect of IS Managers setting unrealistic goals and 'wanting the system yesterday'. The general view that emerged indicated that the practitioners felt that managers did not really appreciate the complexity of the development process and subsequently unrealistic time scales and deadlines were often imposed. Users (or customers) are also seen as constraints that inhibit the overall development process in practice. Many of the interviewees stated that 'users do not go away' after the sign off process and consequently time has to be spent either re-working segments of code or enhancing the overall program functionality. The main constraints identified by many of the practitioner's were how to cope with changing requirements after the release of a particular system into the user community. It was strongly evident that the practitioners felt there was a strong possibility of becoming engaged in a never-ending loop of maintenance. A common theme that emerged from the transcripts was that good development principles were dependent on the individual to implement them. This was also evident for system documentation as practitioners felt that documentation inhibited the creativity of the development process. As one practitioner pointed out 'a cover your back' strategy that can be presented on request to senior management to demonstrate that a structured (and standard) approach had been adhered to. Quality standards were also a major constraint identified by the participants. Many of the more experienced developers felt that the development of GUI operating systems meant that their approach to development had to adhere to 'common' features of a particular environment. This it was felt caused problems in a practical sense as many of the interviewees indicated 'making the interface look right' often overshadowed implementing the core functionality. The developers’ perspective - other practitioners and learning The interviewees identified learning by experience as being of most benefit and the key to being successful in practice. Themes such as 'learning by doing' or 'hands on learning' were described by many as a useful approach to understanding a particular development tool and it's underpinning methodology. Many felt formal training provided the basic practical grounding especially for development tools like Oracle. However it was felt that after this initial training had been completed it was either 'sink or swim' and in a practical sense there were often gaps between what they learned in the 'classroom' and what they were required to do in practice. The more experienced practitioners identified past projects as being an aid to learning. IS development in practice is deemed a success or a failure if the system 'works as it should'. Many felt that while they were producing code that 'behaved' in the correct manner then their approach to IS development was in fact correct. What also emerged from the analysis was that practitioner learning in practice was often constrained or limited to a particular 'niche'. For example, one interviewee stated that 'he did not really understand the technological side of things' and as a result tended to 'call on someone down stairs for help' [technical support staff]. Furthermore many felt it was unnecessary and counter productive to have a grasp of the technology as 'it was not their job to do this', others suggested that there was a clear boundary between the technical side of the IS department and the systems development side. As one interviewee stated 'people get cagey and wary when you cross over into their particular patch, you have to remember that some of the people down stairs don't like to share their knowledge with us’.
1187
The interviewees considered documentation and development guidelines as an effective learning mechanism provided they had the time to sit down and study the material. Many suggested that formal documentation did have some benefits such as when transferring knowledge from one practitioner to another in the 'hand over' process. The knowledge of other practitioners was seen as being a 'valuable resource' to many and themes such as 'coaching', 'mentoring' and the idea of a 'development buddy' were all put forward as ways of developing knowledge in practice. One practitioner did highlight the concern that many of the practitioners have of informal approaches or ways of working. These 'bad habits' often 'rub off' on less-experienced practitioners. Many interviewees identified that the 'skill' of being able to 'cobble bits of code together' is a skill that develops through practice. The lessexperienced practitioners indicated that this was a skill that was 'picked up' quickly in practice. The developers’ perspective - evaluation in practice The interviewees tended to be dismissive of methodology and tool evaluation. Many of the participants were not aware of explicit academic frameworks for evaluation and suggested they 'did not have the time to study such things'. The general consensus among interviewees was that evaluation of specific development tools was an activity carried out by senior management. On an individual level many stated that when they are presented with a new tool or methodology their approach to evaluation is purely objective. Comments emerged from the transcripts such as 'I look for ODBC functionality and connectivity'; 'I think about how I could apply the tool to re-engineer some of my older projects'. The overall opinion emerged that the practitioner is more interested in 'what he can do with the tool' rather than trying to understand it in a theoretical sense. A common theme in respect of tool and methodology evaluation is politics, many suggested 'power dominates' evaluation in practice. Changes in business climate tend to influence the evaluation and selection process in practice. As one interviewee indicated: 'the company last year spent seven million pounds on a Oracle based Logistics system as the powers above decided we have to go with this decision as development expertise and support for this system is essential for it's success'. Changes in company aesthetics also have an influence and power over the evaluation and selection process in practice. One interviewee indicated that such changes directly influenced the technology, which in turn influenced the need for new systems. As one interviewee highlighted 'often I'm drafted in to re-engineer or re-write a perfectly good system just because the company logos on the original system are out of date or do not fit the culture the company requires at that point in time'. Overall the interviewees indicated that the current approaches to tool and methodology evaluation were limited 'but they didn't know how to go about it differently'. Some evidence of functional evaluation in practice was available and this focused on the used of Quality Function Deployment techniques to match the functionality of a particular tool or methodology to a particular project. Some of the participants indicated that this approach to evaluation was often 'inappropriate' and they were 'forever fiddling' the approach to fit the tool or methodology under evaluation. Many of the interview responses indicated that the culture of the IS department was weak in the respect of practitioner involvement. It was subsequently suggested that 'people who have power and play with tools' within the organisation were the 'key' to specific development tools and methodologies being brought into the development domain.
1188
The developers’ perspective - understanding of methodologies and development tools From the analysis of the interview transcripts the practitioners in general tended to be dismissive of the value of certain 'open' and 'in house' methodologies. Specific methodologies were perceived as 'out of date' and 'not having a customer focus'. One interviewee suggested that the SSADM was often 'prescriptive and error prone’. The general consensus suggested that such methodologies in practice resulted in the customer being 'beaten up' by the technicalities and the subsequent functional specifications associated with such methodologies. Of the interviewees who participated in the research many perceived methodologies as synonymous with method. Answers such as 'oh it's a way of solving a problem' and 'you mean DFD's, normalisation and techniques used to build a system' were common responses to the questions asked. In respect of the available in-house methodologies, many practitioners indicated that they could not understand or see how these specific techniques could be applied to their particular line of work. Some interviewees suggested they had used certain techniques in the past such as 'brown paper' to develop and structure user interfaces however many suggested that modern development tools like Oracle Designer 2000 and Personal Oracle meant that such methodologies became redundant in practice. One interviewee provided an interesting metaphor and suggested that certain methodologies and development tools were like clothes, as he pointed out 'one minute they’re fashionable and everybody is seen to be using them and the next thing they’re not'. The inhouse methodologies as many of the respondents suggested were conceived at a time where the business was undergoing a 'renaissance' in thinking and practice. The general opinion seemed to suggest that such methodologies could be made portable to any area of the business, in practice however many indicated that these methodologies were 'outdated' and of 'little use to them'. One of the more experienced practitioners provided further insight by indicating that 'even management is not pushing these methodologies any more. They finally realise they only have value to manufacturing and the production areas of the business, anyway so why do we need such methodologies in this day and age when we have development tools like Oracle and Infomaker that do all the systems analysis for us'. Summary of IS development in practice The framework given in figure 1 together with the written categories represent the local ‘grounded’ empirical model of systems development at Autoco. In summary the model indicates that the development process requires the practitioner to draw upon a variety of both situated and formal skills. In practice these two competing paradigms combine until an appropriate development process emerges. The framework illustrates that the IS practitioner's individual mental constructs - that is the ways that he or she thinks about the development process - are influenced by six primary sources: the situated constraints on the development domain; the situated political and formal strategic aims of managers; the practitioners own formal training and education; the situated relationship with user groups; formal methodologies including in-house methodologies; and the situated influence of other practitioners. What is clear from the model is that it is unhelpful to consider the development process as simply a formal process. The model suggests that for Autoco the individual practitioners work out for themselves a methodology-in-action (Jayaratna 1994; Fitzgerald 1998) that is appropriate given the exigencies of the particular situation – it is not claimed to be either ‘good’ or ‘bad’. The model also represents a snapshot of the development process in one organisation. Therefore it challenges the reader to consider the development process as it applies elsewhere rather than purport to be generalisable. Indeed if the study were to be carried out now it would be entirely likely that a different model would emerge.
1189
Training and education ruct inst ce / n e u Infl
info rm s
Management Influence
Mental constructs
Other practitioners Int erv ene s
r tso ibi Inh ggers tri
in
IS practitioner Situated / Formal development domain
Domain constraints Management pressures Business climate
selects
Project profile Development standards
User groups
Quality
Hardware platforms
Methodologies
Figure 1: Local empirical framework for understanding the IS development process in practice in Autoco
DISCUSSION For the research development process the research largely confirms the propositions presented in the introduction. The study indicated that less-experienced developers relied more on formalised methodologies than did their experienced colleagues. These less-experienced developers did feel that the formal methodologies provided a psychological security and the more experienced developers, whilst cynical about standards and quality, recognised the need to produce ‘what the managers wanted’. This has some resonance with the work of Nonaka (1994) and the conversion of tacit to explicit information – novices may also adhere to formal methodologies because of their limited tacit knowledge processing. Even in development environments where formalisation and dictated methods were commonplace – such as the Oracle or Infomaker environments – the developers continued to tailor methods to the contingencies of the situation. It may be possible to surmise from this that academics and practitioners alike should not be searching for greater formalisation and rigour in IS development, since the case suggests that formalisation is but one of the major elements. They should instead be seeking a greater understanding of the heavily situated nature of the development process. The authors maintain that roles need to be considered for the systems developer, which move beyond the traditional notion of expert and indeed beyond the emergent role of facilitator. That role has been variously expressed as moral agent (Walsham 1993) or reflective practitioner (Schon 1983) and considered in the problem solving context (Jayaratna 1994) where the emphasis is not exclusively on technical skill sets nor on interpersonal skills but on the thinking skills of the developer. Interestingly, this accords with the view of the researcher as proposed by (Lincoln and Denzin 1994) and as explored by (Hughes and Wood-Harper 1999) in which the systems developer may be considered to be the ultimate ‘bricoleur’ (or Jack of all trades). But more than simply the Jack of all trades, they are also the inventors
1190
they know they have few tools and little by way of appropriate parts and so become inventors (Lincoln and Denzin 1994, p.584) This is a deeper understanding of the limits of methods and openness to learning and adaptation. If applied to the information systems development process it opens the door for methodology-in-action and the analysis of experiences and making explicit learning with fellow developers and sharing also with those who are affected, that is, ‘users’. This role of developer as bricoleur broadens rather than narrows the scope of action for the systems developer. It challenges methodological purity in action, where dogmatism is at the fore. The bricoleur role also avoids the pitfall of treating the selection of methods and indeed methodologies as one might select a tool from a toolbox since the role incorporates the reflective (thinking) aspect.
SUMMARY AND CONCLUSIONS The case study has been presented to illustrate the situated nature of information systems methodologies. It rejects the traditional view of the process being exclusively technical and rational. Whilst the situated concept may be intuitively well understood by information systems practitioners it is increasingly important that a larger body of empirical evidence be provided to counter the traditional viewpoint – to which this case study makes a contribution. Not least because of the increasingly rapid changes in technology and the increasing pervasiveness of computer based information systems. If the process is to be understood then it needs to be understood in its situated context: the domain; the organisational constraints; the social actors and their interactions; and the politics. Each must be equally attended to and not simply attention paid to the technology.
REFERENCES Churchman, C. W. (1971). The Design of Inquiring Systems: basic concepts of systems and organisation., Basic Books, New York Dreyfus, H. and S. Dreyfus (1986). Mind Over Machine. Blackwells. Oxford. UK. Fitzgerald, B. (1994). The Systems Development Dilemma: Whether to Adopt Formalised Systems Development Methodologies or Not? Second European Conference on Information Systems, Nijenrode University Press. Holland. Fitzgerald, B. (1996). “Formalized systems development methodologies: a critical perspective.” Information Systems Journal 6(1): 3-23. Fitzgerald, B. (1997). “The Use of Systems Development Methodologies in Practice: A Field Study.” Information Systems Journal 7(4). Fitzgerald, B. (1998). An Empirically-Grounded Framework for the Information Systems Development Process. Proceedings of the 19th International Conference on Information Systems, Helsinki, Finland. Glaser, B. and A. L. Strauss (1967). The Discovery of Grounded Theory: Strategies for Qualitative Research., Aldine, Chicago. Goguen, J. A. (1994). Requirements Engineering as the Reconciliation of Social and Technical Issues. in Jirotka, M. and Goguen, J.A. (eds.) Requirements Engineering: Social and Technical Issues. Academic Press, London.
1191
Howcroft, D. A. and J. Hughes (1999). Grounded Theory: I mentioned it once but I think I got away with it. In Brooks, L. and Kimble, C. (eds.) Information Systems the Next Generation. Proceedings of the 4th UK AIS, York, UK. McGraw-Hill Hughes, J. (1998). “Selection and Evaluation of Information System Methodologies: the gap between theory and practice.” IEE Proceedings Software 145(4): 100-104. Hughes, J. and A. T. Wood-Harper (1999). “Systems Development as a Research Act.” Journal of Information Technology 14(1): 69-82. Jayaratna, N. (1994). Understanding and Evaluating Methodologies. McGraw Hill. London. Lincoln, Y. S. and N. K. Denzin (1994). The Fifth Moment. Handbook of Qualitative Research. N. K. Denzin and Y. S. Lincoln., Sage. London: 575-586. Nonaka, I. (1994) ‘The Dynamic Theory of Organizational Knowledge Creation’ Organization Science, 5(1) pp. 14-37. Schon, D. A. (1983). The reflective practitioner. How professionals think in action. USA, Basic Books. Strauss, A. L. and J. Corbin (1990). Basics of Qualitative Research : Grounded Theory Procedures and Techniques. Beverly Hills, California, Sage. Suchman, L. (1987). Plans and Situated Actions: The Problem of Human-machine Communication. Cambridge, UK, Cambridge University Press. Walsham, G. (1993). Ethical Issues in Information Systems Development - The Analyst as Moral Agent. Human, Organizational and Social Dimensions of Information Systems Development. D. Avison, J. E. Kendall and J. I. DeGross. Amsterdam, North Holland : 281294. Wastell, D. G. (1996). “The fetish of technique: methodology as social defence.” Information Systems Journal 6(1): 25-40. Wastell, D. G. and M. Newman (1993). “The behavioural dynamics of information systems development: a stress perspective.” Accounting, Management and Information Technology 3: 121-148.
ACKNOWLEDGEMENTS The authors wish to acknowledge the help of Mike Ostapski in the data collection and analysis. Also the staff of Autoco (a psuedonym) for their cooperation in the study. Also the contributions made by the anonymous reviewers – unfortunately not all suggestions could be incorporated within the page limit.
COPYRIGHT Jim Hughes and Trevor Wood-Harper © 1999. The authors assign to ACIS and educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive licence to ACIS to publish this document in full in the Conference Papers and Proceedings. Those documents may be published on the World Wide Web, CD-ROM, in printed form, and on mirror sites on the World Wide Web. Any other usage is prohibited without the express permission of the authors.
1192
