Estimating is one of the most challenging aspects of software development projects. If you work in an organization where management expects estimates that are accurate down to the last cent, even though you have nothing more than a couple pages of high level requirements written before the project even started, then you have likely witnessed the frustration and stress this puts on a project team. This often results in resources who are very resistant to providing estimates, and when they finally do, the estimates are drastically inflated with “buffer” to account for the unforeseen.

The idea of building a buffer into estimates is less than desirable. While it provides the project team a sense of comfort, management does not have an accurate picture of the real cost of the project. With a drastically higher budget, they could also pass on a project they may have otherwise approved. If you feel the need to have some sort of buffer, it is better to build a contingency budget into the project.

The simple way to calculate a contingency budget is to multiply the total project estimate by a factor - let’s say 20%. This is not very accurate, but the advantage of this approach over adding a buffer to individual task estimates is that management sees both the expected cost and the contingency cost.

In the buffer approach, the estimates already have the contingency included. For example, with the contingency approach, management can see a $100,000 project has a contingency of $20,000. With the buffer approach, management will only ever know that the project cost is $120,000, but not necessarily why. You can take the contingency approach one step further by using a sliding scale multiplier based on the complexity of the project. Say, 10% for simple projects, 20% for average projects and 30% for higher complexity projects.

The danger with the contingency budget approach is the team and management may start to assume the project will dip into that contingency budget and everyone automatically adds the extra 20% when reviewing project budgets.

A way to avoid this pitfall is to provide confidence levels in your estimates. This communicates how accurate you believe your estimates are. This approach avoids the “tacking on the contingency” danger, but still conveys the risk of going over, or under, budget.

Confidence levels do not replace contingency budgets, instead they complement them. Contingency budgets play a big part in long-term financial planning for organizations and as a result provide a lot of value. When management is deciding on whether or not to approve a project for commencement, they will make a more informed decision if they have estimate confidence levels.

What is an estimate confidence level? Based on the name, you can take a guess and probably be correct. Simply put, estimate confidence levels are an indication of how confident you and your team are in your estimates.

There are a few ways to go about implementing confidence levels, but first it helps to understand why they are useful. Imagine NASA designing and building Columbia, the first Space Shuttle. Nothing like it had ever been done before. It was ground breaking stuff, cutting edge, the forefront of technology. Imagine those poor engineers sitting in a room and trying to come up with a realistic estimate on how much it would cost to send a spacecraft back-and-forth from earth to space. According to Wikipedia, the figure they gave back in 1983 was $54 million (adjusted for inflation to 2011 dollars). The actual cost per shuttle flight computes to $1.5 billion.

Compare the momentous estimating task those NASA engineers had to that of a home builder estimating the cost of a particular model of home which they have built dozens of times before. It is pretty obvious the home builder would have a higher confidence level in their estimates.

That’s the “why”. Here are a few options on the “how”:

  • High/Medium/Low: Indicate your project team’s confidence in their estimates by polling them and coming to a consensus.
  • Calculate a percent confidence: Poll everyone doing their estimates and take an average. (eg, we are 90% confident)
  • Define categories: We have never done a project like this before, have done this once before, have done this a handful of times, we’ve done this a ton of times already. Each category correlates to your confidence level.

Estimating is far from an exact science, particularly in our business when there are so many unknowns. By implementing a system that not only accounts for those unknowns, but also ensures an accurate picture of the project costs means everyone will be better off over the long term.

If you’re looking for more ideas or advanced techniques, please see the sites below: