The Truth About the Credibility of Schedule Data
In a companion blog at It’s About T.I.M.E., we learned that all Schedule Elements in a Project Schedules are expressed in terms of what Cognitive Project Management calls Schedule Tense. We learned that a Schedule has three Schedule Segments: Past Segment, Current Segment, and Future Segment. And we further learned that within each of these Segments, Schedule Data Types differs by origin and purpose. Past Segment Schedule Data is either Realized or Gleaned; Current Segment Schedule Data is Apparent; and, Future Segment Schedule Data is either Strategic or Predictive. Together, these five Data Types underpin the G.R.A.S.P. Concept.
The Flow of Essential Schedule Data
In this blog, we will take advantage of this new-found appreciation for the variable quality of Schedule Data. We begin by plotting the progressive flow of Essential Schedule Data. Figure 1 provides an easy-to-follow diagram of how information within the five Schedule Segments evolves across the Schedule Data continuum.
The red arrow maps the natural progression of Schedule information. It starts with Actual performance, where the best efforts and intentions of the Project Team are “realized” as Work is performed. This information is provided to the record, as Realized Data. Calculations and analyses are performed on the Realized Data and certain conclusions are inferred; these are called Gleaned Data.
In the Current Period, when all Actual Work occurs, plans are made for the immediate future (Imminent Period Apparent Data). These Plans are the most detailed that the Project Team will ever see. We recall that these Plans are based on the insights gleaned from Past Segment Realized Data. Said differently, based on what we have learned from our performance to date we lay plans for the immediate future that reflect an appreciation for the limits of our ability to perform.
There is a symbiotic relationship between Apparent Data and Strategic Data. This is true because our short-term, immediate plans (Imminent Period Data) modify – and are modified by – our strategic, long-range plans for the balance of the Project. Finally, the Strategic Data is the basis upon which we apply some fairly simple formulas, which in turn generate what we call Predictive Data.
Schedule Data Integrity Improves Across the Project Length
As a general statement, all types of Schedule Data tend to collectively improve as the project progresses. Of course, the opposite is also true: Schedule Data is least reliable or credible at the outset of the project, with one glaring exception: Imminent Period Data for the opening weeks of the project. But now, let’s look at the quality of Schedule Data within specific Schedule Segments and sub-Segments. Now, here are some further observations discussed in greater detail in the above-referenced companion blog.
- Realized Data accuracy correlates to data acquisition frequency.
- Gleaned Data accuracy gets better as the project progresses.
- Apparent Data reliability correlates with the width of Current Period.
- Strategic Data reliability and coverage period are inversely proportional.
- Predictive Data credibility and coverage period are inversely proportional.
Hard to Say : Steering and Navigating
Dominant Project Management’s Idea of Project Control
Little has changed, in over five decades, when it comes to how Project Time Management is practiced according to the Dominant Project Management model. Just reference any mainstream book on recommended or best practices concerning the development, maintenance, and usage of the Project Schedule, and you are certain to learn about three basic stages of the overall Project Time Management protocol:
- Schedule Development
- Schedule Monitoring
- Schedule Control
That’s it in a nutshell. Once the Project Schedule has been created, Project Time Management boils down to (a) monitoring the ongoing project work, and (b) taking necessary steps to keep that work in accordance with the intended plan of attack, as depicted in the Project Schedule.
- Schedule Monitoring further subdivides into two basic processes: measuring and recording. First, you measure the work that has been performed in the current reporting period. Second, you record the progress in the Project Schedule iteration, and perform some basic scheduling calculations in order to derive key scheduling data about where the project stands as of the Data Date (end of the current reporting period).
- Schedule Control, too, is subdivided into two basic processes: analysis and correction. First, you analyze the key scheduling data identified in the Monitoring step, looking for any significant disparities between what had been planned to take place and what actually did take place during the reporting period.
Second, you call for “corrective actions” to be taken as soon as possible. Principally, only two corrective action options are considered. One option, if the disparity is not too great, is to craft a recovery plan that steers upcoming near-term performance back into alignment with the Project Schedule. The other option, if the Project Schedule is found to be simply too out of whack, is to call for an overall revision of the Project Schedule.
So, when we speak of Schedule Control, just what are we controlling, and how are we achieving that control? As for what is being controlled, I can think of only two objects of control: either the project, or the schedule.
- Controlling the Schedule: To be sure, we are certainly safeguarding the ongoing relevance and viability of the Project Schedule when we demand that it be either followed or revised. In that sense, at least, we are controlling the quality and utility of the schedule. This much we can agree on, readily.
- Controlling the Project: But what about the Project itself? Are we controlling its execution? And if so, just how are we accomplishing this? Let’s apply a simple process of elimination:
- I think we can agree that Monitoring is not the same as controlling, so merely monitoring work performance (after the fact) would not constitute project control, right?
- That leaves the processes of Controlling. And about this, can we agree that Data Analysis is not a controlling behavior, since it is after-the-fact and retrospective?
- All that remains is Corrective Actions: which boils down to either devising a Recovery Schedule (and, we assume, dutifully following it), or creating a Revised Baseline Schedule (and, again assumed, dutifully following it).
- Which of these, to your mind, constitutes controlling? If you’re like me, you probably find it hard to say.
Who’s to Navigate and Who’s to Steer
Dan Folgerberg has this beautiful verse in his classic song, Hard to Say. “It’s never easy and it’s never clear who’s to navigate and who’s to steer. So you flounder, drifting ever nearer the rocks.”
When you stop to think about it, steering and navigating are two very different things. In a car, the person behind the wheel is doing the steering. The person alongside, with map in hand, is navigating. But which one of them would we consider to be controlling the vehicle? I would argue that it is the driver, not the passenger, no matter how vital or timely her navigational information might be.
Let’s repeat the question: who is steering the Good Ship Project? And just what constitutes steering, as such? I submit that it is the Project Manager or, in construction, the General Superintendent. I submit that the gist of steering takes place at the Weekly Coordination Meeting with subcontractors in attendance, when the next week’s workload is highlighted and a sort of preflight checklist is read off and confirmed Ready!
So how does a Revised Baseline constitute steering? It doesn’t. And neither does the Recovery Schedule, which is just a limited override for a piece of the Original Baseline Schedule. Either way, we are just messing with the first half of “Plan your work…”, but we are not really dealing with “…working the Plan.”
I dare to assert that, under the Dominant Project Management model, Project Time Management contributes very little to the genuine cause of steering the project forward, let alone controlling the action. With only the slightest exception (the limited influence of a Recovery Schedule), there is no aspect of the traditional Schedule Update process that meaningfully contributes to the control of the project itself.
Cognitive is About Never Losing Sight of Destination
The previous discussion about steering does not exhaust the Project Control discussion. There remains the other role of the Project Schedule, to facilitate navigation. We have already noted that the Dominant Project Management model is little concerned with matters of navigation.
In the Cognitive Project Management model, we identify an entire category of Future Segment Schedule Data dedicated to helping the project navigate challenges waters. Strategic Data includes changes to Future Segment Schedule Data that result from prospective thinking that dares to revisit the last-known Future Segment data and compares it with the most recent Apparent Data information.
In practice, Strategic Data is constantly being revisited and revised, as necessary. Such changes are seen as Course Corrections, a proactive, preventive measure. Contrast this practice with Dominant Project Management’s aversion to schedule content changes. It is quite common for contracts to prohibit the Contractor from revising the Schedule without prior consent from the Owner.
One has to wonder how different the track record would be if constructions projects were managed with a philosophy that emphasizes Execution Strategy instead of the current obsession over loyalty to the Original Plan and strict compliance with its every detail. The contrast could not be more stark, or obvious. Dominant Project Management is singly concerned with steering, keeping the project compliantly between the lane markings. Meanwhile, only Cognitive Project Management cares about navigating (as well as steering); that we might always be sailing down the most advantageous lane.
What GRASP Tells Us about Dominant PM Approach to Project Time Management
What is being Gleaned and How It Being Used?
As previously stated, Dominant Project Management seems overly concerned about Contractor compliance with the Baseline Schedule. I have mapped this concern in Figure 2. Using the GRASP model, it is really easy to see why, quite possibly, the Dominant Project Management approach to Project Time Management doesn’t seem to lead to consistently successful projects.
As its main cyclical analytic exercise, Dominant Project Management calls for a comparison between Planned Past Period Performance and Actual Past Period Performance. As for how the combined Realized and Gleaned Data is actually used, it boils down to two initiatives: insuring Compliance with the original Baseline Schedule, and predicting project outcomes.
What is Not Being Gleaned?
Notice that there is no real emphasis on Future Period Strategic Data, and Imminent Period Data is modified solely to “correct” for any deviations identified by the above comparison between Planned and Actual Past Segment performance. The focus is on adherence to the original Baseline Schedule. Contrast this approach with Cognitive Project Management’s emphasis on forward-thinking strategy, as shown in Figure 3.
Why GRASP is So Powerful
The GRASP Concept is indeed a powerful alternative to the current Compliance-based approach to Project Time Management. I encourage you to apply the GRASP Concept to your next project. While it promises to deliver many benefits, here are three of the most significant:
- It keeps the Schedule credible, relevant, and useful.
- It tempers our judgments with a constant awareness of our informational limitations.
- It disallows us from ever losing sight of our goals (long-term, and short-term).
I hope you have enjoyed this discussion about this brief introduction to GRASP and the Schedule Data Credibility Profile. If you are interested in learning more about either, CPM Mechanics has two chapters dedicated to these all-important topics. To get your copy of the book, click here.