Cost Estimation in Agile Software Development Projects

Abstract

Abstract. Numerous studies over the years have shown that information systems development (ISD) projects often run over budget or fail entirely. Such failures are not restricted to certain industry sectors or project types; rather they occur with some regularity in systems development projects and organizations of all types and sizes. Cost estimation has long been a difficult task in systems development, and although much research has focused on traditional methods, little is known about estimation in the agile method arena. This is somewhat ironic given that the reduction of cost and development time is the driving force behind the emergence of agile methods. This study looks at how classical problems which adversely affect cost estimation in traditional ISD are managed within the agile paradigm. A qualitative approach was followed, based on data collected from four companies. Amongst other findings, the study revealed that estimation inaccuracy was a less frequent occurrence for these companies. A number of recommendations can be drawn from the research: estimation models are not a necessary component of the process; fixed price budgets can prove beneficial for both developers and customers; and experience and past project data should be documented and used to aid future estimation efforts.

Detection of early warning signals for overruns in IS projects: linguistic analysis of business case language

“…Poor planning is a serious problem for IS projects (Kutsch et al, 2011;Moløkken-Østvold & Jørgensen, 2003;Shmueli et al, 2016a). Specifically, unrealistic estimates at the start of a project are a key cause of budget and schedule overruns (Flyvbjerg et al, 2002;Lang et al, 2013;Nelson & Morris, 2014;PricewaterhouseCoopers, 2014). Prior research suggests that underestimation is much more common than overestimation (Flyvbjerg, 2008;Flyvbjerg et al, 2002;Kutsch et al, 2011).…”

“…Underestimation of the required time and budget (also known as over-optimism) is considered to be one of the main factors associated with project failure (Harvey Nash & KPMG, 2017;KPMG, 2017;PricewaterhouseCoopers, 2014;Project Management Institute, 2018). Over-optimistic estimates have been linked to overruns in projects (Buehler et al, 2010;Flyvbjerg et al, 2002;Kutsch et al, 2011;Lang et al, 2013;Nelson & Morris, 2014), scope overload (Bjarnason et al, 2010(Bjarnason et al, , 2012Buschmann, 2009;Shmueli et al, 2016a) and over-requirements (Buschmann, 2010;Coman & Ronen, 2010;Shmueli et al, 2015Shmueli et al, , 2016aShmueli et al, , 2016b. In addition, organisations focused on cost savings may underestimate costs or select projects in which costs have been underestimated (Connolly & Dean, 1997).…”

“…First, this study contributes to the body of knowledge on overruns in IS projects by identifying a potential early warning signal for budget and schedule overruns. This is an important contribution because budget and schedule overruns are among the most persistent problems that IS projects encounter (Cao, 2008;Conboy, 2010;Lang et al, 2013). Yet, relatively little attention has been given to identifying potential early warning signals of budget and schedule overruns.…”

“…Recent surveys have estimated that cost overruns affect as many as 60% to 70% of projects, and the estimates for schedule overruns are similar (KPMG, 2017;Wellingtone, 2017). Unfortunately, many IS projects also fail to meet their targets with regards to budget, schedule, and functionality (e.g., Cao, 2008;Conboy, 2010;Keil et al, 2000;Lang et al, 2013). It is estimated that only 36% of software projects complete on time and within budget (Standish Group, 2014).…”

“…Many (IS) projects fail to meet their targets due to poor initial estimation (e.g., Kutsch et al, 2011;Lang et al, 2013;Nelson & Morris, 2014), and people appear to be unable to learn from past mistakes. While people acknowledge failures to accurately estimate in the past, they generally do not question the accuracy of their current predictions (Buehler et al, 2010;Kahneman & Tversky, 1982), arguing that no meaningful comparison with past projects can be made due to the perceived uniqueness of the new project (Buehler et al, 2010;Kahneman & Lovallo, 1993).…”