RAID Log

After breaking down the work and adding time constraints to the roadmap, you are ready to formalize many things that have already been discussed:

• Risks that might arise

• Assumptions that we have about the future

• Issues that already exist with the plan

• Decisions to be made

• Dependencies across teams

By creating a RAID log, you will identify and document these things. A RAID log is just a formal way of handling that diverse set of information you need to track and drive.

What is a RAID log?

RAID stands for risks, assumptions, issues, and dependencies (or decisions). A RAID log is a tool to document and track these elements, starting in the planning phase but continually being used throughout execution.

Having a comprehensive and up-to-date RAID log will help you consolidate the many moving pieces of the program that you need to track throughout the program lifecycle.

You are learning about it in the program planning phase so that you can create this artifact early in the program.

In this lesson, we will learn how to create a RAID log, and how to use it effectively to ensure the smooth execution of your program.

Creating a RAID log

As the TPgM, you own the RAID log and are responsible for keeping it up-to-date. You drive the successful creation and maintenance of the RAID log. It is created through the combined effort of all members of the program team.

Risks (R-a-i-d)

Risk Management is an important aspect of your role as a technical program manager.

It involves identifying, assessing, and mitigating potential risks that may impact a program's success. Effective risk management requires a thorough understanding of the potential risks that may arise, as well as the tools and strategies needed to manage them effectively.

Note: We will have an entire lesson dedicated to risk management, but let's talk about what needs to happen around Risk Management during the planning phase.

Risk management culture

The planning phase is the perfect time to create a proactive risk management culture. The opposite of this is reactive risk management, meaning risks are only identified as they happen, which isn't really risk management. It's more like constantly putting out fires.

Common risks to watch for

There are common risks that may happen during the program. These risks can impact either the timeline or scope of the program.

• Technical risk: Are the nonfunctional requirements being met? For example: performance, reliability, redundancy, scalability, and maintainability.

• Staffing risk: Are all teams prioritizing this program appropriately so that we have the right people to consistently make progress?

• Legal risk: Does the program have any legal implications that need to be accounted for?

• Security or privacy risk: Can we continue to ensure the safety of our systems, users, and services? Can we maintain compliance with data privacy laws across various countries?

• Quality risk: What are we doing to maintain quality engineering?

Risk log

A Risk Log is a simple documentation method to capture and track risks across the program. Every risk in the risk log should include a description of the risk, an owner, likelihood, the severity if the risk becomes a reality, and a mitigation plan.