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.
