Why to Draw CPM Logic

When I was a young boy my older brother had a college textbook in his bedroom entitled, How to Write a Sentence. I was only nine or ten at the time, which explains why as I quickly thumbed through the pages it all seemed quite boring to me. So I slid the book back onto the shelf and went outside for a bike ride.

Every now and again, over the years, I have found myself thinking about that book’s title. The idea that someone could write an entire book about what goes into a single sentence … sort of blew my mind. That book title was the inspiration for this chapter’s title. But that doesn’t explain why I felt the need to devote an entire chapter to the Dos and Don’ts of drawing CPM network logic.

I have been scheduling for 36 years now, and I have seen a lot of schedules (and known a lot of schedulers) over that time. From the perspective of the aging relic that I am, I can share with you my opinion that the gradual demise of effective Project Time Management can be linked, in no small part, to the increasingly lost art of drawing logic.

CPM is a Cryptic Language Used to Model Reality

We often forget (and maybe some never realized in the first place) that the Critical Path Method is a cryptic language, filled with unique symbols and shorthand notations, that is used to simulate reality (planned or actual). According to Dictionary.com, the word “cryptic” means:

  1. Mysterious in meaning; puzzling; ambiguous
  2. Abrupt; terse; short
  3. Secret; occult
  4. Involving or using cipher, code
  5. Obscure in meaning

Anyone who has ever tried to read someone else’s CPM-based schedule has had the experience of trying to guess what the schedule’s creator(s) had in mind for a particular schedule element. Why did they draw a logic tie between those two particular activities? Why is the duration for Drywall Installation the same on all of the building’s nine floors but one? Why are certain activities overlapped, while their identical counterparts on other floor’s are strung in series? Why did they impose these mandatory date constraints? And so forth.

The point is that a network-based schedule, written in the CPM language, is a coded and cryptic form of communication. And depending on the presentation format of the schedule, the coding and symbolism can mean quite different things. Mainly, CPM schedules appear in one of three presentation formats: graphical, tabular, or narrative. Chapter Four of the textbook, CPM Mechanics, deals with CPM as a graphical language.

The Demise of Logic Drawing

While I still shutter when others label me such, I guess my gray hair and 36 years of work in the trenches justify others referring to me as a Scheduling Expert. I am not sure how expert I am, but I know that I have seen a lot across almost four decades. In the world of Project Controls, detecting and evaluating trends is a key service we provide to the cause of Project Time Management.

Well, applying those same skills and instincts to our profession itself, I have witnessed a trend over the last two decades that I believe correlates directly with the gradual demise of the Project Schedule as an effective and useful tool. And that is … the increasing lost art of drawing logic.

The easiest way to understand what I am driving at, as well as to appreciate the significance I place on this singular point, is to compare what Schedulers do to how an architect might go about creating Construction Drawings for a new house.

There are three basic stages of design development.

  • First there is Information Gathering. This is where the architect meets with the client (usually, multiple times) and learns what the client has in mind, what they want in their house, how they want the building to function, what particular features they want included, and so forth. During Information Gathering, the architect also gives feedback to the homeowners so that they can make more informed decisions along the way, and so that their expectations are tempered by what is ultimately practical and possible. Thus, both parties are gathering information.
  • Second, there is production of Concept Design. This is where the information exchanged in both directions in the first stage are incorporated into general-level documents (drawings and narratives) that depict concepts more than specifics. This is an extremely important middle step because it allows all parties to get, quite literally, on the same page.
  • Third, and only after the previous two stages have been completed, the architect is ready to immerse herself into the finite details and precise calculations that ultimately yield the Construction Documents which the builder will follow, like a well-written recipe, to produce the end product that the Homeowners have in mind (and are expecting).

Construction Documents are often called “Plans and Specifications,” with Plans referring to the drawn diagrams – the floor layouts, the wall sections, the site contours, the pipe alignments, and so forth. Well, a Project Schedule is much like those physical Plans, except Schedules deal with Project Execution Plans.  But, when all is said and done, plans are plans. Schedules are just Temporal Plans (versus Spatial Plans).

Schedule Logic Development Sessions Facilitate Brainstorming

So, if we learn from the good practices of our architectural design colleagues, we will immediately realize that the first stage in the development of a Project Execution Strategy (Project Schedule) is to brainstorm at a general level – to gather information. And this is when those Logic Diagrams are at their most importance. Think about what is being discussed around the table.

In attendance at the Logic Session(s) are those who have the most responsibility for the performance of the Project’s scope of work. These are not merely Management Leaders, they are also the Project’s thought leaders. Their combined wisdom, borne of collective decades of practical experience, have been proven across the history of Project Management to consistently yield the most intuitive, most clever, and most achievable Project Execution Strategies of all.

But at the specific level, just what are they discussing around that table?  Answer: Pace and Direction.   They are discussing what will be done: by whom, where, when, how much, how long, how well. In no small way, they are choreographing the Project … before it begins.

Now we have long heard that “a picture is worth a thousand words.” And that may explain why it is second-nature for a constructor, when trying to describe a technical issue, to almost always resort to a diagram. In the job site trailer, leaning over a plan table, he may reach for a pencil and start sketching in the margins of a blueprint.  In the field, he may grab a twig on the ground and start drawing in the loose sand.

When the topic is the choreography of the Project Execution itself, the best medium for communication is a well-drawn Logic Diagram. And that is what Logic Diagrams are all about: communication of the dynamic movements of the Project.

But back to the point of this subheading, with each passing year fewer and fewer schedulers ever draw schedule logic. Instead, they jump right into the scheduling software and start keying in activity descriptions and durations. As for how the activities are tied together, they simply encode relationships between activities by using the particular data fields and abbreviations required by the scheduling software.

For all too many, the first time any graphical representation of the Project Schedule appears it is quite often in the form of a bar chart generated by the scheduling software after the schedule has been completely built on the computer.

Quality of Logic Equals Quality of Schedule

This is the correlation I wish to drive home. Almost without a fault, the best Project Schedules begin as well-drawn Logic Diagrams. The opposite is equally true: the worst Project Schedules almost always began in the software and not in a diagram!

And why does this correlation make practical sense? Because all humans suffer limited mental retention. We are talking about short-term memory and how humans compensate for their limited ability to hold more than 5-10 thoughts in their heads at a single moment. The name that psychologists have given to a category of techniques for dealing with short-term memory overload is called Complexity Reduction. And one such technique within this category is called “chunking.”

As you might imagine, chunking is where we mentally compartmentalize the various issues facing us, and set aside all but one at a time to deal with in detail. The others are mentally “shelved” for the time being, while we deal with the one topic in minute detail. This process of chunking corresponds nicely to the recommended processes involved in Schedule Development.

Logic Development Session General Process

We start with the Project itself and then, through a series of questions and answers, we subdivide the Project into major and/or minor components, phases within each minor component, etc. This may sound an awful lot like Work Breakdown Structure, which has sometimes been referred to as “progressive elaboration.” But WBS is a code-based process whereas Logic Development is a graphics-based process. But they both pursue the same communication objective: informational clarity and accessibility.

When I conduct a Logic Session, I start by asking the Project Team to identify the Major Components of the project. Let’s say it is an Airport Project, for instance. They might identify: Construct New Runway, Resurface Existing Runway, Construction Parking Garage, Construct New International Terminal, and Upgrade Baggage Handling System.

Next, taking one of these major components at a time, I will ask them to identify the Minor Components. So, for the International Terminal, they might list: Building Pad (Rough Site Work and Subgrade utilities), Foundations, Structural Frame, Building Enclosure, Interior Rough-Ins, Interior Finishes, Vertical Transportation, etc.

Now we will take just one of those Minor Components (chunking the rest to a mental shelf) and we will proceed to identify the activities required to perform this segment of the Work Scope. This is where Logic Diagrams come into play. On a White Board (or computer screen, if web-conferencing), the scheduler skillfully draws the activity boxes one at a time, as the participants in the Logic Sessions contribute their individual thoughts on whatever is the subnetwork under discussion. Gradually, logic ties (arrows) sew the activities to one another.

What I have found is that when this graphical approach to collective brainstorming is skipped – when a single individual is relegated to a room where he or she is expected to create the schedule in a vacuum – the resultant Project Schedule is rarely worth very much. In fact, if dutifully followed during the course of the Project, it may very contribute to the Project’s temporal failure!

The Art of Drawing Logic

All of the above brings us to the realization that Drawn Logic is a form of communication. And all communication involves language. Drawn Logic is a graphical language, and every single element of the diagram is a symbol, representing a specific concept or statement.

For instance, the activity box is not just a box. It is four straight lines that touch at their ends. The left-side vertical line represents a moment in time, that is different from the moment in time represented by the activity box’s right-side vertical line. Contrast that with the upper and lower horizontal lines which do not represent conditions of temporal performance, but instead depict the actual process of performance of work scope.

It’s all symbolism. The activity arrow, the graphical element that communicates a “relationship” between activities, also has several distinct parts. Where the arrow head touches a downstream activity tells us something important about the relationship between the two activities. Likewise, where the activity tail touches the upstream activity tells us something equally significant.

You get the point.  And that is why I decided to devote an entire chapter to how to draw CPM logic. Because if Project Schedules are ever to return to their previous luster and usefulness, we must teach this lost art anew.

4 Responses to Why to Draw CPM Logic

  1. Michael Neal says:

    [C] The process is similar to lean construction style, by taking the pieces and bracking it down into smaller sections using sticky notes to relate activities.

  2. Connie Bremer says:

    This blog makes great sense in that much can be missed if creating the schedule after the brainstorming session and rarely do the participants have adequate time to fully evaluate that theirs or others requirements have been met. Complete steps could be missing and/or durations, linkages, etc. This method would be a much simpler and quicker way to “pre-build” your schedule, probably a lot less explaining to do when anomalies are inevitably encountered along the way.

  3. Stephen Short says:

    [B] I agree as well; however, currently serving as QA/QC I assist with the review of the schedule and more often attempt to decipher the logic. Being “green” to this process, I find myself attempting to absorb as much of the many aspects, approaches and mindsets that everyone expresses. Hope to be more involved as we get further into the symposium.

  4. Thomas Long says:

    I could not agree more. In the scheduling class I teach the first homework is a manual calculation of float so that they know what a forward and backward pass is. I draw the boxes for them in the first few examples, and the second part of the question is creating an activities list from the diagram. In the later questions they create a network diagram from an activities list. If you can’t covert easily from an activities list to a network diagram or a Gannt Chart you get trapped in two dimensional thinking, and construction doesn’t happen in two dimensions.

    My first boss in scheduling insisted on us using network diagrams to create our schedules. In the interview of the subcontractor or project manager drawing the logic in front of them often got them to see the job logically and it was a learning experience for both of us; many times leading to quite a few changes in how they were going to build the job.

Leave a Reply

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