5 steps to writing an effective project risk

5 steps to writing a project risk
Author: PM Majik
Copyright 2015. All rights reserved. www.pmmajik.com

Contents
1.0 Purpose of this presentation
2.0 Risk title
3.0 Risk detail
4.0 Risk consequence
5.0 Target resolution date
6.0 Mitigating action
7.0 Summary
8.0 PMO resources

1.0 Purpose of this presentation
The purpose of this presentation is to provide the 5 steps to writing a project risk,
including examples of good and bad.
Unfortunately many project risks are poorly written and as a consequence are not
managed. If risks are not managed they can delay the completion of the project.
5 steps to writing a project risk
1. Risk title
2. Risk detail
3. Risk consequence
4. Target resolution date
5. Mitigating action

2.0 Risk title
• Each risk needs a title that gives an indication of the nature of the risk.
Poor Title
Resources
•Too generic
•Does not specify resource type
•Does not specify if there are not
enough / too many resources
•Does not specify why they are
needed
Good Title
Lack of resources to develop
website interface
•Title is specific
•Identifies resource type
•Identifies there are not resources
•Specifies what they are needed for

3.0 Risk detail
• Each risk needs a clear description that explains the risk so that it can be
understood. Avoid project language, technical terms and acronyms.
Poor Risk Detail
There may not be sufficient
resources to complete the project.
•Does not specify resource type
•Does not specify when they are
required
•Does not specify what work needs
to be completed
Good Risk Detail
There may not be sufficient java
developers to complete the
development of the website
interface between September and
October 2014.
•Identifies resource type
•Identifies there are not enough
resources
•Specifies what they are needed for
•Defines when they are needed

4.0 Risk consequence
• The reason for identifying a project risk is that they usually will have some
form of impact on the project if the risk becomes an issue. Therefore, it is
important to document the consequence so that the reviewers can
understand the consequence to the project if the risk is not managed.
Poor Risk Consequence
Lack of resources may cause delays.
•Generic statement
•Does not explain consequence of
not having the required resources
Good Risk Consequence
Delays to completing the website
interface development by 31st
October 2014. This will directly
delay the testing phase. Each day
delay during development will
extend the completion date of the
project by 1 day.
•Clearly defines consequence that
there will be a delay in the project if
resources not secured.

5.0 Target resolution date
• This is the date by when the risk needs to be addressed (mitigating action
taken) or accepted (the project is happy to accept the impact if the risk
becomes an issue).
Poor Target Resolution Date
No date specified, TBC (to be
confirmed), TBA (to be advised),
general dates (i.e. end of year, end
of project).
•If there is no clear understanding
when the risk needs to be
addressed, it is usually because it
has not been clearly defined. It is
common to see generic risks
relating to resources and the end
date being set as end of year /
project.
Good Target Resolution Date
This should be the date by when
action needs to be taken to address
the risk. In this example 1st
September 2014 as resources
needed on this date to start work
•Important: try to set real dates as
opposed to ones where it does not
matter. If a date is set and missed
and there is no consequence, it will
mean that other deadlines will not
be taken seriously.

6.0 Mitigating action
• Defining the risk is only part of what needs to be captured. The project team
should also provide proposed mitigation (the action to be taken to address
the risk).
Poor Mitigating Action
Monitor resources to identify
delays.
•Generic statement that states that
resources will be monitored. This
will probably result in lack of
resources only being known when
it is too late.
Good Mitigating Action
Identify named resources to
complete java website interface
and gain agreement that they will
be available to support
development between September
and October. As contingency,
engage 3rd party provider of java
developers to see if they can
provide resources at short notice
should they be required.
•This mitigating action gains
commitment of the required
resources and also tries to put in
place a back-up plan.Copyright 2015. All rights reserved. www.pmmajik.com

7.0 Summary
Follow these 5 steps to capture and document project risks that can be monitored and
progressed.
Reminder of the list:
1. Risk title
2. Risk detail
3. Risk consequence
4. Target resolution date
5. Mitigating action
Additional Resource
http://www.pmmajik.com/5-steps-write-good-project-risk/

8.0 PMO resources
If you want more information, visit www.pmmajik.com where you will find lots of project
and PMO resources including the FREE guide, 7 Steps to Set-Up a PMO.
Visit http://www.pmmajik.com/set-pmo/
PM Majik Website
On the PM Majik website you will find over 100 articles that contain practical and
pragmatic tips and insights for designing, mobilising and managing a PMO. New
articles are added weekly. Topic requests are encouraged from the community.

5 steps to writing an effective project risk

Recommended

Recommended

More Related Content

More from PM Majik

More from PM Majik (9)

Recently uploaded

Recently uploaded (20)

5 steps to writing an effective project risk