Uncertainty

In terms of my last post this looks like starting at the end but, since project lifecycles and policies are adopted in the first place as a coping technique for uncertainty, it is the logical first stop.

Uncertainty for most of those faced with managing a project tends to be conflated with risk, and more or less rigorous application of tried and tested risk management techniques is deemed to be the most that can be expected. In practice this hardly scratches the surface. I’ve found the differentatiation suggested by Lawrence Leach useful here. He differentiates between Common-Cause Variation (to the planned work) and Special-Cause Variation – essentially risk. Whilst I am of the opinion that much of what passes for risk management could benefit from much greater rigour (especially the handling of conditional risk), that is not what I mean to address here – for now anyway. I want to explore uncertainty, especially as it applies to outcomes.

Uncertainty and value from projects

When a project is commissioned there are large areas of uncertainty that impact the potential value it can deliver. Many of these are far more direct and predictable than the usual ‘Special Cause’ uncertainties that are encompassed by a risk register. Effective project governance, planning and execution must also explicitly encompass the management and mitigation of these ‘Common Cause’ uncertainties.

If project requirements start, as they must if projects are to have a chance of success, by establishing clear objectives with well-defined measures and targets, then an overall performance expectation is set. This establishes what I’ll call the ‘Potential Benefit’ and, coupled with the expected resource requirement, defines the project’s potential value. In devising a solution that we expect will deliver the required level of performance we must distinguish, and address, several forms of uncertainty that attach to any proposal. Briefly stated these include:

• Required outcome uncertainty – uncertainty about the clarity with which intended outcomes have been specified and are measurable;
• Solution uncertainty – uncertainty about the underlying causal assumptions and the probable actual performance of the outputs;
• Adoption uncertainty – uncertainty about whether those who need to learn and apply new skills, or simply do something differently, in order to benefit from or manage the outputs will actually do so, and in the way intended;
• Delivery uncertainty – uncertainty about the schedule, organisational dependencies, task times and resource availability that impact on, and usually delay, delivery if they are not managed.

On top of this of course we must add the special-cause uncertainty already discussed– those uncertainties that are properly addressed through risk management techniques.

All, or any, of the above may affect the ‘Realised Benefit’ on delivery. Similar uncertainties surround lifetime cost and thus the actual value that is realised by the project (more on uncertainty about resource use later). Failure to adopt an approach to a project that acknowledges these uncertainties,  manages them where possible, and accounts for them in their estimates where not, almost guarantees failure. Yet most are hardly considered, let alone managed.

Where did the value go?

This blog will start with an exploration of how we get value from projects. I hope to expand into broader issues  value,  but everything must start somewhere.

So let’s start with those awful statistics about value from projects (or the lack of it):

• 80% cost more than the total value they create; (Mercer Consulting, Dosani)

• 71% are not deemed to have been a success after they are delivered; (Standish Group Chaos Report, 2007)

• Over 52% of projects cost more than 180% of their allocated budget; (Standish Chaos Reports)

• 65% of the outputs are never, or hardly ever, used; (Standish Chaos Reports)

Despite this:

• (only) 10% of projects are abandoned. (Oxford University, Saur & Cuthbertson)

I could go on. Yes, most of these statistics are gathered from software projects, but the record is not good in any discipline. As usual the results vary somewhat from sector to sector. Probably they depend on variables like the degree to which solutions are established and well tested and, of course, whether success has been defined or is being evaluated at all.

Causes

As much effort has gone into identifying the causes as into the problems. Common causes identified include:

• 80% of all the issues stem from poor scoping & requirements, and 60% of defects are due to specification flaws; (Standish Group Chaos Report, 2007)

• 80% of overrun costs involve rework; (National Institute of Standards and Technology)

• 65% of features are never or rarely used; (Standish Chaos Reports)
  

The two major sources then are poor requirements and rework. New lifecycles, such as Agile, are intended to deal with these issues but, as generally practiced, really only address the second.

Organisations are disabled from effective project dleiery by a number of practices that were, usually, put in place to improve on past results, and may once have helped. The primary inhibitors will explore, at least to begin with are:

1. Policy (as dictated by project governance)
2. One-size-fits all lifecycle planning
3. Narrow understanding of uncertainty and its impact (to be fair this one is probably not imposed, it is nearly universal)

This leaves plenty of room for speculation about how things might be improved.