project milestone

One Page Plan for Project RAID Success

March 25, 2015 by

Some project managers tend to focus more on issue or risk management rather giving equal focus to the four areas of RAID Management (Risk, Assumptions, Issues, and Dependencies).

A lack of focus on any one of these areas is a risk itself and can result in a negative effect and take a project off course.

The best practices for the project management of Risks, Assumptions, Issues, and Dependencies is a critical success factor in IT project management for a successful project outcome.

A great benefit of BrightWork is the management of Issues and Risks are part of the solution with automated, configurable metrics and the ability to customize project templates to suit the needs of an individual organization.

To meet the requirement of a complete focus on RAID including the Assumptions and the Dependencies, I typically customize the Project Statement on the Project Template being used so these two areas are captured by the Project Manager when creating a project. This means that information on Risks, Assumptions, Issues, and Dependencies are always visible to someone managing and reviewing the project so they have a full understanding of the RAID context and status.




5 Key Areas for Project RAID Success

1. Risks

  • A risk is a possible future issue i.e. something that may go wrong.
  • The definition of a risk is any specific event which might occur and thus have a negative impact on your project or program.
  • Each risk has an associated chance of occurrence along with an impact on your project if it does materialize.
  • This is the one key area PMs do take focus upon in the managing and mitigating of risks.
  • Your project risks are the “issues” waiting to happen.
  • If the likelihood of the event happening and impact to the project are both high, the event is classed as a risk.
  • All risks should be logged, no matter how small.
  • All risks should have an ID number and all risks should be owned by someone who has been involved in the discussion about the specific risk.
  • In addition, all risks should be measured in a standard way with probability and impact.
  • In the risk log section, there should be columns for the risk owner, status, and any dates that may be relevant.



2. Assumptions

  • The definition of an assumption is something that is set as true to enable an organization to go ahead with a project.
  • As part of the initial planning phase and project brief, assumptions are identified and documented. Unfortunately, many times they are just forgotten after this first activity.
  • A common assumption in many projects is there will be access to the required specialist resources for the duration of the project.
  • The purpose of tracking assumptions is you need to be ready for your assumptions being wrong.
  • Most project plans are produced on this assumption, but if this assumption turns out to be false, then the project will falter.
  • It is important to include all the assumptions that have identified into a project document such as a Project Brief (PRINCE2).
  • Any assumptions made about the delivery of externally controlled deliverables should also be included.
  • If there are actions that can be taken to avoid the consequences of an assumption not being true then it should be considered (and managed) as a risk.
  • If an assumption cannot be changed then it should be considered (and managed) as a constraint
  • If an assumption uses words like ‘relies on’ or ‘depends’ then it should be considered (and managed) as a dependency, which in itself should be managed as a risk.



3. Issues

  • An issue is something that is going wrong now in a project are those things which have occurred, is current and have yet to be properly addressed.
  • Issues differ from risks in that they exist as a problem today, unlike risks which might turn into issues in the future.
  • Like risks, issues need to be managed through an agreed management process.
  • An issue is anything which arises on your project which you have to deal with to make sure your project runs smoothly.
  • An issue is something that has gone wrong (deviation from the approved scope, schedule, budget etc.)
  • Issues are also risks that have been realized and have turned into issues.
  • As with risks and actions, all issues should have an assigned id, owner, and timescale.


Failure to manage issues may result in a poor delivery or even failure.

The RAID log includes a description of each issue, the impact it is having, its seriousness and actions needed to contain and remove it.


Issues can be any of the following:

  1. A risk that has gone live and requires attention
  2. An unresolved question (e.g. from the Project Brief)
  3. New ideas or concerns
  4. Potential changes e.g. a need to change a deliverable
  5. An unexpected event that has occurred e.g. a contractor going bankrupt
  6. A problem that will impact on another project’s objectives.


 Issues can be resolved in ways, such as:

  1. Cleared immediately with no action required.
  2. Additional planning is undertaken and new deliverables added or existing deliverables changed.
  3. An issue becomes a risk, with an owner appointed and a countermeasure ready.



4. Dependencies

  • Dependencies exist when an output from one task or another project is needed as a mandatory input for another task or another project.
  • Dependencies must be delivered to enable a project’s delivery. These must be identified and tracked as they will impact on the project going forward and being successful.
  • Dependencies form a key part of workload prioritization during the programme and are a basic agenda item for any meetings and decision-points. As such, they must be consistent with all other aspects of the plans, projects, and programmes.
  • It is a key responsibility for project managers to record, monitor, and manage these dependencies.
  • Dependencies may be items being delivered from elsewhere, and that may not be directly under the control of a project manager.
  • Poor management of project dependencies often leads to project failure.
  • The dependencies log will capture at least who the project is dependent upon and what they should deliver and when.
  • PM’s should also keep details of the actual agreement and when it was made, plus any later variations of this.



5. RAID Log

The RAID log is a key project management tool that allows the stakeholders to see the progress of the project and issues having an impact on the successful implementation of a project.

Brightwork facilitates a RAID log in an effective manner. Instead of being recorded in a static spreadsheet, Issues and Risks can be monitored and managed in a live reporting environment, helping you to make sure nothing falls through the cracks.

Brightwork aids accountability as all risks, actions, issues, and decisions are recorded with ownership, accountability, responsibility, and time.


Image credit 

Latest posts by Ken Martin (see all)

    Pin It on Pinterest

    Share This