Thanks for your question.

Examples do tell more than principles, don’t they? I think the question you and John are asking is: how much of a “reserve” do I allocate and how to I justify it.

Again, in principle, what this means is coming up with likely scenarios, usually a “high” and a “low” and having a justification for each.

Here are two ways we arrive at justification for cost ranges:
- PERT, which finds the standard deviation among the Pessimistic, Most Likely, and Optimistic estimations for a list of tasks; with PERT, we share the highest bound number as the estimate and we internally use the lowest bound for estimations. Internally, that difference becomes our management reserve.
- SLIM estimate, a software project modeling tool, we are presented with probabities. We usually quote the 65-75% probability for the customer and the 50% probability internally.

With SLIM, we are able to share the probabilities with the customer and encourage them to choose a budget, around the 75-85% range that they can take to their sponsors.

We essentially recommend the following language to the sponsor:

“Based on what we know now, your project will cost x. We also know that over the course of time, you will want to make changes, which will increase the cost of the project. If you have communicated a fixed cost to your executive sponsors, change will result in x-y. If you negotiate a higher amount, the result will be x+y. You will have control over the y.”

The purpose of the reserve is not really to protect the contract, it more to ensure productivity, so that when there is change, the sponsors don’t sacrifice more than they gain.

I’ll share some more examples at http://www.ciocode.com.

Most management teams would look for savings out of the project cost and slash the budget as their way of “adding value”.

Then they complain when the project runs over budget.

Project managers then respond by padding their estiamtes to hide contingencies from their executive teams.