Critical Path Myth, Part 1: Confusion & Illusion

Overview

Blog Series Abstract: The widespread faith in the Critical Path Concept is not justified by the facts. Still, those with a vested interest in their projects finishing timely continue to support the Critical Path Concept and embrace recommended practices that they are told will lead to more successful projects. This three-part blog series is intended to shed light on the Great Delusion under which most Project Management stakeholders unknowingly suffer.

Myself hardly naïve, I fully expect disagreement with what is written in these three blogs. The resistance expected from proponents of Critical Path Concept is both understandable and anticipated. I am comforted by a saying in the Air Force: “if you’re drawing flak, you must be over the target.” I remain hopeful that the discussions and debates that this Blog Series is certain to provoke will nonetheless facilitate the kind of open, honest, and informed dialogue needed to at last turn around the ship upon which we all sail together. The truth shall set us free.

About Critical Path Myth, Part 1: Confusion and Illusion: Unknown to most outside the technical ranks, there is widespread confusion and disagreement regarding virtually every aspect of Critical Path technology. And yet, despite the Confusion that such differences have caused, there is continued propagation of the notion that the Critical Path Concept is worthy of the pre-eminent influence and reputation it has acquired over many decades. The ultimate consequence is a grand Illusion, one that is at last achieved through a crowning touch: specifically, the precision of the sizzle  obscures the uncertainty of the steak.

In Part 1, we will examine what the Critical Path Concept is at its fundamental core. I suspect that many readers will be surprised to find it fraught with technical limitations and deficiencies. That these inherent demerits are not mentioned often or loudly throughout prominent Project Management literature is a matter for Project Time Management stakeholders to pursue, if they are so inspired. Let’s begin:

Widespread Terminological Differences

We begin by looking at the most fundamental building block of every Project Schedule: the activity. Here are some of the disparities of opinion among scheduling practitioners as to the activity element:

  • Activity: Some consider a “task” to be a subset of an “activity;” others consider the “activity” to be a subset of the “task.” Still others consider the two terms synonymous.
  • Duration: Some believe that an Activity Duration ought to represent the shortest, reasonable length of time need to perform an Activity. Others think it should reflect a greater likeliness of timely achievement, and thus should reflect an arbitrary confidence level; for instance, 90% probability of achievement. Some (Critical Chain proponents, in particular) argue that Activity Durations are normally padded at conception, and thus should be slashed across the board by a certain percent, the removed Duration portions being put into one or more buffer Activities somewhere else in the schedule.
  • Path: Despite the word appearing in the name of the Critical Path Method, one is hard-pressed to find a definition for the term, path, in conventional Project Management literature. As for opinions as to what constitutes an Activity Path, there are several possibilities. An Activity Path might be a string of consecutive Activities that:
    • Have the same Total Float value and for the same reasons. Such a Path might not span from a separately-defined Path Start or terminate at a separately-defined Path End.
    • Commence at a separately-defined Path Start and terminate at a separately-defined Path End. Such a Path might have different Total Float values along its length.
    • Spans from the very start of the Schedule all the way to the very end of the Schedule. Such a Path might have different Total Float values along its length.
  • Critical:  Just as surprising as the ambiguity surrounding the term, path, there is hardly universal agreement as to how criticality is determined, or to what it is applied:
    • Some believe that it is the Path that is critical, and that Activities along the Path acquire their criticality from the Path to which they belong.
    • Others believe that it is the Activity that is critical, and that the Path acquires its criticality from the Activities that reside along its length.
    • Still others believe that criticality is a subjective value, which may be set or adjusted, schedule-by-schedule and update-by-update, as falling below a predetermined statistical threshold. As just one example, a Path would be deemed “critical” if its Total Float was either zero or a negative value.
  • Subsidiary Terms: There are a host of other terms pertaining to the Critical Path Concept, and most (if not all) of these suffer from a lack of unanimous definition. Included in this subset are terms like: lead, lag, constraint, restraint, event, deadline, milestone, window, calendar, and so forth.

And the daddy of them all is the very word, schedule. Believe it or not, there is even widespread and passionate disagreement in the Scheduling Community as to what is a Schedule. Is it a Schedule Model, as some insist?  Or is each iteration of a Schedule to be called a “schedule?” Is it a database of temporal information? Perhaps a Schedule is differentiated by who gets it, what it contains, how detailed it is, etc.?

Disagreement Over Key Computed CPM Values

Let us move up one level from the base terms themselves and consider how the Critical Path Concept evolves into a set of formulas, definitions, processes, and techniques. It is here that we will find an additional smothering layer of confusion.

Definition of Critical Path

Just what is a “critical path?”  This sounds like such a basic question. And after five decades of the Critical Path Method, surely there must be a clear, concise, and universally-accepted answer to the question. There isn’t!

  • Least Total Float Path: One of the two most popular definitions of a Critical Path, some believe it to be the Path having the least (or lowest) Total Float. Of course, as can be demonstrated beyond debate, the Least Total Float Path is not always the Longest Path through the Schedule. In fact, quite often it does not even terminate at the end of the schedule, and many times does not commence at the start of the schedule!
  • Longest Path: This is the other of the two most popular definitions of a Critical Path which argues that the Critical Path is the longest Path of Activities through a Schedule. It often insists that the Longest Path terminate at the Schedule’s end, and commence at its start. Just as often, these requirements are left out of the definition. As it turns out in practice, the Longest Path can often have different Total Float values along its length. Furthermore, try finding Longest Path definitions that explain how to determine a Path’s “length.” Is it the sum of the Durations of the Activities along its length? If so, how are overlapped Activities treated?
  • Driving Path: This third option is, by the admission of most its advocates, not actually a Critical Path, per se. Instead, it is a method for tracing a Schedule’s Longest Path by way of an arithmetic process that purposely disregards Date Constraints. The Driving Path method exists to overcome the problem of a Longest Path having different Total Float values.  Still, it traces a Path that can have different Total Float values.

Formula for Total Float

This brings us to the all-important Total Float value, for which there is no widespread disagreement either.

  • Start Total Float: A very common formula for Total Float is stated as Late Start minus Early Start, which yields a value known as Start Total Float. But without referring to it as such, advocates of this formula insist that Start Total Float alone equals Total Float. The flaw in their thinking is that this formula completely disregards Finish Total Float.
  • Finish Total Float: Conversely, there is a formula for Total Float stated as Late Finish minus Early Finish, which yields a value known as Finish Total Float. This formula asserts that Finish Total Float alone equals Total Float. The flaw in this formula is that it completely disregards Start Total Float.
  • Maximum Total Float: A smaller group of scheduling “experts” insist Total Float as the difference between Late Finish and Early Start. This is an especially misleading and useless value, because this formula derives the greater of Start Total Float and Finish Total Float. So, for instance, in a case where Start Total Float is -2, and Finish Total Float is +6, it would yield +6.  [Note: It might actually yield a value greater than even +6!!  How is this value of any practical use in running a project?]
  • Minimum Total Float: The fourth formula, and the one to which I subscribe, is that Total Float equals the lesser of Start Total Float or Finish Total Float. Interesting, of the four formulas this is the least commonly cited or adopted. In fact, it is not the default in many major scheduling software programs.

Formula for Earliest Start

This may seem incredible to believe, but there is even disagreement over how to determine the Earliest Start for an Activity. For many decades the formula was clear and consistent. The Earliest Start date for an Activity was determined through an arithmetic process of addition known as the Forward Pass. Using this method, the Earliest Start date for Activity B was determined by first determining the Earliest Start and/or Earliest Finish dates for any immediately prior, linked Activities, and choosing the greatest of these.

But in recent years, leading and influential scheduling software producers have actually reversed the calculation flow such that the Earliest Start of an Activity is determined by subtracting an Activity’s Duration from its own Earliest Finish!  Said coyly, the Forward Pass is flowing backwards. This may be getting a little too technical, but let me state the net effect of this change.

So why is this a problem? Because the Earliest Start date does not always represent the earliest that an Activity can actually start! It violates the very meaning of the word, earliest. Under certain circumstances, which occurs perhaps as much as 75% of the time in construction schedules, the Earliest Start as calculated under this method significantly squanders precious Total Float. In other words, rather than the Project Team having the final say-so on how the Total Float is expended, the scheduling software makes the arbitrary decision to wait on the start of an Activity until a point in time when, once it starts, it can continue uninterrupted!

Confusion within the Context of the Critical Path Concept

The main point of this three-blog series is that there are some rather pervasive misconceptions about the true level of certainty, reliability, and accuracy capable of the Critical Path Concept. Clarification of such misunderstandings should lead the reasonable mind to rethink the degree of confidence we have so easily bestowed upon the Critical Path Concept.  Here are some things to think about:

Critical Path Schedules are Inherently Inaccurate

A common perception is that there can be great accuracy in a Critical Path Schedule, if properly developed and maintained. But one must be careful not to confuse precision with accuracy.  The Weatherman sets tomorrow’s chance of rain at 50%.  Not 48%, not 52% — 50%!  This is a rather precise statement. And yet, isn’t she just saying that she doesn’t know which way it will go?  “Maybe it will rain on you; maybe it won’t”  Complete uncertainty expressed with great precision.

  • Durations: Activity Durations are estimates. They are numbers given by individuals who estimate how long a particular Activity will take. Furthermore, they base the Duration estimate on subordinate estimates:
    • Crew Composition: In their mind’s eye they envision a certain configuration of workers — by trade, skill level, and quantities of each. These are estimates, for the actual configuration may very well differ in quantity, skill, or proportions of trades to the total crew population.
    • Productivity Rates: Assuming a certain crew configuration, the next estimate they make is about the amount of work that the crew can perform over a given period of time.
      • More Than Aggregation: And this is more than a simple aggregation of each worker’s individual productivity rate. There is a synergistic aspect that must be considered. For instance, a slow laborer can encumber a fast bricklayer.
      • Sources of Productivity Rates: Two common sources for productivity rates are (a) industry production tables, and (b) prior direct experience. Industry production tables make many assumptions, and ask the user to speculate on working conditions. As for using prior experience:
        • The first element of uncertainty is whether the prior experience is sufficiently comparable. Since no two projects are ever the same, and since the range of project experiences is limited within any company and even more so within a small Project Team, the likelihood that prior projects are one-for-one matches with the subject project, is a bit of a stretch.
        • The other element of uncertainty is that there is no justification for the belief that just because a productivity rate was achieved on one or more prior projects (even as an average across many projects) it will be derived on this project.
    • Scope of Work: The amount of work involved in the Activity is also an estimate. After all, the professionals who perform Quantity Takeoffs to determine the amount of materials to be installed are known as … “estimators!”  Plus … the scope of work for any Activity is more than a mere physical quantity of materials. For instance, two walls can require an equal square footage of drywall. But one wall may be filled with openings: doors, windows, piping cutouts, curves corners, etc. while the other wall may have no obstructions whatsoever.
  • Dependencies:  Those logical relationships between Activities go under many names: dependencies, logic ties, leads/lags, restriction linkages, and so forth. What we are talking about is the manner in which a Successor Activity is restricted by a Predecessor Activity. The default relationship, known in the Scheduling world as a Finish-to-Start (FS), is where two Activities are performed in series, one after the other. The other two common relationship types are used to simulate a condition where two Activities are performed more or less at the same time, with the Predecessor starting a little ahead of the Successor. Where assumptions come into play is in predicting whether the two Activities will be performed in series, or overlapped. Make no mistake about it: the overall Duration of the Activity Path and the Schedule itself is dramatically affected, in a cumulative way, by these individual assumptions.
  • In Series: Obviously, if the initial assumption is that Activities will happen one after the other but in reality they overlap, the schedule will realize a noticeable gain. However, the opposite situation is the one to be more feared. Here, at the outset the Activities are expected to be worked somewhat simultaneously, but in reality it is deemed necessary to perform them in sequence. The effect is an elongation of at least one Activity Path, and if that Activity Path is “critical,” then it could lengthen the entire project.
  • Overlaps: In construction, more than in many other industries, Activities are more likely to be overlapped than performed in series. That puts increased importance on what are called “leads and lags,” the numeric values that space the start or finish of the overlapped Activities.
    • Example: Suppose we have a SS: 4 logic tie, which means that the Successor Activity can start no earlier than four days after the start of the Predecessor Activity. This is an assumption, is it not? This much in advance, we cannot possibly know for certain when the Successor will start, relative to the start of the Predecessor.  Maybe it will start three days after the Predecessor starts; maybe five days afterward. The numeric value is an estimate.
  • Schedule Logic is Representative, Not Comprehensive: It is important for the reader to understand that in any CPM schedule, not every conceivable linkage between Activities is ever drawn. For if every Activity were to be tied to every other activity to which it has even a remotely plausible relationship, the Schedule would be so over-tied that it would become completely non-functional. There is such a thing as over-linking a Schedule.  What this means is that inherent in the Schedule’s logic is another assumption: that as the key Activities go (as they are linked), so will the other, non-linked Activities.
  • Execution-Stage Conditions are Speculative: A major set of assumptions are made during Schedule Development as to what will be the working conditions under which Activities will be performed. Since humans are not clairvoyant, these assumptions sometimes smack of “wishful thinking.” As we have all learned the hard way, “the only constant in Life is change.” That tells us that, no matter what we assume or build into our Schedules, reality will be something else entirely.
  • Performance Assumptions are Averages: I purposely inserted this statement here, and not earlier when we were talking about productivity, because I wanted the full weight of this statement to sink in. Whenever we apply productivity rates to Activity Durations, we are applying averages. Regardless of source – whether from industry productivity tables or corporate history – we are assimilating the experiences of other projects and speculating that they will happen on our project at the average rate. But what I want you to ponder is not so much that the source data represents an average … but that the Durations that we assign to our Activities are based on averages. For instance, in a multistory building, we might estimate the same Duration for all ten Hang Drywall activities. But, in reality, when the project is finished, I guarantee that the actual durations for those ten Activities will not be the same exact value.
  • Contingencies are Speculative, Approximate: Finally, even when we humans try to introduce some “reasonableness” into our schedules, we merely inject more uncertainty. The thinking behind Risk Management is that we can give quality pre-thought to what might go wrong on a Project, and then add “contingency” to the Schedule to serve as a time bank that we can draw against, should those unfortunate events occur.
    • First, please realize is that the size of those buffers is subjective, set by other estimates that we make.
    • Second, depending on the nature of the contingency and what policies are in place, the placement of those contingencies can often add further uncertainty. Consider the case of weather contingency. Many construction contracts require the Contractor to “anticipate” the normal weather conditions that might be encountered in the course of the Project.  So the Contractor consults NOAA records and determines the number of inclement weather days one might expect, per month. Now comes the question of where to put the weather contingency?  At the end of the entire schedule?  At the end of each month?  Spread out across the month?  This is a complicated topic, and I could spend many pages discussing it.  Suffice it to say that the mere location of the contingency introduces further uncertainty, especially if the Contract imposes a ‘use it or lose it’ policy when it comes to weather contingency.
  • Schedule Maintenance: Finally, our processes for updating the schedule — in an effort to maintain it as much as possible as a relevant, reflective, and realistic management tool — are replete with speculation and approximations. Our assessments of Percent Complete, for instance, are almost entirely subjective. Our estimates of Remaining Duration are .. just that, estimates!
  • Attempts at Accuracy are Speculative: I close by noting that, in reaction to the speculative nature of Duration Estimates, some “experts” have called for the return of the three-point Duration Estimate, popularized back in the 1950s by the Program Evaluation and Review Technique (PERT). This method involves assessment of three Duration values: Most Optimistic, Most Pessimistic, and Most Likely. By way of  formula, these three values are then combined to yield what is offered as a more realistic Activity Duration. I am here to remind the reader that all three subordinate values are, themselves, estimates.

 Closing Statement

As I bring Part 1 to a close, I wish to draw your attention to something that may be obvious enough, and yet may get lost in the length of this post. Total Float is a very unstable, and hence incomparable, value. For all of the reasons given above, the typical CPM Schedule is a massive packet of assumptions. The odds of the actual Project ever unfolding precisely as detailed in the initial Baseline Schedule is … well, incredibly unlikely!

All it takes is just one activity to slip for all of the Earliest Dates of all of downstream Activities to change. In turn, each change in Earliest Dates, by formula or algorithm, will automatically and unavoidably change the Start Total Float and/or Finish Total Float values for all of those downstream Activities. These rippling changes will cause the Critical Path to reroute, flipping around from update to update like a downed power line after a violent storm.

And I guarantee that the Schedule will experience more than just one Activity slippage! This makes the Schedule very unstable; and the idea of using any of the statistics from the CPM Schedule to speculate on the timeliness of project completion is, again, a crazy one.

On to Part 2

In Part 2 of this three-blog series, we will look at how the Critical Path Concept is typically applied in the management of Construction Projects. What we will discover is that the very Project Time Management practices that we have been trained and certified to perform … actually exacerbate the unreliability of the Schedule already caused by the fundamental factors discussed in this blog. See you in Part 2!

 

Leave a Reply

Your email address will not be published. Required fields are marked *