What are RAID Items?

Risks, Assumptions, Issues and Dependencies, as the acronym denotes, are four different types of situations that can hinder a project's progress if not identified early and managed continuously.

• Risks are potential situations that can negatively affect the project.
• Assumptions are unproven but relied upon facts based on which projects are planned.
• Issues are problems popping up in the project.
• Dependencies are associations between tasks or projects that make one dependent on the other to start or end.

A project progresses smoothly when RAID items are documented, communicated, reviewed, and controlled. 

Amplify allows you to document all RAID items, monitor and control them by assigning a rating to every RAID item and communicate their implications to stakeholders.

This article covers the following topics:

• Risks
• Assumptions
• Issues
• Dependencies

Risks

Risks are factors that can have a negative impact on the execution of the project.  If left unmanaged, risks can severely affect the project's ability to deliver the planned benefit value. An iterative risk management process is required to avoid or mitigate damages. Standardisation of risk rating is essential to communicate the impact a risk may have on the project and allow them to be comparable within a program.

Amplify offers an iterative risk management workflow, where risks are identified, rated and communicated with the project and the program. Every risk is identified as a Delivery risk or a Realisation risk. An event that can impact the project is a  is a delivery risk, whereas any possible hindrance to achieving the targeted benefit value is termed as a realisation risk. Risk also has a standardised rating calculated from the impact and likelihood as well as a dedicated field for capturing any potential financial impact. 

How it works

• Risks are identified and documented in the project.
• Their impact and likelihood of occurrence is assessed and are given a rating.
• Mitigation steps are identified and a review date defined.
• Period review - Risks rating is reduced if incorporating mitigative measures brings down their impact or likelihood.

Best Practice Implementation 

The following sample scenario describes the standard steps and guidelines to identify, manage, and control project risks using Amplify.

Scenario Background

The Human Resource Department plans to implement a Workflow Management software as it expected to bring efficiency to its day-to-day operations and thereby significant cost savings. After his catchup with the IT vendor, the Project Manager see chances of a possible delay in Implementation timelines. This is a risk which needs to be assessed.

 Roles Involved

• Project Owner

Documenting the Risk

The first step after identifying a risk would be to document its characteristics.  

Rating the Risk

Use the impact and likelihood estimates to calculate the standardised risk rating based on the organisation's risk matrix. 

Devising Mitigation Plan

Describe steps to mitigate the risk.

 Assigning a Review Date

Select a review date to evaluate the mitigation plan.

 Reviewing the Risk

The Project owner reviews risks based on the review date.  The Register allows stakeholders to review, prioritise and re-evaluate risks. 

Risk Dashboard shows all information pertaining to the risk. Project Manager can see the delivery and benefits risk indicators on the Gantt chart. 

 Risk Closure

Once mitigation steps are underway, the impact and likelihood are reassessed on the review date, bringing down the rating as applicable or closing the risk. 

 back to the top of the page

Assumptions

An assumption is a known fact or a key piece of information that is assumed to be true for the project to be successful. For example, a building management project leveraging an ongoing vendor contract may move forward with the assumption that vendor staff is available at all times.  Every project plan is created with a set of assumptions. Assumptions add risk to the project since they should remain true and valid throughout for the project to complete successfully.  The validity of an assumption, however, may change over time which is why it is a good practice to review and reassess assumptions from time to time throughout the project lifecycle. If an assumption is continuously verified to be true, it can be closed or if it turns out to be invalid, measures should be taken to mitigate the impact on the project.

Amplify allows you to document, communicate, and validate assumptions. Assumptions are described as part of the project. A rating is assigned based on their impact on the project if proved incorrect. Mitigation steps are determined to reduce the impact.

How it works

• Assumptions are evaluated and documented.
• The owner takes responsibility for reviewing.
• Validates the assumption at various points throughout the project.
• Actions are taken to adjust the project plan in case an assumption changed.

Best Practice Implementation 

The following sample scenario describes the standard steps and guidelines to identify, document, and control assumptions using Amplify.

Scenario Background

While planning the new Marketing Campaign project in Ab & C, Inc the team identifies the general assumption that 2 personnel will be required from the Information Technology group. The team's degree of confidence in this assumption requires to be validated and its impact should be determined. If this assumption proves wrong at any point in the project lifecycle, it can lead to project delay and added costs. In case the assumption turns out to be incorrect at any point in the project lifecycle, enough measures have to be planned to ensure that the project continues without delay.

Roles Involved

• Project Owner
• Assumption owner

Documenting the Project Assumption

The team member who identified the assumption documents it in a way that will help everyone understand it and how it is going to be managed going forward. The team member now owns the assumption. They then communicate it to the project owner.

Rating the Assumption

The Project owner gets the stakeholders involved in identifying the likelihood of the assumption turning incorrect to determine its impact on the project.

Devising Mitigation Plan

Describe the steps that will need to be taken if the assumption turns out to be invalid.  

Assigning a Review Date

The review date is the date on which the assumption will be validated.

Reviewing the Assumption

The RAID Register allows stakeholders to view and track project assumptions as and when they are made. The Project owner and other stakeholders validate the assumption based on the review date.

Closure

As the validity dates pass, the assumption is marked as closed.

  back to the top of the page

Issues

An issue is an unexpected negative event that occurred in the course of the project conduct. For example, a key resource resigns in the middle of a project. Issues should be resolved as they occur, otherwise, they can cause delays or even result in failure of the project to complete on time. It is important to document issues and the steps taken to resolve them as they can be applied to similar future situations.

Amplify treats Issues in the same way as risks.  

How it works

• Issues are identified and documented in the project.
• Their impact and likelihood of occurrence is assessed and are given a rating.
• Mitigation steps are identified and a review date defined.
• The issue is resolved and closed.

Best Practice Implementation 

The following sample scenario describes the standard steps and guidelines to identify, document and resolve project issues using Amplify.

Scenario Background

The Infrastructure Project is facing a sudden shortage of building materials. This situation was identified as a risk during the initial phase but was disregarded as it was assessed that the chance of facing this situation was considerably low. The increase in demand has surpassed the original estimated supply requirement. The Project Manager should resolve this issue immediately in order to ensure that the day-to-day activities carry on without any hindrances.

Roles Involved

• Project Manager
• Team Member

Documenting the Issue

The team member creates an issue in Amplify as soon as it is known. A relevant name is entered. The background, reason, and possible impact is captured in the Description field. The issue is now available in the RAID register for the stakeholders to review.

Rating the Issue

The project manager uses the impact and likelihood to calculate the rating. 

Devising Action Plan

The project manager and team members discuss and arrive at an immediate action plan. The steps to resolve the issue is captured in the Issue definition interface.

Assigning a Review Date

Select a review date to review the issue.

Reviewing the Issue

The Project owner reviews issues based on the review date.  The Issue Register allows all team members to view and track project issues.

RAID Dashboard shows all information pertaining to the issue. 

Closure

Once the issue is resolved, it is closed. 

  back to the top of the page

Dependencies

When an organisation is undertaking multiple programs of work, it is common for a project in one program to enable the outcomes in another. Identifying and communicating inter-project dependencies is complicated by the fact that different programs have different delivery teams that rarely have visibility into the projects and schedules of other programs of work. inter-project dependencies provide a mechanism of visibility, communication and a reporting conduit between two related but logically separated projects. Successful management of inter-project dependencies allows you to avoid delays by taking corrective action.

How it works

• Each program needs to have a Dependency Manager
• A Project Owner identifies a dependency on another program and submits it to the Dependency Manager.
• Dependency Manager communicates and assigns the dependency to the appropriate project.
• The Project Owners develop a dependency action plan and a workflow confirms their agreement.
• Dependencies appear on the schedule and in RAID registers for management through to completion.

Best Practice Implementation

The following is a fictional scenario that is intended to take you through the best practices for implementation of inter-project dependency management using Amplify.

Scenario Background

The Marketing program in AB & C, Inc is rolling out a new campaign and the Sales program needs to complete an awareness training on the campaign materials. Sales Program is dependent on Marketing to ready their new campaign so that the awareness training project can be started. You can see this illustrated in the below picture. Mr.Jack Harkness handles the Marketing Campaign creation project. Mr.Gavin Cooper is responsible for the Sales Training project. Ms.Bridget Evans is appointed as the Dependency Manager for the Marketing Campaign.

Roles Involved

• Bridget, the Dependency Manager for the Marketing Campaign 
• Gavin, the Project Owner for Sales Training
• Jack, the Project Owner for Marketing Campaign Creation
• Other stakeholders who act as the  approvers of the dependency
  

Identifying and Creating the Dependency

Gavin Cooper, the Sales Training Project owner has identified a dependency, he requires the marketing campaign materials before he can begin his training. He creates a Dependency item from the project's RAID register or schedule. Gavin must assign the Marketing program as the predecessor initiative, he also completes the rest of the form to the best of his ability. 

Dependency Manager assigns

Bridget sees the dependency on her dashboard, or email and needs to assign the dependency to Jack Harkness, the owner of the Sales Project generating the marketing material. At this time Bridget can also assign the specific schedule task if it is known. If only the project is assigned, the project owner will be responsible for assigning it to a specific task in their schedule (schedule may or may not be there).

Generation of a Plan

Both parties contribute to the action plan and ensure that it contains the appropriate level of detail to communicate the tasks proceeding and following the deliverables. 

• appropriate name
• action plan
• set review dates
• scheduling

Agreement

The dependency workflow enables Gavin to communicate the action plan to all parties involved in the delivery. 

The workflow can be configured to have different layers of permissions. It is possible to set up a workflow that demands unanimous approval, single consent, or self-approval. Use 'unanimous' approval type to secure agreement from all required stakeholders. 

All participating users agree to the plan and approve the workflow. Dependency becomes recognised and accountable.

Monitoring 

Both project owners regularly view and update the dependency via the Dashboard. The dependency is visible in both RAID registers. It appears on both schedules. The progress flows through from one schedule to the other.  

Delivery

Progress is reported using the schedule progress (of the task) and reaches 100%.

Closing a Dependency

The predecessor task is completed. Jack makes sure that the deliverables are handed over to Gavin and his team as per the action plan. The dependency ends there and one of the parties closes it with final comments using the Edit function. 

  back to the top of the page