CTS – Your Technology Partner

The Real Reasons Behind Incorrect Software Estimation – Part 1

Written by Jeff Lether on August 6, 2015

Software estimation is a notoriously difficult activity. According to an industry analysis such as the Chaos Report by the Standish Group, a large number of projects don’t meet original estimates. They suffer overruns on time, money, or both. This is fueled by the complex nature of software solutions, the dynamically changing real-world problems they try to solve, and the difficulty of visualizing an abstract concept without seeing something concrete first. Despite these difficulties, it’s important to get software estimation right. Here are some common pitfalls and ways to mitigate them.

  1. You left out the meta-work

In addition to the effort needed to build the project deliverables, there are always many supporting activities that need to be performed to complete the work. Often, work estimates include much better detail about deliverable activities than supporting activities, or even omit supporting activities entirely. Maintaining the schedule, holding team meetings, reviewing documentation, training users, and production deployment activities are just a few examples of the kinds of process-oriented work that can be overlooked when preparing an estimate. And since many of these activities can be sizeable and/or recurring, the missed time can add up fast.

  1. You estimated the wrong thing

No matter what technique you use to estimate, if you don’t have an accurate picture of the work, your estimate is guaranteed to be off. It’s very common for users to have one vision of a solution in mind, whereas the solution developer is anticipating building something quite different. This happens when requirements are not well understood, or not detailed enough. Often, a bulleted list of desired features or a series of mock screen shots are used as requirements when trying to define work. These artifacts simply don’t provide enough detail to accurately estimate a solution. Critical areas like workflow through the solution, interfaces with other systems, data model, and data validation aren’t addressed by such summary-level artifacts, yet they heavily affect the level of effort. In the absence of specific information, both end users and solution developers will naturally assume that the solution will conform to their unstated expectations. However, it’s unlikely that those two sets of expectations will match, producing a potentially large gap in the estimate between the work planned by the solution developer and the work necessary to build what the users are expecting.

  1. You don’t use assumptions and document them

Even if you start estimating with a good understanding of the work, you’re never going to know everything. With any non-trivial system, it’s simply not possible (or desirable) to have every detail fleshed out in advance. With Agile-based development approaches, it’s particularly unlikely you’ll possess this level of detail in advance, when you are estimating. As noted above, when this happens people naturally assume the estimate will match their unstated expectations. When you don’t write down these expectations, there’s no way to detect disconnects between user and developer expectations in advance. They are discovered after software is built, introducing rework and delays.

A better way to start

The problem of producing accurate software estimates is multi-faceted, and so is the solution. By using a combination of techniques, you can address the challenges above and produce better estimates. Estimates will never be actuals in advance, but you can make them much closer than they are today. At CTS, we start with proven estimating templates that include all the meta-work for a project, but we don’t simply fill them in and go with it. Next we turn to the work description and ensure it’s understandable and at an appropriate level of detail for the development approach being used, whether Agile, Waterfall, or somewhere in between. Then we identify any remaining areas of uncertainty and try to resolve them to refine the work description. This isn’t always possible, so when it isn’t we make reasonable assumptions and document them so all stakeholders can see the assumptions underlying the estimate. Then, as more clarity becomes available later about an area of uncertainty, it’s readily apparent how it affects the work plan and adjustments can be made proactively.


Next time we’ll look at 3 remaining challenges and techniques to address those. Stay tuned!