Why Single Point Estimating?

July 9, 2009

A couple of weeks ago DeliveryDemon got involved in some interesting discussions about whether a single point estimate could actually exist. Various thoughts circulated for a while before being buried in a deluge of other ‘stuff’. Now the ‘stuff’ has been cleared, the thoughts are coming to the surface again.

Certainly an estimate has associated with it a degree of uncertainty. Depending on  who’s looking at it, understanding of that uncertainty varies with the eye of the beholder. A good estimator will have a fairly sophisticated view of the nature and range of the band of uncertainty. Some people will recognise the existence of the uncertainty without having much understanding of how it can be managed. Some people are oblivious to its existence while others take a position of total denial – ‘Just give me the number. What’s wrong with you that you can’t give me a single number?’

There’s an education gap creating the demand for a single number. There’s also something more systemic. Take a look at budgeting systems. They demand single values for each line in the budget. If a manager wants to create contingency to allow for uncertainty in a project, the common ways of doing it are to include contingency in each budget line, and to have a separate slush fund for allocation at the manager’s discretion.

This approach was a minor anomaly in the days when business as usual consumed nearly all of a company’s budget. Today, Change is an important business function and companies often need to allocate a substantial proportion of the budget to it. The anomaly is becoming a significant problem for two reasons:

  • A large uncertainty factor is becoming embedded in every budget
  • The company does not know how much contingency it has in its budgets, and how much contingency it needs. As a result it is not in a position to manage contingency in line with business priorities.

The DeliveryDemon doesn’t have a perfect solution, but a working solution would have some of the following features:

  • Three figures associated with each budget line – target, best case and worst case, with budgets being based on the target figure
  • The ability to allocate contingency to individual budget lines based on the best case / worst case figures
  •  The ability to allocate contingency at an aggregate level, thus reserving decisions about its use for more senior management. This would also allow for a lower contingency figure, on the assumption that not all lowest level budget lines would need to call on contingency.
  • A process to review allocated contingency, and retrieve it when the need is reduced or gone, or reallocate it should business priorities change.
  • A requirement to justify the use of contingency, to offset the human tendency to use up the funds available.

Some of this happens in practice in some companies, but not as an explicit process, which is dangerous from a due diligence perspective. The big difference will come when Change is recognised as a fundamental business function, and managed from a strategic perspective in the same way as other major business functions. Once that happens, Change ceases to be special. Its processes and characteristics will be made explicit  in the same way as those of any other business function, as will its interfaces with other business functions. When Change is recognised as just another business function, then it makes sense for it to feed business requirements into systems design, which will be an interesting challenge to current budgeting and contingency management conventions.


Expectations and Single Point Estimating

June 7, 2009

Bob Barnes and Fred Baker have an interesting blog post entitled Project Life Cycle is Essential in Managing Risk. Their blog is at http://www.pmprofessors.com/ This is an interesting example of stakeholder expectations, and here’s the DeliveryDemon’s take on it.

Common understanding of an estimate is that it is a single point value. As project managers we know that there is an uncertainty range associated with any estimate, which narrows as more knowledge becomes available through the life of a project. Business processes tend to force us to provide a single point estimate, and expectations are adopted on the basis of that value. It’s an ongoing piece of work for a project manager to keep stakeholders in touch with the reality of what is happening, and that is no guarantee that a stakeholder won’t suddenly revert to the original expectation.

This is a reflection of the current level of maturity in non-PM understanding of project management processes. It won’t go away until PM becomes a core business competency, at the level exercised by today’s above average PMs, and we are still some way away from that.

Today’s PM needs to be aware of the issue and factor it into stakeholder expectation management.