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…

Schedulers are Nerds

Yes, I am the pot calling the kettle black. I am a nerd, too; no debate about it. But until they make a pill to keep my disorder under control, I am left to self-manage, as best I can.

Acknowledging that I have this affliction is the first step toward Healing. Many of my scheduling colleagues, however, are deep in denial. I know this because I constantly see them (and hear them) confusing Reality with the artificial model of that Reality (the schedule). “How are we doing on the schedule?” Their poorly-worded inquiry is intended to discover whether the project is on schedule, or not?  But what they have asked is whether we are making progress with the schedule (perhaps with its development). Or, they may say, “The schedule slipped again.” No – the schedule didn’t slip; it’s still on my desk!  Project productivity has slipped; maybe that’s what they meant. You get my point.

Not just schedulers, but everyone who uses the Project Schedule, must be diligent in separating what is Real from what seeks to simulate Real. A Project Schedule is a model of Project Execution Strategy.  It is not the Project.

In my latest book, CPM Mechanics, I go out of my way to suggest counterpart terms, so that this distinction between Reality and Simulation is always forefront in our minds. For instance, I insist that the words Activity and Action are counterparts. The Activity exists in the Schedule; its counterpart, Action, exists in Reality. Likewise, a contractual deadline exists in Reality (found in the contract); a Date Constraint exists in the Project Schedule (to simulate that deadline).

What is a Start-to-Start?

That brings me back to us schedulers being Nerds. Just try asking a Scheduler to explain a Start-to-Start dependency. Almost without exception he or she will start parroting some formal definition of a Start-to-Start tie as taught by some well-respected authority on Project (Time) Management.  “A Start-to-Start means that the successor cannot start …”.

The central point I am trying to make is that their answer, no matter how worded, invariably speaks to what a Start-to-Start is … rather than why we might use it.  Ask me to describe a bicycle. I could answer in terms of what it is comprised of: wheels, pedals, tires, handle bar, chain, etc.  Or, I could describe it in terms of what we do with it: it is a means of manually-propelled, two-wheel transportation.

The problem with describing the three (or four) primary dependencies/relationships of the Critical Path Method solely in technical terms is not just that we may confuse the person asking the question. Worse … we run the very real risk of confusing ourselves. If we humans say anything enough times we are apt to believe it.

The same holds true for how we describe the interdependencies between Activities. When we see them as mechanical connections between activities, we lose sight of their modeling function. For just as Activities (in a Schedule) represent corresponding Actions on the Project (reality), dependencies between Activities represent commitments between living, breathing human beings on the Project.

Choosing the Right Dependency Type

I have trained a lot of schedulers over the years, and one question that comes up more than practically any other is this: how do you know when to use a Finish-to-Start, versus a Start-to-Start (or some other combination of  available dependency types)? At first, I used to send to the bookshelf to find the answer in a good scheduling book. But one day one of those students returned to inform me that none of the books spoke to the question!

I checked for myself and, lo and behold, none of the books gave any guidance on when to use an SS tie versus an FS tie.  I suppose the authors felt that the choice was condition-specific, and that all the scheduler needed to know was how the various dependency types worked … and they would then know which one to draw into service.

Stenographer or Facilitator?

The previous paragraph is a great segue into another frequently-contested debate among schedulers. Are schedulers to be note-takers (stenographers, if you will) … or are we to be facilitators of the Schedule Development process? In other words, is the role of the scheduler to simply take notes as the Project Team debates Project Execution Strategy?  Or, is our role to be more assertive, more influential – to help guide the discussion that ultimately unfolds the Schedule’s development?

There is little doubt that in the early days, schedulers were clearly more facilitator than stenographer. Typically, the Project Scheduler was the only one on the Project Team to understand the technical side of Critical Path Method modeling. Conversely, the Project Manager, Superintendent, and subcontractors understood the Project Execution far better than did the Scheduler. So there was a mutual respect (if not always a mutual trust … but that’s another story for another day) between them.

Then came the desktop PC, standalone software, and a plethora of one-week training seminars. Suddenly Project Managers could produce their own schedules, and the Scheduler went the way of the dinosaur. But in recent years things seem to be coming full circle. With the advent of enterprise-level scheduling software, and with the gradual realization that Project Managers didn’t really get enough training in that one-week seminar to teach them how CPM works “under the hood,” the chasm between Reality and the effective modeling of that Reality has once again widened.

Another historical notation must be mentioned. When those schedulers went the way of the dinosaur, eventually there became a worldwide shortage of truly knowledgeable scheduling technocrats. In a mad rush to fill the void, scheduling classes popped up everywhere. But the content was the same superficial, one-week overview of Planning and Scheduling that had proved inadequate for the Project Managers. Even more so, the content proved inadequate for what were intended to be the “scheduling specialists” within the Company.

Today, we find both Schedulers and their Customers (Project Managers, Superintendents, and Owners) equally unaware of the nuances of the Critical Path Method. Neither is capable of facilitating the discussion. That is, neither is able to confirm that a particular configuration of schedule logic will – or will not – correctly mimic the corresponding Reality it is meant to model. Instead, they are left to trust that a particular arrangement of Activities and Logic Ties will behave (in a computer model) the same way the corresponding Actions (and mutual commitments between the Project Participants) will behave in Reality.

Logic Ties Reflect Interdependency

We must not lose sight of the essential message of every Logic Tie between Activities in a schedule. A Logic Tie is a symbolic representation of an interdependency between two Actions in the field (or home office). But dependency is more like an onion than a rock.  It has layers of implication; it is not just there.

If you are arriving on an afternoon flight and your spouse has committed to picking you up, you are depending on her for a ride home.  But just what is implied by “I’m counting on you?”  For starters, when. You trust that she will be there when you arrive – and not two hours later. Next, you expect her to meet you where you agreed to … at the curbside marked “Arrivals,” and not be waiting at another terminal. You might able expect her to arrive with a vehicle having enough storage space for your two pieces of luggage. Finally, you expect her to slow down long enough for you to throw yours bags in the back and then hop into a seat.

Dependency types (in schedules) work the same way. There are only four of them, each with its own innocent-sounding name. But each one represents a complex and interwoven set of assumptions about how the Actions (that the Activities simulate) will interact with one another.

Sequential versus Overlapped Activities

The first, most significant, choice is between whether two Actions follow one another, or happen (to some degree) at the same time. A Finish-to-Start dependency models an assumption that, in Reality, a downstream Action waits until the upstream Action has completed before it proceeds. Like diners in the restaurant lobby waiting for a table, they cannot sit down until the previous party has finished using that table, and it has been bussed and reset.

Overlapped Activities, however, represent more than just timing.  If the two involved Activities reference corresponding Actions that are to occur in the same general Space, then Overlapped Activities reflect work congestion. Imagine two trades that each have a week’s worth of work to perform in a specific area. If we sequence then one after the other, then each has exclusive access to the Work Area, and the other trade is not an intrusive factor.  But if we overlap those two Activities, we are modeling a situation where, for some period of time, both trades are in the same Space at the same time. This is the meaning of “overlapped.”

You see, it is not just a technical explanation of how a Start-to-Start works. An SS Logic Tie is the Critical Path Method at its notational best. With the cryptic, shorthand of an innocent SS:2 Logic Tie, we are saying that the Second Trade will commence its work two-days after the First Trade has entered the Space. The overlap period will be those other three-days: the last three-days of the First Trade which coincide with the first three-days of the Second Trade.  During those three days, both trades will occupy the same Space.

Overlapping Correlates to Schedule Risk

The final point that I wish to make is that overlapping is not merely an On-or-Off proposition. It offers infinite and exponential degrees of potency. There is a fascinating and dangerous correlation between Degree of Activity Overlap and Extent of Temporal Risk to the project.

As a child, did you ever play Domino Stacking (also called Domino Toppling)? This is where you stand dominos on their ends in a row, such that if you push your finger into the first domino and it falls, as it falls it knocks over the domino next to it, which in turn knocks over the next domino. And so forth.

There are hobbyist groups that perform amazing and elaborate Domino Toppling feats all around the world. They are experts in the art of Domino Stacking. I had the delight to ride alongside one such expert on a commuter train between Baltimore and Philadelphia; I learned a lot from Frank.

He explained that the closer together the dominos are stood, the faster the “falling” will occur.  If you want a longer-lasting display, then spread the dominos farther apart. He also explained that the closer together that the dominos are stood, the greater the likelihood of an accidental discharge (during construction of the display).

I think we can draw a lesson from Domino Stacking. As I see it, between any two dependent Activities, the intensity of that dependency is expressed along a spectrum that has two clearly describable extremes. At one end of the spectrum, Finish-to-Start, there is no overlap. This represents the minimum risk condition, and corresponds to the dominos being as far apart as possible while still being able to trip one another.

The other end of the spectrum is a Start-to-Start with a zero Lead/Lag (Restriction Delay, in the jargon of Cognitive Project Management). In this case, there is a 100% overlap.  This is like two dominos practically touching one another as they stand. In between these two extremes, the extent of overlap decreases as the Lead/lag value increases.

When we view the practical functionality of overlapped Activities through the lens of Risk and Speed, we get a different understanding of what we are doing when we link Activities via Start-to-Start or Finish-to-Finish. When we use very small Lead/Lag values, we are increasing the window of overlap. This might make the Activities start sooner (dominos fall faster), but it also introduces a higher level of risk.

For if the upstream Activity is delayed, then the downstream  Activity is more likely to be delayed, with less chance of recovery. In the inverse, if we use larger Leads/Lags, we reduce the “domino effect” between Activities, but we also model a slower-performing project.

So the next time you find yourself motionless in front of a Logic Diagram that you are constructing, and you are trying to decide whether to string Activities in series or overlapped — and, if overlapped, by how much – you may want to think about the implications out on the Project. Just how closely do you want to schedule those trades in the same Spaces?  How much “breathing room” do you want to give them?  Remember that the less overlap you can get away with, the more “cushion” you build into your schedule to offset those occasion Domino Falls when “Stuff Happens!”

4 Responses to The Art of Stacking Dominos

  1. Zach Reed says:

    A good perspective to keep in mind when creating a project execution strategy. The level of risk to be taken should be decided by the project team. The project manager’s level of comfort with differing levels of risk will likely drive the restriction linkage determination.

  2. Sue Backiel says:

    When overlapping activities it is important to take into consideration the lead/lag times involved. Your attempt at trying to speed the project up by using too many start restrictions and finish restrictions may actually slow the project down if trades can’t do their work due to other trades in their way.

  3. Michael Neal says:

    [C] The quality of works tend to go down and mistakes are more apt to occur with mulitiple trades working in the same area. This will inturn actually slow the progress of the project. Not to mention the changes the owner will make which will cause redo work. The contractors need to be pushed but using to much overlap is not the way to go.

  4. Connie Bremer says:

    Interesting analogy and read. It does make sense that the closer activities are overlapped, should the predecessor be delayed, the higher risk probability that successive activities could as well be delayed. This could potentially have a small or huge impact overall. Good point made in determining not only the correct restriction, but also the correct restriction delay value.

Leave a Reply

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