PROJECT RAID LOG SUMMARY

Project Number: <Please complete>

Project Name: <Please complete>
Project Manager: <Please complete>
Project Sponsor: <Please complete>

Risks Assumptions Issues

0 0 0
ACTIVE RISKS ACTIVE ASSUMPTIONS ACTIVE ISSUES
High 0 High 0 High 0

Medium 0 Medium 0 Medium 0

Low 0 Low 0 Low 0

Date Owner Circulation

24 January 2024 <Please complete> <Please complete>

GUIDANCE NOTES:
A RAID Log is the 'bread and butter' of project managers and should be at the forefront of your mind if you are managing
RAID stands for risks, assumptions, issues, and dependencies and the log for each of these areas can be found in the diffe
(tabs) of this workbook or by clicking the coloured headers above:

- Risks: uncertain events which may have an impact on the project, either positive (opportunity) or negative (threat)
- Assumptions: beliefs that are accepted as true which, if proven invalid, will have an effect on the project
- Issues: risks that have materialized or any problems incurred which impacted the project
- Dependencies: links between projects, work packages or deliverables which, if delayed, will impact the project

Benefits of using a RAID Log:

- keeps your project organized and on track as all information is centralized, making it easier to monitor and control proje
- makes the information easier to store and retrieve, as the different logs are combined into a single document (and is alw
option rather than keeping everything in your head!)
- gives confidence to key stakeholders that the project is being closely monitored, resulting from the visibility of informati
- brings focus, as it serve as an aide-memorie to give appropriate attention to each area, ensuring that areas that are typic
overlooked, such as assumptions, are not forgotten
- enables accountability for mitigating actions, which is where risks and issues usually fall through the cracks
- creates a sense of ownership by inviting all members of the project team to contribute with the identification of new are
concern
- useful for auditing purposes (internal or external)
- keeps your project organized and on track as all information is centralized, making it easier to monitor and control proje
- makes the information easier to store and retrieve, as the different logs are combined into a single document (and is alw
option rather than keeping everything in your head!)
- gives confidence to key stakeholders that the project is being closely monitored, resulting from the visibility of informati
- brings focus, as it serve as an aide-memorie to give appropriate attention to each area, ensuring that areas that are typic
overlooked, such as assumptions, are not forgotten
- enables accountability for mitigating actions, which is where risks and issues usually fall through the cracks
- creates a sense of ownership by inviting all members of the project team to contribute with the identification of new are
concern
- useful for auditing purposes (internal or external)

Best Practices on using and maintaining a RAID Log:

- the RAID Log is a living document, and should not be something that you use in the beginning of the project and then sto
should be continually updated as changes occur or more information is gained
- put the "RAID Log Update" as an item of your project meetings agenda and go through it with your team
- make the RAID Log easily available in a central location so that it can be used collaboratively by all key stakeholders (unl
something confidential or sensitive information on it, of course!)
- identifying risks and issues without also identifying actions to mitigate them, or making decisions to resolve them will no
use. Identifying actions is as important as identyfing problems!
- the project manager or the sponsor are usually accountable for removing obstacles to the project but that does not mea
should be responsible for carrying out all the actions themselves. Distribute responsibilities amongst the team and design
experts - accountability and responsibility are two different concepts
- remember that assumptions and dependencies are as important (and dangerous) as risks and issues.
- be ready to accept that your assumptions may be wrong. However, it's better to log a wrong assumption and actively te
sorted it out than to believe that all your assumptions are correct and do not log them just to realize, usually too late, tha
have challenged them before
- it's not just important to log the right risks, assumptions, issues and dependencies, you also need to log them at the righ
detail: too many and too much detail makes you loose sight of what real matters and is impractical to manage; to few and
detail does not offer the granularity needed to assign responsibilities or assess progress. This is a difficult one but you nee
balance
- finally, remember that good project management is not about the absence of risks and issues (if you found a project tha
have any risks or issues, please share your secret!) but about how well you manage them. And that's where this RAID Log
Y

Dependencies
0
ACTIVE DEPENDENCIES
High 0

Medium 0

Low 0

Circulation
Please complete>

our mind if you are managing a project.

reas can be found in the different sheets

nity) or negative (threat)

on the project

l impact the project

to monitor and control project status

a single document (and is always a better

rom the visibility of information

uring that areas that are typically

ough the cracks

h the identification of new areas of
 to monitor and control project status
a single document (and is always a better

rom the visibility of information

uring that areas that are typically

ough the cracks

h the identification of new areas of

ng of the project and then store away. It

ith your team

y by all key stakeholders (unless there's

isions to resolve them will not be of much

project but that does not mean that they

amongst the team and designated matter

nd issues.
g assumption and actively test it and
o realize, usually too late, that you should

o need to log them at the right level of

actical to manage; to few and too little
is a difficult one but you need to strive for

es (if you found a project that does not

nd that's where this RAID Log can help you.
 Project Number: <Please complete>
Project Name: <Please complete>
Project Manager: <Please complete>
Project Sponsor: <Please complete>

Date Identified by Risk Description Risk Effect

ID Identified (author) Risk Type (there may be a risk that…) (leading to…)

R1

R2

R3

R4

R5

R6

R7

R8

R9

R10
 PROJECT RISK LOG

GUIDANCE NOTES:
Risks are a combination of probability and impact, which will result in a certain score for the project and r
escalation. Each risk should be clearly described, identifying its potential effect on the project, who is acco
employed to mitigate it. Risks should be part of the agenda of every team meeting.

Risk Effect Risk Score Risk Owner Mitigation Action

(leading to…) Probability Impact (P x I) Tolerance (who) (what)
ES:
ore for the project and related level of appropriate tolerance and
the project, who is accountable for the risk and what action will be
.

Date of Last
Risk Status Last Update / Comment Update
 PROJEC

Project Number: <Please complete>

Project Name: <Please complete>
Project Manager: <Please complete>
Project Sponsor: <Please complete>

Date Identified by Assumption Description

ID Identified (author) (it is assumed that…) Impact if Assumption is proven In

A1

A2

A3

A4

A5

A6

A7

A8

A9

A10
 PROJECT ASSUMPTIONS LOG

GUIDANCE NOTES:
"It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain'
project getting into avoidable trouble, all assumptions should be recorded in the Assumptions Lo
importantly, how will it be tested if the assumption is actually valid or not.

Assumption Action Assumption

Impact if Assumption is proven Invalid Impact Level Owner (how the assumption will be tested) Status
(who)
OTES:
ow for sure that just ain't so" (Mark Twain). To avoid the
ed in the Assumptions Log, identifying their impact and, as
ot.

Date of Last
Last Update / Comment Update
 PROJECT ISSUES LOG

Project Number: <Please complete>

Project Name: <Please complete>
Project Manager: <Please complete>
Project Sponsor: <Please complete>

Date Identified by
ID Identified (author) Issue Description Priority

I1

I2

I3

I4

I5

I6

I7

I8

I9

I10
PROJECT ISSUES LOG

GUIDANCE NOTES:
While issue management is, by definition, a reactive endeavour, it is still important that issues are resolved as
soon as possible in the project, by identifying the necessary action that could remove obstacles to the project's
success.

Issue Owner Response Action

(who) (what) Issue Status Last Update / Comment
 issues are resolved as
bstacles to the project's

Date of Last
Update
 PROJECT DE

Project Number: <Please complete>

Project Name: <Please complete>
Project Manager: <Please complete>
Project Sponsor: <Please complete>

Date Identified by
ID Identified (author) Dependency Description

D1

D2

D3

D4

D5

D6

D7

D8

D9

D10
 PROJECT DEPENDENCIES LOG

GUIDANCE NOTES:
It is useful to record dependencies in a separate log to allow for a greater level of focus contr
should refer both to receiving products (inbound) and to dependencies towards other projec
appropriate, dependencies can also be added in project schedules (e.g. MS Project).

Dependency Dependency Action Dependency

Type Impact Level Owner (how the dependency will be Status
(who) monitored)
UIDANCE NOTES:
allow for a greater level of focus control. Dependencies identified
to dependencies towards other projects (outbound). Where
ct schedules (e.g. MS Project).

Date of Last
Last Update / Comment Update