Please login or join to subscribe to this thread
The key is looking "Cone of Uncertainty" which belongs to Barry Bohem and it has been taken for lot of different industries. It is a paper you can find into the internet. The complete work is inside "Software Economics" book.
You'd likely not be establishing contingency reserves, defining and baselining your budget until your estimates were more refined.
However, once you are down to a low variation, your budget would include the contingency reserves to address the financial impacts of realized, identified negative risks.
So if you had a situation where your team had estimated costs of $50K with a potential 10% increase due to realized, identified risks, then the budget would be $55K ($50K expected + $5K contingency reserves).
The contingency is usually based off the accepted most likely estimate or the mean value, so you would base it off the 100k.
You don't necessarily have contingency for the worst case estimate (125k in your example). The 3 point estimate describes a range and you might say that with a reserve of only 110k then you have an 80% chance of at least break even or better.
If you tied up the whole 25k for the contingency, that money can't be used for other revenue generating projects.
Is it normal practice to determine the entire project budget with accuracy +/- 10% before Detail Design phase, considering that there is no feed or pre-feed?
The point is that we are usually provided with estimates level 5 at project initiation stage and accuracy +30% to 100%. With no optimistic or pessimistic options. As I understand now, we should present the these estimates with accuracy to validation committee. And probably re-present the new estimates after design phase if its above the initial estimates and its accuracy
When the conceptual design is complete, your estimate might be to WBS level 3. At the end of preliminary design it might be to level 5. Prior to starting manufacturing where costs increase dramatically, the estimate would be updated and refined again.
On large projects that last multiple years, many things could change that could impact whether the project is still a good business venture such as market changes, interest rates, or new technologies. Those need to be periodically reassessed along with the latest cost estimates to evaluate whether the project still meets the stakeholder expectations.
Your contingency reserve should be based on project risks, not budget uncertainty. For each risk, you calculate the cost of contingency actions (actions taken should the risk be triggered) and multiply by the risk's likelihood--between 0 and 1. For example, if a risk has a 20% post-mitigation likelihood of being triggered with a cost of $20,000 for the contingency action, you have a weighted risk contingency cost of $4,000. You add up all the weighted risk contingency costs to get your contingency reserves.
Your budget should be reviewed regularly, usually monthly, and a new outlook produced. The outlook includes your actuals to date and your revised forecast for the remainder of the project. This allows you to either seek additional funds, if necessary, or relinquish those no longer necessary.
Not sure what you mean by "feed or pre-feed" so some clarification would help.
In general, for a predictive life cycle, you'd not be in a position to provide a definitive budget before you had reached a high level of confidence in your solution design.
Please login or join to reply