How To Write A Good Risk Statement

Risks should be written down as a Risk Statement and logged in the Risk Log. They should be reviewed regularly to ensure they are being managed and communicated effectively.

It is essential to write clear risk statements in order to understand them, assess their importance, and communicate them to stakeholders and people working on the project.

The Risk Statement helps everyone understand and prioritise the risks on the project. The Project Manager will focus on communicating and managing the highest priority risks.

Risk Statement is a communication tool

The Risk Statement is used to communicate the risk to the relevant stakeholders, if it is of sufficient importance. It should state clearly:

• What the risk is
• What the trigger is for the risk ie what will cause it to happen
• What the impact of the risk is if it happens

In addition to this each risk should be:

• One single risk
• Understandable to the audience intended ie it should be jargon free or non-technical if targeted at executives

The key point is that if people understand what the risk is they can then help to mitigate it.

Risk Statement format

Using a standard format for writing Risk Statements helps to ensure all of the essential elements are covered. For example:

“If <event X> happens then there is a risk <consequence> that the project could be impacted in <Y way>”

Example 1: If the new servers are not delivered by 10^th February, then there is a risk that the commissioning engineers will not be able to start on the 11^th and so there could be a delay to the project timeline.

Broken down:  If [EVENT] the new servers are not delivered by 10^th February, then there is a risk that the [CONSEQUENCE] commissioning engineers will not be able to start on the 11^th and so there could be a [IMPACT] delay to the project timeline

Example 2: If the new HR software is not delivered by 1^st May, then we may have to extend the contracts for the HR software testing team meaning there would be an increase in budget required.

Broken down:  If [EVENT] the new HR software is not delivered by 1^st May, then we may have to [CONSEQUENCE] extend the contracts for the HR software testing team meaning there would be an [IMPACT] increase in budget required.

Prioritising Risks

Once the Risk Statement has been completed then its likelihood and impact can be assessed and scored. The Project Manager can then decide how important the risk is and who needs to know about it and assist with its mitigation.

See the article: How to rate project risks for likelihood and impact.

Back to Help with starting and running projects