RAID Log for Programmes: Roll Up Three Projects, with ₹ Example

A RAID log is one register where a delivery team records what could, or already does, threaten its dates, budget or benefits. RAID stands for Risks, Assumptions, Issues and Dependencies in most organisations; others read it as Risks, Actions, Issues and Decisions. Check your template's headings and keep one version across every project.

The Institute of Risk Management’s short guide uses the first reading. The University of Waterloo’s project management office template uses the second. A risk may happen and would change the outcome. An assumption is treated as true without confirmation. An issue has already happened. A dependency is something your work needs from another team, project or supplier. In the second version, an action is a task with an owner and a due date, and a decision is a choice with its reason.

If your projects use different versions, the programme manager picks one and maps the others before the first roll-up. If your version has no assumption or dependency type, add them, because the programme layer in this page depends on dependencies. Because A and D mean different things in the two versions, code entries R (risk), A (assumption), I (issue), DP (dependency), AC (action) and DC (decision) so that IDs read the same everywhere. A RACI chart (Responsible, Accountable, Consulted, Informed), which assigns roles on tasks, is a different tool.

A project RAID log records everything that affects one project. A programme RAID log records only entries that need a programme-level decision or touch more than one project, plus items that belong to no single project. It is a filter plus a layer, not a copy. A programme is a group of related projects managed together for benefits no one project delivers.

The programme board is the group of the sponsor (the executive accountable for the programme's benefits) and senior stakeholders that makes programme-level decisions. Our recommendation for the programme-visibility flag: set it to Y when a second project is affected, when the fix needs people, money or authority above the project manager, or when a programme benefit is at risk. The programme manager confirms or clears the flag at every review.

The escalation flag is separate. It marks entries going to the board for a decision. The criteria for setting it are on our page on program risk escalation criteria, and the method for assessing and responding to risk is in program risk management.

Thirteen columns cover a programme log: eight as in any project log, then five that make the roll-up work (₹ exposure, the two flags, Linked IDs, Last reviewed). Each has a pass test.

Owners for assumptions come from the stakeholder register, the list of people with an interest in the programme and what each needs from it: the people who can confirm what the plan is relying on.

An entry changes type when its status becomes known. A risk becomes an issue when the event happens. An assumption becomes an issue when its validation date passes unconfirmed, or a fact contradicts it. A dependency becomes an issue when the committed date passes without delivery.

Close the old entry with a reason (occurred, unconfirmed past validation date, delivered late), open a new one, and fill Linked IDs on both. Do not overwrite the original. The history shows how long a doubt sat unconfirmed.

PMI's Learning Library defines a risk as something that has not happened yet and an issue as something that already has: Risks vs. issues.

Dependencies between projects need their own layer because each project log records the dependency from its own side, in its own words. The same blocker then appears twice and neither project manager sees the chain. The programme layer holds one line per dependency: providing project, receiving project, committed date and the consequence of a miss.

A dependency line passes when both ends name an owner and quote the same date. If two project logs give different dates, the programme manager settles the date before the next board meeting. Dependencies on a supplier or team that serves several programmes belong at portfolio level, so keep this layer to the projects in your programme.

Here is one dependency line from the example later on this page.

In this illustrative example, a non-banking financial company (NBFC) runs a customer-onboarding programme of three projects with a combined budget of ₹18.5 crore and a planned benefit of ₹2.4 crore a year. The figures are our model, not data from a real programme.

Three of the seven flagged entries describe the same blocker (P2-I-05, P1-DP-02 and a P3 entry on its four regional batches), so they merge into one line, PG-I-03. That leaves five flagged lines. Three programme-only entries are added, giving eight lines on the programme log out of 25 entries in all (22 + 3). The board reads eight.

The ₹ exposure of PG-I-03 is our working, shown here.

The escalation flag is Y because the cost falls on three budgets and the cure is a senior call to the vendor. The three programme-only entries are PG-DP-01 (the same two vendor engineers promised to P1 and P2 testing in January, exposure to be sized by 15 Jan), a risk on the sponsor's approval of P3's second funding instalment, and a risk on the audit committee's calendar.

Project managers should review their logs weekly. The programme manager reviews the flagged lines and the programme-only layer before each programme board meeting, usually fortnightly or monthly. The board decides each escalated entry: accept it, reassign it, fund it or take it to the sponsor. These intervals are our recommendation; set them to the pace of the work.

Every entry marked Escalated should leave the meeting with a decision, an owner and a date. Decision rights are set out in our program governance framework; review the log at each gate of the program management life cycle too.

Four failures make a programme RAID log unreliable: it is filled in at kickoff and never reviewed, the same blocker is logged in several places, entries have no owner, and the visibility flag stops filtering. Each has a test.

• Never reviewed: sort by Last reviewed. Pass: no entry is older than one review cycle. Fail: close it or re-justify it at the next board.
• Duplicates: search the programme log for repeated causes. Pass: each blocker appears once, with Linked IDs to the project entries.
• Unowned: filter for Owner. Pass: every row names one person. A team name or "PMO" fails.
• Flag inflation: divide flagged project entries by all project entries. Fail: more than about one-third are Y, which means the flag no longer filters (our recommendation). Reapply the three-part rule.

A spreadsheet is enough while every project manager uses the same thirteen columns and one person can merge the flagged rows in less time than the review takes. Our recommendation: move to software when merging the flagged rows takes longer than the review, or when people need different access to different projects' entries. Start with one workbook: a tab for each project, a Programme tab and a Dependencies tab.

If you want the practice behind this log, Program Management Essentials is our 12-week foundation course. Its modules include Program Risk Management and Program Stakeholder Engagement. It is not PgMP® exam preparation.

A programme RAID log works when it stays small enough for one board meeting to decide. Keep one RAID version across every project. Let each project flag what the programme needs to see. Give every dependency between projects one line, with a named owner at both ends and one agreed date. When an entry changes type, close the old one and open a new one, so the log shows how long a doubt sat unconfirmed.

In our illustrative example, one unconfirmed assumption became a ₹77 lakh exposure across three budgets, and the programme layer is what let the programme manager see it. Your figures will differ, but the method holds. If you want a second opinion on your flag rules or merge process before the first roll-up, you can book a free discovery consultation with us.