Why Single Point Estimating?

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.