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!

 

Just What Is Total Float?

Just What Is Total Float?

It may seem like an odd question to ask. After all, Total Float is the same age as the Critical Path Method (CPM), of which it is the Key Value — over fifty years now. Is it possible that we still don’t agree on just what Total Float is? That is what I am submitting with this blog. (more…)

When Means Become Ends

In a corresponding blog (How We Confuse Ourselvesat the “Thinking Outside the Box”  blog site), I wrote about how, in today’s CPM schedules, the date called an “Earliest Start” does not always represents the very earliest date by which an activity can possibly start.  The blog article traces how the use of a Contiguous Duration software setting has effectively violated the literal meaning of “earliest.”

It is a great example of how means have become ends in their own right, the theme of this blog article. I happen to like the expression: ‘keep your eye on the doughnut, and not on the hole.” Another expression, prominent in the world of marketing, highlights the same message: to not lose sight of what really matters. In their world, the expression is: “sell the sizzle, not the steak.”

We Humans Are Easily Distracted

We humans are easily distracted, especially by things that glitter and look/act cool.  So it is no surprise that we are fascinating by statistics. Just walk into any sports bar and listen to the statistics flying around the smoke-filled tavern. And what is even more amazing is that many of the folks spouting the statistics are only high-school graduates, are not especially computer literate, and have a few pints in their bellies!  Still, they argue performance stats extended three points beyond the decimal.  Go figure!

We humans like our statistics. Our foods have labels filled with grams and daily allowances and percentages.  Our weather reports speak in terms of probabilities and barometric pressure readings. Our nightly news almost always has a few political or demographics polls. And US Today loves to show us colorful pie charts and graphs.

So it comes as no surprise that Schedulers found a willing and insatiable audience for its volumes of statistics when it came up with Total Float, Free Float, Critical Paths, Earliest and Latest Dates, and such.  And on top of that they serenade us with Earned Value statistics, Critical Chain buffers, Monte Carlo outputs, cluttered PERT diagrams, fancy looking bar charts, and endless tabular reports. We schedules love our statistics!

For Whom the Schedule is Written

The problem with all of this, however, is that we schedulers have forgotten that the Schedule was intended to help the Project Team build the project. Instead, we see the Schedule (and its maintenance) as an end in its own right.  My gosh, when the PMBOK Guide went from Version 3 to Version 4 it adopted a Verb-Noun format that only served to further the loss of focus on why we have schedules in the first place.

Prior to Version 4, the culmination of Schedule Development was something called Schedule Control.  And while those two words could have mean “the control of the schedule,” one understood that it really meant “control of the project through use of the schedule.”  But in Version 4, the title became Control Schedule.

And, to make matters worse, the one-sentence explanation of the meaning of this new term, Control Schedule, essentially limited the focus to what was required to maintain the schedule … and nothing more.

The one-sentence explanation read: “Control Schedule is the process of monitoring the status of the project to update project progress and manage changes to the schedule baseline. [italics added]. It then goes on to list four bulleted items that explain what Schedule Control “is concerned with:”

  • Determining the current status of the project schedule,
  • Influencing the factors that create schedule changes,
  • Determining that the project schedule has changed, and
  • Managing the actual changes as they occur

Where, in any of this, is anything about helping the Project Team run the project, by using the Schedule to control project performance?  It seems to me that, more than just Schedulers themselves, the entire Project Management world has lost sight of the doughnut.  They are captivated by the sizzle of their processes and outputs, and forgetting the stake (“steak”) they once had in project performance.

Start Seeing the Schedule as a Means to an End; Not an End in Itself

If I had one piece of advice for the current breed of Schedulers it would be to start seeing Scheduling as a means to an end, rather than as an end unto itself. They must see a schedule as a young boy would see his bicycle laying on the ground at a ball field. Today’s schedulers see the Schedule as a bicycle with so many parts, and Scheduling as so many discrete processes. Everything is technical. There is no feeling!  They have lost the human connection in all of this.

Sure, one could describe a bicycle by its parts, and the description would be accurate. A bicycle is a transportation vehicle comprised of wheels, a frame, handle bars, pedals, chain, brakes, and seat. And each of these could be further described in greater detail. A wheel is comprised of a rim and hub, concentrically aligned by a radial set of evenly-spaced spokes. The rim is wrapped by an inflatable rubber tube which is encased in a molded rubber tire.

But if you ask that boy to describe his bicycle, he will tell you about the feeling of wind on his face, or the sound it makes thanks to a playing card and a clothes pin. To that young boy, a bicycle means a paper route. It means getting to school on time even after waking up late. It means giving his kid sister a ride on the handle bars. It means racing down an alley with a buddy.

And riding a bike isn’t thought of in technical terms either. It is not simply pedaling or balancing or looking both ways at intersections. Sure, all of those things are necessary for successful rides … But they fail to describe WHY we ride.  We ride for speed. We ride for conveyance. We ride for convenience. We ride for fun. We ride for transportation.

Scheduling and schedules are means to ends, and not ends in themselves.  I wish I could get that point across to my anal-retentive colleagues. Recently, one such colleague responded to the announcement of the PTM TALKS series by doubting the positive value of what he called “more talk.” Instead, he went on to complain that I (and other Thought Leaders he knew personally) had not yet joined his campaign to change the location where Early and Late Dates are written around an Activity Box in a logic diagram. For five decades Earliest Dates have been written on the top of the Activity Box, and Latest Dates on the bottom.

[My good friend, a globally-renowned trainer in Project Management topics, argues that the two sets should be reversed.  Why? Because Total Float is derived by subtracting Latest Dates from Earliest Dates.  And in basic arithmetic, the subtrahend is one the bottom and the minuend is on the top.]

When I responded that I was far more concerned that only 25% of those who create Construction Project Schedules (whether they be Project Managers or “professional” Schedulers) have had any formal training beyond a few days in a scheduling seminar), he responded that if we can’t get agreement on a simple matter (like the placement of dates on a page) how can we hope to affect larger issues.

I responded by noting that we need to focus on what is important to our customers, rather than on what may be intriguing to a handful of technocrats. But he held steadfast, again asking me to join “the Cause.” I told him that I had neither time nor political capital to expend on fixing what isn’t broken.

Scheduling is not an end in itself. It is a means to an end. And because the Project Schedule is so darned versatile and robust, and because it comes in so many different forms and serves so many different purposes, there is no single End to which all schedules are pointed. Every project (by definition) is unique. Every Project Team is equally unique. Every Project Execution Strategy is therefore unique, as well. And since the point of a Project Schedule is to model Project Execution Strategy, it follows that every Schedule is unique, and every Scheduling effort is just as unique.

With all of this uniqueness floating around, the ONLY way to appreciate or even understand a Scheduling effort (or the Schedule at the center) is to recognize and value the reasons for creating and maintaining both. We must always keep our eye on the destination, if we seriously hope to arrive there. Every boy on a bike knows that!

Project Time Management reminds us that the underlying reason for Schedules and Scheduling is to help the Project Team make their very best use of Time during the execution of the Project. THAT … is the prize at the finish line, the pot of gold at the base of the rainbow.  And everything we do or say or think … should be in the context of this single objective … to help Management make the best use of time during the execution of the Project.

The point for this blog article is that all members of the Project Team share a common objective: to better the project.

  • Recruiter: When a recruiter looks for someone to fill a key position on the Project Team, a critical part of the vetting process should be to ascertain whether the candidate truly understands the factors that coalesce to create Project Momentum. Projects are streams of coordinated action. They are not discrete, detached parts. A Newtonian view will miss the point, time and again. By contrast, holism teaches that the whole is greater than the sum of the parts.
  • PMs and Superintendents: The most decorated Project Managers and Superintendents, like their Conductor counterparts on the orchestral stage, intuitively understand this point — for it has been reaffirmed through a lifetime of experiences. It is all in the flow! Projects are streams of coordinated action, and when that action flows undisrupted it creates a palpable momentum that is rich with cadence and energy.
  • Hiring Manager: The HR Manager who understands this then examines resumes for evidence of this perceptive. And it won’t be found in a string of initials after one’s name. All that those abbreviations confirm is that the holder studied books, memorized facts, and passed a test! Nor will it won’t be found in keywords sprinkler across the resume. Rather, it is to be found in candidate’s eyes … as he or she  describes the ordeals they survived and HOW they met adversity. These are the details that matter. And as the candidate describes what they did, and the reasoning behind their actions and decisions, the astute Hiring Manager watches for the connection back to Project Momentum, to that invisible flow of coordinated action.
  • Attorneys and Consultants: The lawyer or consultant who struggles to make sense of a project gone awry, to understand what went so terribly wrong, must too look at the collective story, and not get distracted or misled by the details. There is always the Big Story. One can never understand a book by only reading one page. And one should never dare to create each page separately.
  • Owners and the Agents: Owners, above all others, should pursue and cherish the Big Picture. And yet it is Owners (and their agents) who, more than any other Interest Group, wallow in minutiae. They drive the discussion into fractious and meaningless details. They have Managers squirming in the Hot Seat to explain the most minute shifts in Total Float or a projected completion date two years away. They are the force behind the demand for Earned Value. They are the authority behind  countless contract clauses that seek to micromanage the Schedule and the Scheduling processes.

And the overall tone of the Scheduling Specs is unmistakable: the Schedule is an End in its own right. Because it is to be used to validate progress payments, or justify time extensions, it must be kept current. It cannot be changed without Owner permission. But what about the Schedule’s use to actually guide the work in the field? Does the Contractor have the right to change the Schedule as performance conditions change … without first getting Owner permission?

Much of the struggle between Contractor and Owner (and their respective agents) can be traced back to this blurring of the line between Means and End.  Maybe this blog article will spawn some discussion. What do you think?

CPM: Constant Perfection Method

November 1963

I remember exactly where I was when it happened. It was November 1963 … and I was upstairs in my bedroom, lying on my bed and staring at the ceiling, counting the silver star-shaped decals I had proudly applied in the hour before.

From the date, you may be thinking that I am talking about where I was when President Kennedy was assassinated, but you’d be wrong. I was out on the front porch when that terrible moment happened just after I had finished lunch. Besides, that would not happen for another three weeks.

No, this Major Event in my life took place on November 3rd, a Sunday. I remember because we had just finished (more…)

The Art of Stacking Dominos

Ever heard the joke about the brainy scientist whose six-year-old comes up and asks, “Daddy, where did I come from?” The father breaks into an instant sweat and his lips begin to tremble as he mentally searches for the best way to tell his child about the Birds and the Bees. After a long pause to gather his words, he begins: “Well, you see, mommies and daddies are different ….” But before he can complete the first sentence, the child interrupts: “No, daddy. Am I from Cleveland or Denver?”

Sometimes we make things too complicated. I happen to think the Nerds among us do so much more often — and with seemingly more ease and less self-awareness that we are even doing so – than the rest of society.  Here’s the shocker… (more…)

Schedule Logic Dependency Objectives

I have long been intrigued by the wide range of reasons why schedulers choose to link two activities together in a predecessor/successor relationship.

Between Hard Logic and Soft Logic

In the early years, when Arrow Diagramming was the only game in town, the linkage between activities was classified as either hard logic or soft logic. That was it!  Hard Logic meant that the linkage was absolutely mandatory – e.g., the roof follows the walls; the walls follow the floor. (more…)

Dynamic Projects: It’s All About Attitude

It’s All About Attitude

In the last few years, the expression “Dynamic Project Management” has inched ever closer to mainstream Project Management dialogue. But, as with virtually every other term within the diverse and eclectic world of Project Management, this expression has different meanings, depending on who is doing the talking … or listening. Until a universally-recognized authority unequivocally asserts what the expression means, it remains open to individual interpretation.

For me, I don’t see a three word term, but rather just an adjective (“dynamic”) in front of a fairly well understood two-word term, Project Management. And for me, it makes sense that Dynamic Project Management is an expression that simply labels a Project Management model that is designed to deal with dynamic Projects; that is, projects that (more…)

What is a Project Schedule?

What is a Project Schedule?

I know what you’re thinking.  “Again, Murray?  You’re going to litigate this question … again?  Give it a rest, my friend!”

“But not so fast,” I rebut. “I don’t think the matter has been fully resolved. At least not enough to be of much help at a practical level.  Hear me out … please!”

[Note: You may want to follow along with the diagram to the right.]

(more…)

What Do We Mean By “Strategy?”

Throughout my book, CPM Mechanics, I refer to a Project Schedule as a Project Execution Strategy. But this begs the question: just what is a strategy? According to the Online Dictionary, a strategy is “a plan, method, or series of maneuvers or stratagems for obtaining a specific goal or result.”

It’s All About What We Value Most

Okay, but  … when it comes to Construction Project Time Management, I’m not sure if that definition helps all that much. Since a strategy is aimed at pursuit of an objective or goal, a strategy must therefore reflect held Values. This points a light on one of the challenges of creating a single Project Schedule: A Project Schedule  is a strategy for successful project achievement.  But … “success” is defined differently by different contributors. (more…)