Summary: Focusing solely on the main critical path can lead to project delays, as other paths may slip unnoticed. Analyzing and managing multiple critical paths, especially the second and third ones, is crucial for achieving on-time project completion. Regularly monitoring and addressing potential issues in these paths can prevent delays and ensure timely project delivery.

The key to being on time is to not only watch the main critical path, but also the second and third paths behind the main critical path, because these are likely the ones that will slip if they lack focus and attention. All three paths have to be accelerated to finish on time. When teams get really good at this analysis, they can focus on more than the first three paths. The more paths you focus on, the better your chances are of finishing on time.

There is a tendency for teams to focus on the critical path at the exclusion of anything else on the project. A project has multiple paths to the end, the longest (critical path), and then a series of shorter paths to the end. Each path is separated by Float (the amount of time a task can slip before it affects its successor task or the project end date). A path can Float a number of days before it bumps into the next longer path and eventually the longest path to the end of the project. Effectively managing these paths is the key to FTTM results.

Let’s look at an example project (above) which ends with Firmware being released. The long path pulled in. We can see this because we have a baseline of the schedule 4 weeks prior. It is clear in the first task (Develop Contactors Control) which started earlier than planned and is projected to finish earlier as well. Prior to this update, we had been concerned because we could see the schedule trend was flat. We call this “flat-lining.” This should be investigated. Is the project really maintaining a consistent schedule, or are people not telling the truth or hiding a schedule slip?

Example of a flat-lining Wigglechart Trend

The next week, we could see the critical path had changed and in fact had accelerated (see Critical Path - CP1 above). We wanted to know why it had been flat and what was causing this? We were curious about what was happening behind that stable CP1. We knew that CP2 and CP3 were at least a month or more behind. However, if CP1 was pulling in and CP2-3 were slipping, then eventually CP2-3 would overtake CP1 as the longest path. Could we provide the team with an early warning? Could we take actions that would stop CP2-3 from slipping if in fact they were?

We peeled back one layer from CP1 to show CP2. CP2 is 20 days behind CP1; however, each week CP2 had been slipping. Leaving the 4-week-old baseline on, peeling back one layer, we could see that the first task “Initiate AFEs” had started late and was taking considerably longer than the original estimated duration. It grew from a few weeks to over a month. The co-CP2 task “Balancing” had also not started, which was a concern. We dug in to find out that the manager had deprioritized Balancing and shifted all of his resources over to AFEs, not knowing that this may cause Balancing to slip onto CP1. We also learned that AFEs were experiencing technical problems (bugs) that they had just been able to resolve. This meant that the “Initialize AFEs” and “Implement Meas” tasks would finish as scheduled.

As CP1 decreased in length, CP2 had been expanding. Everyone was happy to see the project pulling in, but had not paid attention to the paths behind that were actually slipping. The trick to FTTM is getting CP1-3 to all be shrink at the same rate. This means focusing on each of the first three (of more) CPs every Refresh Meeting.

We peeled back to the CP3. This was only one day behind CP2 and 21 days behind CP1. Again we found a problem, the “Test Bench” task. Although it started early, it too had grown to a much longer duration than originally estimated. There were technical problems there as well. Basically, CP2 and CP3 were the same and should be treated as the second critical path.

The team leader was able to alert the team of the pending problem. Resources were shifted, and a new near-term focus provided. The team was able to pull in both CP2 and CP3, while also continuing to hold CP1 steady. CP1 was being managed externally by a development partner who had dedicated resources to this part of the project; this is why we knew this was stable.

Had we not seen this in advance, it is likely that CP2 or CP3 would have slipped and pushed out the project. Once it slips, you have to recover time, which is much harder than avoiding slips before they happen.

In order to see the gap between CP2 and CP1, we used the Logic Peel. Focusing on the last milestone in CP2, we can see the 20-day gap between CP2 and CP1. This is the gap that has been closing over the past 4 weeks. Each week, as CP2 slips, it has eaten up this float time. The idea is to focus on CP2 to determine what it is slipping and how to get it going such that it no longer is slipping. In this instance, it was slipping because this string of tasks was put on low priority while the team focused on CP1 (partially a resource constraint problem). They also were having technical problems with the current tasks on the CP2 path. Once the problem was identified, the team moved resources to CP2 and solved the technical problem, enabling CP2 tasks to get back on schedule.

Critical Path Analysis (In the inspector)

The Critical Path Analysis report illustrates the problem using a different format. We can see that CP2 is in fact three equal paths, which means that any one of these three paths could catch up to CP1 if they slipped or CP1 would continue to be pulled in. The third task, a touchpoint from another team, slipped 6 days in the past week while CP3 slipped 8 days in the past week. At this rate, they will quickly push to the right and catch up with CP1. This is a great example of how projects slip if people are not paying attention to the paths behind the critical path. It is also a good example of how to make a project finish on time by paying attention to those paths just behind the main longest path on the project.

Again, the Wigglechart trend is what caused us to start digging into the schedule. A flatline trend is always a cause for concern. Is it really stable? Are people telling the truth? Is it hiding slips? Will it be on schedule until the end, then have a big slip? As it turned out on this project, the main critical path was stable, and that team had been holding to their schedule, but when we investigated what was happening on the second and third critical paths, we discovered a future pending problem. Since we found this early, we could change priorities of the team and focus on those paths which caused them to stop slipping.

Mechanics of how to do this using fastProject:

1. Run a critical path to the target milestone using the Inspector.

2. Open “Scroll through history” in the Inspector (Cause of Change dropdown).

3. Go back to the baseline one month ago.

4. Compare the current schedule to the 1-month-old baseline.

5. Peel back one using the Inspector.

6. Compare the second critical path to the 1-month-old baseline. Scroll through each week to see how the second critical path had changed. Was it slipping or pulling in?

7. Click on the last milestone in the second critical path and then Logic Peel in the Inspector. This illustrates the gap between the second and the first critical path.

8. Run the Critical Path Analysis report (Advanced) in the Inspector. Select the first three critical paths. Evaluate how much each path changed from the previous week.

Briefly, the analysis technique we used was to:
Run the critical path to a target —> Turn on the scroll through history —> Scroll back a month —> Peel back to CP2 (repeat)

lateralworks

lateralworks

Ideas

lateralworks

It’s the second or third critical path that can sneak up and bite you…

lateralworks

Ideas

Tools