Top Tips for a Project Management RAID

Share this post


Delivering any project requires the management of several key aspects, including Risks, Issues, Dependencies, etc. which can take time to document, review and track.

To achieve this it is critical to create and manage logs of the identified Risks, Issues, Dependencies, Assumptions, etc. This is traditionally managed through a RAID and is a tool I would not do without, but what makes a good RAID?

What should a RAID include?

Classically a RAID consists of 4 components:

  • Risks
  • Assumptions
  • Issues
  • Dependencies

This is a good starting point, but over the years I have extended this depending on the size of the project, to include:

  • Contacts
  • Risks
  • Actions
  • Assumptions
  • Issues
  • Dependencies
  • Decisions
  • Holidays

So what are these and what items should be included in each log?

Key RAID Logs


To help with the ongoing management of any project a communication strategy is required and at the core of this you need to know who is involved with the project, their role and how to reach them. To achieve this, the following items are required:

  • Contact Name – name of individual.
  • Project Role – the role of the individual in the project, which should be linked to defined roles set out in the initial stages of the project.
  • Company & Job Title – details of which company they work for and their given job title.
  • Contact Details – telephone number, mobile number and email address.


Unmanaged risks have the potential to derail any project, so a log of each risk is required looking at the impact and likelihood of the risk. Although often covering only threats I would recommend including potential opportunities to enhance the project/business, so informed decisions can be made on whether they should be pursued. To achieve this, the following items are required:

  • Risk Description – description of the risk/opportunity, including details of cause, event and effect.
  • Date raised and who by.
  • Type – flag to indicate if this is a risk or opportunity.
  • Likelihood – indicator from ‘high’ to ‘low’ on the chance of this event occurring.
  • Impact – indicator from ‘high’ to ‘low’ on how the project will be impacted by the occurrence of the event.
  • Proximity – indicator from ‘imminently’ to ‘distant’ on when the event is likely to occur.
  • Risk Score – using the levels set for ‘likelihood’, ‘impact’ and ‘proximity’ set a risk score.
  • Status – status of the current risk.
  • Owner – name of individual assigned to monitor/manage risk.
  • Actionee – name of individual assigned to implement risk response.
  • Response Type – identification of how risk/opportunity will be responded to:
    • Risk – avoid, reduce, fallback, transfer, accept or share.
    • Opportunity – exploit, share, enhance or reject.
  • Response – actual response to risk/opportunity to take advantage or mitigate.
  • Date closed and next review date.
  • Comments – current comments on risk/opportunity.


Projects require activities to be completed, which need to be identified, allocated and implemented. To manage this each action will need to be recorded and reviewed, with the following items required:

  • Action description – title and details of action required.
  • Date raised and who by.
  • Owner – name of individual assigned to monitor/manage action.
  • Actionee – name of individual assigned to complete action.
  • Status – status of the current action.
  • Date closed and next review date.
  • Comments – current comments on action.


Assumptions are something we set as a given fact to enable us to proceed with the project and can happen at any stage in the project. To help manage these assumptions and ensure a false assumption is identified and handled a log containing the following items is required:

  • Assumption Description – title and details of the assumption.
  • Owner – name of individual who is responsible for the assumption.
  • Date raised.
  • Status – current state of assumption (raised, confirmed, rejected).
  • Date Closed – date assumption confirmed or rejected.
  • Comments – current comments on assumption.


Within projects problems and challenges will arise, which will need to be identified and a resolution planned/implemented to reduce/remove the issue. To manage each issue the following items are required:

  • Issue Description – description of the issue, including details of cause and impact.
  • Date raised and who by.
  • Type – flag to indicate type of issue:
    • Request for Change (change from original specification)
    • Off Specification (something which should be delivered, but currently is not expected to be delivered)
    • Problem (Other type of issue)
  • Severity – severity of impact indicator (How much has the project been affected by occurrence of event) from ‘high’ to ‘low’ on the impact of the issue.
  • Priority – urgency of responding to the issue from ‘high’ to ‘low’.
  • Status – status of the current issue.
  • Owner – name of individual assigned to monitor/manage issue.
  • Resolution Plan – plan to resolve issue.
  • Plan Decision – decision on plan to resolve issue:
    • Accept (accept plan).
    • Reject (reject plan).
    • Defer (defer decision, which will require a date to revisit issue).
    • Concession (accept off specification change).
  • Decision Approval – name of individual who made decision on resolution plan.
  • Decision Date – date of decision.
  • Date closed and next review date.
  • Comments – current comments on issue.


When an output from one piece of work, internal or external to the project, is required as input for another piece of work, a dependency has been identified. These dependencies need to be identified, recorded and managed, with the following items required to be logged:

  • Dependency Description – description of the dependency.
  • Deliverables – key deliverable of dependency.
  • Date raised and who by.
  • Internal/External – flag to indicate if dependency is internal or external to project.
  • Project Impact – flag to indicate impact on project from ‘high’ to ‘low’
  • Action Required – yes/no flag to indicate action required.
  • Action No. and Status – action log reference linked to dependency and the current status of the action.
  • Owner – name of individual assigned to monitor dependency.
  • Dependency Status – current state of Dependency
    • Open (dependency still exists, but not delaying project).
    • Critical (dependency exists, and is or about to delay project).
    • Closed (dependency has been removed or no longer affects project).
  • Date closed and next review date.
  • Comments – current comments on dependency.


Within a project several key decision will be made, which can be logged to record the decision, who made the decision and when it was made. To log these decisions the following items are required:

  • Decision Description – title and details of the decision.
  • Impact – impact of decision on project/deliverables.
  • Date raised and who by.
  • Status – current state of decision (open, pending approval, approved, declined).
  • Approved By – name of individual who approved or declined decision.
  • Date closed.
  • Comments – current comments on decision.


Absences of key individuals can have a big impact on a project, so understanding when holidays will be taken and the cover provided is critical in the continued successful delivery of a project. To manage this, the holiday log should contain the following items:

  • Name – name of individual taking holiday.
  • Date from – date absence starts.
  • Date to – date absence ends.
  • Cover – name of individual covering absence. (note: the covering individual should be in the contacts list)


RAID logs provide a good tool for managing and recording elements of your project, but need to be used actively and not just as a store for default risks, issues, assumption, etc. so ensure they are reviewed regularly and alongside the delivery of the core purpose of a project, its deliverables.

If you have any further questions or would like support / guidance in managing your projects, or  discovering and defining your Data Driven Marketing solution, please contact me through the BlacklerRoberts Ltd “Contact Us” page and I will be happy to discuss your needs. Alternatively please follow @BlacklerRoberts on twitter for further insights.

1 Comment on “Top Tips for a Project Management RAID

  1. Hi. I like this breakdown, and I use it myself too. I particularly like the “proximity” facet of the risk portion.
    1. For RAID log, I also have “trending”, as that gives me and my stakeholders/owners an indication if progress is being made on some items…”Improving, Deteriorating, NoChange” as a useful indicator.
    I also include “project Resolutions and statements” under decisions.

Leave a Reply

Your email address will not be published. Required fields are marked *