Author: Eric Uyttewaal

In the world of project management project schedules can be characterized by their level of sophistication, intended use, or the nature of their content. In terms of sophistication, project schedules range from the simplest (activity listing or timetable), to the more comprehensive (bar charts which mesh 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 include feasibility, optimization, 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. A third type of project schedule relates to the content it contains, such as “barchart schedule,” “milestone schedule,” “submittal schedule,” “design schedule,” or “outage schedule.” But what all of these 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 itself as the actual reality — only as a representation of a possible reality. In this regard, a project schedule isn’t unlike a road map. No one would attempt to drive on the map rather than on the streets it represents. 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 isn’t 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 doesn’t stop with the name of the model, the project schedule. It goes deeper, in that for every entity on the project, a corresponding entity exists in the schedule: Out in the project, there are actions; in the schedule there are activities. Out in 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’s a “project model.” It doesn’t model itself; it doesn’t model the schedule. Therefore, it’s not a “schedule model.” Old School, New School This 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 epicenter of project management culture and thought — the PMBOK Guide in its 4th edition, which appeared 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” isn’t actually defined in the exposure draft of the Practice Standard for Scheduling (2nd edition) but it is described: “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 on this topic, which sadly seem polar opposites. There’s what respectfully might be called the New School of Thought, which 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 them, we’ve 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! Now 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. But, frankly, we have joined forces because we 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. What does the typical project manager consider the project schedule to be? A project model or a schedule model?   In keeping with the notion that the project schedule models the project execution, we’re 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” as a list of things created in the project along with their due dates. Essentially most people think of a project schedule like this: If you look at the old school definition, in which the schedule is a model of the project, you can see that this common understanding of a “schedule” is encompassed in its definition, 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 whether the aggregated workloads of the resources stay within their availability constraints. None of these enhancements, however, take away from the project schedule’s ultimate purpose: to model the project. The obvious value in embracing the old school, which reflects a morecommon 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 that reminds us that the project schedule is meant to model, then let it be “project model,” not “schedule model.” A Call to Action Within days a working group will decide which term should be adopted in the second edition of the Practice Standard for Scheduling The working group expects to deliberate this issue in the last weeks of January 2011. Inasmuch as this 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 5th edition) will likely reflect it. So, we’re asking you: Should PMI re-institute the decades-old understanding of a project schedule as the model of the project Or should it continue to argue its current line of thought: that a schedule isn’t a model and therefore we need a new technical term, which is “schedule model”? We’re also asking you to register your voice as to which school of thought you subscribe to! You can express your preference by sending an email to the project manager of the PSS Working Group of the 2nd edition of the Practice Standard of Scheduling, Mike Mosley. That message should be emailed to the secretary of the working group, Elaine.lazar@pmi.org. At the same time, we’d appreciate your cc’ing us in that message with the subject header, “Schedule or Schedule Model.” Our email addresses are EricU@ProjectProCorp.com and mbwoolf@ics-global.com. The window of opportunity to make a difference is closing quickly. You need to register your position before Friday, January 21, which is when their deliberation is expected to begin.