What should be Considered when Estimating Effort?

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 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 consumer of such numbers:

Performing the actual estimation is not the topic here, we have separate blog pages for that for the project team:

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. this 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 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 it is also worthwhile to endure it if the new information status produces an estimate for which the business case no longer looks so rosy. The question then 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 opening 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 to reach 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 them and 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 make structured estimates.
  • 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.

Never accept an estimate (whether internal or from external suppliers) simply as a number, but question it: is it a wish, a truly informed "bottom-up" estimate, or a politicized number?

Andreas Stucki

Was ist Ihre Meinung? Bitte kommentieren Sie hier!

Keywords/ Tags

Comments

No Comments

What is Your Opinion?

* These fields are required

Share On

Let us discuss your idea/ your project