RAID Log vs Issue Log: Why Most Teams Only Need One

I once inherited a program that ran an issue log and a RAID log at the same time. Different owners, different tools, different review meetings.

In week three a vendor delay showed up as an issue in one and a dependency in the other, with two different owners and two different due dates. Both were being worked. Neither owner knew about the other. The delay was three weeks old before anyone put the two entries side by side.

That is the whole argument against running both. It is not that either artifact is wrong. It is that the same fact lands in two places and the program stops having one answer.

The short version

• An issue log tracks what is already broken. One category, present tense, every entry needs an owner and a resolution date. Narrow and deep.
• A RAID log tracks what is broken plus what might break. Risks, Assumptions, Issues, Dependencies. The issue log is one of its four sections. Broad and shallower.

A RAID log contains an issue log. That is the part most teams miss when they set up both.

What an issue log is for

An issue is something that has already happened and is costing you now. The environment is down. The vendor missed the date. The integration test fails and nobody knows why. Present tense, actual damage.

An issue log is good precisely because it is narrow. Every row is the same kind of thing, so the review is fast and the format can be strict: what broke, who owns it, what it blocks, when it clears. No scoring, no probability, no judgment calls. An issue either is or is not resolved.

That narrowness makes it the right instrument in exactly one situation, and it is a common one: incident-heavy operational work where nearly everything on the list is present tense. Support escalations, migration cutovers, stabilization periods after a launch. There, a RAID log's other three sections sit empty and get in the way.

Who reviews an issue log

Whoever can unblock it, usually daily, usually standing up. Issue reviews should be short and slightly uncomfortable.

What a RAID log is for

A RAID log's job is to hold the forward-looking categories next to the present-tense one. Risks are what might break. Assumptions are what you are betting on without proof. Dependencies are what you need from someone who does not report to you. Issues are what already broke.

The value is in the adjacency. Most issues on a mature program were a risk, an assumption, or a dependency first. A vendor delay was a dependency before it was an issue. A failed integration was an assumption about an API contract before it was an issue. Keeping the four categories in one artifact means you watch things move between them, and that movement is the actual signal.

An issue log alone cannot show you that. It only starts recording after the damage. By definition it is a lagging instrument.

Who reviews a RAID log

The program team, weekly, fifteen minutes. Four sections, named owners, and the only question that matters: what moved since last week.

The honest comparison table

When an issue log alone is the right call

• Cutover and stabilization windows. During a two-week migration, nearly everything is present tense. Run the issue log daily and pause the RAID review until the dust settles.
• Operational and support-shaped work. If the team's job is responding rather than delivering, the forward-looking sections stay thin and the ceremony is not worth it.
• Programs under about eight weeks. There is not enough runway for a risk to mature into an issue. By the time you would have caught it, it has already landed.

When you need the full RAID

• Multiple workstreams with cross-dependencies. The D section is the whole reason. Dependencies between teams are where multi-workstream programs actually fail, and an issue log has nowhere to put them until they are late.
• Anything with a vendor or an external party. External commitments are dependencies for months before they become issues for a week.
• Programs where you inherited the plan. The assumptions section is how you find out what the previous PM was betting on. Half of them will be undocumented and one of them will be wrong.
• Anything longer than a quarter. Runway is what makes forward-looking categories pay off.

The most common failure mode

Running both, which is what my inherited program was doing.

It rarely starts as a decision. A team has an issue log from an operational past. A new PM arrives and stands up a RAID log because that is the discipline. Nobody retires the issue log, because it is somebody's tool and it still works. Now the same vendor delay exists twice, and the two copies drift within a fortnight.

The second failure mode is quieter: keeping the full RAID but only ever reviewing the I. The R, A, and D sections are there in the file, untouched since kickoff, while the weekly meeting works the issue list. That is an issue log with three columns of decoration, and it has all the lag and none of the warning.

The fix for both is the same. Pick one artifact. If it is the RAID log, the issue section can still run on its own daily cadence during a bad week. What it cannot do is live in a second file.

Practical setup

1. Count the present tense. Look at your current list. If more than about 70% of entries are things that have already broken, an issue log is your artifact. Below that, run the full RAID.
2. If you already run both, migrate rather than merge. Move every open issue into the RAID log's issue section, then archive the old log read-only. Do not leave it writable. It will be written to.
3. Split the cadence, not the file. Issues daily during a hot period, all four sections weekly. Same artifact, two review rhythms.
4. Watch for promotion. Once a month, look at the issues that landed and ask which section they were in first. If the honest answer is "none," your risk and dependency sections are not being worked.

A worked example: the vendor delay

Here is the entry from the program I inherited, in both artifacts, on the same Tuesday.

In the issue log: "Vendor integration delivery late. Owner: Marcus. Blocks: UAT start. Target resolution: 15 March." Present tense, actionable, correct.

In the RAID log, dependency section: "Vendor API contract required by 1 March for UAT. Owner: Dana. Status: at risk." Also correct. Logged six weeks earlier, while it was still a future problem.

Both entries were being worked. Marcus was chasing delivery. Dana was chasing the contract. Neither knew the other existed, because the two artifacts had different owners and separate review meetings.

The instructive part is the timeline. The dependency was flagged at risk on 20 January. It became an issue on 3 March. That is six weeks in which somebody could have escalated, and nobody did, because the person holding the early warning was not in the meeting where escalations happened.

One artifact would have caught it. The dependency and the issue would have sat two lines apart, in the same fifteen-minute review, in front of the same people. The vendor would still have been late. The six weeks of silence would not have happened.

Questions PMs ask

What actually separates a risk from an issue?

Tense, and nothing else. A risk has not happened and carries a probability. An issue has happened and carries a cost. The moment a risk lands, rewrite it as an issue and close the risk row with a pointer to it. Teams that leave both open end up double-counting their own exposure and reporting it to a steering committee.

Where do assumptions go if we only run an issue log?

Nowhere, and that is the cost. Most teams running an issue log alone keep assumptions in someone's head or buried in the charter, where they are never revisited. If you are going to run issues only, re-read the charter's assumptions once a month and treat that as the substitute.

Our PMO mandates an issue log. Can we still run RAID?

Yes. Run the RAID log as the working artifact and export the issue section into whatever format the PMO wants. What you must not do is maintain two sources by hand. Export, do not duplicate. The moment a human is retyping between them, they will drift.

How big should a RAID log get?

If the weekly review cannot cover it in fifteen minutes, it is too big, and the usual cause is that closed items were never archived. A RAID log is a working document, not a permanent record. Archive aggressively and keep the closed rows on a separate tab.

The bottom line

An issue log is a RAID log with three sections removed. That is a legitimate choice for stabilization work and short programs, where the removed sections would sit empty anyway. It is a bad choice for anything with runway, because it can only tell you about damage you have already taken.

Run one. If you are running both today, the vendor delay is already in there twice.

The issue log tells you what hit you. The RAID log tells you what is coming. You get to be surprised, or you get to be ready.