Time to Read 6 min
The road seems narrower in the distance to the horizon, unfortunately the effort estimate does not, it becomes wider in the distance of the future....
"Prediction is difficult, especially when it concerns the future" Danish proverb
We see time and again that the topic of effort estimation leads to discussions between developers, project managers and management. Therefore, we have summarized here our thoughts and experiences on this topic "for managers", i.e. for the consumers of such numbers:
- How much trust does the estimate deserve?
- How "accurate" can estimates be anyway?
- Why are estimates "never" correct?
Performing the actual estimation is not the topic here, we have separate blog pages for that for the project team:
- Effort estimation in general
- Project estimation when a specification already exists
- Coarse (ROM: Rought Order of Magnitude) estimation with little information
How Much Trust does the Estimate Deserve?
Most of the time, an estimate of development efforts and especially development costs is simply a number that is needed for planning, i.e. as a basis for decisions. The number can be used as a basis for cost accounting, as a basis for time-to-market planning or even to justify the investment in product development to the board of directors or investors.
Unfortunately, this one number has a history. This background affects the trust one can have in the number. The trust depends on two factors:
- Level of information at the time of estimation: What was already known of the project goal at the time of estimation: just a product idea or already all the details of a complete set of specifications or requirements?
- Estimation methodology and thus also estimation effort that was spent: Was the estimate simply thrown out there as a number by one person, or was there a structured estimate, e.g. using one of these estimation methods?
So it would be appropriate to put a disclaimer on the number stating:
- how well the estimate can be trusted
- for which decisions it should be used
- for which decisions it would be appropriate to verify and improve the estimate
If the business manager, for example, uses the first, intuitively optimistic estimate from the product management workshop for his business case, then he can almost be sure that he will be allowed to give another presentation with a budget supplement that is higher by factors...
Therefore, before using the estimated project effort in decisions, it is worthwhile to ask where the estimate comes from, how it was made, and on what level of information it is based. And also to endure if the new level of information produces an estimate for which the business case no longer looks so rosy. In this case the question arises as to whether it is not better to have a more realistic estimate on the table now than to have a massive budget overrun later?
How "Accurate" can Estimates be Anyway?
Cone of Uncertainty
An estimate is always subject to uncertainty. For example, the farther away the end of the project to be estimated is, the greater the uncertainty, i.e. the right opening of the funnel. What does this mean for planning? Part of the uncertainty can be captured by systematic estimation. The rest can be included in the planning on the one hand, and on the other hand a new estimate can be made after some time, which should then be more accurate.
Where does this Cone Come From?
The reason for this cone or funnel are the risks, which are present in every project:
- Risks of the project scope: what belongs to the project and what does not (which features, which interfaces, which standards...).
- Technical or more general realization risks: what may not work out
- Estimation risks: general estimation errors, mostly people are too optimistic...
The risks that the project contains also result in the width of the cone towards the future: the less risks a project contains, the more accurate I can estimate.
Estimate or Promise?
Many estimates start life as a number thrown around at a meeting, as a first order of magnitude, usually with great optimism. This number should not be taken as a promise for the effort of the project.
When we as Solcept really make a promise (e.g. when we offer a fixed price), we put quite a lot of effort into achieving a sufficient accuracy, e.g. we perform a system design phase and a structured estimation.
Why do we do this? Because so we are limiting the risks:
- Scope risks: contained with clear requirements
- Technical risks: contained with architecture and rapid prototype
the remaining risks are identified and are part of the promised scope (called "risk management") - Estimation risks: contained with structured estimation methodology
How do we Proceed at Solcept?
If at the beginning of a project, you want to have an estimate, we perform a coarse estimate based on the desired functions or assumptions about those and on our empirical values for documentation, testing and integration.
After the system design phase, where a system specification and a system architecture are created, we can perform a project estimate, at least on the part that is already clear. This is significantly more accurate. Each next phase can then be estimated this way once the scope of the phase (i.e., the requirements that the product should meet after the phase) is clear.
Why are Estimates "Never" Correct?
There are several reasons when estimates are "never" right:
- Tightened Parkinson's Law: There is Parkinson's Law: "Work expands so as to fill the time available for its completion". If the leadership is a proponent of this law in its tightened form: "...so on principle we approve only one third of the estimate", then it is clear that the estimates can never be correct.
- Poor estimation methodology: many organizations do not perform structured estimations.
- Optimism estimation: the organization is stuck with the first number given in e.g. the product workshop.
- Default target instead of estimate: The estimate is already known as the default ("it was sold for that price").
- Not enough resources: Not enough experts and especially not enough time are available for an estimate.
- Our experience shows that for a reliable project estimate about 1% of the subsequent project effort has to be calculated.
You say now: this is too much, only for an estimate! And you are absolutely right, because the project estimation also produces the planning basis for the project, namely all tasks (work breakdown structure) and the inital list of all risks.
- Our experience shows that for a reliable project estimate about 1% of the subsequent project effort has to be calculated.
We think you should never just accept an estimate (whether internal or from external suppliers) as a number. Question it: is it a wish, a truly informed "bottom-up" estimate or a politicized number?
Andreas Stucki
Do you have additional questions? Do you have a different opinion? If so, email me or comment your thoughts below!
No Comments