Dealing with schedule planning by the Critical Path Method

A project usually involves a large amount of activities and tasks needed to be done. Even for the most experienced project managers it can be a bit of a challenge to control the huge amount of complexity in a project. By mastering the concept of planning a schedule a project can not only be more structured. Sufficiently planning can reduce the overall costs and limit the time duration of the project. The Critical Path Method is one of the tools a project manager can use to plan the project in the best possible way.

This article analyses the Critical Path Method. It takes a closer look at how to use the method and discus the advantages and limitations of the method.

The article starts by clarifying the idea behind the method and by an illustrating example the general application of the method is shown. The article then reflects on the use of the method. This is done by looking at the limitations of the Critical Path Method and comparing the method to other approaches of project scheduling. Furthermore, suggestions to improve the method are discussed.

The idea behind the method

A project has several tasks that needs to be done in order of the project to progress. The tasks can have dependencies on each other and some of the tasks needs to be completed before others can start. The tasks can also be dependent in a way that they should be done at the same time. The dependencies of the tasks can be divided into three main cases.

• Technical dependencies - Beams cannot be placed without any supports and the construction of the beams therefore depends on the construction of supporting columns.
• Organisational dependencies - Walls can be painted before the installation of the roof is completed, but the risk of damaging the painting by dust and other things by this schedule planning is high. It therefore might be a good idea to reverse the order of the two tasks.
• Spatial dependencies - The installation of electricity and water pipes does not have any technical dependencies, but they often require the same space. In other words, they have spatial dependencies and therefore needs to be completed parallel to each other.

For even small projects the amount of complexities of these dependencies can easily be high. To handle the dependencies a technique known as the Critical Path Method has been developed. The method was developed separately during the late 1950’s by the U.S. Navy and DuPont. The basic idea behind the method is to identify all the dependencies and interactions between the tasks and point out the essential tasks that drive the project timeline. By doing so, the planning can be optimized to know which tasks that can be delayed and which ones that will affect the whole time of the project if not completed on time. The minimum length of time to complete the project is identified as the length of the sequence of tasks defining the critical path. Delaying any of the tasks on the critical path by either starting or finishing a task later then planed the whole project will be delayed. If any tasks outside the critical path is delayed it would not affect the project unless the delays are so extreme that these tasks become the new critical path. To reduce the time duration the project manager then knows which sequence of task that should be focused on because more resources on tasks which are not on the critical path will not affect the overall duration of the project. It is important to realise than even though many projects have only one critical path, multiple critical paths can occur.

Application and guidance of the method

In the following section the application of the method will be described. This is done in a general manner but with use of an illustrating example. The essence of the application is to fill out a sequence of critical path descriptors, as seen in Table 1. Based on the sequence of task descriptors, the critical path can be identified.

Table 1: Critical path task descriptor

Step 1: Identifying the dependencies

To apply the method all the dependencies of the tasks needs to be identified. The network of dependencies can then be illustrated as seen in Figure 1. The duration estimates of the tasks will be explained later in this article, but for now the durations are shown with no comments. The durations are given in days, but the unit are in principle not important for the example.

Figure 1: Project network of dependencies

Step 2: Calculating the earliest start and finish

As soon as the dependency network is established, the earliest start and the earliest finish of every task in the project can be calculated. This is done by carrying out a forward pass computation. The earliest start of a task is given as the earliest finish of the previous tasks in the dependency network, because the following task cannot begin before the others has ended. The earliest finish is given as the sum between the earliest start date and the duration of the respective task. For the given example, the earliest start and finish of all the tasks are shown in Figure 2.

Figure 2: Project network of dependencies with forward pass computation

Step 3: Calculating the latest start and finish

Based on the computed dates of the earliest start and finish the latest start and finish can be calculated. This is done in a similar way as shown in Step 2, but this time by backward pass computation. The latest finish of the last task in a sequence is set equal to the earliest finish of the last task in the project. The latest start is then calculated as the difference between the latest finish and the duration of the task, as seen in Figure 3.

Figure 3: Project network of dependencies with backward pass computation

Step 4: Calculating the slacks of each task

The allowable slack in the tasks can then be calculated. The slack for each activity is given as either the difference between the earliest start and finish or the difference between the latest start and finish. The slacks in all the tasks in the example are shown in Figure 4.

Figure 4: Project network of dependencies with slack computation

Step 5: Identifying the Critical Path

The critical paths can then be identified as the sequence of tasks without any allowable slack. For the illustrating example the critical path is the sequence of task B and D, as shown in Figure 5. Since there are no slack in those tasks the earliest and latest finish of the tasks are equal. A delay in any of them will extend the total duration of the project. It is noted that the critical path not necessarily is the sequence with most tasks. The critical path is the path that takes the longest time to complete.

Figure 5: Project network of dependencies with the critical path identified

Estimating the time duration

One of the most important assumptions regarding the Critical Path Method is that the time durations for each task are known. When estimating the time durations there are generally two sources of knowledge.

• The time estimates can be based on measuring from previous projects with equal or similar tasks
• The time durations can be estimated by the people in charge of the respective tasks.

It is important to accept that the time estimates can be very uncertain. Unforeseen events such as the weather, material shortages or a flu epidemic can easily extend even the most reliable time estimates. In the estimations of the time durations it is therefore obvious to use probabilistic methods. Serval probabilistic approaches of time estimations exist. One of the most known approaches are PERT, which are developed by the U.S Navy. PERT operates with three time estimates and it is assumed that the distribution between the three estimates follows a beta distribution….. (More here)

Speeding up the time schedule

Everything in a project has costs. The direct cost are a result of labours, materials and equipment. The indirect costs are things like maintaining facilities and sometimes they are also a result of penalties there are incurred because a deadline has been missed. Time-Cost models deals with the case that it might be more cost-effective to invest in more resources in order to speed up a task rather than delaying the whole project. This section deals with a Time-Cost model called The Time-Cost Trade-Off. The section describes the basic idea and application of the method and gives a small example. The basic idea behind the method is that when additional resources is added it might be possible to reduce the time duration of a task. This is known as crashing the project. It is common sense that when additional resources are added the costs to the tasks are increased. The method distinguishes between the normal time and cost, which are the duration time and cost that was originally planned, and crash time and cost, which are the time durations and cost by reducing the time schedule. Based on these values the cost per day to expedite a task can be commuted. It can afterwards be evaluated whether the extra costs by crashing the project is economical beneficial for the project. Let’s assume the same task and dependency relations as given in Figure 5. The job is to reduce the time schedule by two days. The following Time-Cost data shown in Table 2 has been estimated by the project manager in coordination with the contractor.

Table 2: Time-Cost data

From the data in Table 2 the cost per day to expedite the project can be computed as shown in Table 3.

Table 3: Time-Cost calculation

As mentioned earlier in this article, the time duration of the project can only be affected by reducing task times at the critical path. These are task B and D for the shown example. The overall time must be reduced by two days. It is seen that it is cheapest to reduce task D by two days rather than reducing task B with two days. To reduce task D with two days, the overall costs of the project is increased by 2000 kr. The project plan is then given as shown in Figure 6.

Figure 6: Project network of dependencies with Time-Cost computation

It is noted that both the sequence of task A, C and E as well as the sequence of task B and D now defines the new critical path. It is further seen that the length of the project is reduced by two days to have a total duration of 38 days, as wanted.

Annotated Bibliography

Author (year). Title. ?th edition.

Description.