|
 |
|
|
[Inspired] [Prod&Svcs] [People] [Associates] [Contact] [Philosophy] [Reference] [Clients] |
|
|
||||
|
The Influence of Project Method Fit on the Success of System Development Methodology Usage An Empirical Research Paper presented to The Department of Accounting, University of Cape, in partial fulfillment of the Requirements for the Bachelor of Commerce Honours Degree in Information Systems. Richard Bosman, Graham McLeod and Joanne Tanfield, 12 October 1992. Graham McLeod, University of Cape Town, Pvt Bag Rondebosch, 7700, South Africa mcleod@iafrica.com, tel +27 21 650 4028, cell +27 82 578 1834 Abstract Information Systems project failure rates have been quoted as high as 70%. Formalized development methodology use has been empirically shown to improve probability of project success. However, other studies have shown that the benefits ascribed to methodology use are not always achieved. Hackathorn & Karimi found that no one methodology addresses all required issues. Butler Cox points out that organizations have a variety of project types and that these will not be successfully addressed by a single methodology. A contingency approach has been advocated, where an appropriate methodology would be selected per project. Indications are that this would be problematic, given the effort involved in learning a methodology and the complexity of comprehensive methods. Little empirical evidence could be found to substantiate the view that problems were caused by lack of fit between methodology emphasis and type of project tackled. This research explores the issue of methodology to project fit and finds support for the view that a mismatch of methodology to project type indeed contributes to benefits of methodology use not being achieved Introduction The strategic use of new information technology and systems is seen as a vital component of corporate success, yet the history of IS development shows this to be an area fraught with problems (Hirschheim & Newman 1991). Research suggests that between 50 and 70 percent of all system development projects fail (Lyytinen 1988; Saarinen 1990). While numerous factors influence success in the system development process (Lyytinen & Hirscheim 1987), it has been empirically proven that the use of system development methodologies can increase the probability of project success (Lyytinen 1988, Saarinen 1990, Lee & Kim 1992). Despite the use of formal methodologies, however, many IS projects fail to meet budget and time constraints and/or to satisfy user requirements. Hackathorn & Karimi (1988), suggest that inadequate coverage of methods can be a contributing factor. Others (Butler-Cx 1987; Olle et al 1988, Avison & Wood-Harper 1991) contend that organizations have a variety of project types, and that no one method will satisfy all requirements and suggest a contingency approach where a suitable methodology would be chosen per project. While this is intuitively appealing, little empirical evidence has been presented to support this view. This research was designed to explore the issue of project-method fit with a view to finding empirical evidence to support the conclusions of researchers advocating a contingency view of method suitability (Avison & Wood-Harper 1991). Prior Research Definition "A methodology is not a cure-all but it helps tie in all the elements of the software development environment together to ensure success." (Corbin 1991) The term methodology, in the strictest sense of the word, means the study of method. When applied to information systems, it has come to mean "a methodical approach to information systems planning, analysis and design" (Olle et al 1988). System development projects must meet user needs, conform to all the organizational standards, fit the budgetary constraints and be completed on time. A methodology must be used to achieve this (Wright 1991). The Need for a Methodology Many system developers admit that the development process could be improved via a systematic approach (Butler Cox, Lyytinen 1988). The information systems development methodology delineates the development process, thereby reducing the risk of omissions and improving the quality of the overall system (Kniestedt & Hager, 1991). Where the organization follows a formalized structured approach to system development projects, ease of communication, improved performance, consistency of management and reporting processes and integration across phases of the life cycle and between projects in the organization are achieved (Avison & Wood-Harper 1991). Corbin (1991) supports the need for a methodology for information systems development in order to establish a productive software development environment. By ensuring the consistency of techniques, standards and deliverables, a methodology can improve the productivity of development personnel and the quality of the systems developed. Furthermore, the use of a formal methodology improves control of the development process while simultaneously improving system documentation and maintainability. This reduces development and maintenance costs (DeMarco 1982; Martin 1990; Corbin 1991; McLeod 1992). While many factors can influence project success, a methodical approach to systems development is clearly a critical factor. Lee and Kim (1992) conducted a survey to investigate the relationship between the formalization of development methods and project success, using the extent to which user requirements are met as their measurement tool. Their empirical results led them to conclude that the degree of procedural formalization of MIS development and MIS success are strongly correlated. The results of their study suggest however, that IS developers should adapt their level of formalization to the situation, since the degree of success varied according to the degree of structure inherent in the task to be replaced or supported. The opinion held by Olle et al (1988) and Avison and Wood-Harper (1991) is that method suitability is contingent. Certain methods are said to be appropriate to certain project types, organizational culture, project team skills, an implementation technologies. Since most organizations have requirements for a variety of system types, the adoption of any single method will eventually result in a problem of project-method fit. The use of Methodologies According to Avison and Fitzgerald (1988), the evolution of methodologies has resulted from the increasing demand for complex information systems and the growing appreciation of the need for formalization of the development process. As projects become more and more complex, the uncertainty associated with them increases and formalized methods are needed to predict, manage and control the development process. This has resulted in a proliferation of methodologies which try to address various problems associated with system development. The literature details the evolution of methodology use in several phases (Olle et al, 1988) : Ad-Hoc or no methods. This was typical of early application development projects, where projects were viewed as short-term, once-off solutions while formal development techniques were yet to be developed. Lack of training, awareness or management commitment allows this situation to persist in some organizations to this day (McLeod 1992). One-size fits all. The need for formal development methodologies was established in the 1970's and 1980's and a large number of methodologies became available. The organization would choose "one best" method and try to apply it to all projects, with varying success (DeMarco 1982). Where the methodology was well suited to the project and team skills, in an environment with strong managerial support, successes were recorded. Unfortunately, many failures were experienced, since different types of development require different approaches, and management attempted to adapt the methodology to suit the application (Modha 1990). Tailoring the methodology may seem to alleviate the problem of project-methodology mismatch, but may result in the loss of the benefits sought in a formally structured approach, including consistency, skill development, inter-team communication and system integration. Most of the methodologies of this era had one predominant emphasis being oriented towards a process or data centered view (Olle et al 1988). Paracentric approach. The combination of tools and techniques from different types of methodologies into an all-encompassing approach suitable for many development environments, has been the rationale behind most in house methodologies, as well as Information Engineering (IE) (Martin & Finkelstein, 1981) and Structured Systems Analysis and Design Methodology (SSADM) (NCC, 1986). These combine the data and process orientations into a multiple perspective approach. Comprehensive Methods. To address diverse types of development, proprietary methods offer different approaches for different projects types within the methodology. These "super-methods" cater for diverse development approaches, but tend to become very large and unwieldy with long learning curves which intimidate practitioners into reverting to the ad-hoc or no method approach. The inherent weaknesses in the methodologies are compounded when the project type does not fit the methodology used in the organization. Contingency approach. An organization is unlikely to find a single development process that is adequate for all its needs (Butler Cox 1987). To overcome the problems experienced with methodologies, the contingency approach advocates the selection of the methodology that best addresses the type of development project in terms of complexity and standards required (Saarinen 1990). Multiview (Avison and Wood-Harper 1991) is an attempt to provide a methodology framework within which various approaches can be used. McLeod (1992) contends that the contingency approach will suffer from practical problems since it is unrealistic to expect developers to become expert in a variety of methodologies. Variable success achieved Jones and Kydd (1988) provide evidence that the implementation of the same methodology in two different organizational settings produced vastly different results. The successful use of methodologies is therefore dependent on selecting the appropriate methodology and managing it correctly (Saarinen 1990; Butler Cox 1987; Leonard-Barton 1987; Redmill 1990). This seems to indicate that the use of System Development Methodologies is influenced by the project-methodology fit. Various authors (Hackathorn & Karimi 1988; Avison & Wood-Harper 1991; Colter 1984; Jones and Kydd 1988; Olle et al 1988) have begun exploring frameworks with a view to understanding the methodological landscape (McLeod 1992). Some of these are descriptive and are aimed at assisting researchers to understand the problem space, whilst others are intended for use by practitioners as a loose guide, leaving the choice of technique and representation to the practitioner. Iivari suggests a different approach in that the choice of suitable tools takes place within the methodology not between the methodologies (in Avison and Wood-Harper 1991). Hackathorn and Karimi (1988) developed a framework for the comparison of methods, techniques and tools within the dimensions of coverage of the life cycle and degree of detail (depth).
From the framework, it is evident that none of the tools, techniques or methodologies identified addresses both the formalization of the development process (the depth dimension) and coverage of the development life cycle (the breadth dimension) adequately. This supports the view that there is no one method that will support a portfolio of projects. MIS developers, however, continue to be faced with the increasing application backlog and require a methodical development approach encompassing all phases o f development and applicable to all projects. Problems experienced with methodologies The literature examined fails to define the underlying corporate objective behind the use of a formal methodology. Since the discipline of Information Systems has yet to produce a set of stable defined principles, practitioners may differ in their understanding of fundamental terms and their view of the objectives and benefits behind methodology usage. Lack of clearly defined objectives and measures of accomplishment make it difficult to control or evaluate the effectiveness of methodology usage since "You can't control what you can measure" ( DeMarco 1982) The contingency theory assumes that an organization would have a range of methodologies to select from and would have staff who are competent in several methodologies. McLeod (1992) argues that methodologies are time consuming and difficult to learn. Avison and Wood-Harper (1991) acknowledge that it is unreasonable to expect practitioners to know more than one method well and the typical project manager is poorly equipped to select from available techniques. With the rapid evolution of technologies and automated tools, practitioners do not have time to become expert in one approach before yet another one is advocated (Avison & Fitzgerald 1988). The use of an inappropriate methodology, or the mismanagement of the methodology could result in overall project failure (Saarinen 1990; Butler Cox 1987; Leonard-Barton 1987; Redmill 1990). Further investigation into the degree to which ineffective methodology usage impacts on project success, was required. Based on the literature examined it was evident that research has been done regarding the effect of methodology usage on project success or failure, but no research was found that investigated the effect that the fit of the methodology to the project type has on the effective use of the methodology. Given the above we were led to formulate the following hypothesis : The benefits attributed to formal system development methodologies are often not achieved dure to poor fit between project type and methodology. As prior research has determined, numerous factors can influence project success and failure. Our aim was to focus attention on the issues surrounding the use of formal methodologies. The objectives of this research were to identify the issues arising from the cases where a methodology was used but did not contribute to success; as well as those issues arising from cases where a methodology was not used. Research Methodology To establish whether the benefits of formal methodologies are not being achieved due to poor project-methodology fit, senior project managers were surveyed to provide information concerning projects recently completed. Responses were captured in a spreadsheet to allow comparison between the projects (see Appendix). Sample Selection Organizations from four industries in the Western Cape were targeted, viz. Insurance, Retail, Oil and Government. The industries were chosen with a view to inclusion of a wide variety of application and project types. The nature of the research was communicated to senior IS executives in each organization and they were requested to identify candidate projects for the questionnaire. Participants were required to be project managers from a cross-section of typical projects for their environment, completed within the last two years. Other participants included project managers currently studying for the degree of Honours in Information Systems (Part-time) at the University of Cape Town. The aim was to survey a broad range of project types across a variety of industries to avoid a bias toward any specific project type or industry. Survey Instrument Since no prior empirical research could be found, a new survey instrument was designed. Demographic details identified the nature and size of the project concerned as well as the development platform. Participants were requested to rate the degree of project success on a scale of one to five, in terms of the fulfillment of user requirements, corporate objectives and technical specifications. The questionnaire probed whether deviations form scope, time and budget constraints had occurred. It required respondents to indicate which methodologies they had used, the reasons for their choice and whether any problems were experienced in using the methodology. They were also asked to what extent the use of a methodology had contributed to project success and whether they would use the same methodology again for a similar project. Where the participant chose not to use a formal development methodology, they were asked to clarify the reasons for this decision. This was done with a view to discovering situations where the lack of fit contributed to methodologies not being used. The instrument was piloted in assisted completion sessions with one of the participating organizations to ensure its effectiveness. This resulted in the refinement of several questions. The full instrument is included in the Appendix. Limitations The current study is exploratory in nature. The number of projects completed by any organization in the last tow years is small and the survey was limited to the Western Cape for logistical reasons. The sample size does not therefore lend itself to formal statistical treatment, and the study was designed with this in mind. Nevertheless, valuable data has been gathered to begin an empirical investigation of the subject. Analysis of Results Sixty questionnaires were sent to participating organizations and twenty seven usable responses were obtained. Demographic breakdown of sample Type of Application To determine the demographic composition of the sample, projects were classified into nine different categories namely End User Computing (EUC), file maintenance, batch processing, transaction processing, online, Decision Support System (DSS), Executive Information Systems (EIS), real time and knowledge based system. These categories are not mutually exclusive and participants could choose more than one. The breakdown of project types is shown in figure 1.
Platform The hardware platform for each project was identified, with 15 of the projects created in a mainframe environment and 12 on Personal Computers (PC's) while 4 were based on mini's. The projects were also classified according to network platforms with 16 using LAN's and 9 using WAN's. These were the only network configurations represented. The majority of project (22) were developed in a centralized environment. Two were developed in a decentralized environment while four had client-server architectures (one project indicated both centralized and decentralized environments). (See Appendix) Development Approach Various development approaches were used, along with a wide variety of tools and techniques. A breakdown of these is shown in the Appendix. The categories defined are not mutually exclusive. Project Size To gauge the size of the sample projects, participants were required to specify the size of the project team and the amount of effort expended in manmonths. The largest project team consisted of 300 people while the smallest contained 1 and the average team size was 24. The largest effort in manmonths was 8000 while the smallest was 0.5 with the average being 495. Thus, despite the small sample size, results indicate that a wide range of project types from a variety of development environments was represented, effectively eliminating application type and development approach as contributing factors to poor methodology usage/performance for the purpose of this research. Project success The success or failure of the individual projects was assessed in terms of whether the time, budget and functionality requirements have been met. Functionality was measured according to the extent to which the project had satisfied user requirements, system requirements and corporate objectives as perceived by the project managers, each rated on a scale of one to five (Table 1). Deviations from the original scope of the project were also recorded. The reasons for the scope change were not indicated and, since this would affect the time and budget factors, caution should be exercised when making deductions from this datum. Discussion The results of the questionnaire depicted in Table 1 show the number of projects that used a formal methodology; where problems were experienced in using methodology; the perceived contribution of the methodology to the success of the project; and the perceived project success in terms of the time, budget and functionality requirements identified above. Respondents were required to specify whether they would adopt the approach given a similar development project. (A detailed breakdown of the results of the questionnaire is provided in the Appendix)
Table 1 From the table, it is evident that the developer's perception of project success and the number of problems experienced are not consistent. Despite the extent to which the overruns were incurred, most projects seem to have succeeded in meeting user, system and corporate requirements. Although developers' bias should be considered , the results seem to indicate that while projects are succeeding in terms of functionality, control of development is lacking since thirteen projects (48.15%) experienced scope overruns and ten (37.04%) experienced budget overruns. Out of 17 projects using a formal methodology, 13 indicated that this was corporately prescribed. Where respondents chose to adopt an ad-hoc or no-method approach, four participants indicated that the corporate methodology was unsuitable for the project-type and technology. An additional four stated that the organization was still deciding on a methodology. Further reasons quoted included lack of tool support and project team skills, while four respondents indicated that the nature of their application did not justify the use of a methodology. The perceived contribution of the methodology to the success of the project was assessed. Out of 20 replies to this question, only 11 (55%) reported a high benefit from the methodology. Despite the fact that contribution was considered to be low in nine projects, eighteen respondents (81.82%) indicated that they would use the same methodology to develop a similar project. Of these, thirteen experienced time, cost or scope problems. Three of the thirteen encountered a steep learning curve which may have caused these problems, but the results suggest that, while the need for a methodology still exists, these issues are not being adequately addressed by current methodologies or the way they are being used. The results of the analysis indicate that in a cross-section of projects from a variety of environments, project managers are not obtaining the expected contribution from methodology usage to project success. Eight (40%) of the respondents experienced problems with the methodology they used of which five perceived the methodology contribution to be low. Four of the projects that experienced no problems with the methodology also perceived the contribution to be low. This suggests that the methodology contribution may be low even where projects do not experience problems. Factors influencing the level of contribution as perceived by the project managers are listed in Table 2.
Table 2 From the data in Table 2, two themes emerge: namely that the methodology may be inherently inappropriate for the specific project being developed or that the developers may not possess the required skills allow them to utilize the methodology defectively and efficiently. Factors inherent in the methodology itself that render it inappropriate included the lack of tools (25%); unfamiliar or ill-defined terminology (25%) and lack of integration (25%). Likewise, the inability of the methodology to clarify user requirements (15%), manage the change process (15%) or provide adequate quality control (15%) also contribute to a perceived low level of contribution. Where the methodology is not suited to the technological environment (30%) or where the approach is considered to be too cumbersome (20%), the use of a methodology may have a negative effect on productivity. Inadequate training (25%), unfamiliar terminology (25%) and a lack of experience in the methodology (35%) result in project teams which are ill equipped to use the methodology effectively. The result is that, while the methodology may effectively cater for the requirements of the project, the project teams do not possess the necessary skills to utilize the methodology and therefore cannot achieve the expected benefits. Where the organization is not committed to the use of a methodology and lack of management support exists, these problems are exacerbated. Where the methodology is not seen as contributing to project success, developers revert to the ad hoc or no-method approach (Table 1 : Projects E and Y), since the use of a methodology is not justifiable. Alternatively, where the methodology is used or partially used, it is not effective, as is evidenced by the low level of perceived contribution in projects E, G, J, K, Y, X, Z and AA. negative experiences will influence the developers' future perception, as was the case with projects E and Y, who having used a methodology in the project surveyed, would choose to develop a similar project without a methodology in the future. Conclusion Given the strategic importance of information systems, it is imperative that we understand why so many development efforts have not been successful and why IS development has been so problematic (Hirschheim & Newman 1991). Methodology usage has been empirically proven to enhance the possibility of project success. In this paper we have presented evidence from both the literature and a survey of development projects, to support the conclusion that despite the benefits to be gained from a formalized development approach, the contribution of methodologies to project success is frequently not achieved or not consistently achieved. The literature examined supports the need for a formalized development process. However, our investigation into the evolution of current methodology usage indicated that no one method adequately addressed both coverage of life cycle phases and formalization of the development process (Hackathorn & Karimi 1988). This supports the conclusion that no one methodology exists which would support the full portfolio of projects and an organization will frequently experience the problem of project-methodology mismatch. Despite the use of methodologies however, a large number of projects are failing to meet time and cost objectives as well as failing to define project requirements adequately. The causes for the low contribution of methodologies to project success include the inappropriateness of the methodology to the project type and the inability of the methodology to the project type and the inability of the project teams to utilize the methodology. This supports our hypotheses that the benefits attributable to formal system development methodologies are often not achieved due to mismatch of methodology to project-type. Organizations attempting to solve these issues by tailoring the methodology or adopting a contingency approach, are faced with long learning curves and may lose the benefits inherent in a formalized, consistent process. The results suggest the need for an approach that allows the selection of suitable tasks, techniques and tools from within an accepted methodology which the organization is committed to and staff are trained in. The adapting of a subset of an accepted approach should be applied within a framework that ensures consistent project management, quality management and scope management. If achieved, this will ensure integration of tasks, deliverables and infrastructure across phases of the life cycle and between projects in the organization. Consistency of standards and procedures can thus be achieved while simultaneously providing flexibility to allow developers to cater for the unique requirements of each development project. Future Research Issues that arose from the study that were not pertinent to the objectives of this research are detailed below. It appears that the project management benefits of the methodologies used are not being achieved. Four of the projects experienced inadequate project management despite using a formalized approach. Each of these experienced time, budget or scope problems to some extent. In addition, the social aspects of methodology usage need to be considered, since these may significantly affect methodology usage in a corporate environment. One issue that are in discussion with participants is that while junior employees receive training and easily adopt the methodology, senior employees may prefer to follow a more familiar approach and resist the change to the unfamiliar arena of methodology usage. Another area of interest is that projects on which the methodology is first used may not be suitable pilots. Since organizations choose to justify the cost of propriety methodologies by following the approach on large projects, the inappropriateness of the project may be the cause of the organization not achieving the full benefits of methodology usage. As determined the study, negative prior experiences may lead to the avoidance of the use of the methodology in future development projects. Additional issues cited by the participants that should be addressed by methodologies include; the ability to accommodate client-server architecture and configuration management; stronger support for business re-engineering; the ability to adapt to changes in technology; integration into centrally held system documentation (e.g. dictionary); the ability to support multitasking and multi-user requirements; increased support for the implementation phase; and simplification and clarification of the steps required. Future research is required to validate the findings of this study by performing statistical analysis on a larger sample. Acknowledgments The authors would like to thank all participating project managers and organizations for their cooperation. Bibliography Ahituv N & Newman S : Principles of Information Systems for Management: Wm. C. Brown Publishers : Iowa : 2nd Edtion : 1982 : pp 129-141 Arinze B : "A Contingency Model of DSS Development Methodology" : Journal of Management Information Systems: vol 8 : no. 1 : Summer 1991 : pp 149 - 166 Avison DE & Fitzgerald G : "Information Systems Development : current themes and future directions" : Information and Software Technology : vol 30 : no. 8 : October 1988 : pp 458-466 Avison DE & Fitzgerald G : Information systems development : methodologies, techniques and tools: Blackwell Scientific Publications : London : 1988 Avison DE & Wood-Harper AT : "Information Systems Development : A tool kit is not enough" : The Computer Journal: vol 31 : No 4 : August : 1988 Avison DE & Wood-Harper AT : Multiview : An Exploration in Information Systems Development: Blackwell Scientific Publishers : Oxford : 1990 Butler Cox : Using System Development Methods : Research Report 57: Butler Cox Foundation : June 1987 Cameron JR, Campbell A & Ward PT : "Comparing Software Development Methods : Example" : Information and Software Technology: vol 33 : no. 6 : July August 1991 : pp 386-403 Cerveny RP & Joseph DA : "A Study of the Effects of Three Commonly Used Software Engineering Strategies on Software Enhancement Productivity" : Information and Management : vol 14 : 1988 : pp 243-251 Computer Mail : "Meeting Strategic Needs" : Computer Mail: October 25 1991 : p 27 Colter MA : Evolution of the Structured Methodologies in Advanced Systems Development Techniques : John Wiley : 1982 : pp 73-96 Corbin DS : "Establishing the Software Environment" : Journal of Systems Management: September 1991 : pp 28-31 DeMarco T : Controlling Software Projects : Management, measures & estimation: Yordon Press : New York : 1982 Doke ER : "An Industry Survey of Emerging Prototyping Methodologies" : Information and Management : vol 18 : 1990 : pp 169-176 Dos Santos BL: "Differences in Analyst's Attitudes towards Information Systems Development : Evidence and Implications" : Information and Management: vol 14 : 1988 : pp 31-41 Edwards HM, Thompson JB & Smith P : "Experiences in use of SSADM : A Series of Case Studies. Part 1 : First Time Users" : Information and Software Technology : vol 31 : no.8 : October 1989 : pp 411-419 Edwards HM, Thompson JB & Smith P : "Experiences in use of SSADM : A Series of Case Studies. Part 2 : Experienced Users" : Information and Software Technology : vol 31 : no.8 : October 1989 : pp 420-428 Ewusi-Mensah K & Przasnyski Z : "On Information Systems Project Abandonment : An Explanatory Study of Organizational Practices" : MIS Quarterly: March 1991 Gavurin SL : "Where Does Prototyping Fit In IS Development?" : Journal of Systems Management: February 1991 : pp 13-17 Gilhooley IA : "Structured Techniques in Systems Development" : Information management : Strategies, systems & technologies : vol II : Auerbach Publishers : 1989 Gould JD, Boies SJ & Lewis C : "Making Usable, Useful, Productivity Enhancing Computer Applications" : Communications of the ACM: vol 33 : No 9 : September : 1990 : pp 143-159 Hackathorn RD & Karimi J : "A Framework for Comparing Information Engineering Methods" MIS Quarterly : June 1988 : pp 203-220 Henderson-Sellers B & Edwards JM : "The Object-Oriented Systems Life Cycle" : Communications of the ACM:vol 33 : No 9 : September : 1990 : pp 143-159 Hirschheim R, Klein HK & Newman M : "Information Systems Development as Social Action : Theoretical Perspective and Practice" : Omega: vol 19 : No 6 : 1991 : pp 587-608 Hirschheim R & Newman M : "Symbolism and Information Systems Development : Myth, Metaphor and Magic" : Information Systems Research: vol 2 : No 1 : The Institute of Management Sciences : 1991 Huws G, Wintrub M & Martin N : "Solving Knowledge-Based Systems Development Problems" : Information Management : Strategies, Systems & Technologies : vol II : Auerbach Publishers : 1992 Jaakkola JE & Drake KB : "ASDM : The Universal Systems Development Methodology" : Journal of Systems Management: February 1991 : pp 6-11 Jones LH & Kydd : "An Information Processing Framework for Understanding Success and Failure of MIS Development Methodologies" : Information and Management: vol 15 : 1988 : pp 263-271 Karten N : "Prototyping That Supports End Users' Involvement in Systems Development" : Information management : Strategies, systems & technologies : vol II : Auerbach Publishers : 1990 Kerr JM : "The Information Engineering Paradigm" : Journal of Systems Management: April : 1991 : pp 28-35 Kniestedt RE & Hager PA : "Incorporating Quality into Systems Development : Information Management : Strategies, systems & technologies : vol II : Auerbach Publishers : 1991 Kozar K : "Adopting Systems Development Methods : An Exploratory Study" : Journal of Management Information Systems: vol 5 : no.4 : Spring 1989 : pp 73-85 Launi JD : "A Structured Methodology for Off-The-Shelf Software Implementation" : Journal of Systems Management: October 1991 : pp 6-9 Lee J & Kim S : "The Relationship between Procedural Formalization in MIS Development and MIS Success : A Contigent Analysis" : Information and Management : vol 22 : 1992 : pg 89-103 Leonard-Barton D : "Implementing Structured Software Methodologies : A Case of Innovation in Process Technology" : Interfaces : vol 17 : No 3 : May-June 1987 : pp 6-17 Lyytinen D : "Expectation Failure Concept and Systems Analysts' View of Information System Failures : Results of an Exploratory Study" : Information and Management : vol 14 : 1988 : pp 45-56 Lyytinen D & Hirschheim R : "Information Systems Failures : A Survey and Classification of the Empirical Literature" : Oxford Surveys in Information Technologies: vol 4 : 1987 Mahmood MA : "System Development Methods - A Comparative Investigation" : MIS Quarterly: September 1987 : pp 293-311 Mansuy JE : "Evolutionary Development Strategy for MIS" : Journal of Systems Management : July 1989 : pp 7 - 13 Martin J & Finkelstein C :Information Engineering: Savant Institute : 1981 Marin J : Seminar Tour Notes: Savant : 1990 McClanahan A & Perotti J : "The Good Old IS Days Are Gone" : Journal of Systems Management: April 1991 : p 9 McLeod G "A Generic Method Model for Representation, Integration and Management of Methods" : Unpublished Article : March : 1992 Mingers J "Comparing Conceptual Models and Data Flow Diagrams" : The Computer Journal: vol 31 : No 4 : August : 1988 Modha J, Gwinnett A & Bruce M : "A Review of Information Systems Development Methodology (ISDM) Selection Techniques" : Omega: vol 18 : No 5 : 1990 : pp 473-490 NCC :SSADM Manual : National Computing Centre, Manchester : 1986 Necco CR, Gordon CL & Tsai NW : "System Analysis and Design : Current Practices" : MIS Quarterly: December 1987 : pp 460-475 Niederman F, Brancheau JC & Wetherbe JC : "Information Systems Management Issues for the 1990's" : MIS Quarterly: December : 1991 : pp 475-492 Noble F : "Seven Ways to Develop Office Systems : A Managerial Comparison of Office System Development Methodologies" : The Computer Journal: vol 34 : No 2 : April : 1991 : pp 113-121 Norman RJ : "Object-Oriented Systems Analysis : A Methodology for the 1990's" : Journal of Systems Management: July 1991 Olive A : "Analysis of Conceptual and Logical Models In Information Systems Design Methodologies" : Trends in Information Systems - An Anthology of Papers from Conferences of the IFIP Technical Committee : Langefors, Verrijn-Stuart and Bracchi (Editors) : North Holland Publishing Company: Amsterdam : 1986 : pp 159-181 Oliver P : "Enhancing Programmer Productivity with Software Engineering" : Information management : Strategies, systems and technologies : vol II : Auerbach Publishers : 1989 Prescott JR : "Using Structured Methodology For Software Project Success" : Journal of Systems Management : July 1991 : pp 28-31 Paddock CE : "A Critical View of Factors Affecting Successful Application of Normative and Socio-Technical Systems Development Approaches" : Information and Management: vol 10 : 1986 : pp 49-57 Rademacher RA : "Critical Factors For Systems Success" : Journal of Systems Management: June 1989 : pp 15-17 Redmill FJ : "Considering Quality in the Management of Software-Based Development Projects" : Information and Software Technology: vol 32 : No 1 : January/February 1990 : pp 18-25 Richmond K : "Information Engineering, The James Martin Way" : Information management : Strategies, systems & technologies : vol II : Auerbach Publishers : 1991 Saarinen T : "System Development Methodology and Project Success : An Assessment of Situational Approaches" : Information and Management: vol 19 : 1990 : pp 183-193 Shoval P : "An Integrated Methodology For Functional Analysis, Process Design and Database Design" : Information Systems: vol 16 : No 1 : pp 49-64 Theaker CJ : "Editorial" : The Computer Journal: vol 34 : No 2 : April 1991 : p 97 Tommela DR : "Systems Development Strategies" : Information management : Strategies, systems & technologies : vol II : Auerbach Publishers : 1989 Viehland DW : "What's new in decision support : Executive information systems" : AIR 1900 Annual Forum Paper : May 1990 Waema E & Walsham G : "Information Systems Strategy Formulation" : Information and Management: vol 18 : 1990 : 1990 : pp 29-39 Wright J : "The Evolution of Development tools." : Datamation: vol 37 : no. 24 : December 1 1991 : pp 78-80
|
