Estimating size in incremental software development projects O. Benediktsson and D. Dalcher Abstract: The motivation for this work is derived from the current interest in speeding up development schedules. A key implication of the shift to more rapid development methods is the growing emphasis on fixed time and fixed effort delivered during such projects. However, there appears to be little work that addresses the impacts of dealing with bound effort levels. The result of binding time and effort is to deprive project managers of the normal parameters that are used in trade-offs. The paper attempts to introduce a quantitative analytical framework for modelling effort-boxed development in order to uncover the effects on the overall development effort and the potential leverage that can be derived from incremental delivery in such projects. Models that predict product size as an exponential function of the development effort are used in the paper to explore the relationships between effort and the number of increments, thereby providing new insights into the economic impact of incremental approaches to effort-boxed soft- ware projects. 1 Introduction The popular computing literature is awash with stories of IS development failures and their adverse impacts on individuals, organisations, and societal infrastructure. Indeed, contemporary software development practice is regularly characterised by runaway projects, late delivery, exceeded budgets, reduced functionality, and questionable quality that often translate into cancellations, reduced scope, and significant re-work cycles [1]. The net result is an accumulation of waste typically measured in financial terms. For example, in 1995 failed US projects cost $81 billion, with an additional $59 billion of overspend, total- ling $140 billion [2]. Jones contended that the average US cancelled project was a year late, having consumed 200% of its expected budget at the point of cancellation [3]. In 1996, failed projects alone totalled an estimated $100 billion. In 1998, 28% of projects failed, at a cost of $75 billion, while in 2000, 65 000 US projects were reported to be failing [2]. The Standish Group makes a distinction between failed projects and challenged projects. Failed projects are cancelled before completion, never implemented, or scrapped following installation. Challenged projects are completed and approved projects that are over budget, late, and with fewer features and functions than initially specified. Most organisations are constantly searching for ways to improve their project management practice and reduce the likelihood of failures and the degree to which their projects are challenged. Typical projects entail a balancing act between the triple constraints of budget, schedule, and scope (Fig. 1). Trade- offs and adjustments are therefore made by restricting, adding to, or adjusting the cost, time, and scope associated with a project. Indeed the traditional triangle in project management is said to be concerned with finding a balance between cost, time, and scope. For example, the more that is requested in terms of scope (or arguably even the performance or the quality), the more it is likely to cost and the longer the expected duration. If the client needs to have a certain performance delivered very rapidly, this will increase the cost due to the need to work faster and have more people involved in the development. The more features expected from a system, the higher the cost and the longer the expected duration. Conversely, if the costs need to kept to a minimum, one may need to con- sider the essential performance, or the overall scope, and compromise there. Many managers quickly discover that the triangle is not flexible. The three factors are closely entwined and project managers are expected to balance the what (scope) with the when (schedule) and the how much (budget). The trade-off between time, scope, and cost is essential in under- standing the tension in a typical project management environment. Performance expectations and scope are often determined prior to the project. Moreover, project managers often inherit the overall budget from the contracting activities, which may even have imposed a fixed-price contract struc- ture. A fixed overall budget may also exclude typical reme- dies such as the hiring of specialists and the addition of human resources. The only remaining scope for leverage is in the schedule. However, this may also be imposed on a project through a fixed date for delivery, with little regard to the complexity of the intended system or the risks it embodies. Once both budget and schedule are fixed, there appears to be little scope for compromises and trade-offs. The three factors play a key part in determining the degree to which a project is challenged (or even deemed a failure), yet they may be uncontrollable by the project manager. Indeed, Capers Jones observed that the most common constraints encountered are fixed delivery dates, fixed-price contracts, staffing or team size limitations, and # IEE, 2005 IEE Proceedings online no. 20050019 doi:10.1049/ip-sen:20050019 Paper first received 14th March and in revised form 9th August 2005 The authors are with Middlesex University, Trent Park, Bromley Road, London N14 4YZ, UK E-mail: d.dalcher@mdx.ac.uk IEE Proc.-Softw., Vol. 152, No. 6, December 2005 253