Today we are going to refresh an important schedule analysis tool, that is pretty known to the specialists in project management. We are in the area of the project "time management" and the tool is called "critical path method.
CRITICAL PATH METHOD. It was introduced around 1960 and further improved till today. Currently, CPM is implemented by default in the most common project management software.
What is the CPM?
In essence, it is a deterministic model that analyzes every possible sequence of a project network diagram and identifies the longest-duration path.
That duration - otherwise said the critical path - corresponds to the minimum time-frame for the project to be completed.
That duration - otherwise said the critical path - corresponds to the minimum time-frame for the project to be completed.
Why is worth to use CPM?
We can say therefore that it is definitely worth to understand how the method works and identify such path upfront to the execution.
Which are the prerequisites to apply CPM?
If we want to apply the critical path method, we need the following three steps to be done:
- The list of the project activities is defined (therefore a WBS is developed).
- Such activities are put in a logic sequence, after the analysis of the dependencies that link them each other.
- A project network diagram is drawn.
Before looking specifically at how the method works, let's focus on the bullets #2 and #3 (the WBS has been already treated HERE).
Like I said, the network diagram needs to put in sequence all the project activities that cover the WBS.
Like I said, the network diagram needs to put in sequence all the project activities that cover the WBS.
Which kind of dependencies could be set among the variuos activities? There may be mandatory logic relationships due to a contractual or a manufacturing constraint. There may be also discretionary dependencies, where a relationship is imposed by an arbitrary decision of the project members, for instance to have an advantage in terms of budget.
Whether they are mandatory or discretionary, the possible relationships we can expect to find are outlined as follow:
- Finish to Start. We refer to this kind of constraint when the activity B (successor) can't start until the activity A (predecessor) is completed. For example, think about an old man who can't start reading his book until he wears glasses. The "finish to start" is the most common relationship considered.
- Finish to finish. You have this kind of constraint if you can't finish the activity B until the activity A is completed also. For example, you can't finish to completely paint the fence of your garden until the surface is entirely prepared by your coworker. You can start and make a good progress, but you can't really finish B until also A is finished. The example might be a little bit tricky but I guess you caught the idea behind it.
- Start to start. In this case, the activity B can start only when also the activity B starts. Think to a soloist that can start only when his band starts to play the right backing track.
- Finish to start. This kind of relationship is very rare. To complete the activity B, the activity A must start.
OK, once defined the dependencies among the project activities, the network diagram structure may result in something like the below picture, where:
- Some example-tasks have been nominated with #A, #B, #C... etc.
- The activities are in the nodes and the dependencies are indicated by the arrows.
- The project start and the project finish blocks are shown as well.
- To be remarked, we do not know yet the duration expected for each of the activities. For the time being, the network diagram just tells us how they relate each other.
Good. Now that we have a clear picture about the dependencies and the network diagram, we can do a further step and estimate the duration of each package so that we can subsequently determine the most probable overall project duration.
The evaluation of the amount of work to be done to complete each activity is generally made based upon experience, or thanks to the knowledge of individuals and experts familiar with similar projects. The resulting data are manageable through the most common software programs available in the market.
The evaluation can be bottom-up or at high-level, depending on the confidence that the team members have.
Also, a correct evaluation of the tools and the machines to be used, as well as the human resources to be assigned, is instrumental to ensure a realistic and reliable quantification. To be noted that a certain degree of uncertainty is part of the process anyway, like for the costs estimation.
Let's assume that we determine the following:
At this stage you should have a clear understanding of the dependencies, the project network diagram, and you have estimated the tasks.
Let's add another key information: the starting date of the project.
With all those elements in hands, we can determine, for each package, the following 4 parameters (with a proper software it's quite easy) :
Let's have a look to the below picture:
In this example, we have an activity with a duration of 10 days, which may start at day 3 (earliest start), finishing at day 13 (earliest finish), in the best case. In the worst case (red font), it may start at day 6 to be completed, according to the estimated duration, at day 16.
The possible float the activity is allowed to move within is calculated as LF-EF. In this case we have a float of 3 days. Or, that is equivalent, as LS-ES=3 days again.
The same operation needs to be done for all the tasks.
In doing that, we can easily realize also which activity does not have any float because of its duration and the dependencies that it has with its predecessors and successors.
By calculating the earliest starts of all of the activities and by adding to that date its supposed duration through an iterative operation that, as said, can be implemented in any commercial software or in a calculation sheet, we obtain the minimum finish date of the project, namely the early finish of the last node (yellow block).
Let's redraw now the project diagram including the above information and highlighting the critical path in red. And we have done, look at the arrows!
The evaluation can be bottom-up or at high-level, depending on the confidence that the team members have.
Also, a correct evaluation of the tools and the machines to be used, as well as the human resources to be assigned, is instrumental to ensure a realistic and reliable quantification. To be noted that a certain degree of uncertainty is part of the process anyway, like for the costs estimation.
Let's assume that we determine the following:
- Task A: 10 days
- Task B: 40 days
- Task C: 10 days
- Task D: 10 days
- Task E: 5 days
- Task F: 10 days
- Task G: 5 days
- Task H: 10 days
- Task I: 5 days
At this stage you should have a clear understanding of the dependencies, the project network diagram, and you have estimated the tasks.
Let's add another key information: the starting date of the project.
With all those elements in hands, we can determine, for each package, the following 4 parameters (with a proper software it's quite easy) :
- ES (earliest possible start)
- EF (earliest possible finish)
- LS (latest possible start)
- LF (latest possible finish)
Let's have a look to the below picture:
The possible float the activity is allowed to move within is calculated as LF-EF. In this case we have a float of 3 days. Or, that is equivalent, as LS-ES=3 days again.
The same operation needs to be done for all the tasks.
In doing that, we can easily realize also which activity does not have any float because of its duration and the dependencies that it has with its predecessors and successors.
By calculating the earliest starts of all of the activities and by adding to that date its supposed duration through an iterative operation that, as said, can be implemented in any commercial software or in a calculation sheet, we obtain the minimum finish date of the project, namely the early finish of the last node (yellow block).
Let's redraw now the project diagram including the above information and highlighting the critical path in red. And we have done, look at the arrows!
Even if we do not indicate here the parameters of all the tasks, it is evident that the path in the upper path (A->B->F) does not have any chance to be extended without affecting immediately the entire duration of the project.
The activities inside that path can't move in relation to the others. They do not have any float (their ES is equal to their LS, or likewise, their EF is equal to their LF).
In contrast, if you look at the two tasks with a 5-days duration at the bottom of the network (tasks E and I), you can appreciate that they are completely in the shadow of the tasks D and H, and they have 10 days of float overall. In other words, they do not represent a risk for the project.
The critical path method enables to identify the activities with NO float, which are on the critical path of the project and it provides a numerical and objective quantification of its minimum lead-time. A delay of one day in one of those activities will translate into a one delay on the entire project, if not recovered and if all the relevant dependencies will be maintained.
In contrast, if you look at the two tasks with a 5-days duration at the bottom of the network (tasks E and I), you can appreciate that they are completely in the shadow of the tasks D and H, and they have 10 days of float overall. In other words, they do not represent a risk for the project.
The critical path method enables to identify the activities with NO float, which are on the critical path of the project and it provides a numerical and objective quantification of its minimum lead-time. A delay of one day in one of those activities will translate into a one delay on the entire project, if not recovered and if all the relevant dependencies will be maintained.
Once we have done with the CPM, the project schedule can be prepared in the preferred form. It may remain just a network diagram, it may be a milestone chart or a GANTT chart with bars showing kickoff, duration and finish date of every activities.
So, do you manage your critical path? :-)
So, do you manage your critical path? :-)
