“The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.” — Steve McConnell, Software Estimation Book (2006).
People use software estimates as predictions anyway, and this leads to numerous issues.
The Problem
A lot of software projects overshoot their schedule and budget. The CHAOS Report (2015) by the Standish Group states that this happens to around 70% of software projects. Chances are, a project you have worked on has experienced a similar fate.
Business people are more often than not at odds with software developers, especially when it comes to software delivery expectations. The business people believe that software developers should deliver faster, while the software developers are certain that business people are inconsiderate with their delivery expectations.
There are 4 things that happen before any piece of software is delivered. These 4 things take place implicitly or explicitly. They are:
- Setting a target (the business goals).
- Coming up with an estimate.
- Developing a software delivery plan.
- Making a commitment.
The problem is that these terms often get conflated and this results in the feeling that business people are working against software developers.
The Meanings
Business people communicate their business objectives as a target (e.g. today is June 19th and we need the eCommerce app ready by August 31st, just in time for year-end sales). An estimate is an unbiased view of how much time and effort and cost it will take to deliver a piece of software considering all the activities required (e.g. it will take 12 – 17 weeks to build the first version of the eCommerce app).
Plans and estimates are closely related but they are not the same. In fact, plans and estimates get conflated so much that when business people ask for an estimate what they are actually asking for is a plan that will enable them meet their target. From the eCommerce scenario above, the estimate (12 – 17 weeks) is clearly outside of the time available (11 weeks). Therefore the estimate has served its purpose in clearly showing that either the target has to be moved or some features have to be dropped to fit the time available.
Software developers tend to be optimistic when coming up with estimates and end up treating estimates as if it’s a plan. A plan is derived from estimates and by design a plan serves as a guide to meet the set target. Coming up with a plan may require that some estimated activities be left out in order for the target to be met. In other scenarios, the estimates may show that no amount of planning will let you meet the target. Therefore the target has to be moved.
A commitment is a promise to deliver software based on a plan. Plans rely on clear and unbiased estimates. When planning, estimates help you answer questions such as: which features need to be dropped? Is meeting the target even possible? And so on.
So What’s the Way Forward?
Avoid conflating the meanings of these terms. Also, read the quote at the very top of this text one more time.
Further Reading