What is a Project Schedule?

What is a Project Schedule?

I know what you’re thinking.  “Again, Murray?  You’re going to litigate this question … again?  Give it a rest, my friend!”

“But not so fast,” I rebut. “I don’t think the matter has been fully resolved. At least not enough to be of much help at a practical level.  Hear me out … please!”

[Note: You may want to follow along with the diagram to the right.]

We’re Talking Construction

Let me clarify that I am talking about Plans and Schedules in the Construction Industry. After all, this is a Construction Project Time Management blog site.

Distinguishing Between Project Management and Project Time Management

We need to distinguish between two possible levels on the Project Management food chain where we are holding our discussion. There is the overall Project Management level, and then there is Project Time Management … which is considered, by most authorities, to be a functional subset of Project Management.  We shall take each of these possibilities separately.

Project Planning Yields the Project Plan

There is this ultimate key project level document called the Project Management Plan. And it is comprised of the various subordinate Execution Plans deriving from the various Project Management Knowledge Areas.  Thus, there is a Procurement Management Plan, a Cost Management Plan, a Scope Management Plan, and so forth.

According to PMBOK 4th Edition, development of the Project Management Plan requires inputs from other subordinate planning exercises, such as “Plan Procurements,” “Plan Communications,” “Determine Budget,” “Develop Human Resource Plan,” Plan Quality,” etc. It is of course significant to our discussion to note that, among the various subordinate planning exercises that contribute to the Project Management Plan … is one called “Develop Schedule.”

And therein lie the first two of many challenges to our understanding of what constitutes a Project Schedule.

  1. It would seem that the expression “Project Plan” is in all cases too ambiguous. There is no such thing as a Project Plan, per se. There is a Project Management Plan. And, depending on how you define a Project Schedule, there may be a Project Execution Plan.  But the bare term, “Project Plan,” is simply not specific enough.
  2. It would appear that the Project Schedule is a part of the Project Management Plan. Said differently, Project (Management) Plan and Project Schedule are not synonymous terms.

It would seem, then, that when formally-trained Project Managers speak about Project Planning, they would be thinking about production of the Project Management Plan (more generally) and not about production of the Project Schedule (more specifically).

Planning Leads to Scheduling

That brings us to our fourth consideration, which falls within the exclusive realm of Project Time Management. Ask most educated and seasoned Project Controls practitioners and they will tell you that Planning is a prelude to Scheduling. ICS-Research polled several hundred such practitioners and found that greater than 70% of the respondents held the following three views:

  • Planning tends to be more general, whereas Scheduling tends to be more specific.
  • Planning tends to be mainly strategic, whereas Scheduling tends to be mainly tactical.
  • Planning tends to occur before, and serves as an informational prerequisite to, Scheduling.

If we accept these views as being the general understanding within the Project Time Management community, then we must make a few observations that, when taken to their logical conclusion, pose an unavoidable (and, I would submit, still unanswered) question: What is a Project Schedule?

What are those observations?

  • The kind of planning and scheduling that is performed under Project Time Management deals with how the project will be executed. Hence, the more complete labels for these two activities are Project Execution Planning and Project Execution Scheduling. It should make sense that these two exercises speak to execution because, if they do not … then where else is Execution Strategy addressed among all of the other Project Planning exercises that go into the Project Management Plan?
  • The timing of Project Execution Planning, ahead of Project Execution Scheduling, suggests that the two interrelated processes jointly adopt a top-down, general-to-specific approach to the determination of how the project will be executed. Planning comes first, Scheduling second. And yet, the iterative nature of Planning and Scheduling exercises is such that even after detailed Scheduling, there is often the need to revisit the Execution Planning, alter some previous assumptions, and then adjust the Project Execution Strategy, at the higher, more general level.
  • Because it is impractical, if not also likely counter-productive, to force a firm line of demarcation between Project Execution Planning and Project Execution Scheduling, Project Time Management (as a discipline) would be better served with a more all-encompassing label (to include both exercises), which we would logically call the Project Execution Strategy.  That Strategy includes the assumptions and conclusions of Project Execution Planning, and the details of Project Execution Scheduling.

One Document or Two?

If Project Planning (more precisely, Project Execution Planning) yields the Project Execution Plan … and if Project Scheduling (more precisely, Project Execution Scheduling) yields the Project Execution Schedule – then, are the two entities contained in one document, or two?

What I am asking is whether this thing we so casually call the “Project Schedule” actually contains both the higher-level, more general Project Execution Plan and the Project Execution Schedule) … or is the Project Execution Plan to be found somewhere else?

Where is the Missing Document?

This is a legitimate question to ask, for if one were to think of the Project Execution Plan as somehow separate from the Project Execution Schedule, two obvious questions confront us:

  1. Where is the missing Project Execution Plan? For it would not be included in the Project Execution Schedule (That is our assumption.).
  2. More to the point, have we checked the Project Execution Schedule to make sure that it does not contain any general, higher-level strategic content, but instead only the tactical, lower-level, detailed content one would find in a typical Project Execution Schedule?

The Label “Project Schedule” Is a Bad Choice

If our polling is at all correct, then the vast majority of you folks reading this article subscribe to the notion that the Project Schedule actually contains multiple levels of detail. Yes, there is the detailed, tactical level of the Project Schedule (Level 3 and/or 4, according to most scheduling authorities). But, yes also, there is the  more general, strategic level of the schedule, as represented by roll-up or summary activities, and the clever use of inserted milestone and imposed date constraints.

Taken together, this would mean that one single document is both a Project Execution Plan and a Project Execution Schedule. And if this is so, then the label, “Project Schedule,” would appear to be too limiting.  Would you agree?

The above thinking process explains why, within the ICS-Compendium, the document otherwise known as the Project Execution Schedule is referred to as a “Project Execution Strategy.” That strategy includes both the strategic Plan and the tactical Schedule. For how could either component ever be disregarded?  What good is a Project Execution Plan that does not have the credibility of the detailed Project Execution Schedule to confirm its assumptions?  And what good is a Project Execution Schedule that does not consider and accommodate an overarching Project Execution Plan?

Back to the question of this article’s title: What is a Project Schedule? The question was actually intended to challenge the prevailing definitions of the term “Project Schedule.” If you examine them, as we have at ICS-Research, you will find them ‘all over the map’ when it comes to whether they include the Project Execution Plan or not. Some mention planning only; some mention scheduling only; some mention both; and, some mention neither.

And if we, as a discipline, cannot even agree on what we would expect to find in a Project Execution Schedule, then how dare we seek to establish standards and best practices for schedule development and composition?


6 Responses to What is a Project Schedule?

  1. Julie Garcia says:

    The project execution plan and schedule are two different things in my mind, but the schedule includes the plan. I think the term Project Execution Strategy is good terminology for the “schedule” since it does encompass both pieces. Thinking of the project team, when coordinators sit down and discuss a project, they aren’t talking durations and relationships between activities, they are discussing the “plan”, the big picture of the work that needs to be completed. Its not until that plan is worked out with details (durations, relationships, etc) that the plan becomes a schedule or better yet a strategy.

  2. Zach Reed says:

    I can see the importance of separate documents for the project execution plan and project execution schedule. If these are two different objects than they should be made that way. A separate project execution plan would be a clear source of the original plan. From a documentation and “paper trail” perspective, this makes sense, and should be completed prior to the initiation of the project execution schedule. One should not have to be guessing what the plan is during development of the schedule. However, as the schedule develops I imagine it might be necessary to revise the project plan based on what is represented in the schedule.
    The schedule should be transparent and detailed. It should allow the project management team to evaluate each step and not be hypothesizing about a delay based on a high-level activity. Not only does this impact the beginning of a project (the time for drafting all of the planning and scheduling documents), but also the end of the project as well. The way in which a schedule is built could make a major difference when evaluating Time Impact Analyses or other claims.

  3. Sue Backiel says:

    I agree, you can’t have a Project Execution Schedule without Project Execution Planning. The Project Execution Plan is similar to an outline of a book, where as the Project Execution Schedule is the final draft that you send to the editor. There may be edits (additional planning or revisions) needed to the final draft to improve the product. Without the outline, the writer would have a difficult time organizing the paragraphs into an order that makes sense to the reader. An accurate and effective Project Execution Schedule requires Project Execution Planning.

  4. Michael Neal says:

    [C] I agree to Connie’s remarks and add that the strategy will change based on the progress of the project, so this is an ongoing process throughout the project.

  5. Chase Childress says:

    Not to sound repetative, but I must agree, that what is commonly referred to as the project schedule contain elements of both the project execution plan and schedule. As stated above the project execution shedule is can and often does change as the project moves along. As the project progresses project execution planning is often revisited in order to deliver a successful project.

  6. Connie Bremer says:

    This blog was thought provoking in that thinking more critically are we able to better define nomenclature and alleviate some of the ambiguity in the construction scheduling world. I tend to agree that the “Project Execution Stategy” includes both the project execution plan and the project execution schedule. How could you have one without the other?

Leave a Reply

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