Tips to validate a development estimate

Jose -

in the absence of expert judgment (related to the specific context of the project in question) or sufficiently similar historical data, you won't be able to improve estimation accuracy so a better approach might be to make small bets by using an adaptive approach where you try to surface and tackle the areas of greatest uncertainty early on to increase confidence in the team's approach.

Kiron

Jose,

you might have a look at the nine estimating methods the PMBoK Guide ed7 lists. I found it always enlightening to use different methods for estimating.

Also, make sure you can reassess estimates as you gain more information during the project.

Thomas

TLDR - the primary factors to improve the accuracy of your estimates, especially on unique project work, are time and effort. I would call out "understanding the work" in that statement, but understanding the work SHOULD follow time and effort.

I'm going to sound redundant, but make sure your estimates include a range. I'd go so far as to say that if you're not providing a range, you're not providing an estimate; your audience will most likely assume the same. I'm not saying you shouldn't calculate a deterministic estimate, I'm saying you should communicate a probabilistic estimate.

Here are some (oversimplified) approaches to estimating:

- Top Down estimating is helpful when you're doing something similar to something you've done before. That is what you're describing in your scenario.

- You can use Bottom Up estimating once the tasks have been identified. The sum of the tasks gives you the overall estimate.

- Three-point estimating (PERT) also requires that you know the tasks and then calculate an estimate based on the pessimistic, optimistic, and most likely estimates.

I will typically use more than one approach to estimating, on a project. If you're not familiar with the Cone of Uncertainty, you should look into it.

At the beginning of a project, you may not know much about it. If it's truly a unique endeavor, you don't know much about the tasks, either. Unfortunately, leadership wants to know how long the project will take and how much it will cost before you start. This is where Top Down estimating CAN help. But, this is a ROM (rough order of magnitude) estimate. On average, ROM estimates are thought to have the potential for 100% variance: -25% to +75%. So, the range of variance for a ROM estimate for a $10,000 project would be $7,500 to $17,500. You improve the estimate, and the variance, by learning more about the scope and tasks of the project, reducing uncertainty over time.

Key points for improving your estimates are:

- once requirements are done
- once the WBS is complete and tasks have been estimated (Bottom Up)
- as you get closer to finishing testing (on a software project - defects can really blow up your schedule)

If you're using Scrum or Rolling Wave Planning/Progressive Elaboration, you are effectively stretching out the cone of uncertainty. You can estimate a few sprints or your current wave to a low degree of uncertainty, but the rest is still a ROM estimate, at best.