10 Golden Rules of Project Risk Management
10 Golden Rules of Project Risk Management
10 Golden Rules of Project Risk Management
The benefits of risk management in projects are huge. You can gain a lot of money if you deal
with uncertain project events in a proactive manner. The result will be that you minimise the
impact of project threats and seize the opportunities that occur. This allows you to deliver your
project on time, on budget and with the quality results your project sponsor demands. Also your
team members will be much happier if they do not enter a "fire fighting" mode needed to repair
the failures that could have been prevented.
This article gives you the 10 golden rules to apply risk management successfully in your project.
They are based on personal experiences of the author who has been involved in projects for over
15 years. Also the big pile of literature available on the subject has been condensed in this
article.
Are you able to identify all project risks before they occur? Probably not. However if you
combine a number of different identification methods, you are likely to find the large majority. If
you deal with them properly, you have enough time left for the unexpected risks that take place.
A good approach is to consistently include risk communication in the tasks you carry out. If you
have a team meeting, make project risks part of the default agenda (and not the final item on the
list!). This shows risks are important to the project manager and gives team members a "natural
moment" to discuss them and report new ones.
Another important line of communication is that of the project manager and project sponsor or
principal. Focus your communication efforts on the big risks here and make sure you don't
surprise the boss or the customer! Also take care that the sponsor makes decisions on the top
risks, because usually some of them exceed the mandate of the project manager.
Unfortunately, lots of project teams struggle to cross the finish line, being overloaded with work
that needs to be done quickly. This creates project dynamics where only negative risks matter (if
the team considers any risks at all). Make sure you create some time to deal with the
opportunities in your project, even if it is only half an hour. Chances are that you see a couple of
opportunities with a high pay-off that don't require a big investment in time or resources.
Ownership also exists on another level. If a project threat occurs, someone has to pay the bill.
This sounds logical, but it is an issue you have to address before a risk occurs. Especially if
different business units, departments and suppliers are involved in your project, it becomes
important who bears the consequences and has to empty his wallet. An important side effect of
clarifying the ownership of risk effects, is that line managers start to pay attention to a project,
especially when a lot of money is at stake. The ownership issue is equally important with project
opportunities. Fights over (unexpected) revenues can become a long-term pastime of
management.
Risk analysis occurs at different levels. If you want to understand a risk at an individual level it
is most fruitful to think about the effects that it has and the causes that can make it happen.
Looking at the effects, you can describe what effects take place immediately after a risk occurs
and what effects happen as a result of the primary effects or because time elapses. A more
detailed analysis may show the order of magnitude effect in a certain effect category like costs,
lead time or product quality. Another angle to look at risks, is to focus on the events that precede
a risk occurrence, the risk causes. List the different causes and the circumstances that decrease or
increase the likelihood.
Another level of risk analysis is investigate the entire project. Each project manager needs to
answer the usual questions about the total budget needed or the date the project will finish. If you
take risks into account, you can do a simulation to show your project sponsor how likely it is that
you finish on a given date or within a certain time frame. A similar exercise can be done for
project costs.
The information you gather in a risk analysis will provide valuable insights in your project and
the necessary input to find effective responses to optimize the risks.
If you deal with threats you basically have three options, risk avoidance, risk minimisation and
risk acceptance. Avoiding risks means you organise your project in such a way that you don't
encounter a risk anymore. This could mean changing supplier or adopting a different technology
or, if you deal with a fatal risk, terminating a project. Spending more money on a doomed project
is a bad investment.
The biggest category of responses are the ones to minimise risks. You can try to prevent a risk
occurring by influencing the causes or decreasing the negative effects that could result. If you
have carried out rule 7 properly (risk analysis) you will have plenty of opportunities to influence
it. A final response is to accept a risk. This is a good choice if the effects on the project are
minimal or the possibilities to influence it prove to be very difficult, time consuming or relatively
expensive. Just make sure that it is a conscious choice to accept a certain risk.
Responses for risk opportunities are the reverse of the ones for threats. They will focus on
seeking risks, maximising them or ignoring them (if opportunities prove to be too small).
A good risk log contains risks descriptions, clarifies ownership issues (rule 5) and enables you to
carry our some basic analyses with regard to causes and effects (rule 7). Most project managers
aren't really fond of administrative tasks, but doing your bookkeeping with regards to risks pays
off, especially if the number of risks is large. Some project managers don't want to record risks,
because they feel this makes it easier to blame them in case things go wrong. However the
reverse is true. If you record project risks and the effective responses you have implemented, you
create a track record that no one can deny. Even if a risk happens that derails the project. Doing
projects is taking risks.
Rule 10: Track Risks and Associated Tasks
The risk register you have created as a result of rule 9, will help you to track risks and their
associated tasks. Tracking tasks is a day-to-day job for each project manager. Integrating risk
tasks into that daily routine is the easiest solution. Risk tasks may be carried out to identify or
analyse risks or to generate, select and implement responses.
Tracking risks differs from tracking tasks. It focuses on the current situation of risks. Which risks
are more likely to happen? Has the relative importance of risks changed? Answering this
questions will help to pay attention to the risks that matter most for your project value.
The 10 golden risk rules above give you guidelines on how to implement risk management
successfully in your project. However, keep in mind that you can always improve. Therefore rule
number 11 would be to use the Japanese Kaizen approach: measure the effects of your risk
management efforts and continuously implement improvements to make it even better.
Take the example I came across recently where we identified a project finishing ahead of
schedule as a risk. It might seem to be a bonus but the completion date happened to occur at the
busiest time of the year for the company. The last thing they needed was a project going live in
their peak period. The mitigation was that if we were ahead of schedule, we would slow the
project down by reducing resources.
Risk Identification
Risks Quantification
Risk Response
Risk Monitoring and Control
Risk Identification
In this stage, we identify and name the risks. The best approach is a workshop with business and
IT people to carry out the identification. Use a combination of brainstorming and reviewing of
standard risk lists.
There are different sorts of risks and we need to decide on a project by project basis what to do
about each type.
Business risks are ongoing risks that are best handled by the business. An example is that if the
project cannot meet end of financial year deadline, the business area may need to retain their
existing accounting system for another year. The response is likely to be a contingency plan
developed by the business, to use the existing system for another year.
Generic risks are risks to all projects. For example the risk that business users might not be
available and requirements may be incomplete. Each organisation will develop standard
responses to generic risks.
Risks should be defined in two parts. The first is the cause of the situation (Vendor not meeting
deadline, Business users not available, etc.). The second part is the impact (Budget will be
exceeded, Milestones not achieved, etc.). Hence a risk might be defined as "The vendor not
meeting deadline will mean that budget will be exceeded". If this format is used, it is easy to
remove duplicates, and understand the risk.
Risk Quantification
Risk need to be quantified in two dimensions. The impact of the risk needs to be assessed. The
probability of the risk occurring needs to be assessed. For simplicity, rate each on a 1 to 4 scale.
The larger the number, the larger the impact or probability. By using a matrix, a priority can be
established.
Note that if probability is high, and impact is low, it is a Medium risk. On the other hand if
impact is high, and probability low, it is High priority. A remote chance of a catastrophe
warrants more attention than a high chance of a hiccup.
Risk Response
There are four things you can do about a risk. The strategies are:
Avoid the risk. Do something to remove it. Use another supplier for example.
Transfer the risk. Make someone else responsible. Perhaps a Vendor can be made responsible
for a particularly risky part of the project.
Mitigate the risk. Take actions to lessen the impact or chance of the risk occurring. If the risk
relates to availability of resources, draw up an agreement and get sign-off for the resource to be
available.
Accept the risk. The risk might be so small the effort to do anything is not worth while.
A risk response plan should include the strategy and action items to address the strategy. The
actions should include what needs to be done, who is doing it, and when it should be completed.
Risk Control
The final step is to continually monitor risks to identify any change in the status, or if they turn
into an issue. It is best to hold regular risk reviews to identify actions outstanding, risk
probability and impact, remove risks that have passed, and identify new risks.
Summary
Risk management is not a complex task. If you follow the four steps, you can put together a risk
management plan for a project in a short space of time. Without a plan, the success of the
project, and your reputation as a Project Manager, are on the line. Follow these steps and you
will increase your chances of success.