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.
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