Project managers typically use Gantt-charts, milestones and start/finish dates to measure and report the progress of a project. These are common examples of tools and techniques that help visualize the project schedule and allow for transparent schedule communication and controlling.
The schedule baseline is the stakeholder-approved foundation of the schedule of a project. It is one of the 3 baselines in project management. In combination, they form the basis for project work and performance measurement.
What Is a Project Schedule Baseline?
The schedule baseline is the planned schedule of the project after its approval by the relevant stakeholders. In project management, it is typically the output of the schedule development process and becomes a component of the project management plan (source: PMBOK®, 6th ed., ch. 6.5.3). Within this plan, it is one of the 3 project baselines, besides the scope baseline and the cost baseline. Together with the 2 other baselines, it is a constituent of the performance measurement baseline.
The schedule baseline is used to measure and monitor the performance of a project: the delivered work at a point in time or over a period of time is compared against the baselined planned work at that time.
In addition to a baseline, a project should develop a schedule management plan. This plan sets out inter alia how the project will compare the actual performance against the baseline. This will include, for instance, the necessary indicators, the frequency, limits and thresholds for management action or escalations, etc.
What Are the Components of the Schedule Baseline?
A schedule baseline comprises of (at least)
- the documented planned project schedule (sometimes referred to as a schedule model), and
- the approval by the relevant stakeholders.
The detailed components of the schedule baseline may vary among projects. However, the essential information reflected in the baseline is usually:
- sequence of project activities,
- dependencies between activities, including leads and lags,
- activity durations,
- planned/baselined start and finish dates of activities,
- underlying assumptions and constraints,
- resource requirements, and
- other elements necessary for the schedule planning of the project.
Project managers typically use a scheduling or project management software to develop this so-called schedule model. This schedule model is often presented as a diagram (e.g. a Gantt chart) accompanied by a documentation of additional details, such as resource requirements and assumptions.
Once the schedule model is approved by the relevant stakeholders, it becomes the schedule baseline of the project.
Which Reserves Are to Be Included in the Schedule Baseline?
The schedule baseline should include contingency reserves but exclude management reserves.
The difference between both types of reserves is:
- The contingency reserve is estimated and included for the potential impact of known risks on the planned schedule.
- The management reserve, on the other hand, is created to manage and mitigate ambiguity. It allows the management to react to unpredictable risks or events without failing to deliver the scope of the project.
If these reserves are not sufficient to react to materializing risks, the project schedule needs to be re-planned and re-baselined.
Can a Project Schedule Baseline Be Changed?
The schedule baseline can be changed in line with the organization’s or the project’s change control process if the schedule model or its underlying assumptions become obsolete.
However, the reference to the change control process is key here. The schedule baseline is a key element of the project management plan and had been approved by the relevant stakeholders in the first place. Therefore, changes to the baseline require the respective approvals to become effective.
In many projects, however, not every minor change requires a change of the whole baseline (depending on the criteria set out in the change control process). For instance, schedule forecasting is a technique that uses data of observed work performance to project future performance in relation to the schedule baseline. Depending on the individual requirements for a project, this allows to track and monitor minor delays without changing the entire baseline.
When Should a Schedule Baseline Be Changed?
There are three main reasons for changes that can affect the schedule baseline:
- More detailed planning requires adjustments of the previously scheduled activities,
- the planned schedule becomes obsolete due to materializing risks (i. e. issues) or opportunities, and
- changes to other project requirements and constraints.
Like many other project management components, a schedule baseline is often created under the principle of progressive elaboration. The schedule should be planned end-to-end. Near-term activities are planned in detail while later activities are included based on rough estimates. When more schedule-relevant information is available, their timeline should be planned in more detail (source). Examples are planning packages in the WBS which are later turned into work packages for which sequence and durations can be reasonably estimated.
Another source of change is the materialization of risks and opportunities with an impact on the schedule. Opportunities can imply that activity durations are actually shorter than planned, for instance. This can either create reserves for other activities or be reflected in a replanned schedule. On the other end, materializing risks and unforeseen events can lead to activities not meeting their planned finish dates. Impact on other dependent activities across different levels can then blow up to a severe timeline impact. This can exceed planned contingency reserves and require a re-baselining.
Lastly, changes to the scope baseline or the resource plan will also need to be reflected in the schedule baseline. Their changes might add additional activities and affect the duration of already planned activities, respectively.
What Is the Purpose of a Schedule Baseline?
A schedule baseline is an approved documentation of the project schedule. It typically aggregates the schedule-relevant information from the above-mentioned items into a single timeline for the entire project. This is useful for different purposes which include (but are not limited to):
- documentation of the approved project schedule model,
- facilitating the communication of milestone dates (e. g. planned project completion date),
- monitoring and controlling the schedule (performance measurement),
- being a basis for cost estimates and cost baseline, and
- being a basis to assess changes and risks/issues.
The following subsections elaborate on some of these purposes in more detail.
Documentation of an Approved Project Schedule
An approved baseline ensures that all relevant stakeholders have the same understanding of the activities, their sequence and duration estimates, constraints and assumptions and subsequently the whole timeline of a project. The approved baseline documents that everyone is on the same page which prevents disagreement and negotiations of deadlines down the road.
It also provides clarity on which activities (e. g. work packages) have been planned in detail and which are only a placeholder and subject to progressive elaboration (e. g. planning packages).
In projects that use project management software to track progress and performance, baselining is often the prerequisite to allow monitoring and tracking of the performed work (e.g. in MS Project).
Communication of Milestone Dates
Team members in a project need clarity on their activities, their constraints and their planned start and finish dates. The schedule baseline helps provide this information. This allows work package owners to manage their work accordingly.
It also provides information on the sequence, interdependencies and assumptions surrounding the set of activities. This transparency helps with the planning of the operational work and helps identify risks and potential roadblocks on the way.
Schedule Controlling and Performance Measurement
The most obvious purpose of a baseline is to provide the basis against which the project performance is measured.
The schedule baseline is therefore used for a number of different monitoring and controlling analyses. These include but are not limited to:
- performance reviews (e. g. comparing actual with planned start and finish dates and degree of completion),
- earned value analysis and management (EVA, EVM),
- variance analysis (with indicators such as schedule variance),
- trend analysis (e. g. to-complete-performance index/TCPI), and
- ‘what if’ scenarios (for risks).
These monitoring activities may uncover deviations between the actual and the planned schedule. This may even create a need for changing the baseline. Such changes are then to be addressed in the change control process, as described in the previous section.
Example
To illustrate the components of a schedule baseline, we are picking up the case study of an IT project from our articles on project schedule network diagrams, precedence diagramming method and leads and lags. The example and its data are consistent across all these articles on scheduling.
If you want to learn how to create a schedule baseline, read this guide with 6 illustrated steps.
This figure illustrates the project phases designing, developing, implementing, testing and deployment with their underlying activities.
Between these activities, there are several dependencies. These dependencies are summarized in the schedule network diagram below. For instance, the deployment of the completed solution can only take place when the testing is finished (Finish-to-Start), and the development of feature F can only be completed if the development of module B (Start-to-Finish).
You will find a detailed explanation of the dependencies of these activities in the example section of this article. It also contains a detailed definition and charts of all dependency types (FS, FF, SF, SS).
Based on these working results from scheduling techniques, the following information on the project schedule is available:
- the sequence of project activities,
- dependencies between activities, including leads and lags, and
- activity durations.
To complete the schedule model, which is the basis of the schedule baseline, the following items are still needed:
- planned/baselined start and finish dates of activities,
- underlying assumptions and constraints,
- resource requirements, and
- other elements necessary for the schedule planning of the project.
For this example, the start date is set as 1 January.
For illustration purposes, we are using a few simplified assumptions/constraints: It is assumed that
- sufficient resources are assigned,
- they are available all the time and
- they will be working on workdays, weekends, as well as public holidays.
- Scheduling constraints are limited to the dependencies among the activities, with no further external dependencies or constraints that would need to be considered.
All this information is fed into a schedule model which is illustrated in this Gantt chart (probably the most common format for presenting a project schedule model):
The relevant stakeholders’ approval turns this schedule model (including its set of activities, estimated durations, dependencies, assumptions/constraints, etc.) into the project schedule baseline.
Note that this is example is simplified to illustrate the elements of a schedule baseline in an understandable way. In practice, project schedules are typically developed in a project scheduling software, e.g. MS Project, which helps manage the more complex schedule models and constraints of real-life projects.
Conclusion
The project schedule baseline is one of the most important and fundamental documents of a project. It transforms a complex schedule model into a communicable and measurable timeline for all project activities, which is the basis against which progress and performance are measured. Creating a schedule baseline can be a complex task for a project manager and requires the use of several scheduling tools and techniques.
The schedule baseline is one of the three project management baselines, besides the scope and the cost baseline. Together, they form the performance measurement baseline.
For more details about these baselines, read our dedicated article on the performance measurement and scope baselines.