Every literature on project management reminds us that the longest path of dependent tasks determines the total duration of the project. Every practising 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 limitations of the longest path theory and critically evaluated it for a multi-project environment. In an environment where the same set of resources are involved in delivering tasks across various projects and different legs of a single project, the resource dependency can create havoc with 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 with 3 tasks (A, B, and C) to be executed by 3 different skilled resources - blue, green, and orange.  <figure class="image"><img style="aspect-ratio:16668/4458;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//bf-blog-17-img-1-01-1738566503_1777283161.jpg" width="16668" height="4458"></figure>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 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 the image below.   <figure class="image"><img style="aspect-ratio:16668/7360;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//bf-blog-17-img-2-01-1738566513_1777282803.jpg" width="16668" height="7360"></figure>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 is the lead time of a single project lower, but the blue resource also gets a window of opportunity – an opportunity to exercise choice. If the blue resource has no other project on their waiting list, they can go ahead and finish the remaining part of task A (Task A”) knowing that it may not be required in the immediate future. But it is better to finish the remaining part of task A of a project rather than standing idle and wasting capacity.  <figure class="image"><img style="aspect-ratio:16668/15403;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//bf-blog-17-img-3-01-1738566526_1777283073.jpg" width="16668" height="15403"></figure>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  some 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. <figure class="image"><img style="aspect-ratio:16668/17624;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//bf-blog-17-img-4-01-1738566535_1777283009.jpg" width="16668" height="17624"></figure>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 the ‘work-in-progress limit’ rule. Blue resource should be allowed to have 2 projects as their Work-in-Progress (WIP) limit. Within WIP, they 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 WIP, the blue resource should then be allowed to process a new project.  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 (Projects 3 and 4). This is to ensure the resource comes back at the right time without causing a change in the longest path.  In a multi-project environment without a WIP rule, continually working on the longest path of many projects while neglecting feeder paths can soon make those feeder paths critical. This situation requires dropping everything else, 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 during execution make this a futile exercise as the dates begin to clash within no time. Other priority rules like “always longest path first” create a cascading effect of delays.  The ‘longest path first’ rule must be superseded by the implementation of WIP limits for each critical resource group supporting multiple projects.

BA Read More

Problem: In many multi-project environments, focusing solely on the longest sequence of dependent tasks (the 'critical path') in each project can cause feeder paths to become critical over time<o:p></o:p> <o:p></o:p>Solution: Identify and streamline the 'critical path'—remove unnecessary steps, reduce wait times, ensure capacity and resources are aligned for those critical tasks. Prioritise shortening that path to cut overall lead‑time. Allow resources to focus on the longest path tasks of a limited number of projects while returning to feeder paths at the right time. This balances priorities and prevents feeder paths from turning critical.<o:p></o:p> <o:p></o:p>Benefits: Faster delivery, lower cost from reduced work‑in‑progress and waiting, better customer satisfaction, and more predictable operations. Improvements here ripple across the whole system, boosting efficiency and agility.<o:p></o:p>

In multi-project environments, solely prioritizing the longest task path can cause unexpected delays due to resource conflicts. Implementing WIP limits for critical resource groups across projects helps prevent chaos and maintain control.

Focus on longest path ≠ Shortest possible lead time

Every literature on project management reminds us that the longest path of dependent tasks determines the total duration of the project. Every practising 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 limitations of the longest path theory and critically evaluated it for a multi-project environment. In an environment where the same set of resources are involved in delivering tasks across various projects and different legs of a single project, the resource dependency can create havoc with 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 with 3 tasks (A, B, and C) to be executed by 3 different skilled resources - blue, green, and orange.  <figure class="image"><img style="aspect-ratio:16668/4458;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//bf-blog-17-img-1-01-1738566503_1777283146.jpg" width="16668" height="4458"></figure>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 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 the image below.   <figure class="image"><img style="aspect-ratio:16668/7360;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//bf-blog-17-img-2-01-1738566513_1777282775.jpg" width="16668" height="7360"></figure>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 is the lead time of a single project lower, but the blue resource also gets a window of opportunity – an opportunity to exercise choice. If the blue resource has no other project on their waiting list, they can go ahead and finish the remaining part of task A (Task A”) knowing that it may not be required in the immediate future. But it is better to finish the remaining part of task A of a project rather than standing idle and wasting capacity.  <figure class="image"><img style="aspect-ratio:16668/15403;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//bf-blog-17-img-3-01-1738566526_1777283098.jpg" width="16668" height="15403"></figure>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  some 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. <figure class="image"><img style="aspect-ratio:16668/17624;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//bf-blog-17-img-4-01-1738566535_1777282987.jpg" width="16668" height="17624"></figure>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 the ‘work-in-progress limit’ rule. Blue resource should be allowed to have 2 projects as their Work-in-Progress (WIP) limit. Within WIP, they 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 WIP, the blue resource should then be allowed to process a new project.  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 (Projects 3 and 4). This is to ensure the resource comes back at the right time without causing a change in the longest path.  In a multi-project environment without a WIP rule, continually working on the longest path of many projects while neglecting feeder paths can soon make those feeder paths critical. This situation requires dropping everything else, 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 during execution make this a futile exercise as the dates begin to clash within no time. Other priority rules like “always longest path first” create a cascading effect of delays.  The ‘longest path first’ rule must be superseded by the implementation of WIP limits for each critical resource group supporting multiple projects.