That’s one of my favorite topics. Maybe because I love solving puzzles, or maybe because there are a lot of graphs and cool tools you can use to make scheduling an interesting task. The fact is: developing the schedule of a project is more of a challenge (as well as developing the budget) than a repetitive, boring task, and if you like challenges then you are in the right place. So let’s not waste any more second of our precious time and let’s get right into it.

What Are the Components of the Schedule of a Project?

A schedule is not only about listing the order and the duration of tasks. There are several elements that you should include, and here are a few of them:

• It includes all the tasks and processes that will be executed during your project.
• It presents the tasks and processes in the correct order.
• It includes several external constraints that cannot be controlled by the group.
• It can be accomplished on time considering the personnel and the resources available for the execution of the tasks.
• It considers all the objectives of the project, such as team, customer and budget deliverables.

In order to successfully build a schedule for your project, you should implement the following procedures:

1. Define the activities involved in the project (we already talked in details about it in the Work Breakdown Structure article);
2. Sequence the activities in a logical order;
3. Estimate the necessary resources for the realization of each activity;
4. Estimate the duration necessary to successfully complete each activity;
5. Develop the final schedule considering all the information from above.

As we already discussed in details, the steps involved in the planning process are:

1. Create the definition of the project;
2. Develop a risk management strategy;
3. Build a Work Breakdown Structure;
4. Identify the relationships between the tasks;
5. Estimate the amount of labor and resources needed to execute the work packages;
6. Calculate the initial schedule;
7. Adjust the schedule to the project constraints.

This task of creating a realistic schedule focuses on steps 4 through 7, so let’s discuss them in more details.

Identifying the Relationship between Tasks

In order to understand your project resource needs, you must revisit your work breakdown structure. It might happen that you stopped at a level detailed enough to know that the work to complete the scope was included, but perhaps it is not yet possible to assign the work. If your work packages are specific enough so you can use them to determine what types of resources you need, that’s great. If not, now is the time to decompose them into activities. By activity, I mean a piece of work that is assignable to someone or to a department and can go into the schedule.

Which sequence should you follow when executing the work packages? Seems like an easy deduction if you consider obvious tasks, but it can easily become complicated when you are carrying multiple tasks at the same time and they depend on each other to be successfully implemented. This is what we call sequence constraints: some activities must be performed before others. For example: if you are updating the software of your company, the configuration of the new software happens after the deployment of the new software, and before you deploy you must assure that the backup of your current data is not corrupted and is fully functional in case of a problem while updating the software.

An efficient way to represent the required order of events is to use a predecessor diagram and a network diagram. In order to understand and better visualize the tables and diagrams, let’s imagine a general project with 6 tasks (task A, B, C, D, E and F – creative, no?). The predecessor table shows us how the tasks relate to each other. It’s design is quite intuitive, and it shows which tasks should be completed before starting other tasks. Let’s imagine the following predecessor table for our group of tasks:

This table is one of the most useful asset when understanding how your project should be executed. It is used as the starting point to build a network diagram, which shows the relationships between the tasks in a graphical way. In order to make sure your network diagram is correct, there are a few rules to observe:

Rule #1: Keep the details at a reasonable level

Build the network diagram at the work package level, and avoid using summary tasks or very detailed tasks or activities (the latter might be necessary in order to successfully complete a work package). The summary tasks are just groups of work packages, so it wouldn’t make sense to include them. The many activities within a work package can make the diagram considerably complex, so usually it is not a good idea to include them. Evidently, it is not forbidden to include them in your diagram, but here is some advice if you decide to do it: create separate diagrams. If you have many activities included in one work package, create a specific diagram for that work package and put a link to it in your main diagram. This helps you to avoid a messy diagram and still shows all the relationships you need to know. And it might be the case you want to create a diagram only for summary tasks (maybe your project is very big and the summary diagram will help). But again, keep it separate and insert a link to it in your main diagram.

Rule #2: Focus on sequence constraints

The relationship between the tasks in your diagram should show only sequence constraints, not resource constraint. What do I mean by that? If you look closely, tasks A and C, as well as tasks E and F, can be executed at the same time (if we think only about sequence constraints). Therefore, they should be presented parallel to each other in your diagram. It might be the case you don’t have the resources to execute both together, but this shouldn’t influence your diagram (at least not at this stage).

Great! So let’s have a look at how our diagram would look like (and an example of an incorrect distribution).

This is how a correct diagram should look like. As you can see, the tasks that can be executed simultaneously are listed above each other. This does not account for resource constraints. For example, if it is not possible to execute tasks B and D in parallel due to a staff shortage, this should not change the diagram.

Here is an example of an incorrect diagram. As you can see, tasks B and D are listed sequentially instead of in parallel.

Understanding Milestones and How They Can Make Your Diagram Clearer

Milestones are significant events that happen during the course of your project and that have an impact on it. Their duration is zero, so adding them doesn’t affect your schedule. An example of a milestone is the publication of financial reports. Imagine that you run an investment company and you have a project to create a new investment fund. Some of the tasks of your project cannot be executed before the publication of annual financial reports from the relevant companies. As you can see, although not being an activity or work package of your project, milestones present relevant and necessary information for your project to run smoothly.

Here are three reasons why you should include milestones in your planning and schedule:

1. They provide anchor points to your diagrams and make them easier to read.
2. They might represent external dependencies that may be prerequisites for the execution of several tasks of your project.
3. They might represent important events not shown in work packages. Think, for example, of bonus payments to your team if certain parts of the project are delivered within schedule.

Finish-To-Start, Start-To-Start and Finish-To-Finish Tasks

The names sound complicated, but the concepts are very simple. A finish-to-start relationship between two tasks means that one of them must be finished before the other can start. A start-to-start relationship allows both tasks to start at the same time, and a finish-to-finish relationship means that both tasks can start independently from each other but for one task to be completed, the other also needs to be finished. Here are some graphical examples to illustrate the concepts.

Finish-To-Start Relationship

Start-To-Start Relationship

Finish-To-Finish Relationship

Estimating the Amount of Labor and Resources Needed To Execute the Work Packages

In order to estimate and plan the entire project, we must create estimations of the individual work packages. Since we start at the bottom level of the hierarchy and we move up, this approach is known as the bottom-up estimating. Make sure to use a precise method to record the information you will generate, since there will be a lot of data to keep track of.

Estimating the duration of a task requires you to include all the time required from its initiation to its completion. For example, it might take only 30 minutes to request the CEO’s approval for one specific task, but if he takes an average of 5 days to issue the approval, you should consider estimating 6 days as a good figure for the duration of the task.

The estimations for the required project resources come from many sources:

#1 – Estimates of amount of labor

This estimates the amount of labor necessary to complete a task. If 5 people are required, each working 6 hours a day during 5 days, the total amount of labor for that task is 150 hours. In addition to recording the total amount of labor hours, you should consider the necessary skills for the tasks. If you need an IT specialist and an HR manager to complete the setup of a new HR software, include the labor requirements separately. Why? This will help you have a better idea of the composition of your team (and communicate the estimations for the functional managers of the staff, when it’s the case), as well as make it easier to implement different costs for each specialized worker (more on this soon, when we talk about budgeting).

#2 – Estimates of amount of equipment

Here you estimate the necessary tools to finish the work packages. Just as labor, try to list the required amount of hours for each equipment.

#3 – Estimates of amount of materials

This deals with the inputs your project needs. It is anything that your project needs – besides skills and your own equipment. This section can vary greatly from company to company (and from project to project). If you are building a new house, the materials needed will constitute a significant part of your budget; if you are developing a training course for the new software you implemented last month, there will be very little raw material needed.

#4 – Estimates of fixed-price offers

Fixed-price offers are bids made by external companies that are willing to provide the required work for a fixed fee. This is very common in government contracts, when companies provide a total price for the project and take care of the management of the resources (while the government just pays the agreed fee). If it is an advantage for your company to use such resources, include them in the plan of your project.

The amount of labor is directly related to the duration of tasks. If you change the number of workers and the daily amount of work, the total duration of your tasks will naturally vary. Consider the following task: you are running a project to renovate a historic building and you are estimating the necessary amount for painting the exterior of the construction. The two tables below compare the duration of the tasks when you use a different number of workers and different daily amounts of work. The building has an exterior surface of 960 square meters, and it takes 1 hour to paint 10 square meters.

In case 01, you will be employing 2 employees during 8 hours per day. Simple math tells you that you will need 6 days to complete this task. Table 01 puts all the data together.

In case 02, you decide to employ 4 workers working 12 hours each day. As a consequence, the duration of the task is reduced to just 2 days.

So if you are on a tight schedule, you can reduce the duration of your task by changing the amount of workers and of daily hours of work. Which one is more efficient? We will cover that in the near future when we deal with the details of budgeting, but here are a few things to consider: longer work hours means overtime payments and increase in costs; more workers means more costs to train and manage all of them, etc. There is a variety of extra costs that will come with whichever alternative you choose, so you should consider which choice brings the highest benefits at the lowest costs.

There are other concerns when choosing the amount of workers involved in a task. One of the most important ones is the productivity of members involved. Someone working part time on a task will probably not be as productive as someone working full time. If that is the case, varying the availability of workers can influence the final necessary amount of hours to complete the activity.

A constant productivity means that adding more workers to the task does not change the total amount of hours required to finish it. Our previous example has a constant productivity. If, on the other hand, adding more workers changes the total amount of hours, the productivity is not constant. This is usually the case in knowledge tasks. Imagine the case where you are designing the blueprint of a house. If you have two architects on the job and decide to add 3 more, it might be the case that the task will take even longer to be completed (because of different opinions, divergent interests, varying tastes, etc.). Evidently, the output might be better (less flaws and more efficiency), but the higher number of minds thinking will probably lead to more ideas, more work, more analysis and, ultimately, longer duration.

A second factor influencing the productivity of a worker is his/her dedication to the project. If people work across multiple projects, it is likely that their productivity will be lower. On the other hand, full dedication may lead to an increase in productivity.

By now, you probably noticed that the task of estimating resources can be considerably complex. We will cover it in details during the next article and I will provide several tools and tips that will help you create reliable estimates.

Calculating the Initial Schedule of Your Project

The calculation of the initial schedule of a project is one of the most important (and tedious) tasks in the planning of a project, so you might want to go for a project management software. Still, it is really important to understand the dynamics behind it and how you can do it without the aid of a software. So let’s start discussing how you can do it. For that, we need some terminology:

• Early start: stands for the earliest date you can start a task, considering the required schedule and the required previous tasks;
• Late start: stands for the latest date you can start a task without delaying the project and considering the required previous tasks;
• Early finish: stands for the earliest date you can finish a task, considering the required schedule and the required previous tasks;
• Late finish: stands for the latest date you can finish a task without delaying the project and considering the required previous tasks.
• Float: stands for the flexibility of a task in terms of its schedule. While some tasks cannot be delayed, others can be postponed for a certain period of time without affecting the final delivery date of the project. The float represents this time flexibility, and is obtained by subtracting the Early Start from the Late Start.

Once you have these dates and the relationships between tasks (already considered earlier in this article), building the schedule becomes a simple task. But how can you obtain the four estimates for the dates mentioned above? In order to do that, you can follow a three-steps procedure.

Step 1 – Forward Pass

This step determines the early start and finish dates of the tasks in your schedule. In order to do so, you need the following information:

• Relationship between tasks, preferably the predecessor diagram or the network diagram (we already did that);
• Duration of each task: we cover estimation in more details in the post about the dynamics of accurate estimation.

It is highly recommendable to build a simple table for each task according to the following example:

Once you have it, you can execute the following steps:

1. Set the beginning of your project as “day 01” and place the activities that have no predecessors there.
2. Add the estimated duration to your primary tasks and place the following activities right after the end of their predecessors (if there are two or more predecessors, you should consider the longest one as the finishing point). Keep doing so until all your tasks are placed in your schedule.

Simple, no? This gives you an idea of the earliest completion dates of your work packages and of your project.

Step 2 – Backward Pass

The backward pass works exactly the same as the forward pass, but it starts at the latest date your project can be completed. You will need the same information as before:

• Relationship between tasks, preferably the predecessor diagram or the network diagram (we already did that);
• Duration of each task: we cover estimation in more details in the post about the dynamics of accurate estimation.

With this information, you can already start building your schedule:

1. Start at the end of your project and place the final tasks at the latest possible date of completion.
2. In backwards logic, start by deducting the duration of the tasks to obtain the latest start date for that task. Keep doing so until you list all the tasks in your project. In the end, you will obtain a similar diagram to the one created by means of the forward pass method, but the finish date will be different.

Step 3 – Calculate the Float

The float (or slack) measures the flexibility of a task. As you can see in the two previous diagrams, some tasks have the same early start (ES) and late start (LS) dates, so they have no flexibility. Others, however, have some flexibility between the early start and the late start. Calculating the float is simply calculating this margins. The float is obtaining by subtracting the ES from the LS.

Let’s take our earlier example to determine the float of our tasks and to build a more detailed network diagram with all the information about early and late start, early and late finish, and float. Here is how the final diagram would look like, considering the previous relationships and duration of the tasks.

The Critical Path of Your Project

Critical path stands for the longest path through the network diagram of your project. It is the set of all activities that have zero or negative floats, and it’s main use is to identify the tasks that cannot be delayed without harming the schedule of the project. In other words, the critical path shows the minimum time required to complete a project. The best way to make sure the project is on time is to make sure that all the tasks on the critical path start and finish on time.

Evidently, not all projects have a critical path with zero floats everywhere. Sometimes it might be the case that you have to execute the project before an externally imposed date, so you might have some floats everywhere. The same happens when you have negative floats: the external date is just too close and it will not be possible to finish the project on time with the resources available (however, more resources can be included and a new estimation can be done to solve the issue).

The Gantt Chart and How It Can Improve the Quality of Your Schedule

Gantt Charts are an excellent tool for better visualizing the schedule of a project. While the Network Diagrams offer a good help in mapping its landscape, a project’s schedule can be better seen when represented through this tool.

In a Gantt Chart, the horizontal axis displays the schedule and the vertical axis displays the Work Breakdown Structure. It’s advantage is the potential to condense a lot of information into a confined space (by summarizing the data into a few lines). Each bar is distributed in the schedule in such a way that it represents the length and the sequential positioning of the task. We can build an example of a Gantt Chart based on our tasks and estimations from above.

Adjusting the Schedule to the Project’s Constraints – Assigning and Leveling Resources

Resource leveling aims at optimizing personnel and equipment usage during the execution of the project. By assuming that a continuous effort is more efficient than a fragmented one, it tries to reduce repetitions and unnecessary additions of tasks during the execution of the tasks. Resource leveling removes most of the superfluous overtime from the project and keeps the workers employed for a longer period at a steady rate.

The idea of resource leveling is to adjust the schedule so we avoid over and under-allocation of work. Since having many simultaneous tasks might require more work than available, we might have to alter the schedule as to match the needs of a project to the availability of resources.

The Process of Resource Leveling

When we talk about resources, we talk about the allocation of people’s and equipment’s work. We don’t consider raw materials because, well, they are acquired from external sources and are already determined in the specifications of the product or service being developed in the project. So here are the four basic steps for carrying a resource leveling:

1. Forecast how much resources of each type will be needed throughout the project. The best way to do so is to build a resource spreadsheet. The spreadsheet can then be correlated to the diagram of the schedule and you can better visualize how much of each resource is needed each day. However, it might be the case that using an early start schedule will cause over-allocation of resources, so we have to take a few more steps to make sure our resources are best allocated.
2. Identify the peaks of usage of resources. By using the resource spreadsheet and building a resource histogram, you can identify the periods when there will be more demand than supply of resources.
3. Delay non critical tasks within their floats. Remember our floats? They represent the amount of days a task can be extended or delayed (if started on time) without affecting the final schedule of the project. In order to solve the over-allocation problem during resource peaks, the best strategy is to extend or delay non critical tasks within their floats. In other words, you will be redistributing the tasks within your schedule and moving them from periods where there is too much work for periods where there is too little work.
4. Reevaluate the work package estimates to eliminate any further resource peaks. If, after leveling the resources, you still have resource peaks of over-allocation, you might want to revise the estimates of resources in your work packages. Maybe you can assign less workers for longer periods of time to a task and still obtain the same predicted outcome. These changes, however, will alter the time flexibility of the tasks being modified, so you should come back to recalculating your initial schedule and carrying a resource leveling once you’re done with redefining the estimates for the work packages.

Final Words

The task of estimating the schedule of a project is not a simple one. It requires you to forecast many variables and there is a high degree of uncertainty involved during the process. And despite all the effort, it is very common to underestimate the schedule and end up delaying all the project. All these drawbacks make people a bit skeptical about dedicating so much time to estimate the schedule of the project in detail. However, if you’ve already been in the position of managing a project, you know how important the schedule is. This part of the project plan is essential not only to determine the relationships between the tasks, but also to empower you with tools to distribute the work – through resource leveling – and to adjust the execution of tasks when necessary.

Together with the budget of a project, the schedule is one of the most important documents that you will create, so invest enough time to create a comprehensive and complete one!