Considering the high failure rate of information technology (IT) projects over the last 40 years, project managers should use all the tools at their disposal in order to make their project a success; however, more than half of all project managers fail to use a powerful tool that is readily available – a development methodology. A development methodology provides structure to a project, which facilitates communication, establishes expectations, enhances quality and promotes consistency. One potential reason project managers do not employ a development methodology is that selecting the correct methodology from among the hundreds available can be an overwhelming task. For this reason, understanding the decision-making process, and identifying those factors that influence it, is a worthwhile endeavor. While empirical research in this area is lacking, a review of the extant literature reveals several factors that are important when choosing a development methodology. In this chapter, many of these factors are identified, a model for categorizing them is proposed, and a model for selecting a methodology is presented.
Information technology (IT) projects are notoriously difficult to complete on time, under budget and within scope. In fact, over the last decade IT projects faced a 20 to 30 percent chance of being canceled and a 50 to 70 percent chance of exceeding their schedule or budget (Ewusi-Mensah, 1997; Kappelman, McKeeman, & Zhang, 2006). With over 50 years of research and experience in developing information systems, why are these projects so difficult to complete? One potential answer—which has received insufficient research—is that project managers use the wrong system development methodology or they fail to use one at all. As Ewusi-Mensah pointed out, projects needed “some structure [to] be imposed on the development effort to help guide the system to successful completion” (p. 76). A lack of imposed structure, or an inappropriate one, can hinder the development process and contribute to the failure of the project.
Aside from providing structure for the information system project, using a development methodology can provides other significant advantages. One such advantage is that “a quality process will result in a quality product” (Khalifa & Verner, 2000, p. 366). Development methodologies, which are a type of quality process, can instill a certain amount of rigor within the development effort. By forcing the project team to follow each step of the process, it is possible to ensure all critical tasks are completed and, perhaps more importantly, it can be used to recreate the team’s success on future projects. A successfully implemented methodology can be used as the framework on which future systems are developed. In other words, it enables the team to develop systems consistently.
Hopelain and Loesh (1985) provided yet another reason for using a development methodology; it built trust among the primary stakeholders – developers, users and management. The argument made by Hopelain and Loesh was that each of the stakeholder groups had to trust each other in order to work together to complete the project. Without this cooperation, success was unlikely. A methodology agreed on by the stakeholders facilitated cooperation since it would “more likely occur if there is a procedure in place which each group understands and believes will produce a system that meets its particular needs” (p. 43).
It would appear that the benefits of using a development methodology are prodigious, but research conducted by Fitzgerald (1998) turned up interesting and alarming statistics about the frequency with which methodologies were used in organizations. According to Fitzgerald’s research, only 40% of the organizations surveyed were using a methodology and less than 10% were using one consistently. In addition, of those not using a methodology, only 21% were considering the use of one.
Based on the complexity of organizations, information system development projects and implementing processes within an organization, it is likely that many factors contribute to the dearth of organizations using development methodologies. A potential factor is the complexity of selecting a methodology from among the hundreds of options. Guntamukkala, Wen, and Tarn (2006) noted that “project managers often face a daunting task of selecting the most appropriate software life cycle model [or development methodology] for a given project” (p. 266). A review of the extant literature identified those factors that influenced the selection of a development methodology for use within an organization. From this, a framework can be developed to facilitate the classification of those factors and a model can be constructed that illustrates how project managers can choose a development methodology that is right for their organizations.
Key Terms in this Chapter
Prototype: In the context of information systems development, a prototype is a model of the system and is typically used to refine the final design of the system.
Systems Development Life Cycle (SDLC): Similar to systems development methodology but extends to the maintenance and support of the system.
Information System: An amalgamation of human, hardware, software, and firmware components used to process data within organizations.
Systems Development Methodology: A logical and disciplined use of phases, processes and techniques used to create information systems.
Information Technology: The computer-based components of an information system.
Agile Development: A development methodology that favors speed, flexibility, and iterative development. Although this methodology is often employed in software development projects, it can be used in system development projects as well.
Weighted Scorecard: A method for comparing multiple choices along various factors. Each factor is given a numerical weight in order to give it more or less importance in the final comparison.