How to write a good Risk Statement?

In this article I discuss something very simple – how to describe a risk. Most often this is ignored as project managers believe what matters is how we analyze and respond to risks and not how we formulate a risk statement. Would you agree? I have a little different thinking here.

In a risk management workshop when I ask the delegates to cite some examples of risks I get responses as:

  • Project maybe delayed

  • Cost overrun

  • Attrition

  • Raw material prices will hike

....amongst other good risk statements of course!

Do you think these are good definitions of risk? If not, then what’s wrong about them? Well, we will come to the answer of this question in a while. Let’s first look at the definition of risk

“A risk is defined as 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”- source PMBOK Guide

First thing about risk is these are uncertain events. If something is certainly going to happen then it’s not entitled to be a risk. Like for some reason if you are sure that “raw material prices will hike” then it’s not a risk… call it an issue. Simply the word “WILL” doesn’t go with risk; it should be replaced by “MAY”. That is, the probability of a risk occurring should be greater than 0% and less than 100%.

The effect of a risk could be either beneficial or adverse to the project. Those events that can cause a favorable impact are termed as opportunities and the ones that would cause unfavorable impact are termed as threats. Threat management is most often conducted by project managers than is opportunity management.

A risk statement should comprise of three parts – a cause, an event and an effect.

  • Cause – is the trigger or the reason for the event to occur

  • Event- represents the uncertainty (there maybe escalation in raw material prices, weather conditions may not be favorable)

  • Effect – this is the consequence should the event occur (beneficial or adverse)

Whenever you are writing a “risk statement” you must clearly describe all the three.

Example of some risk statements…

  • Text in green represents the cause

  • Text in Orange represents the event

  • Text in red represents the effect

Due to high levels of stress in the project team, there is a possibility of higher than usual attrition thereby delaying the project. This is a threat

Due to extension in project timelines (may be to deliver added scope), there is a possibility that the service provider releases a newer version of the technology (which is expected) before the end date of the project, which can be adopted instead to reduce operation cost of the application by 10%. This is an opportunity

Risks are also termed as uncertainties - when we say a risk is uncertain, it’s not the cause but the event that is uncertain. There is no uncertainty about cause… it’s something that’s already happening.

I hope by now you would have understood what is the issues with the risks listed at the top of this article. Let’s look one ‘attrition” risk.

“Attrition” – this definition is not so bad, we can make out what is meant… there is possibility of attrition being higher in the project team than usual (say 5%) which may affect the project. Do you think this is enough? It doesn’t describe the cause. Why does the project manager believe there would be higher attrition? There could be many reasons for this like

  • More job opportunities in the market post recovery from an economic meltdown

  • High job stress in the project

  • Team doesn’t have the opportunity to work on latest skills

Now, our response to the same risk would so much vary depending on what the CAUSE is. Like

  • More job opportunities in the market post recovery from an economic meltdown – offer employees better compensation/benefits at par in the industry;

  • High job stress in the project – level resource usage; organize stress relief sessions

  • Team doesn’t have the opportunity to work on latest skills – promise to offer them task that they are willing to do in the next assignment;

Without the knowledge of the exact cause I have no clue which of the above response I should be trying out. Imagine the cause is “Team doesn’t have the opportunity to work on latest skills” and I am organizing stress relief sessions and reducing workload.

Now coming to the EFFECT – attrition won’t have the same effect on every project, depends on the nature of work, skills required, the criticality of the project and more. In some cases resources could be easily replaced while in others the learning curve could be long and complex requiring long trainings and orientation to prepare another person to take over. So effect could vary…

If the effect is assessed to be severe then I would possibly consider some response like creating back-up or try retaining the resource by offering some benefits. While if I perceive the effect to be insignificant or minor then probably I would choose to accept the risk. Without this knowledge I have no idea how severe it is to warrant appropriate attention and response. Therefore, there is a need to identify and document the effect as well. However, I don’t have to analyze the magnitude of the impact at this time, this would be next step conducted as part of ANALYSIS.

26 views0 comments

Recent Posts

See All

KPMG urgently looking for PMP certified professional from Telecom industry with SOX knowledge. Offer would be as per current profile. In case you meet pre-requite and are interested, write to dj@pmsha