The schedule baseline, at the vertex of accuracy and approval, enables a project team to answer two long-term questions. Can we still meet our target finish dates? How can we better plan the next project? Schedule baselines are perhaps the most misunderstood concept in Schedule Management both in terms of their utility, and as a metric of performance.

This article will begin by narrowly defining what a schedule baseline is and why a shared understanding of this definition helps teams forecast their project’s outcome.

We will then discuss how the baseline is used in schedule analysis of a single project, and the predictive role schedule baselines play in large, sustained programs.

Defining the Term “Schedule Baseline”

The business world has both overused and mystified the word “baseline” to the detriment of all. Baseline may refer to requirements, schedule, budget, business process, vendors, quality, strategic objectives, and a host of other realms. Bosses admonish their managers to guard the company’s margins in Plutarchian terms. “Come back with your baseline — or on it.” The liege who succumbs to rebaselining their project is convicted of cowardice and consigned to a fate worse than death!

Figure 1: Schedule baselines do not measure project success. However, their upkeep may warn a project team of trouble in time to prevent it.

Do not think of schedule baselines in such terms. All projects have “must not miss” deadlines. But these critical points in time are mere pieces of the whole picture. Project schedules are unavoidably fluid. Meeting essential deadlines and maintaining a schedule baseline are separate responsibilities with very separate purposes.

All project planners create their schedule using a collection of estimates and assumptions. Project activities will take a certain amount of work. The team will include a certain number of people. Some tasks can happen in parallel, while others must happen sequentially. Combining these assumptions allows the project planner to build a model of the schedule which predicts the project completion date. A disciplined project team will formally review and approve the plan just as they would be expected to approve the project scope and budget. This formal approval of the schedule allows the Schedule Manager to set the baseline, taking a snapshot of the plan to date. Figure 2 depicts a very simple project plan which has just been baselined. In this instant, all projected start/finish dates, by definition, equal the baseline start/finish dates when the baseline is set.

Figure 2: Baseline and projected tasks dates are identical before the start of a project. A newly baselined project plan has a Schedule Performance Index (SPI) of 1.0, and zero schedule variance.

This snapshot also captures the duration, effort, and – depending on the sophistication of the schedule and schedule management software – the resource loads for every line in the schedule. How the schedule baseline is used and the reverence that it is given are subsequent concerns. For now, let’s take the discussion above to define the schedule baseline as follows.

This simple definition contains two components which deserve emphasis. First, the elements of the baseline are agreed upon. This means that the planners, the managers, the leaders, and the clients have reached a consensus that the work described in the schedule accurately models how everyone believes the work will unfold. The baseline approval process also documents stakeholders’ understood commitment that they will use their involvement to support the plan of action outlined in the schedule.

The second point of emphasis is that the schedule baseline is limited only to work and events which have thus far been planned. Many projects, even late in their life, include work which has not yet been planned. A construction crew working on a foundation may not know every step they must take to secure the building’s structure until the hole for the basement levels are dug. Their initial schedule baseline may only detail the first few months of a yearslong endeavor. Work not yet planned should not be included in the schedule and thus not be included in the baseline.But schedules are not snapshots. Schedules are fluid documents which change regularly over a project’s lifetime. Deviation from the baseline is inevitable and predictable.¹ To cope with these expected shifts, Schedule Managers track how the current schedule varies from the baseline plan.

Schedule Baseline Relevance and Importance

Over the course of a project, some tasks start or finish early. Others may start or finish late. The difference between the baseline start/finish dates and the projected start/finish dates is called variance and is usually measured in business days. In Figure 3, Task A has a finish variance of 3 days because it finished late. Task C has a start variance of -2 days because it is projected to start early. The overall finish variance of the project is zero because the overall project finish date has not changed.

Figure 3: Task projected start/finish dates often shift, but do not necessarily delay the entire project.

When a task completes, its actual finish date is set, and the projected finish date becomes the actual finish date. By the end of the project, each task’s projected start/finish dates equal the task’s actual start/finish dates. The Schedule Manager’s most prominent responsibility is to ensure the project finishes on time. They do this by tracking individual tasks through to completion. This managerial form of dead reckoning affords the Schedule Manager the earliest possible opportunity to detect when the schedule is drifting and grants the project team the largest possible window to take corrective action.

Figure 4: All tasks marked complete after the end of the project. Note that the project ended slightly earlier than planned.

This recorded history also enables project teams to improve their estimation and planning over time by regularly comparing task effort and duration estimates against actuals. Figure 5 shows a partial table of estimates that a project team has populated based on years of past performance recorded in the schedule. These small, medium, and large estimates may vary considerably for individual tasks, can provide surprisingly accurate long-range forecasts for schedules that are thousands of lines long.

Figure 5: Table of typical software development tasks estimated over a program’s multi-year history.

Schedule Baseline as a Measure of Team Performance

An eighteen-month project which runs three months late will breach customer expectations, and possibly its funding window. When a large program which is tracking earned value reports that the Schedule Performance Index has fallen below 0.9, the managers usually must devise and explain a get-well plan to senior leadership. Finger pointers inevitably use the schedule baseline as a cudgel, beating home the message that deadlines and expectations have been missed.

But the schedule baseline’s acuity deflects the worst of the blame. The baseline doesn’t simply show that the major client delivery was six months late. It shows the requirements were reviewed three weeks late. It’s shows software development ran a month longer than planned. It shows logistics delays held up the vendor’s hardware delivery for two weeks. And it shows these variances during the project, not just at the very end. The baseline may not prevent a project from running late. But it will resolve doubt about whether the schedule is off course and can give alert project teams forewarning to mitigate or even rescue upcoming delays.

Next Steps

This article discussed what a schedule baseline is, and how it serves as a measuring stick for a single project and others like it. Baselining Principles will discuss when and why a schedule should be baselined or rebaselined, as well as why and how to achieve consensus for establishing the schedule baseline.