What is the longest path of tasks to be completed?

The critical path is the longest path through the network based on task duration. This measures the shortest amount of time in which the project can be completed. Tasks not on the critical path have slack, while tasks on the critical path have zero slack. Slack is the amount of time that a task can be delayed without impacting the project end date.

A project activity network looks like this:

Calculating the Critical Path

There are plenty of tools like Microsoft Project that can calculate the critical path for you. But even when using software, it’s helpful to know how it is calculate and understand what factors will affect it.

Calculating the critical path requires some assumptions and estimation. Some of the key assumptions include:

◆ All tasks are known: If you forget to add some tasks and add them later, the original critical path may change. Most project plans are missing tasks when they are initially built.

◆ All links are accurate: A complicated plan with hundreds of tasks is likely to have some incorrect task dependencies defined.

◆ All estimates are accurate: Inaccurate estimates can cause the original critical path to change.

◆ Other non-critical paths may have small amounts of slack: A complicated activity path can have multiple noncritical paths. A change in any one of these paths can cause the original critical path to change.

Given the amount of assumptions we rely on in our analysis, the only time you know the actual critical path is after project completion.

Despite these potential problems, the critical path method gives the project manager a good indication of where to focus attention. The most important application of CPM is to realize a late task on the critical path will cause the project end date to change.

The following shows an example of calculating the critical path.

Path

Length of Path

Longest?

1-3-4-6-10

9 days

No

1-2-5-7-10*

12 days

Yes*

1-8-9-10

11 days

No

Note that tasks 3, 4, or 6 can be up to 3 days late without changing the critical path. These tasks each have three days of slack.

Also note that the tasks on the 1-2-5-7-10 path are on the critical path and have zero days of slack. If any task on the critical path is late, the project end date will be later.

◆ What would happen if Task 2 consumed five days instead of three days?

◆ What would the length of the 1-2-5-7-10 path become?

◆In this case would the 1-2-5-7-10 path still be critical?

Further Reading

There are a couple of other related terms that can be useful in understanding more about the critical path. One of those is CPM, which is simply an acronym for the Critical Path Method. For a comprehensive guide on the Critical Path Method, we recommend ProjectManager.com’s article.

Another similar concept is Program Evaluation and Review Technique (PERT). PERT evaluates a probable outcome based on three scenarios: a best-case, expected-case, and worst-case scenario. The outcome in question may be the duration of a task, its start date, or its finish date.

Click here for a guide on identifying the critical path in Microsoft Project. For the most comprehensive look at how to manage projects using project management software, you can purchase our training guide on Microsoft Project.

Every literature on project management reminds us that the longest path of dependent tasks determines the total duration of the project. Every practicing manager believes that delaying work on the longest path damages the project timeline. So, logically speaking, project management should focus on ensuring minimal delays on the longest path. With this strong intuition, managers spend a lot of time in planning and execution to ensure focus on the longest path. In planning, efforts are made to move tasks away from the longest path into the feeder path to crash lead times, while in execution, faced with a choice, the priority is given to the needs of the longest path even at the cost of a few delays on the feeder path.

Analysis of delayed projects reveals a pattern, the delays of the projects are not just because of the delays in the original longest path. In fact, the longest path keeps shifting across many path sequences throughout execution creating chaos of shifting priorities. Even seemingly non-critical items with a lot of slack in the original path become critical adding to the frustration of managers. Small low lead time items, non-critical designs, and non-critical resources hold up projects quite too often.

It is time we looked at the limitation of the longest path theory and evaluate it critically for a Multi-Project environment– an environment where the same set of resources are involved in delivering tasks across various projects and even different legs of a single project. The resource dependency environment across projects and legs within a project can create  havoc of delays if one blindly follows the logic of “longest-path-first-no-matter-what”.

Let us try to understand the problem with an example of a simple network. We have a project of 3 tasks (A, B, and C) to be executed by 3 different skilled resources blue, green, and orange.

As we put the task durations, we are not happy with the total duration. A close examination of the dependencies, tells us that task B need not wait for the completion of task A to start and the remaining part of task A is actually required to be ready before the start of task C. This analysis provides a thrill to every manager as lead times come down in the planning stage. The new crashed network looks like as given below.

The above approach to network planning leads to the creation of complex networks with many feeding chains. At this stage, one is not bothered with this complexity because such detailed analysis helps in crashing lead times in the planning stage.

Now let us try to understand the scenario from a Multi-Project environment. The blue resource is not just working on the longest and feeding paths of a single project, but at any point in time, also has to execute similar tasks of other projects.

When the network model is changed, there are two gains, not only lead-time of single project is lower, the blue resource gets a window of opportunity – an opportunity to exercise choice. If the blue resource has no other project on its waiting list, it can actually go ahead and finish the remaining part of task A (task A”) knowing fully well that it may not be required in immediate future. But it is better to finish up the remaining part of task A of a project rather than standing idle and wasting capacity.

As shown in the diagram, if the blue resource uses the window of opportunity created in project 1 by working on task A of project 2, it is a good decision as the blue resource is working on a task which has an immediate requirement. But at the same time, as the above diagram shows, the window of opportunity for project 1 is substantially reduced. If the blue resource tries to focus on completing task A of a few more projects (project 3 and project 4 as shown in the diagram below), then project 1 will be compromised as the window of opportunity will be exposed and the feeding path will become critical for project 1.

This implies that there is a limit to the number of projects that should be opened by the blue resource. In this case, it might be just 2 projects. This is called as the work-in-progress limit rule. Blue resource should be allowed to have 2 projects as their Work-in-Progress (WIP) limit. Within the WIP, it should work on tasks of the longest paths of two projects and then return at the right time to finish the feeding path tasks of the two projects. Once a project goes out of the WIP, a new one should be allowed for processing by blue resource. This rule tells that the blue resource would be working on feeding tasks of projects (projects 1 and 2 in the above example) even when the longest path tasks of other projects are waiting (Project 3 and 4). This is to ensure the resource comes back in right time without causing a change in the longest path.

In a Multi-Project environment, without a WIP rule, if one keeps working on the longest path on many projects while keeping feeder paths aside, soon the feeder paths of many projects become critical requiring one to drop everything else thus creating a cascading loop of frequent expediting, shifting critical paths and delays in almost every project.

Many try to deal with the above problem by detailed scheduling of tasks. One assumes that the task schedules with exact start dates will resolve the conflicts of priority. However, the uncertainties in task durations in execution make this a fruitless exercise as the dates begin to clash within no time. Other priority rules like “always longest path first” creates a cascading effect of delays. The longest path first rule has to be superseded by the rule of WIP limits for every critical resource group supporting multiple projects.

What is the shortest time project can be completed?

What is the critical path of a project?