RAIDs Management

RAIDs are the management of risks, assumptions, issues and dependencies of projects and programs. It is vital to differentiate between RAIDs and understand their need to be identified, monitored and how to analyse and manage them. We start with the initial overview of the RAIDs in the project brief and later on develop a procedure to identification and management of RAIDs. As a standard procedure we develop logs and templates for each RAIDs category which also forms to be a part of project initiation document (PID).

Risk is any uncertain event or circumstances that if it occurs, will have positive or negative impact on the project. We structure our processes to allow individual risks to be understood and managed and minimising the threats to project success. We prepare for managing risk through determining risk categories and parameters including likelihood, impact and severity. We focus on analysis of identification, analysis and categorisation of risk. When a risk is logged on the register, continuous mitigation process is our practice until the risk is controlled and RAG (Red, Amber or Green) status identified based on the likelihood.

Assumptions are anything which is taken for granted or supposed to be true. These are supposition that cannot be established as being true at this point but are likely to be true. This implies a high probability of unknowns as the assumption might go wrong and have an element of risk. Once an assumption goes wrong it will trigger an issue. Even though the assumptions are quite risky but projects still need to have as to move the project forward. We at E-Tech are very concerned when it comes to raising assumptions and would always discuss with the project managers as to level of their confidence, how long the project manager thinks before they can prove or disapprove the assumption and the reworking impact if the assumption is found to be incorrect.

Issue is a threat to the project objectives that cannot be resolved by the project manager. We always try our best to have least issues and try to cater for the risks in due time to avoid getting them crystallised as issues. Once an issue gets raised our focus is to manage it in a way that least threats the project objectives and is identified and removed the threats they pose. We ensure each issue is identified and analysed and documented in the issue register. With the help of the owner, we need to have a complete action plan in the register to solve the issue and periodically monitor the progress to successful closure. In any kind of deviation this needs to be escalated. During the progress, issue severity/impact needs to be assessed and RAG status clearly identified.

Dependency can be internal and external or incoming and outgoing or top down and bottom up. Projects are always dependent on some situations, things or someone else. These dependencies are logical relationships between two or more tasks that are either in the same program/project/workstream or are external to this environment. Internal dependency is used in those projects in which activities and tasks identify the amount of work to be done. In such projects their tasks logically relate to each other and never refer to non-related activities of other projects. Internally dependent tasks are performed and managed under the rules and conditions defined in their projects only. They are never subordinated to other, external projects and activities. External dependency is often used either in one project that includes several sub-projects, or in multiple projects. External dependency means that two or more tasks from different projects or sub-projects are dependent on each other. Such tasks may use common resources but have different goals, and vise-versa.