After you have defined the scope of a project and created the scope baseline, you will likely start developing the project schedule. The approved schedule will become the schedule baseline of the project which the basis for the cost baseline and performance measurement.
In this article, we will guide you step-by-step through the process of creating a project schedule baseline.
Definition of Schedule Baseline
The schedule baseline is the approved schedule of a project. Its key components are:
- The schedule model which sets out the schedule of activities and their finish dates after considering assumptions, constraints, estimates and dependencies, and
- the documented approval of the schedule obtained in line with the project or organizational governance requirements.
A schedule baseline serves several purposes. Its main use is to provide the start and finish dates against which the project performance is being measured. You will find more details, as well as an example, in this article:
Creating a Schedule Baseline (Step-by-Step)
To create a schedule baseline, you will need to develop a schedule model first. This process involves defining the activities, determining their sequence and durations, as well as identifying constraints and making assumptions. By obtaining approval from relevant stakeholders, this schedule becomes the schedule baseline of the project.
In this guide, we are walking you through the process in 6 steps.
Prerequisites
Before you start developing the schedule, you will need:
- The scope baseline, and
- the work breakdown structure (WBS; it is typically part of that baseline).
The work breakdown structure defines work and planning packages, which represent the deliverables of a project. This structure is the basis for defining the activities.
1) Identify Activities and Dependencies
The lowest level of the work breakdown structure consists of work packages and planning packages.
For work packages, you will need to identify the activities that are required to create the deliverable. For instance, if it refers to a design or architecture document, you could use the sections and chapters of the document as deliverables.
‘Planning packages’ stand for deliverables that are in the scope of a project but lacking sufficient information for detailed planning. Thus, a breakdown into activities is challenging and comes with a high level of uncertainty. In some cases, it is even impossible to define activities. More detailed planning typically takes place when more information about the work and the activities become known. This approach is called progressive elaboration.
When you describe deliverables, it is a good practice to name activities with a verb + an object, e. g. “develop module 1” (of software) or “write section 1” (of a document). The verb can also be in a continuous (‘developing module 1’) or nominalized (‘development of module 1’) form if preferred.
Notice that although it is common to present the activities under work packages in a WBS, they are technically not a part of the WBS.
among activities, there are sometimes logical and technical dependencies that need to be taken into account. Here is a simple example: you cannot test the software before it has been developed, so these respective activities have a so-called Finish-to-Start relationship.
In total, there are 4 dependency types that we have discussed (incl. examples) in this article on the precedence diagramming method (PDM). This method is a useful technique to identify and visualize logical relationships and dependencies between activities. Another technique that you might want to consider is project schedule network diagraming (read more in this article).
2) Estimate Durations and Resource Needs
Once the activities are defined, you will need to estimate both their resource needs and their expected durations.
For estimating the expected durations of activities, the most common estimation techniques are:
- Expert Judgement,
- Analogous Estimating,
- Parametric Estimating,
- Three-Point-Estimating, and
- Bottom-Up Estimating.
If you are not familiar with these techniques, look at this comparison that also discusses the pros and cons of each technique.
As a rule of thumb, bottom-up estimates tend to be the most accurate types, followed by parametric and three-point estimating.
You can normally apply these estimation techniques to activities for which resources or sufficient data are available. For planning packages, not many details are known at the time of planning. You might therefore want to consider using expert judgment and analogous estimating to come up with an order of magnitude.
3) Create a Schedule Model
The schedule model consolidates all the data gathered in the previous steps. It eventually plans activities on a timeline (i. e. defining start and finish dates) while taking the sequence, duration estimates and other assumptions and constraints into account.
A typical starting point is to identify the critical path activities in a project. The critical path is the longest chain of sequenced activities and determines the duration of the whole project. On the other hand, delays of any critical path activity will inevitably lead to a delay of the project completion.
A typical way of presenting the schedule model is a Gantt chart, which in some cases even includes arrows to illustrate the dependencies between the activities.
If the number of activities and the complexity of their dependencies are manageable, you can create the schedule manually (e. g. on paper, a whiteboard, or in Excel, as in the screenshot below). For larger and more complex projects though, the use of a scheduling or project management software is recommended.
When scheduling activities, you should be aware of a few potential pitfalls and follow these tips:
- Take weekends, public holidays and leave days into account,
- make sure you start with critical path items first and schedule other activities in a second step, considering the interdependencies is with those activities,
- add in contingency reserves where possible – they will serve to absorb delays from materializing risks,
- consider leads and lags and plan such activities wisely, to optimize resource utilization and reduce risks for instance
- be aware of other, project-external constraints or assumptions, e. g. availability of products/services/resources needed from the organization or vendors, and
- Other constraints that are idiosyncratic to your project.
If you are using project management software, it will likely allow you to input all constraints and assumptions and consider them in the computation of the schedule model.
4) Seek Approval
Once the schedule model is completed, the developed project schedule requires the approval of the stakeholder. Follow the organizational or project-specific standards for obtaining this approval.
Some organizations might establish a steering committee for their projects while others have different committees or rely solely on the project sponsors’ decisions. Whatever approach your organization follows, make sure you adhere to the approval requirements of your project and document the approval properly.
The way of presenting the baseline also depends on the organization’s and the stakeholders’ requirements. In many projects, a visualization of the schedule (e. g. a Gantt chart) and a summary of assumptions and constraints is sufficient. However, some stakeholders might want to look deeper, e.g. by reviewing the dependencies of activities before approving the schedule.
5) Communicate the Schedule Baseline
Once the schedule baseline is approved, you will need to circulate and communicate it to the wider circle of stakeholders. Use techniques such as the RACI or stakeholder engagement assessment matrix to determine who needs to be informed. Many projects also have stakeholder engagement and communication plans that set out how this communication is done.
In addition, the members of the PMO as well as the project team members need to be aware of the schedule baseline. They will have to plan and prioritize their work accordingly.
6) Use and Maintain the Schedule Baseline
When the project execution has started, you will begin to use the schedule baseline to measure the project’s performance.
Performance measurement techniques that you can use include, but are not limited to:
- conducting performance reviews,
- performing earned value analysis (EVA),
- determine variances such as schedule variance or schedule performance index,
- assessing trends, e. g. through the to-complete-performance index, and
- simulating ‘what if’ scenarios.
While a baseline should not be changed carelessly, some reasons may require its update from time to time:
If your WBS contained planning packages, you will likely have to enhance the project schedule at a later point when more accurate estimates are available.
Besides, materializing risks, delays, or changes to the scope (change requests) often lead to a replanning of the project schedule.
Even if the schedule of a project has been planned as well as possible, such changes are common in projects, in particular in multi-year projects.
Most of the changes require the use of the control change process. in some cases, a re-approval of the baseline becomes necessary. For more background on changes to the schedule baseline, read subsections 3 and 4 of this article’s first section.
Conclusion
The schedule baseline is one of the three project baselines. It is used for measuring and monitoring the performance of a project. The schedule is built on the scope baseline. After it has been created, a project manager typically moves on to the third baseline, the cost baseline.
All three baselines are sometimes combined into a consolidated baseline that is referred to as the performance measurement baseline. You will find more about this as well as the approaches to measuring project performance in this article.