What is a Project “Schedule”?

In the world of project management, project schedules can be characterized by their level of sophistication, by their intended usage, or by the nature of their content:

• In terms of sophistication, project schedules range from the simplest (activity listing, timetable), to the more comprehensive (bar charts which converge action with time), to the most complex (network-based schedules, such as CPM, where activities are causally linked).
• Project schedules can also be characterized by their intended uses.  Early-phase schedules (more commonly called plans) can be helpful in forging a project execution strategy.  Examples of strategic plans include feasibility plans, optimization plan, and consensus plans.  Project schedules enjoy their greatest use as tools of communication, coordination, and collaboration.  In all cases, project schedules (including precursor plans) are tools of the project manager, intended to optimize their efforts to effectively manage the project.
• The third categorization of project schedules relates to content of the presentation of the schedule. This content is conveyed using adjectives placed before the word “schedule”. Examples are “bar chart schedule”, “milestone schedule”, “submittal schedules”, “design schedules”, “outage schedules”.
  
  

What all project schedules have in common is an underlying assumption and belief: the project schedule models reality, whether that reality is anticipated or already realized.  No rational member of the project team would ever construe the schedule as the actual reality – only as a representation of a possible future reality.  A project schedule is not unlike a road map.  No one would attempt to drive on the map rather than in the streets.

The comparison of a roadmap to a project schedule is ideal for advancing the main point of this Open Letter: the project schedule models reality; it is not reality.  The project execution itself (as performed on the project) is the reality; the project schedule is the model used to manage that reality.  The correlation does not stop with the name of the model, the project schedule.  It goes deeper, in that for every entity on the project, there is a corresponding entity in the schedule:

• Out on the project, there are actions; in the schedule there are activities. 
• Out on the project, those actions consume time; in the schedule, activities have durations. 
• Out on the projects, human performers interact with one another; in the schedule, activities are related through dependencies. 

The project schedule is an intricate, computer-based model of the reality (actual or future) of the project.

The project schedule models project execution.  As such, it is a “project model.` It does not model itself; it does not model the schedule. Therefore, it is not a ‘schedule model.’ `.

CALL TO ACTION: The above point of view may seem obvious to most people familiar with Project Management and Time Management. But the idea that the project schedule models the project execution does have its detractors , because the term `schedule model` has invaded the very epicenter of project management culture and thought, the PMBOK Guide in its 4^th edition published in 2008. It invaded the PMBOK after the term was first inserted in the first edition of the Practice Standard for Scheduling that was released in 2007. The term “schedule model“ is not defined in the exposure draft of the Practice Standard for Scheduling (2^nd edition) but described as “This schedule model integrates and logically organizes various project components, such as activities and relationships to enhance the likelihood of successful project completion”.

From our vantage point, the authors of this open letter recognize two distinct schools of thought, that sadly seem at polar opposites of one another.  There is what respectfully might be called the New School of Thought, and that therefore leaves the other to be called the Old School of Thought. 

The following table compares the two Schools of Thought. To be sure, the two perspectives differ on many important points, including terms, concepts, processes, objectives, and so forth.  To illustrate the wide chasm that separates these two opposite viewpoints, we have chosen just one term: the one meant to represent the project schedule.  The Old School thinks of the project schedule as a project model. The New School thinks of it as a schedule model. And this standoff is at the root of this Open Letter!

We ask you, our fellow Scheduling Practitioner: Which is the better choice of term?  The answer may be apparent from a common-sense review of the arguments on behalf of each. But, frankly, the authors of this Open Letter have joined forces because we so strongly believe that the most important opinion is the one coming from our primary customer, the project sponsor, and also from the intuitive understanding of the terms by the other stakeholders of the project, in particular the project resources. 

We must thus ask: What does the typical project manager consider the project schedule to be?  A project model or a schedule model?

There are two schools of thought on what a “schedule” is:

Old School of Thought	New School of Thought
A schedule is a model of the project. Eric Uyttewaal defines “schedule” in the context of project management (“project schedule”) as follows in his book “Forecast Scheduling with Microsoft Project 2010” (www.projectprocorp.com/products.php): A schedule is a model of the project to forecast it. Murray Woolf defines “schedule” in the context of project management (“project schedule”) as follows in his book “Faster Construction Projects” (www.ics-global.com): A schedule is a project execution model.	The term “schedule” is neither used, nor defined in the PMBOK (4th edition) and Practice Standard for Scheduling (1st Edition). Replacing this term is a new term, “Schedule Model”, which by its wording gives the impression that the schedule is the matter being modeled.
Both authors treat the project schedule as the model of the project: The schedule essentially IS the model.	Instead a new term was introduced and adopted in these standards which is: “Schedule Model”.
We do not need a new term because this definition embraces the way people commonly understand what a schedule is. (See explanation below this table.)	The new term “Schedule Model” was invented because the common meaning of the term “Schedule” was found to be not useful for professional schedulers. This is at the heart of our overarching message; that the scheduling community has come up with a new term at the disregard of: Our primary customer, the project sponsor, that uses the term “schedule“ The intuitive understanding of the term “schedule“ by all other stakeholders in projects

In keeping with the notion that the project schedule models the project execution, we are most comfortable with how the typical project sponsor views the project itself.  As we discern, they seem to see project execution as the purposeful orchestration of effort by numerous parties, and toward the production of a final single product, which is most often comprised of numerous sub-products, called deliverables.  As such, a project involves actions taken to produce those deliverables.

Project sponsors and most people understand the term “project schedule”: a schedule is a list of things created in the project and their due dates. Essentially most people think of a project schedule typically as being like this:

Project Schedule
Project Deliverables	Due Date
Requirements document	Aug 12 ’11
New Location	Aug 30 ’11
Remodeling Contract	Sep 14 ’11
Remodeled New Location	Nov 10 ’11
Move to New Location	Nov 22 ’11

If you look at the Old School definition (Schedule is a model of the project.), then you can see that this common understanding of a “schedule” is embraced by their definition. It is embraced because the example of a typical project schedule as shown above is the simplest model possible of a project.

Now, as it happens, scheduling practitioners tend to add “sophistication” to this simple model by:

• Elaborating it into a more detailed Work Breakdown Structure (WBS) of phases, deliverables and often even activities and milestones.
• Adding dependencies between the WBS-elements (network logic),
• Adding duration and/or effort estimates to the model
• Adding constraint dates and other constraints to the model
• Adding resources and availability constraints to the model
• Assigning the resources to the activities and checking on if the aggregated workloads of the resources stay within their availability constraints.

None of the enhancements, however, take away from the project schedule’s ultimate purpose, that being to model the project. The obvious value in embracing the Old School (which is also the common) understanding of the term schedule is that no new term (such as “schedule model”) is needed.

What has worked so well for five decades requires no improvement.  If we wish to put an adjective in front of the single word, schedule, then let it be the word “project” as in “project schedule”.  And if we wish to have a pronoun which reminds us that the project schedule is meant to model, then let it be “project model”, not “schedule model”.

CALL TO ACTION: Currently, the working group that will decide about which term will be adopted in the second edition of the Practice Standard for Scheduling (PSS) will deliberate on this issue in the last weeks of January of 2011. Inasmuch as this working group essentially “owns” the definition of the term “Schedule,” it has the power and influence to change it. If the PSS working group changes the term, the next edition of the PMBOK (the 5^th edition) will likely reflect it.

So, the main question is: Should PMI re-institute the decades old understanding that a project schedule IS the model (of the project), or should it continue to argue its current line of thought, which is that a schedule is NOT a model and (thus) that we now need this new (technical) term “schedule model?” What is your opinion?

This Open Letter to the scheduling community asks you to: register your voice as to which school of thought you subscribe to! You can express your preference by writing an email to the project manager of the PSS Working Group of the 2^nd edition of the Practice Standard of Scheduling, attention of Mike Mosley through the secretary of the working group [email protected]. We would appreciate you also copying one or both of the authors of this Open Letter as well, see their email addresses below. Please use the subject line “Schedule or Schedule Model“.

The window of opportunity to make a difference is closing quickly. You need to register your position before January 21 when their deliberations begin.

With sincere and deep concern for the future of the scheduling practice, we remain …

Eric Uyttewaal, [email protected]

Murray Woolf, [email protected]

Don’t forget to leave your comments below

---

Eric Uyttewaal is one of the foremost authors/trainers/consultants on scheduling and on the use of project management tools from Microsoft. He authored the bestselling book “Dynamic Scheduling with Microsoft Office Project 2003” and his latest book is “Forecast Scheduling with Microsoft Project 2010”. Eric is founder and president of ProjectPro Corp, a company specializing in Microsoft Project and Project Server (www.projectprocorp.com). Eric has been involved in the Canadian Forces Supply System Upgrade Program, the Cognos (IBM) BI Suite release program and a Northrop Grumman Airplane Upgrade program. View Eric’s book “Forecast Scheduling”: http://www.projectprocorp.com/products.php

In 2010, Eric was named most valuable professional in project management applications “MVP Project” by Microsoft. In 2009, Eric received an award from PMI for his “Significant Contribution to the Scheduling Profession”. In 1997, he was President of the Ottawa Chapter of PMI, currently serving over 1900 members. From 2001 until 2004 and again since 2009, he is president of the MPUG-Ottawa chapter.

Murray Woolf is the president of The International Center for Scheduling (http://www.ics-global.com/  ) and author of Faster Construction Projects with CPM Scheduling (http://www.ics-global.com/IG-ICSStore.html ).