Estimates, commitments, and targets in software projects

“Many people don’t even know that there is a difference that has led to countless project failures.”

Software Estimation balancing act

Most people have never learned what good software estimation looks like or how to communicate it effectively.

The importance of understanding the difference between estimates, commitments, and targets in software projects

In my previous article, I discussed the inherent complexity of doing software estimation and the phenomenon of discovered complexity. Beyond this complexity lies another problem: poor communication. Most people have never learned what good software estimation looks like or how to communicate it effectively. Business people involved in software projects often view estimation as the domain of the technical team and make no effort to understand its nuances. Technical team members, on the other hand, often rely on gut-feel estimates without understanding the importance of clear communication.

As a result, estimates are often treated as commitments, and commitments are communicated as targets. Many people don’t even know that there is a difference between these concepts. This lack of understanding has led to countless project failures and eroded trust in the software development process.

To clarify the differences between these concepts:

  • An estimate is a best guess at how long something will take, based on the information available at the time. As I explained in my previous article, estimates are inherently flawed and will change as more information becomes available and problems are solved. A good estimate should be plotted against a probability curve to quantify the uncertainty and risk surrounding it. Rather than communicating a single point estimate (e.g. “I think this will take 6 months”), it’s better to communicate a range (e.g. “given what we know, this could take anywhere from 6-9 months”). Thinking of estimates as a range of possibilities reduces the stress of having to be perfectly right and accommodates the inherent ambiguity and uncertainty of the software development process.
  • A commitment is a promise to deliver functionality at a certain level of quality by a certain date. It’s critical to realize that estimates inform commitments, but commitments should never drive estimates. The working position should be that the estimate is flawed and commitments should be based on the most pessimistic estimate, allowing for additional buffer time. If the estimate is not acceptable, business stakeholders should prioritize the project and make the hard choices necessary to give it a quantified chance of success.
  • A target is a single-point hard deadline, usually driven by external factors such as a product launch or a regulatory requirement. Targets are not based on estimates or commitments and are often imposed on a project team without their input. Meeting a target can require significant compromise on scope, quality, and/or timeline.

In summary, it’s essential to understand the purpose and value of software estimation and to communicate estimates, commitments, and targets clearly and accurately. By doing so, we can avoid the frustration and trust erosion that often results from project failures.