A Needle in a Haystack: Choosing the Right Development Methodology for IT Projects

Introduction

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.