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.


The 3 Layers of an Organisation’s Processes

April 30, 2009

Look at the processes in any organisation and they can be split quite neatly into 3 layers.

  1. Operations. These processes are the lifeblood of the organisation. Each and every one of them contributes directly to delivering goods / services to the organisation’s customers. The people operating these processes are the organisation’s front line, and woe betide the organisation which doesn’t recognise this.
  2. Infrastructure. Any organisation has to be managed, so it needs management processes. Think of Finance, HR, IT, Facilities…. The processes behind these functions are not directly customer facing but they are still essential to the business.
  3. Change. The invisible layer, but a particularly important one as change and innovation becomes an increasingly important factor in the survivial of an organisation. Think of the 3 Ps – projects, programmes and portfolios. These activities bring change and these activities need to be managed. Any organisation undergoing change has a need for change processes.

It seems to the DeliveryDemon that many organisations struggle to optimise their change processes. Change activities are often tied to the business unit undergoing change, with limited links to the broader business, and little if any coherent attention to the change processes themselves. Strategic planning activity gives rise to change in both Operational and Infrastructure processes, but many organisations give little thought to the Change processes which form the bridge between strategy and delivery.

The Carnegie Mellon Software Engineering Institute’ Capability Maturity Model has been around for some time http://www.sei.cmu.edu/cmmi/. Although its roots are in software development it is in fact a widely applicable model. It classifies processes as:

  1. Initial
  2. Repeatable
  3. Defined
  4. Managed
  5. Optimizing

CMMI Models are a good foundation for assessing whether Change and other processes operate reliably and consistently. What they don’t provide is a model of good practice for the processes being assessed.

As change and innovation become ever more important to the success of commercial organisations, the DeliveryDemon is watching to see which organisations are leading the thinking when it comes to optimising change management in order to deliver strategy effectively.