The following is an excerpt from Eric Uyttewaal’s new book, Forecast Scheduling with Microsoft Project 2010.
The “Schedule”
Most people understand the schedule as a list of deliverables and their due dates. To a professional scheduler that list of deliverables and their due dates is not the schedule, but the baseline schedule. The baseline schedule is a frozen copy of the approved schedule. It’s the target you work towards and compare progress against.
Many users of Microsoft Project don’t realize that the approved version of the schedule can be copied to and isolated as the baseline schedule. Others don’t realize that there’s a feature in Microsoft Project that allows you to do this very easily. All these people treat the schedule itself as a collection of promised dates that need to stay the same, which is really the role of the baseline schedule. These people become reluctant to make any changes to the schedule once it has been approved. They stop using the schedule as a dynamic model to explore the impact of changes and suggest ideas for solutions. This is similar to being the doctor of a dead patient; there’s no need to monitor or intervene any longer.
Instead, project managers need to treat the schedule as a living body to be constantly updated with the latest available data. Now, the doctor has a live patient and will need a thermometer to measure the temperature of the patient. The doctor will also need a standard of reference to determine if the temperature is normal (37.5 degrees Celsius or 98.6 degrees Fahrenheit). Better yet, the doctor needs a range with control limits for the body temperature to determine if corrective action should be undertaken. For project managers:
- The project itself is the live body of the patient.
- The dynamic model of the project is the thermometer.
- The baseline schedule (or the set of deadlines) is the standard of reference.
- The organization (including the project management office, portfolio managers, and executives) should specify the control limits.
The dynamic model and the baseline schedule together will tell you how much the project is behind or ahead.
The “Baseline Schedule”
We hope you recognize that the baseline feature in Microsoft Project is a major feature — very beneficial and very important. It allows you to actually monitor and control your living project. Alternatively, you should have at least a set of deadlines to work towards.
In the illustration below you can see that each task bar is split into two parts when setting the baseline. The top part (with the gray shade) is the current schedule — the dynamic model of the project. The bottom part (solid black) is the static baseline — the target schedule. The baseline schedule is an important artifact that should be handled with care; the baseline is essentially the contract between you as the project manager and the external customer or between you and the internal sponsor of the project. The baseline should remain the same throughout the project unless there’s a valid reason to change it. Like every contract, it requires careful change control, as explained in PMI’s Practice Standard for Project Configuration Management, published in 2007.
Questions to Consider
So, how did we get into this situation where many users of scheduling applications are treating the schedule itself as the target instead of treating it as a dynamic model? Why does just about every single executive mandate that the schedule can’t and shouldn’t change What happens is that Project users treat the schedule as cast in concrete Are they wrong Or are we professional schedulers wrong?
Who should make the adjustment here? There are two ways forward…
Should the user of Microsoft Project learn about baseline schedules and how to create them? Should they educate their executives that it’s the baseline schedule that won’t change, whereas the live schedule (dynamic model) is supposed to change to keep it reflecting the project and to have a tool with which what-if scenarios can be explored?
Or…
Should the professional scheduler forget about the term “baseline schedule” and start treating the word “schedule” like everybody else in this world is treating it today–as the list of deliverables and their due dates? Should we then replace the term “schedule” as we know it today with another term, such as “project model”? This term clearly communicates that what we create is something alive — something that should not be kept static and killed. Should we stop referring to ourselves as “schedulers” and start calling ourselves “project modelers“? A scheduler clearly doesn’t create a schedule; a scheduler receives a schedule (a list of deliverables and their due dates) and then creates a model of the project that will help the project team meet its schedule–their contract.
At the last PMI-College of Scheduling Organization (COS) conference in Calgary in May 2010, we even considered the term “Project Prophet” for the entire length of a hundredth of a second. Then we laughed about this joke (compliments of Primavera’s Joel Koppelman).
As professionals, we have arrived at a crossing here, and we’ll have to make up our minds sooner rather than later. Will you start calling yourself Project Modeler?
If you’re interested in chiming in on discussions like this and on other “scheduling” issues, please join our public LinkedIn group, “Forecast Scheduling.”
