Peruse the multitude of Project Management, Project Time Management, and Project Controls groups on LinkedIn and at least once or twice a month you will find debates over some technical aspect of what goes into a good Project Schedule, or of what constitutes recommended scheduling practice. Words fly, tempers rise, heels dig in, and … in the end, no one budges.
Strong Differences No Surprise
That there are strong differences of opinion among Planners and Schedulers comes as no real surprise. First, humans rarely agree on anything! Second, Planning and Scheduling practices differ widely by industry, as well as by geography. Third, there are widespread inconsistencies among the leading authorities and trainers on Project Time Management practices, so naturally their followers and students will disagree.
Beyond all of the above, I happen to think that there is a wide philosophical divide that transcends and even trumps all other factors: purpose. As simple as it sounds, I think the Project Management world is split right down the middle as to why we have (or need) that pesky Project Schedule in the first place!
Uses for the Project Schedule
In my first book, “Faster Constructions Projects with CPM Scheduling,” I identified fourteen common uses for Project Schedules, including: planning, coordination, communication, work organization, resource management, performance measurement, forecasting, reporting, contract administration, cost control, marketing, financial planning, record-keeping, and dispute resolution.
While the above list is fairly exhaustive, I am not sure it is especially helpful. Perhaps we would be better served if we could reduce the list to just those uses of the Project Schedule that are the most common ones. As I see it, they fall under two primary headings:
- Using the Project Schedule to Understand
- To Measure Progress
- To Analyze Reality
- To Optimize the Future
- Using the Project Schedule to Communicate
- To Inform
- To Coordinate
- To Direct
- To Control
Recognizing How and Appreciating Why: Two Different Things
There is a problem with even this shorter list: it speaks to how the Project Schedule is used, as opposed to why it is used. You might think that why is implied by how. But you would be mistaken. Take, “To measure progress,” for instance.
Okay, so we use the Schedule to measure progress. But why do we want to know how much progress has been made? It could be that we want this information in order to validate progress payments. Or, we may want this information in order to better plan for upcoming resource needs. Perhaps we want this information in order to more accurately predict whether or not we will meet contract deadlines. You get my point, I am sure.
Back to the In-Fighting
Let’s get back to the in-fighting that I mentioned being so prevalent on LinkedIn. I have been studying those debates for more than a year now and have come to a conclusion, of sorts. I think that there may actually be two dominant schools of thoughts as to why we produce and maintain Project Schedules in the first place. And I think that the differences in those two schools of thought go a long way to:
- Explain why there is such disagreement in the Scheduling World about what constitutes a good schedule or acceptable scheduling practices.
- Explain 50-70% failure rate across construction projects, when it comes to meeting deadlines.
Prediction versus Commitment
That’s it! That’s the tug-of-war! Some folks see the Project Schedule as a tool for predicting how the future will play out, while others (far fewer, sadly) see the Project Schedule as a set of commitments among the Project Participants.
Let me contrast the two perspectives with a simple example. Your brother is returning from a business trip and calls to ask if you could pick him up at the airport. He will be arriving the next day at 2:30 pm. You check your calendar, confirm that you are free, and you tell him, “I will be at curbside at 2:30.” Is this a prediction, or is it a commitment? Hopefully, you will agree with my sense that this is a commitment. After all, your brother is depending on you.
Now let us move forward to tomorrow. You are actually in route to the airport when you suddenly encounter a major traffic jam. Realizing that you are running late, you call your brother’s cell phone and leave a message for him to hear once he lands: “I am running late. I will be at curbside at 3:00 pm.” This, I hope we agree, is a prediction.
The question I am asking with this article is whether the dates that we see in a typical Project Schedule are predictions or commitments? The short (and easy) answer is that they are always predictions. That is, based on the arithmetic Forward Pass calculations performed (in the blink of an eye) by the scheduling software, the Earliest Dates that we read are, for all practical purposes, predictions of when each and every future activity will start or finish, at its earliest!
The unanswered question, then, is whether the Project Schedule ever reflects commitments? And if it does, then how can we distinguish which dates are predictions and which are commitments.
We’re Not Talking About Date Constraints
Let’s be clear: we are not talking about Date Constraints imposed on Milestone Activities, such as to reflect contractual requirements like “Achieve Building Dry-In” or “Achieve Permanent Power.” A requirement is not the same as a commitment. A set of bid documents will include a number of performance requirements, to be sure. And so, when a contractor submits a bid proposal, he is saying that it understands what the requirements are. When he signs the contract and accepts the requirements as performance goals, he promises to meet those requirements. The question I am asking is whether the Project Schedule represents firm performance commitments as between the Project Players – or not. Do you understand the question?
Successful Projects Require Schedule Commitments
As I see it, if the Project Schedule is not understood by the Project Players as expressing firm, credible, and trustworthy commitments between and among them, then I think the project is doomed to missing its temporal deadlines.
Why do I say this? Because, more than anything else, Project Management is about Coordination. According to Cognitive Project Management, Project Management boils down to Collaboration, Coordination, Cooperation, and Communication. And the Project Schedule is to be found at the epicenter of all four objectives.
When a Project Schedule is first created, input into that process comes from those who will be performing the work of the project. These Project Players are the ones who best know what is entailed in achieving the contractual requirements of the project: after all, they are the ones who bid the job, put their money where their mouths are, and are now conveying to the Project Scheduler all of the gory details pertaining to each activity that they will be performing: activity durations, crew configurations, productivity rates, and interdependencies between activities.
A Schedule is Absolutely a Set of Commitments!
There is a trust that is formed during Schedule Development, a trust between the Scheduler and the Project Players themselves. The Scheduler promises the Project Players that the schedule, once sewn together, will insure that each of them has the time (duration) and access (logic) to perform their respective pieces of work. And, in turn, the Project Players promise to one another that they will do their level best to perform their respective work in the time (duration) allotted and in the sequence (logic) depicted in the schedule.
Think of the Project Schedule’s details (dates, durations, logic, and so forth) as functioning similar to the standard symbols and rules of driving. By mutual agreement, we agree to staying on the right side of the road. We agree to using turn signals to indicate our intentions. We are agree to staying with the minimum and maximum speed limits. We are to not tail-gate, or drive aggressively. And so forth.
So, when I see an Early Finish of June 3 for installing a transformer, to me that is a commitment by the electrical subcontractor that he will, in fact, install the transformer by June 3rd. And if the electrical subcontractor likewise sees this as a commitment he made, and if the other subs also see it as a firm commitment, then coordination is fostered and facilitated.
Get Out of My Way!
I am happy to report that findings by ICS-Research confirm that the vast majority of construction workers have a really great attitude toward their work: “get out of my way!” If asked whether they will have that transformer installed by June 3rd, the response we can expect to hear, reflective of this “get’r done!” attitude would be: “I said I will get it installed by then. Well, by God, it will be installed by then!”
Constructions workers have some of the best work ethics you will find anywhere. Contrast this with the nonsense propagated by Critical Chain advocates, who decry the worker as lazy and unreliable, and who cite Parkinson’s Law as justification for robbing Project Players of their exclusive durations. Parkinson’s Law says that “work expands to fill the time allowed for its performance.” Maybe in other industries this is true. But in Construction the dominant pressure is to get done as soon as possible, mainly in order to get paid as soon as possible.
Workers are Not Marbles; Durations are Not Probabilities
Now we get to the crust of it. In recent years I have observed, with a fair amount of dismay, an increasing influence of the Prediction Scheduling crowd across Project Management, Project Time Management, and Projects Controls circles. What I somewhat simplistically called Prediction Scheduling has taken root within several statistical camps. One such camp is Monte Carlo Analysis. Another is Probability Analysis. A third is Critical Chain. A fourth is Earned Value. A fifth is Risk Management.
In all of these cases, the underlying assumption is that the activity duration is this deterministic estimate that necessarily contains a margin of error. According to these various sciences, the activity duration cannot be taken as anything close to an absolute. Instead, it must be understood as a superficial, unreliably simplistic, and inherently inaccurate estimate of how long something will take. And when aggregated across an entire schedule, the exponential effect of single activity duration inaccuracy yields an overall Project Schedule that could not possibly reflect how the project will actually turn out (add your own sarcastic inflection). And so, these different sciences recommend running thousands of iterations of the schedule, using a range of duration estimates.
Frankly, their thinking might make some real sense, and I would be inclined to climb aboard their bandwagon, but for the fact that workers are not marbles, coins to be flipped, dice to be tumbled, or mindless silver balls in a pinball machine. Workers have character. They have pride. They honor their word.
Set up a tennis ball pitching machine on the side of a busy highway and set it to shoot a tennis ball every 15 seconds laterally across the highway. What is the probability that a car will be hit by a tennis ball? Statisticians can create a formula that will answer that question, based on the density of traffic, the speed of the vehicles, the width of the highway, the trajectory of the balls, etc.
But I can guarantee you that whatever the answer, the number of tennis balls colliding with cars will be a heck of a lot more than the number of pedestrians colliding with cars. Why? Because humans have eyes and ears. They have judgment. They have experience. Humans think!
Back to Your Brother at the Airport
So when you tell your brother that you will be at curbside by 3:00 pm., is your statement a prediction or a commitment? Likewise, when we assign durations to activities, are these commitments or not?
Now go back to that list of uses for the typical Project Schedule. Do you better appreciate the distinction between what we do with our schedules, and why we do them? For instance, when we status the schedule as part of the monthly schedule updating process, we do so in order to maintain the schedule as a current and relevant document. But that is still not the why we are looking for.
Why do we want the schedule current and reflective of reality? Well, one possible answer is in order to have the most reliable and beneficial tool for coordinating the work. But, I am sad to report, that is not the most common use of a properly statused schedule. Instead, it is to be able to predict, as accurately as possible, how the project will turn out.
Prediction Is at the Heart of Project Control
I close by noting that the essence of Project Control, as espoused by Dominant Project Management, is Variance Measurement and Reporting: that is, comparing what was planned with what actually transpired. Any differences, called variances, are reported and the Project Management Team is expected to take corrective actions to return the project back to the planned Execution Strategy.
The problem with this approach, as I see it, is that all of the applied variances compare planned and actual predictions. For example, if the latest update shows the Project Completion date as the same as was reported in the previous, then the variance is assessed as “none.” How about Earned Value? If the SPI (Schedule Performance Index) is found to be 1.00, then the variance is considered “none.” If the Early Finish dates for a future activity remains the same as it did in the previous update, then variance is said to be “none.” In all of these cases, what is being compared are estimates about future events. Can you see that?
Navigation versus Weather Reporting
Cognitive Project Management takes a different view. It believes that effective Project Time Management boils down to being aware (cognizant) of current circumstances and then making improvisational decisions that help navigate the project across turbulent waters. Just like the pedestrian who studies the traffic flow before venturing across the street, shrewd Project Managers and Superintendents consider a number of real-time factors before deciding how best to move forward.
Notice that this approach to Project Management cares little about past variances, except in what it tells them about their current capability. So, whereas Cognitive Project Management is about navigating the storm ahead, Dominant Project Management is mostly about reporting yesterday’s weather. But worse, Dominant then uses the performance of past history to predict future outcomes, as if we never learn from our mistakes, recognize windows of sudden opportunity, or honor our word.
And therein lies the difference. I happen to think that this difference in attitude accounts for the bulk of the in-fighting on LinkedIn, and elsewhere, among Project Management, Project Time Management, and Project Controls “experts.”
What do you think? Am I all wet? Add your comments below … please.