Risk and the Critical Path

Critical Path analysis has been done to death and the deeper the analysts delve, the more it seems that CP management is a black art requiring the skills of a mathematics PhD. The problem is that the critical path is important to managing the project and unfortunately, most critical paths are far more complex than the network models we’ve been shown in ourproject management training. Stop and think about it: how simple would you expect the critical path of a 400 task plan to be? Not very. There might be close to 100 activities on the path for such a project and I advise using only one MS Project file to manage up to 600 items. Fortunately, the critical path can be simplified and used to help the project manager mitigate risks without much of the mumbo jumbo associated with it. Using MS Project and some common sense, it’s really fairly simple.

Let’s look at the relationship between the Critical Path and project risk first. By definition any task on the Critical Path has zero slack time. That means that any slippage in the completion of that task will lead to a slippage in the overall project delivery date unless something is done to correct the slippage. That’s why it is important to focus more attention on the items on the Critical Path. Looked at another way, any tasks not on the Critical Path will have some slack so that late delivery will not necessarily impact the overall project delivery date. The impact of a risk event that would cause the completion date of a non-Critical Path task to slip cannot be known until the magnitude of the slippage is known. It might be minor if the slippage is less than the buffer for the task, or major if it exceeds the buffer.

We often look at risks from the point of view of their sources. First we identify the risk event and then examine it in light of the probability of the event happening and the impact it would have if it did happen. Let’s take as an example the risk of a flu epidemic preventing us from delivering a software application development project on schedule. It makes sense to look at the risk event this way because we would tend to mitigate the risk as a whole rather than breaking it down further. Our mitigation strategy might be to give flu shots to the entire team, or to have hand gel dispensers installed at strategic points in the office. These mitigation strategies do make sense – short of performing the entire project in a bubble there is not much more you can do to avoid some of the team catching the flu bug. But does it make sense to end our efforts there? Let’s delve a little further into the possible impact the flu might have on our project.

A flu bug that bites a programmer responsible for delivering a module that is not on the critical path may not be serious at all, providing the work has the 2 or 3 days slack built in that the programmer will need to recover. On the other hand, the same illness striking the programmer of a module on the Critical Path would put the project 2 or 3 days behind schedule. Now you can’t provide flu shots to programmers of modules on the Critical Path and leave the others unprotected. You probably can’t even ensure that everyone is willing to be vaccinated and you sure can’t trust to luck that only those working on the Critical Path will get vaccinated. What you can do is to identify a contingency plan to cover the work on the Critical Path. If programmers responsible for that work fall ill, have a backup identified who can take over that work so that the schedule doesn’t slip. The programmer might be someone working on a non-Critical Path module that will leave their work for 2 or 3 days to cover for the flu-stricken programmer. You might try pairing both programmers and making them responsible for the non-Critical Path and Critical Path work in tandem. Risk events that impact the schedule due to different causes may have to have slightly different strategies to address them but the concept is the same: sacrificing the schedule for non-Critical Path items to preserve the schedule for those on the Critical Path.

Now let’s look at how you identify the Critical Path. MS Project, the all-time leader in Project Management tools, is the project manager’s best friend when it comes to identifying the Critical Path for large, complex, projects. MS Project has a feature that will identify the Critical Path of any project it manages. This feature creates the network diagram for all paths in the project and identifies the Critical Path by coloring all the nodes in red. The only problem with the diagram produced by the Network Diagram feature is its complexity. This can be diminished somewhat by isolating the Critical Path from the other paths. You may want to simplify the result even more to help you focus on the tasks that matter. Try rolling the tasks up to their parents and viewing that Critical Path. Play with the tool and resultant diagrams until you get a diagram you can work from, and then concentrate on the risks to those tasks/deliverables/milestones.

You need to be very careful defining relationships between your tasks in your MS Project file. Every relationship you identify will affect the Network Diagram output from MS Project. Miss key relationships and the Critical Path will be incorrect. Misidentify relationships and you can also miss the actual Critical Path. Identify too many relationships and your Network Diagram becomes so complex that it will be incomprehensible and of no use to you. Taking care to identify the right relationships will produce a Diagram that can be used to identify the Critical Path.

Here’s another tip for managing risks to your Critical Path activities: assign your more experienced resources to those activities and your less experienced ones to non-Critical Path activities. We usually tend to de-risk the larger, more complex, pieces in our software development projects by assigning them to our more experienced resources. If this work happens to be on the Critical Path, so much the better. If it isn’t on the Critical Path give some thought to whether there is enough slack in the schedule to allow a less experienced resource to tackle the work while you move the more experienced work to something on the CP. Yet another approach to this problem is to re-organize the work so that the more difficult, complex work is on the CP. Senior programmers like to be challenged and simply assigning them to work on the CP may not be perceived as sufficiently challenging for some. That’s when you need to re-organize the work so that you can assign them to work they find challenging and still put them on the CP.

So what’s the "take away” from this discussion? Focusing your attention on the risks to the Critical Path will make more effective use of your Risk Management budget and ensure you deliver your project on time. MS Project can make an impossible task (constructing network diagrams by hand) into a simple one but the diagram it produces for you is only as accurate as the information you feed it, particularly information on the relationship between tasks. Taking care defining tasks and their relationships will allow you to identify the CP and focus on the risks to the tasks on it.

The tips and tricks described in this article implement some of the best practices promoted by the PMI^®(Project Management Institute). These are taught in most PMP^®courses and other PMP^® exam preparation training products. If you haven't been certified as a PMP^® (Project Management Professional) by the PMI^® and would like to learn more about certification, visit the three O Project Solutions website at: http://threeo.ca/pmpcertifications29.php. three O Project Solutions also offers a downloadable software based training tool that has prepared project managers around the world to pass their certification exams. For more information about this product, AceIt^©, visit the three O website at: http://threeo.ca/aceit-features-c1288.php