Consultant| Canarys Automation LtdBangalore, Karnataka, India
In one of my previous organizations we would calculate EMV while budgeting for project. This was over 10 years back when I wasn't aware of Reserves. We were part of performing organization. We would include EMV for coming up with Project Cost. Would put our margin over this and propose it as Project Budget. Can you please let me if the EMV we calculated can be called Contingency Reserve? Saving Changes...
Sort By:
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Well, it is not the same, EMV is a statistical tool used for many purposes, one being to estimate a contingency reserve, which is a tool for responding to risk. Saving Changes...
as Thomas has indicated, the scope of what EMV can be used for goes well beyond contingency reserve calculations. For example, decision tree analysis (e.g. build vs. buy) often uses EMV.
In the same vein, contingency reserves do not have to be based on EMV. For example, some organizations will put a flat percentage of the estimated total costs as the contingency reserves. While I find this to be "lazy" and they might get challenged for doing so, it happens quite a bit in the "real world".
Kiron
...
1 reply by Ashwin Kumar H M
May 31, 2021 9:42 AM
Ashwin Kumar H M
...
@Kiron - That is partially what we did too :-) Partially because our projects involved the deployment of a lot of hardware on the site. So, we considered the impact we would have on hardware, software and overall cost our organization would be incurred in managing the risk when\if it occurs for coming up with EMV. Can you please point me to some resource that details the right approach to calculate EMV?
Consultant| Canarys Automation LtdBangalore, Karnataka, India
Mar 15, 2020 9:32 AM
Replying to Kiron Bondale
...
Ashwin -
as Thomas has indicated, the scope of what EMV can be used for goes well beyond contingency reserve calculations. For example, decision tree analysis (e.g. build vs. buy) often uses EMV.
In the same vein, contingency reserves do not have to be based on EMV. For example, some organizations will put a flat percentage of the estimated total costs as the contingency reserves. While I find this to be "lazy" and they might get challenged for doing so, it happens quite a bit in the "real world".
Kiron
@Kiron - That is partially what we did too :-) Partially because our projects involved the deployment of a lot of hardware on the site. So, we considered the impact we would have on hardware, software and overall cost our organization would be incurred in managing the risk when\if it occurs for coming up with EMV. Can you please point me to some resource that details the right approach to calculate EMV? Saving Changes...
Hi Ashwin, I recommend calculating the expected value using the Monte Carlo tool for risk analysis. The final contingency depends on the % probability that the organization is willing to assume. P60, or P80, etc. Saving Changes...
The whole function of statistics is to take some small population where we have data, and use that to represent a larger population which is impractical to measure.
If you have data on the intermediate steps, then applying variances at each step may make sense. If you don't, then you assume the variances, roll all those up into a model, and while it looks impressive you really just have some kind of fancy numerical soup.
In the "real world", sometimes there are many variances which cancel each other out, and at a higher level of grouping, there is much less variance unless some major risk materializes. Groups A through G might each over or under-run their estimates, but the total of A-G may be surprisingly consistent. Groups A and D may have high variances over many projects, but generally not in the same project.
If the sum of A-G is consistent, and the budget is under some larger grouping, is it lazy to assign some risk factor to the larger grouping, or is it wasteful to try and calculate every variance knowing that some things will always come in high, others low, and any significant project overruns are due to the realization of a major risk?
...
1 reply by Kiron Bondale
Jun 01, 2021 6:12 PM
Kiron Bondale
...
I'd agree Keith that we always need to balance the cost of doing "more" risk management analysis with the corresponding benefits, but what I've found is that the risk profile of a project is rarely consistent across the deliverables/milestones/lifecycle and hence a flat rate allocation might not adequately reflect the changes in risk profile. Some aggregation is fine, but I'd avoid doing it to too high a level.
The whole function of statistics is to take some small population where we have data, and use that to represent a larger population which is impractical to measure.
If you have data on the intermediate steps, then applying variances at each step may make sense. If you don't, then you assume the variances, roll all those up into a model, and while it looks impressive you really just have some kind of fancy numerical soup.
In the "real world", sometimes there are many variances which cancel each other out, and at a higher level of grouping, there is much less variance unless some major risk materializes. Groups A through G might each over or under-run their estimates, but the total of A-G may be surprisingly consistent. Groups A and D may have high variances over many projects, but generally not in the same project.
If the sum of A-G is consistent, and the budget is under some larger grouping, is it lazy to assign some risk factor to the larger grouping, or is it wasteful to try and calculate every variance knowing that some things will always come in high, others low, and any significant project overruns are due to the realization of a major risk?
I'd agree Keith that we always need to balance the cost of doing "more" risk management analysis with the corresponding benefits, but what I've found is that the risk profile of a project is rarely consistent across the deliverables/milestones/lifecycle and hence a flat rate allocation might not adequately reflect the changes in risk profile. Some aggregation is fine, but I'd avoid doing it to too high a level.
Kiron
...
1 reply by Keith Novak
Jun 02, 2021 1:36 PM
Keith Novak
...
I agree to an extent, but people often fall into the trap of trying to precisely quantify the unknown, when in many cases, a simplified version will often be accurate enough to be useful.
This proves itself out in many cases. If you were to estimate the "tolerance stack" of many items of different length laid end to end, to find the total length including the errors, the root mean squares method is extremely simple and the standard method. If you were to lay out very complex equations to do the same thing using partial differential equations, the largest error source will dominate the result. If many people guess the number of beans in a jar, and you average their guesses, that average will be surprisingly close to the actual number (The Wisdom of Crowds). The point being, you can spend a great deal of effort to estimate the uncertainty from many sources, but often that is no more useful than a simplified approach.
I do however find the discussion of risk sources and magnitudes extremely valuable. It helps with the understanding of what's actually going on and what can go wrong. You are likely to start mitigating the risks in that process of discussing them as people explain how some big risk is probably avoidable. The deeper understanding and forethought becomes invaluable when a risk does materialize and you've already talked through it.
When you try and combine the numbers though, the intelligence behind the individual numbers gets lost in the mathematics which combine them, and that's where I describe it as numerical soup.It's great for convincing people that a complicated approach should be trusted for its sound logic, but often it's no more useful than the simple approach, particularly if you have historical data or expert knowledge to justify the rough estimate.
I'd agree Keith that we always need to balance the cost of doing "more" risk management analysis with the corresponding benefits, but what I've found is that the risk profile of a project is rarely consistent across the deliverables/milestones/lifecycle and hence a flat rate allocation might not adequately reflect the changes in risk profile. Some aggregation is fine, but I'd avoid doing it to too high a level.
Kiron
I agree to an extent, but people often fall into the trap of trying to precisely quantify the unknown, when in many cases, a simplified version will often be accurate enough to be useful.
This proves itself out in many cases. If you were to estimate the "tolerance stack" of many items of different length laid end to end, to find the total length including the errors, the root mean squares method is extremely simple and the standard method. If you were to lay out very complex equations to do the same thing using partial differential equations, the largest error source will dominate the result. If many people guess the number of beans in a jar, and you average their guesses, that average will be surprisingly close to the actual number (The Wisdom of Crowds). The point being, you can spend a great deal of effort to estimate the uncertainty from many sources, but often that is no more useful than a simplified approach.
I do however find the discussion of risk sources and magnitudes extremely valuable. It helps with the understanding of what's actually going on and what can go wrong. You are likely to start mitigating the risks in that process of discussing them as people explain how some big risk is probably avoidable. The deeper understanding and forethought becomes invaluable when a risk does materialize and you've already talked through it.
When you try and combine the numbers though, the intelligence behind the individual numbers gets lost in the mathematics which combine them, and that's where I describe it as numerical soup.It's great for convincing people that a complicated approach should be trusted for its sound logic, but often it's no more useful than the simple approach, particularly if you have historical data or expert knowledge to justify the rough estimate. Saving Changes...
Community Champion
