Critical Path and Estimates - Part 1

A recent post on an agile forum conjectured that the Critical Path Method (CPM) is based on two false ideas:

• The task duration estimates are accurate;
• That the plan (derived from these estimates) can be executed in a deterministic manner, including the idea that variation in task duration does not happen.

This is an argument by obversion. This means "let me speculate that you'll do something stupid and then point out that you're doing something stupid."

We have a saying in the large project management world...

...don't do stupid things on purpose.

This would include:

• Stupid Thing #1: Estimating task durations that are not probabilistic or risk adjusted - taking a single value and assuming it represents reality:
  • Pick your favorite probability distribution - mine is the Triangle
  • Pick a risk adjust percentage spread from the "most likely" duration
  • Apply these upper and lower estimates and run a Monte Carlo simulation to expose the sensitivities of the plan to duration estimates
• Stupid Thing #2: Treating the CP as something that is fixed - once identified, the CP is fixed for the duration of the project.
  • Although I can't believe I'm saying this, this is one of the reasons formal project management training adds value to the software development business. When you have a PMP or even sit through a formal project management training class, you'll learn that the Critical Path is a "conversation" starter.
  • The CP is the "current" sequence of tasks that take the longest to execute. The Critical Chain - from the Theory of Constraints - uses this concept, so does the probabilistic models produced by Monte Carlo.
  • But no trained project manager would consider the CP to be fixed. In fact we produce a new CP ever Monday morning when the BCWP numbers come in from the week before.
  • The CP changes with every updated assessment of "actual" progress.
  • A "test question" you might ask yourself on a project is "what is the sequence of work that results in the longest duration for the project?" This is the critical path. If you arrange or re-arrange this work into a shorter path, that would be a useful exercise. In order to determine is you have the shortest path already, you need to do some analysis of this "path."

Time Boxed Scheduling

Many have conjectured that CP is not very useful in a "time boxed" approach to software development. And they are mostly correct. Fixed iterations have little need for "path analysis."

Build and manage the queue of features to be fed into the front of the "time box" machine, get the working code out the back in two to four weeks. From within the time box this works well. From the outside if and only if the work fits inside the time box AND if the amount of work can be known in some way (what is the population of features needed for the system to be useful) and this list is bounded in some way (we've run out of money, stop) then the total duration of the project can be estimated for those on the outside looking in asking annoying questions like:

• How much will this cost in the end?
• When will you be done spending my money?

The nice thing of course is that "some" of the features can be put to work generating benefits. Again If and Only If, they are carefully planned to do so in some manner suitable for the business to absorb their operational in a benefit producing way - but that another "planing" discussion for a later time.

All of these "time box" concepts are great concepts and actually work - If and Only If the two conditions hold:

• Work fits inside the time box or can be partitioned to fit inside the time box, so that when it exits it is done forever and actually provides bookable benefit in some unit of measure recognized by the funding agency (person, system or banker)
• Work entering the time is bounded in some way, so the number of time boxes can be estimated for the completion of the project. Although you could make the case that continuous maintenance is unbounded - but in most organizations I've worked the money is not unbounded.

This approach is the core of agile development. It is also the core of other approaches used in many other industries and has been shown to work time and time again - therefore is a logical approach when the two conditions can be met.

If they can't be met, then something else needs to be used to estimate the total duration of the project - the Critical Path.

So Why Is There So Much Misunderstanding About These Topics?

In theory there is no difference between the theory and practice, in practice there is.

In practice the CP methods provide insight into the complexities of projects.

Applied with understanding and skill CP is a powerful tool to sort out what is the impact is the sequence of work on the completion date of the project.