How to Build a Project Schedule

8 July 2022

Home
Blog
Schedule Management
Project Schedule

In our previous article, we looked at what schedule management is and why it is important for project success. In this article, we will learn how to build a schedule.

We have seen that the schedule serves as a project roadmap; it tells us what needs to be done and when for the project to be carried out on time. To develop this roadmap, the scheduler will first have to question the project and its environment. After all, the right questions must be asked to understand all necessary details and constraints. Here we will walk you through this and the 5 key steps to build a good project schedule.

Getting Started with your Schedule

Before setting up a Gantt chart or mapping out your project tasks, it’s important to understand the context of the project. The scheduler must understand the main challenges and objectives of the project: its purpose and business case, the project plan and charter, etc.

They also must understand the history of the company to draw on previous lessons learned. This will provide context to the project and prevent repeating historical errors, all of which impact the project timeline and therefore the schedule.

After understanding the context of the project, the scheduler then must identify who will work on the project: key stakeholders, the project management team, vendors, etc. This is also where we become acquainted with the WBS (Work Breakdown Structure) that will shape the organization of the schedule.

With this information in hand, we can now embark on the scheduling phase of the project.

5 Steps to Build a Project Schedule

The baseline schedule is the main point of reference throughout the project to keep it on track. Here are five key steps to build your project baseline schedule.

1. Establish the sequence of tasks

Define your tasks: The first step in building a schedule is to take the WBS and refine it down to the appropriate level so that each deliverable is realized. These more manageable chunks of work become the project’s tasks.

Determine their order: Once we know all of the project tasks and milestones, we will need to set them up into a logical sequence or network. Consider, for example, the construction of a house. It seems logical not to put the roof on without the walls to support it. The same reasoning of logical task sequencing applies to projects.

Link your tasks: Once the tasks are defined and sequenced for each branch of the WBS, we must ensure that the relationships between branches are identified and taken into account. Some tasks cannot start until others are finished, and there are other types of relationships, as mentioned in our Introduction to Project Schedule Management article. This is how tasks in a sequence become linked and builds the foundation for our schedule.

2. Estimate task durations

The next step is to define each task’s duration. This estimate is based on a set of assumptions, such as the number of resources available and their skills. For example, laying a roof will take less time if five people work on it rather than just one, and an apprentice will likely work slower than an experienced roofer.

There are different methods to estimate this duration:

Expert Judgement
Group Decision Making
Analogous Estimation
Parametric Estimation
Three-Point Estimation

With a logical sequence of tasks as well as their relationships and durations defined, we can now create a first version of the schedule.

Read also our Schedule Development Case Study.

3. Incorporate project constraints

Using this first version of the schedule and the start date of the project, the scheduler can take this “ideal” version and consider the realities of life. That is to say, the scheduler will discuss with the project stakeholders to take into account constraints such as legislative or governmental constraints, holiday closures, or the availability of key resources.

4. Optimize the schedule

With this updated and more realistic version of the schedule, we can compare the scheduled end date with the expected end of the project. If the two coincide, the schedule is good. If this schedule leads us to finish earlier, we have a positive float (this situation is rather rare).

If the schedule leads us to finish after the expected project end date, however, we will have to compress the schedule. This could be done through resource optimization or fast-tracking, for example. However, these changes could increase cost or risk. The alternative option is to negotiate a new project delivery date.

Once the project stakeholders have agreed on the constraints and an updated version of the schedule, we are ready to set the baseline. This baseline will serve as a point of comparison throughout the project (or until a new baseline is set) between what has been approved and the actual progress of the project. This allows us to identify any delays and take any corrective actions needed.

5. Determine the critical path and manage float

Next, the scheduler must identify the critical path(s) of the project and the float. The critical path is the sequence of tasks for which any delay will impact the end date of the project. Therefore, it is very important to keep an eye on these tasks in particular. Float is the amount of delay that can be applied to a task without impacting the end of the project. Monitoring float and the critical path allows the planner to predict how project contingencies or delays would impact its objectives.

Before setting the schedule baseline, an analysis of the critical paths (primary and secondary) is carried out during an iterative process in order to reduce the risk on these critical paths and to free up the maximum possible float at strategic locations for the project. It is only after this exercise that a schedule baseline is fixed, which then serves as a standard reference for managing the project.

Schedule Monitoring and Reporting: The Best Tools to Use

As soon as we enter the execution phase of the project, the scheduler takes off their “planning hat” and puts on their “monitoring hat” to begin following the progress of work. After all, having spent so much time building this roadmap, it would be a shame not to monitor it and ensure we do not deviate from it.

Keep in mind that the schedule is a projection of what could happen and a roadmap built according to elements we know (tasks needing completion, cost of equivalent projects, etc.). Therefore, it is likely to evolve during the life of the project, as unexpected events occur.

For this, the scheduler can rely on various tools and software to make this easier. The best tools for this are Planisware, Sciforma, Primavera, and MS Project. These tools are dedicated to scheduling and make it possible to consolidate large schedule data, create visuals, and automate reports. They can also be linked to other information systems, such as Enterprise Resource Planning (ERP) and Enterprise Risk Management (ERM) software.

While these types of software are very useful and effective, they are also complex, often require training to use, and can be expensive. Therefore, they are not necessary for projects with simple schedules but are worth investing in for very large projects. For simple situations, a spreadsheet with colored cells could be enough.

Whether using complex software or not, the most important thing is that the scheduler can see where the project is, compare it to the baseline, anticipate the sequence of events, and warn the project team of any changes (availability of resources, business risks, etc.).

Read also our case study: Arriving on Schedule with Alstom.

When comparing the actual progress to the baseline, the scheduler not only relies on the tools mentioned above. They also use a wide range of indicators such as the following:

S-Curve: This is the most common indicator. It represents the physical progress of the project deliverables over time compared to the baseline that the project team committed to at the start of the project. It indicates the project’s performance, but a deeper analysis is needed to know if the recorded progress has been made in the right place, at the right time. This S-curve is easy to set up; however, it tends to lose effectiveness at the end of the project.
Burn Down Chart: Some schedulers prefer a Burn Down Chart. It reads similarly to an S-Curve but shows the work remaining for the project to reach completion.
Milestone Slip Chart: More complex, less common, but very effective is the Milestone Slip chart which focuses on the project milestones. Milestones are clearly identified in the schedule and represent a stepping point, major advancement, deadline, or point of delay to avoid in the project. Each curve on this chart represents a milestone and the evolution of its schedule over time. The 45° line is crossed when a milestone is reached. If a curve “rises” without ever crossing the diagonal, it’s because the associated milestone is continuously re-scheduled without ever being delivered. This is, therefore, an interesting point of discussion to ask the team and understand why.

There are many more indicators than these, some of which are automatically generated by the software mentioned above. Mastering these indicators is important because they objectively represent advancement on the project. Therefore, a scheduler must know how to interpret them because it is their responsibility to analyze the root cause of delays and to suggest the right corrective actions.

We will speak in more detail in our next article about the roles and responsibilities of a project scheduler.

Interested in becoming a Schedule Manager?

See our open positions

This article series was written by Sébastien DESLANDES, Jeremy LESCOP, and Christine ORIARD with contributions from the MIGSO-PCUBED Scheduling Community of Practice.