Work

Estimating IT projects

Home \ Work \ Estimating IT projects

I’ve estimated a fair number of IT projects over the years. Each estimate has always been accompanied by a variance that accounts for uncertainty – something like “x years, plus or minus a factor of y”.

A trend emerged. My nominal estimate (“x years, minus a factor of y”) was the number that stakeholders looked for, and took literally. Inevitably, when things don’t go to plan (almost always) I was asked why my estimate was so bad.

Having to explian yourself is never fun. I used to do this by referring stakeholders back to my wording, and the cone of uncertianty (see below). The point is that the only time you can produce an accurate estimate is once the project is complete. Hence my estimate variance.

This led me to not include a number that stakeholders will pick out and hold me to. Instead I now include the diagram above, and the following graph –

The word nominal is chosen carefully, because, after only a couple of weeks on the project, my estimate of one years’ effort is nothing more than a guess. Tokenism. Being such in name only. Putative. Being trifling in comparison with the real value. I’ve gotten a lot less heat from stakeholders since I began presenting my estimates like this.

Of course these days the statement that inevitably follows when people see the cone of uncertainty is "We do agile, so those milestones don't appy to us." True. In agile you've yet to name your milestones...

The way to remove uncertianty is to research what's unknown. In old-school terms that means doing conceptual, logical and physical designs, creating project plans, and then an estime (a project schedule). The estimate is refined with knowledge gained from throw-away proofs of concept, prototypes, and as development continues.

In the agile world someone creates a backlog of epics (epic user stories, not the War and Peace variety), which amounts to a statement of scope. The team then estimates complexity by assigning t-shirt sizes or dog types like Chihuahua or Great Dane to each epic¹ (Gregor has a very pragmatic perspective on story points). This aligns the agile world with the old-school Vision/Scope complete milestone. The next agile step is to start writing code, and measuring velocity. This is used to refine the estimate. In other words, the estimate is refined retrospectively, rather than progressively as in say, a waterfall-like environment. While the result is similar, the cone of uncertainty doesn't include named milestones from the outset, because agile milestones are completed sprints. Sprints are determined as the project unfolds.

If you want to know more about the cone of uncertainty, or software estimation in general, read Steve McConnell’s book on software estimation. It's the best and most complete resource on estimation.

[1] Michael James (2007). Applied Macromeasurements to Ensure On-Time Delivery, an Agile Approach to “Metrics” (.PDF).

< Back to Work | ^ Back to top