A Meeting of the Minds

One topic that continues to surface every few months in various Internet forums has to do with what it takes to produce a good Project Schedule. That the question continually surfaces is strong indication that there is still much interest, if not downright uncertainty, regarding what processes and core elements will predictably and consistently yield quality Project Schedules.

In late September 2011, a LinkedIn discussion thread appeared, bearing the title, “Beginning a Construction Schedule.” As I often do, I quietly monitored the discussion, but without necessarily sticking in my two cents. I like to read Discussion Threads because I almost always learn something of value from my colleagues.

In the case of this particular discussion, over a period of nearly two months I read as one after another the suggestions for how to begin a construction schedule seemed to ignore one of the most important early steps. Mostly, the postings tended to focus on fairly technical ideas, like creation of a WBS (Work Breakdown Structure), automatic feeds from the estimating database, data entry fields, activity coding ideas, etc.

A Case for Logic Development Sessions

But after seven weeks and 168 comments, I felt I had to chime in and talk about Logic Development Sessions. Here is what I wrote:

I tend to favor a more “human” approach to Schedule Development. Yes, a WBS is a useful way to categorize the scope of work. And yes, the contract is a comprehensive description of the scope of work (re: construction projects). But a Project Schedule is, at its core, a simulation that seeks to model the Project Execution Strategy that is held, at the outset, in the minds of the Project Team.

The primary challenge for the Project Scheduler is to extract those ideas from their brains. This is accomplished in a group setting, in a meeting (or series of meetings) known as Logic Development Sessions. At these Logic Development Sessions the Project Team discusses their individual thoughts about how the Project might be built. Collectively they conceive what is called a Project Execution Strategy. It is this Strategy that the Project Schedule ultimately models.

Since there is almost always more than one way to skin a cat, as the saying goes, there is also usually more than one credible, viable approach to Project Execution. But the approach that ultimately matters is the one that the Project Team agrees to. Since the Project Schedule is a communication tool, it should be organized and structured to correlate with the collectively preferred approach to the work.

For this reason, it should be organized using a work breakdown that complements the way the Project Team sees the work. This may not be the same way that the Estimating Department sees it. Please understand that scope of work and organization of work are two different things.

Most Cost Managers organize the scope by work type, such as Spec Sections that correspond to CSI codes or the like. But that is rarely the order in which the work will be performed. And  … it is rarely the way the Project Team necessarily thinks about deliverables. So if you mechanically set up a WBS based on the Specs in a contract, the odds are quite high that you will not be organizing your schedule in alignment with how the Project Team wishes to choreograph Project Execution.

My recommendation (on this question) is to assemble the Project Team, ask the right questions, challenge the given answers, and develop the schedule in their presence, one activity at a time. In so doing, they will (a) immediately catch any of your mistaken interpretation of their comments, (b) their subsequent acceptance of the Schedule will occur all the more readily, and (c) the ultimate Project Execution Strategy will reflect the best (collective) thinking of the Project Team

How to Conduct Logic Development Sessions

What follows are choice excerpts from my first book, “Faster Construction Projects with CPM Scheduling<” Chapter 13.


Time and time again experience has confirmed that the best Execution Schedules are created by those who will eventually oversee the work. The Logic Development Sessions should be attended by those who will be managing the construction project should participate aggressively in the Schedule Development process. All of them!

From the offices of the general contractor and construction manager, invite the project manager, general superintendent, cost engineer, estimator, and project or field engineer. Beyond them, the Logic Sessions should be attended by the highest ranking, project-specific supervisor for each of the prime subcontractors and by representatives of the critical long-lead vendors, suppliers, or manufacturers. In an ideal world, the architect and the owner would also be present.

Finally, the Owner (or its legal representative) should participate. The Owner’s performance on the project (directly and through his agents) historically affects every aspect of the construction process, from review and approval of construction performance plans (safety, quality, protection, and so on) and submittals to inspections and supply of owner-furnished equipment and materials.

General Orientation

Start by orienting the group to what they are about to be undertaking. No one likes to be torpedoed; least of all, contractors. They’re coming into the Session not just a little apprehensive. They are guarded, fearing that they’ll be expected to make promises and give up their padding (float). Furthermore, keep in mind that you’re working with a diverse group of experts, each with a unique and different technical orientation, yet with few having any really strong background in the Critical Path Method. You need to get everyone on the same page.

Explain what they will be doing and what they won’t be doing. They will be sharing their expertise in their respective disciplines, and they will be making some commitments on behalf of their company. They won’t be asked to give away the store. They must come to understand that the purpose of the Logic Development Session is to jointly create a strategy that all participants can work to achieve, so that all are singing from the same music sheet. You will receive very little resistance from the group if you take this approach.

Next, quickly walk the group through the very basics of PDM scheduling. Show them how start-to-start and finish-to-finish relationships work, by demonstrating their equivalence in a standard bar chart format. Emphasize that activity-durations will be in consecutive workdays and not in elapsed time or calendar days.

This next point is critical. Anyone who provides you with an activity-duration estimate must assume the following three conditions:

  • That any preceding, constraining work has been completed and nothing impairs the subject activity from being completed.
  • That the work will be completed in one continuous series of workdays.
  • That the logic ties will create the elapsed duration effect they probably have in mind.

Content Checklist

Just before launching into development of logic and subnets, in some conspicuous place on the wall set forth a list of the primary parameters that should guide all Schedule Development:

  • That any preceding, constraining work has been completed and nothing impairs the subject activity from being completed.
  • That the work will be completed in one continuous series of workdays.
  • That the logic ties will create the elapsed duration effect they probably have in mind.
  • Is the contract scope fully reflected in the Project Schedule?
  • Is the level-of-detail consistent with the parameters set forth in the Schedule Performance Specifications?
  • Is the sequencing of the work consistent with management’s execution strategy?
  • Are the activity-duration estimates reasonable, achievable, defendable, and documented?
  • Do activity-duration estimates derive from the same assumptions that are behind the budget’s cost estimates?
  • Are all contractual and negotiated milestones reflected in the Project Schedule?

Defining the Subnets

Finally, instruct the group that they will be working from general to specific, and then back again to general. Explain that the first hurdle is to agree on how the project can be logically subdivided. Often, this segmentation is done along geographic lines; less often by functional segments. Allow the group to suggest subheadings as you write them on the board.

Once the subnets have been agreed upon, ask the group to list the major elements of work under the first heading. If you’re working on a subnet called Foundations, they might throw out such things as Spread Footings, Continuous Footings, Drilled Piers, Pile Caps, Grade Beams, Slabs-On-Grade, Underground Utilities, and so on. At first, merely list the items in whatever order they’re shouted out.

Construction Approach Decisions

With the handwritten list staring back at your group from the board, withdraw from the details and start up a discussion about the physical flow of the work. Roll out the site plans and talk about staging areas, where the tower crane will be, where trucks will offload, and where workers will park. Most importantly, decide the direction in which the structure will begin to materialize (north to south, east to west, inside to outside, and so on), and the direction in which it will finish (top down or bottom up).

Pounding Out the Logic

At this point, you are now ready to start sketching logic. Return to the board and begin drawing boxes. String the activities so that they are logical (based on what makes sense from a construction perspective) and consistent with the physical direction of work just agreed upon. Don’t worry about durations; that will come next.

Just diagram the logic in a flow upon which all can agree. As you draw the boxes, have someone in your group begin copying the logic onto paper or inputting it into the scheduling software. Tell them not to get too close, meaning not to draw the most recently created activities, since these have a nasty habit of getting changed several times before they assume their final order or sequence.

Assigning Activity-Durations

This is hardly an exact science. Let the subject matter experts at the table throw out some numbers. You’ll find that on construction projects the spread between the highest and lowest durations will not be all that great. And, without your prodding, the group will pull their own extremes in toward the middle.

Justification for activity-durations ranges from scientific to educated guesses. If you are fortunate enough to be working with a group that prefers to base each activity-duration on solid backup, such as activity work scope, worker productivity rates, crew sizes, and the like, seize the moment. But, more often than not, durations are derived by “gut feel,” as the superintendent for the subject work merely blurts out a number.

Good practice encourages that a record be kept of whatever assumptions are behind the activity-durations. This includes the obvious: crew size, hours in a shift; shifts per workday, and tacit scope of work. Beyond the obvious, other assumptions might include the expected arrival of materials or equipment that some fear might arrive late. The resultant “List of Assumptions” will be invaluable to any parallel or subsequent risk management efforts.

Adding Activity Relationships

Start by spending adequate time with the group explaining the meaning of the three major relationship types (start-to-start, finish-to-finish, and finish-to-start). Their absolute understanding of these concepts is essential to development of an Execution Schedule that is viable, realistic, understood, and supported.

Choose the Right Relationship Type: A schedule is often compared to a roadmap, but the two are very different indeed once the journey begins. While both may set forth a route before the fact, once the project is underway the automated schedule alone can be used to predict outcomes as well as to coordinate the work.

Ensuring Realism in Relationship-Durations: The important thing to remember about relationships and their durations is that they are simply a device for modeling the expected pace of the project. The image that comes to mind is that of the starter on a golf course, an individual who holds back and then releases each golf party onto the first tee. His job is to pace the golfers so that they don’t overrun one another out on the green. A project manager employs the same technique when setting up the initial Execution Schedule. This is accomplished using the relationship types available with the Precedence Diagramming Method. Logically, it is imperative that realism be the central ingredient when determining relationship-durations.

Missing Finish-to-Finish Ties: A common mistake among less experienced Project Schedulers is the use of start-to-start relationships without corresponding finish-to-finish relationships, or vice versa. If you stop to think about it, in the majority of cases, whatever dependent relationship exists between two activities at their starts also exists at their finishes.

Over-Linked and Under-Linked Schedules: I estimate that over 90 percent of all performance patterns, as originally scheduled, are violated in one manner or another, in real life. Work starts, then work stops because design and construction issues arise or changes are effected, materials are late, work crews collide, deficient work is reworked, and the like. The primary reason for a linked CPM schedule—and an automated one at that—is so that, month to month, the project’s current state of affairs can be recorded and analyzed. All of those open-ended activities add up to one single result: a good schedule rendered worthless when the first change from planned to actual takes place—often, as I said earlier, on Day One.

This is not to say that a schedule cannot be over-linked. It most surely can. Beyond a certain point, the more entwined a CPM becomes, the less valuable it is as an analytical tool. False critical-paths emerge, total-float values become obscured, and true critical paths turn invisible. A disproportionate number of activities appear to have been started (or, less often, completed) out-of-sequence.

Avoiding Extreme Relationship Durations (Leads/Lags; Restriction Delays): Relationship Durations are used to pace the project within the physical constraints of the project scope and design. The prudent Project Scheduler knows to temper all Relationship Durations with a philosophy of moderation and reasonableness. Nothing is gained by creating an Execution Schedule that is either too fast-paced or too slow-paced.

Still, within the range of what is reasonable, there is plenty of room to fail. The Execution Scheduler and project manager should listen closely to their gut feeling about the individual and collective abilities of key project players to perform in a timely, predictable, and efficient manner. All relationship-durations should be conceived accordingly.

Non-Zero Finish-to-Start Durations: The default relationship between two activities in PDM is a finish-to-start with a zero relationship-duration. In other words, the successor activity can start zero days after the predecessor activity completes. It is the relationship type default because this setting represents the natural progression of logically related activities that are not overlapped.

A tactic used by some Execution Schedulers is to put a positive duration on a finish-to-start tie, so that the successor activity cannot start until X days after the predecessor activity has completed. There are many reasons why one would adopt this practice, some sinister and practically all in stark violation of the imperative Scope-Duration Correlation. Occasionally, however, a nonzero relationship-duration is innocent enough, perhaps reflecting an absolute time lag because of a physical requirement, such as not removing shoring supports until the concrete is cured.

Manual Forward Pass

Now do a manual forward pass out loud. Do it quickly enough to get to the answer but slowly enough to allow your audience to learn, through observation, a little more about how earliest-dates are derived. Subtly, you are teaching them CPM … in a non-intrusive, non-demanding way,and they’re soaking it up. I guarantee it!

When you’re done, announce to the group that this individual subnetwork, “in a vacuum,” will take X continuous workdays to complete. Have your scribe record the earliest start and earliest-finish dates for a few, random activities in the subnetwork but most especially for the subnet’s starting and ending activities.

Scheduling All Subnets

Repeat this process for each separate subnetwork. Do not attempt to link the subnetworks together yet. The reason for this prohibition is that if your participants can see where this is all leading to, it might bias their subsequent input in order to achieve the results they desire. The beauty of CPM scheduling, versus bar chart scheduling, is that you don’t need to know how the Big Picture is going to turn out before scheduling the details. With bar charts, you have to know where to stop the pencil at the end of each bar; you can’t draw a bar without knowing the duration first.

Now, Forward Pass each subnetwork. When this is done, you will have gotten as detailed as you will need to get during these Logic Development Sessions.

Putting It All Together

I find that the process of tying it all together, going from specific back to general, is the most difficult thing for novice Project Schedulers to master. At the same time, I happen to think it’s the single most dramatic phase of the Schedule Development process. For here, with drums rolling and anticipation high, the answer to the one question that everyone has wondered about suddenly materializes: Will the Project Schedule we have spent the last two days compiling get the job done by the contractual end date?

So, what is the best way to tie the subnets back together? Scheduling Practitioners tend to have their personal preferences. Mine is a two-part approach intended to get everyone involved. First, I take the photocopies of the subnetworks that my scribe has drawn and spread them out on the table. If we jointly created 11 subnetworks, then there are 11 pieces of paper on the table (or wall).

I then assign to the group the task of identifying specific activities that will become the hook points between subnetworks. Meanwhile, as they talk among themselves, I return to a clean wipe-off board and quickly sketch out a blank bar chart form: time scale along the top and subnetwork headings down the left. I’m ready for them.

As a single horizontal line, I draw to scale the first subnetwork, say Foundations, beneath the time scale. The group looks up to see that I have begun to materialize a Level Two bar chart. I join them at the table and facilitate the discussion about how the Foundations subnetwork will “hook” into the Superstructure subnet. Based on the hook point, I determine how much to offset the second bar on my bar chart. And so it goes. Manually, and somewhat crudely, I compute a new forward pass through the now developing Level Two Project Schedule. On the board, the bar chart takes shape.

Meanwhile, the group is learning—they’re seeing how logic can drive a bar chart. And you’re learning a lot about the group. You’re identifying the leaders, the followers, the confident, the arrogant, the technical, the skeptical, the dreamer, the bully, and the wimp. You and your project manager are getting a first good look at how cohesive this group is going to be over the next X months. And they’re learning something about how the Execution Schedule and the Project Scheduler can factor into the way business will be done day-to-day. Imagine how beneficial these early insights can be.

Assorted Other Hints

Successful Logic Development Sessions involve far more than what these few pages convey. A good book on CPM scheduling may dedicate a few paragraphs to the Logic Development Session; most downplay or ignore the process altogether. But the Logic Development Session is, without question, the most important step in Schedule Development, and it’s a big reason why your Execution Schedule will either be used or tossed in the can!

It is essential that the Schedule Logic Session is successful. You must get group buy-in, no matter what it takes. And while there is no one rule which, if followed, ensures a successful Session, the following tips will certainly increase the likelihood of a productive gathering.

Come Prepared: Nothing will enhance your credibility more than knowing as much, or more, about the project than anyone else in the room. Do your homework. Study the plans and specifications from cover to cover. Make a list of all critical submittals. Note any suspiciously long-lead items. Know the lay of the land, the layout of the structures, and their relative location to one another. Fully understand the Schedule Performance Specifications.

Ready the Conference Room: Have the room ready for the exercise, including white board, paper and pens, set of plans and specs, butcher block paper or Post-It notepads, laptop with appropriate software (e.g., MS Visio), a projector, etc.

Bring Food: People are friendlier and more cooperative when they’ve been fed something—anything. I often have a few liters of soda; it’s inexpensive and everyone’s throat gets dry eventually. Water, coffee, and tea are good choices. Donuts are nice, though messy and costly and can cause sugar-high crankiness. But always offer something for the mouth—even a pack of chewing gum, tossed matter-of-factly across the table, is a friendly gesture.

Establish a Timetable: Announce at the outset the timetable for the meeting. Don’t promise a shorter meeting than is likely or worthwhile. A good Logic Session can easily span a day, sometimes two or three days. Anything less than four hours is inadequate; don’t waste your time or anyone else’s if you can’t get the group to commit to more than four hours. If they can’t—or won’t—then they’re not serious, and the effort won’t yield anything you’ll be proud of or want to hang your hat on.

Plan to Have Frequent Breaks: A trick I use is to take breaks, one half the group at a time. This may sound a bit like grade school, but hear me out. Call it the teacher’s pet syndrome, but there is something kind of magical that happens when people get a chance to “talk to the prof.” I see the same thing at every speaking engagement. When the speech is over, as the majority of people file out of the auditorium or banquet room, a handful make their way to the podium. There, they wait patiently to have a chance to offer their two cents: to chew the fat with the expert. I don’t fully understand the underlying psychology, but it makes people feel good, maybe even special. This is particularly true if they impart a personal pearl of wisdom that draws a rise of the expert’s eyebrows. In Schedule Logic Sessions, you are the expert.

The way I accomplish this is by announcing a short break. As the group begins to file out, if a few members of the team don’t choose to stay behind on their own, I ask a few people by name if they’d hold up a minute. Then I draw them into the struggle to solve a problem or address a specific technical question concerning the Execution Schedule. By the time the others have returned, this small subgroup has succeeded in working out something that makes them feel somewhat superior to the others. They’re in possession of some insider information.

They then take their break, and I repeat the process with the returned balance of the group—but on another subject, of course. Once the entire group has reconvened I ask each subgroup to explain to their colleagues what they did while the others were “in the sandbox.” Believe it or not, I use this technique during every break of a two-day or three-day set of Logic Sessions, and no one ever catches on that they have been subject to an intentional ploy of mine. But it works!


Like I said at the outset of this blog post, Logic Development Sessions are an essential and indispensible way to gather the collective wisdom of the Project Team that is ultimately responsible for the successful prosecution of the Work.  The primary challenge of every scheduler is to transfer the knowledge that is in the heads of those Key Players into a software model that is capable of simulating their mutually-preferred Project Execution Strategy.

Logic Development Sessions are a vital meeting of the minds. If your Project Schedules are not being widely used, or if they tend to become obsolete and fall out of relevance over a period of time … not holding Logic Development Sessions during Schedule Development may be one of the main reasons why.

I hope this article helps.

6 Comments to A Meeting of the Minds

  1. Ed Backiel says:

    It seems like this would be common sense. But I realize other commitments always threaten to pull us away from the most important tasks. I would think this form of communication cannot be substituted efficiently in any other way.

  2. Zach Reed says:

    This seems like a great approach to a logic session. The one hesitation I have is with regard to the level of commitment or involvement of the project team. I believe it comes down to how valuable individuals believe project time management to be (consider those who have negative experiences with project controls). This emphasizes the importance of consistent and accurate approaches to project time management.

  3. Sue Backiel says:

    This is a great example of how to conduct a Logic Development Session with the Project Team. By having a Meeting of the Minds, you not only create a Logic Diagram but you also learn about the people you will be working closely with. Learning the different personality types during the inception of a project will benefit you throughout the entire process. People are more willing to make compromises when needed and work productively towards an end goal if they participated in the creation of the SMART (Specific, Measurable, Achievable, Realistic and Timebound) Schedule.

  4. daveddbDave says:

    The blog proposes a way to begin a construction schedule in response to a LinkedIn Discussion thread. The author suggests using Logic Development Sessions as the preferred approach. This is the claim made by the blog’s author when he states he prefers to use this approach. There are other methods, which the author acknowledges and rebuts briefly before he goes on to define and elaborate his approach, by using excerpts from a chapter in his first book.

    He recommends assembling a project team ask them the right questions, challenge the answers, and thereby develop the schedule with them one activity at a time. The reasons for doing so are to a) immediately catch any mistaken interpretations you might make, b) motivate them to more readily accept the schedule developed, c) the ultimate execution strategy will reflect the best collective thinking of the project team.

    The blog covers some interesting and appropriate points while providing a fairly detailed description on how to conduct such sessions and is a reasonable argument for using such sessions when creating a construction schedule. The details provided offer an effective approach that can be used when developing project execution schedules whether for the construction or other industries. Similar approaches are used in other industries although not called the same.

    While a good blog / article the claim is qualified and there are exceptions because they’re his reasons have since it’s his blog are a normal approach. The reasons provided are relevant and effective for the suggested approach however, the evidence supporting the reasons is based on personal experience yet they do provide some sufficiency, credibility, and accuracy yet lacks any scientific rationale.

    In conclusion without going through a detailed analysis I like the approach and think it is a compelling and effective way to get all of the relevant information from the project team, ensure all relevant information is provided accurately, and will also cause them to adopt the schedule more readily than handing down the finished product from on high.

  5. Michael Neal says:

    [C] This is a great blog about the beginnings of schedule development and the processes that need to be involved. The contractors must be well prepared to go over their scope or else this could take a very long time to develop. I have seen the site work take multiple days to get organized due to the contractor not really knowing what work was involved. I like the breeakdown and intend to use it during our next work session.

  6. Connie Bremer says:

    This blog is certainly quite useful to understanding how to get to a point that you can ensure credibility of the schedule. All stakeholders are involved, so all will be on the same exact page before execution of work begins. If there are issues to iron out, it can all take place at this point in time. That’s not to say that unforeseen issues or mother nature will not play a role into the progress once work has commenced, but this step will provide the most accurate picture and model of scope.

What is your opinion? We'd like to know!