While
working on a variety of IT projects, I’ve seen several project charters and
risk registers. Over time, I’ve noticed that not all project managers have a
solid grasp of how to identify and mitigate project risk. So, here’s an
introduction to the subject.
These aren’t project risks
Perhaps
it seems an odd place to start, but the most common problem I see is that many risks
identified aren’t really risks. So, what
is not a project risk?
An issue is not a project risk. An issue is something that is already a problem for the project. E.g.
a risk item that states: Vendor is late
delivering components. Since the vendor is already late, or you already
know the delivery is going to be late, this is an issue, not a risk. A risk is
something that could happen, but hasn’t happened yet.
An outcome is not a project risk. E.g. a
risk item that states: The project might
not go live on time. This statement is an outcome of one or more events
that could happen, for which the outcome is that there could be an impact on
the project timeline. A risk is the thing that might cause the project to go late or cost more, etc.
Also,
a vaguely-defined concern isn’t a
risk. Risks aren’t really properly identified if they are not specific. E.g. a
risk item that states: Testing is a risk.
This statement is too vague, as it doesn’t say what specifically about testing
is a risk and why it is being identified.
These aren’t mitigation plans
In
addition to incorrectly identified risks, I often see vague mitigation plans.
E.g. Manage dependencies and milestones. E.g. Leverage vendor’s experience.
These mitigation plans are too vague to be actionable.
What are we worried about? What will we
do about it?
Every
book on project management has a risk definition along the lines of “Project
risk is an uncertain event or condition that, if it occurs, has a positive or
negative effect on one or more project objectives such as scope, schedule,
cost, and quality.” (PMBOK, Fifth Edition). Following that, there’s a
definition of risk mitigation, such as: “Risk mitigation is a risk response
strategy whereby the project team acts to reduce the probability of occurrence
or impact of a risk.” (PMBOK, Fifth Edition)
Although
accurate, these definitions can be simplified to aid understanding. The easiest
way to identify risks is to ask yourself and others: What exactly are we worried about and why are we worried about it?
Then,
once the worry and rationale are very clearly defined, the mitigation plan is
based on: What very specific actions are
we going to take regarding that worry?
An example
Do
you have reason to believe the vendor might deliver late – before it happens?
For example, maybe the vendor has recently made a lot more sales than usual and
you’ve had late deliveries when you’ve bought from other fast-growing vendors.
If so, you can record the risk very clearly: Vendor has gained significant
market share in the last three months. Based on our experience with other
vendors, this market gain can have an impact on manufacturing capacity, which
may result in late delivery.
If
you want to avoid this event, think about what options you have to avoid your
project being derailed by late delivery. For example, if the contract isn’t
signed yet, can you build in a penalty clause, or pay a premium for on-time?
Can you spend extra effort on vetting your requirements to ensure your own
project doesn’t cause any impact on the vendor? Do you have access to other
equipment you could use temporarily if the delivery is late? Does that strategy
lead you define an additional risk and mitigation plan? Ask others for ideas on
how they’ve managed this kind of risk before and how successful the strategy
was for them. Be specific in your mitigation plan: go beyond platitudes such as
good project management.
Do you have other worries?
Anything
that causes you a specific concern is a candidate to be included as a risk. Risks are as varied as the projects on which
they arise. Here are a few examples I’ve seen: (1) Servers are being moved from
a company-run to an external data centre during the same time period that our
project needs to test connectivity for several interfaces. Testing connections
to the old data centre will need to be repeated for the new data centre, with potential
for delay to our project’s timeline. (2) Although the on-site project manager
assigned by a major vendor has great leadership skills, he’s not particularly rigorous
about scheduling and tracking against the schedule. Since he is managing a
large team and a tight delivery timeline, we are concerned that we won’t have
adequate visibility to progress or lack thereof. (3) Previous upgrades to this
application have failed due to lack of understanding of the integration points.
Notice
that all of these risks are very specific, and they provide a rationale for why
the risk has been identified.
Schedule and follow up
Assign
a responsible person and due date for every mitigation action item. If you
aren’t able to assign a person and due date, the mitigation step probably isn’t
defined clearly enough. Track these mitigation steps to make sure that they
actually get accomplished.
Conclusion
Understanding
of IT project risks and mitigation plans can be improved by simplifying the
definitions to: (a) What you are worried about exactly and why; and (b) what
you will do about it.
