Critical Path and Estimates - Part 2

There are two types of uncertainty on any sufficiently complex program:

• Technical - uncertainty about the functional and performance aspects of the program's technology that impacts the produceability of the product and creates delays in the schedule
• Programmatic - uncertainty about the duration and cost of the activities that deliver the functional and performance elements of the program, independent of the technical risk

By connecting technical and programmatic risk a clearer picture of the overview performance of a project can be gained.

Agile Approaches to Technical Risk Reduction

Agile development methods are based on many principles. But the one principle that deals with technical risk reduction is iterative delivery of working products. This of course does not remove the "requirements breakage" risk, but it does force the customer to address requirements changes in fine grained increments.

Requirements in fact age. The customer gets "requirements fatigue" and gives up control over requirements management, producing higher requirements breakage rates. Agile deals with requirements fatigue and breakage through rapid delivery of working software on fine grained boundaries. This rapid delivery confirms that the requirements provided at the beginning of the iteration are still valid.

If the project team can put the delivered requirements to use and if they can get those requirements stabilized - accepted for use - then the project can reduce the requirements breakage rate.

Agile Approach to Programmatic Risk

Fine grained boundaries for delivery provide fine grained visibility into a project's programmatic performance. This does not remove the programmatic risk - it only makes it visible to management so intervention can take place on the same fine grained boundaries. It is this lack of intervention opportunities that is the primary cause of project failure.

Project are still populated by humans, run by human, managed or mismanaged by humans.

The rapid and repetitive feedback created by an agile development environment exposes the failings of both the technical and programmatic aspects of the project - but also the failings of the humans involved with these technical and programmatic aspects.

So What Does the Critical Path Have to Do With This?

In any sufficiently complex project the term uncertainty takes over from deterministic and becomes the dominate operative force. It is total bunk to say that properly managed project, looked after by good project managers use deterministic data as their basis of performance management. This is a myth perpetuated by some in the agile community and by others with little or no understanding of how good projects are to be managed. Even my not-so-favorite PMBOK advises PM's to use ESTIMATES of duration when constructing the project plan - not the FACT of task duration.

But more importantly uncertainty is about the lack of certainty. Uncertainty is about the variability in the project's performance measures - cost, duration, quality. Uncertainty is about the ambiguity associated with a lack of clarity. Discovering the known and unknown sources of bias and ignorance helps define how much effort it is worth to clarify this uncertainty.

As well uncertainty arises from the basic processes of work. This is the Deming uncertainty. It is the statistical noise built into the work process. Both these sources of uncertainty impact cost and schedule. Trying to control the noise adds little value. Trying to control the lack of certainty arising from ambiguity and lack of clarity does have value.

Plans are Networks of Random Variables

Task completion dates and their efforts are random variables. These variables have underlying probability distributions. These distributions can not be "added" in the normal sense of arithmetic to produce a project completion date.

The failure to understand that these random variables exist creates several problems:

• The Critical Path approach to planning can be misunderstood to be deterministic throughout the life of the project. This is a naive assumption, but one made by naive project managers and critics of traditional project management failing to understand that the probabilistic nature projects is also known to others. Both are misinformed.
• The durations and the resulting dates can be misunderstood to be deterministic as well. Failure to separate the "noise" from uncertainty induced variance simply increases the probability that the project will run into trouble sooner than later.

With the random variable aspects of the project network are understood, specific interventions can take place - this is the role of programmatic project controls.

• The project members can stop believing in the deterministic nature of plans and start understanding that the network of random variables is their best effort approach to understanding the programmatic risk model of the project
• The critical path can now represent the probabilistic critical path rather than a deterministic critical path.
• The confidence interval of the project completion date can now have meaning
  • This project will complete on or before December 12th, 2006 with 80% confidence
  • The cost of this project will be $125,000 or less with 80% confidence

The beginning of this discussion is in Part 1