Once you have defined the scope of the project and created the baseline of the scope, you will most likely begin to develop the project schedule. The approved schedule will become the basic schedule of the project which is the basis for the cost base and performance measurement.
In this article we will guide you step by step in the process of creating the baseline of the project schedule.
Define a schedule baseline
The baseline of the schedule is the approved schedule of a project. Its key components are:
- The schedule model that defines the schedule of activities and their end dates after examining assumptions, constraints, estimates and dependencies, and
- The documented approval of the schedule obtained in accordance with the requirements of the project or the organizational administration.
A schedule baseline serves a number of purposes. Its main use is to provide the start and end dates by which project performance is measured. You can find more details, as well as an example, in this article:
Creating a Baseline Timeline (Step by Step)
To create a timeline baseline, you will first need to develop a schedule model. This process includes defining the activities, determining their sequence and duration, as well as identifying constraints and making assumptions. By getting approval from relevant stakeholders, this schedule becomes the baseline of the project schedule.
In this tutorial, we will guide you through the process in 6 steps.
Prerequisites
Before you start developing the schedule, you will need:
- The baseline of the scope, and
- Work breakdown structure (WBS; it is usually part of this baseline).
The job breakdown structure defines work and planning packages, which represent the products of a project. This structure is the basis for defining the activities.
1) Identification of activities and dependence
The lowest level of the work dismantling structure consists of work packages and planning packages.
For work packages, you will need to identify the activities required to create the product. For example, if it refers to a design document or architecture, you can use sections and chapters of the document as products.
‘Planning packages’ represent products that are within the scope of a project but lack sufficient information for detailed planning. Thus, division 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 usually occurs when more information about the work and activities is known. This approach is called progressive processing.
When describing products, it is a good practice to name activities with a verb + object, such as “develop module 1” (of software) or “write section 1” (of a document). The verb can be either continuously (‘Module 1 Development’) or nominally (‘Module 1 Development’) if preferred.
Note that although it is common to present the activities under work packages in WBS, they are technically not part of the WBS.
Between activities, there is sometimes a logical and technical dependence that needs to be taken into account. Here’s a simple example: You can not test the software before it is developed, so these activities respectively have a connection called Finish-to-Start.
In total, there are 4 types of dependencies discussed (including examples) in this article on the Forward Charting (PDM) method. This method is a useful technique to identify and illustrate logical connections and dependencies between activities. Another technique you may want to consider is project diagrams of network schedules (read more in this article).
2) Assessment of time durations and resource needs
Once the activities have been defined, you will need to assess both their resource needs and the expected duration.
To estimate the expected duration of activity, the most common estimation techniques are:
If you are unfamiliar 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 a parametric estimate and three points.
You can usually apply these estimation techniques to activities for which there are resources or sufficient data available. Regarding package planning, not many details are known at the time of planning. It may therefore be worth considering using expert judgment and analogous assessment to reach an order of magnitude.
3) Create a schedule model
The schedule model combines all the data collected in the previous steps. He ultimately plans activities on a timeline (i.e. setting start and end dates) taking into account sequence, duration estimates and assumptions and other constraints.
A typical starting point is to identify the critical path activities in the project. The critical path is the longest chain of activities in a row and determines the duration of the entire project. On the other hand, delays in any critical lane activity will inevitably lead to a delay in project completion.
A typical way to present the model of the schedule is a Gantt chart, which in some cases even includes arrows to illustrate the dependence between the activities.
If the number of activities and their complexity dependence are manageable, the schedule can be created manually (e.g. on paper, board or in Excel, as in the screenshot below). However, for larger and more complex projects, it is recommended to use project scheduling or management software.
When scheduling activities, you need to be aware of some potential pitfalls and follow these tips:
- Take into account weekends, holidays and vacations,
- Make sure you start with critical path items first and schedule other activities in the second step, given that the interdependence is on these activities,
- Add drawer reserves if possible – they will be used to absorb delays from the realization of risks,
- Consider leads and arrears and plan such activities wisely, to optimize resource utilization and reduce risks, e.g.
- Be aware of other external limitations or discounts for the project, such as the availability of products / services / resources required by the organization or vendors, and
- Other constraints that are unique to your project.
If you use project management software, it will most likely allow you to enter all the constraints and assumptions and consider them in calculating the schedule model.
4) Request approval
Once the schedule model is completed, the schedule of the developed project requires the approval of the stakeholder. Follow project or project-specific standards to obtain this approval.
Some organizations may set up a steering committee for their projects while others have different committees or rely solely on the decisions of the project’s sponsors. No matter what approach your organization takes, make sure you meet your project approval requirements and document the approval properly.
The way the base is presented also depends on the requirements of the organization and the stakeholders. In many projects, simulation of the schedule (e.g., a Gantt chart) and a summary of assumptions and constraints are sufficient. However, some stakeholders may want to look in depth, for example by reviewing the dependency of activities before approving the schedule.
5) Report the baseline of the schedule
Once the timeline of the schedule is approved, you will need to disseminate and communicate it to the wider circle of stakeholders. Use techniques such as RACI or a stakeholder engagement assessment matrix to determine who should receive information. Many projects also have stakeholder involvement and communication programs detailing how this communication is done.
In addition, PMO members as well as project team members should be aware of the baseline of the schedule. They will need to plan and prioritize their work accordingly.
6) Use and maintain the baseline of the schedule
Once the project is started, you will start using the timeline of the schedule to measure project performance.
Performance measurement techniques that you can use include, but are not limited to:
While the baseline should not be changed negligently, a few reasons may require its updating from time to time:
If your WBS contained design packages, you will likely need to improve your project schedule at a later stage when more accurate estimates are available.
Besides, material risks, delays or changes in scope (change requests) often lead to a re-planning of the project schedule.
Even if a project schedule is planned as well as possible, such changes are common in projects, especially in multi-year projects.
Most changes require the use of the control change process. In some cases, re-approval of the baseline is required. For more background on schedule baseline changes, read subsections 3 and 4 in the first section of this article.
Summary
The baseline of the schedule is one of the three baselines of the project. It is used to measure and monitor project performance. The schedule is built on the baseline of the scope. Once created, a project manager usually moves to the third baseline, the cost baseline.
All three baselines are sometimes combined into a unified baseline known as the baseline for measuring performance. You will find more about this as well as the approaches to measuring project performance in this article.
