Why a Living Outstanding-Items Register Beats a RAID Log

A client asks, three years into an engagement, exactly what’s been delivered against the original scope. If the honest answer lives across a RAID log, a folder of change request emails, and someone’s memory of a favour done last spring, that meeting is going to go badly. A Living Outstanding-Items Register (LOIR) exists to prevent it: one register that tracks formal requirement status, change requests absorbed into scope, and ad-hoc requests together, instead of splitting them across documents that were never built to talk to each other.

Why Does a RAID Log Fall Short on Long Engagements?

A RAID log does one job well: it tracks risks, assumptions, issues, and dependencies. On a project that runs for months, that’s a reasonable job to have.

On a project that runs for years, it isn’t enough. Requirements evolve. Change requests get discussed, agreed informally, and folded into the existing build without ever getting their own line item. Ad-hoc requests, the kind a stakeholder raises in a corridor conversation or buries in paragraph three of an email about something else, don’t get logged at all, because a RAID log has no column for them.

None of that missing information disappears. It just moves somewhere unofficial, usually a client email thread, which is its own extraction problem before you even get to tracking it. I’ve written before about pulling structured requirements out of a messy client email thread, and the same mess is exactly where ad-hoc requests go to hide when there’s no register built to catch them.

What Is a Living Outstanding-Items Register?

A LOIR keeps everything a RAID log tracks and adds what it doesn’t: continuously updated requirement status, absorbed change requests, and ad-hoc requests, all in one place. Think of it as the register that answers “what did we actually deliver,” a question a RAID log was never designed to answer.

Aspect	RAID Log	Living Outstanding-Items Register
Risks, assumptions, issues, dependencies	Tracked	Tracked, integrated with delivery status
Formal requirement status	Not included	Continuously updated
Change requests	Tracked separately, if at all	Integrated once absorbed into scope
Ad-hoc requests	Not tracked	Always included

The value isn’t the new categories on their own. It’s that everything sits in one register, so a client question about what changed six months ago has a single place to look, not four.

What Columns Does the Register Actually Need?

Keep the structure simple enough that people will actually fill it in. A working LOIR needs eight columns, no more:

Column	What it captures
Item ID	A unique identifier for the entry
Description	What the item, request, or requirement actually is
Type	Formal requirement, change request, or ad-hoc request
Status	Pending, in progress, or completed
Owner	The person or team accountable for it
Date logged	When it was first documented
Last update	The most recent status change
Comments	Context that explains the status, not just states it

Type and Owner are the two columns doing the real work here. Type is what lets you filter a years-long history down to “everything that started as a change request,” and Owner is what stops an item drifting for months because nobody’s name is attached to it.

How Do You Stop the Register From Becoming Another Graveyard Log?

RAID logs have a well-known failure mode: they get created, filled in for a few weeks, and then quietly ignored while the real decisions happen elsewhere. A LOIR fails the same way if you treat it as a document rather than a habit.

The fix is to put it inside rituals the team already runs, not alongside them. Review it in daily stand-ups or sprint planning, the same sessions where the work itself gets discussed, so updating the register is part of doing the work rather than a separate admin task someone does on a Friday afternoon.

In my experience, that’s the real difference a LOIR makes over a RAID log. It’s not just more thorough documentation, it changes how a team manages delivery day to day, because the register becomes something people check before making a decision rather than something they update after one.

What Cultural Shift Does a Living Register Require?

The bigger change isn’t the extra columns, it’s what goes in the Comments field. A RAID log rewards a good risk description. A LOIR rewards a named decision owner and a next action.

That’s a shift from passive monitoring to active unblocking. An entry that says “budget risk on the reporting module” is a RAID log entry. An entry that says “budget risk on the reporting module, owner: [name], next action: cost revised scope by Friday” is a LOIR entry, and it’s the second one that actually gets resolved instead of sitting there for a quarter.

What Belongs Beyond the Traditional RAID Categories?

A LOIR isn’t limited to risks, assumptions, issues, and dependencies. It also has room for the things that don’t fit those categories but still need a home:

• Critical decisions that were made and need a record of who made them and why
• Parked features that were discussed and shelved, not rejected outright
• Cross-team dependencies that don’t belong to either team’s own backlog

Without a register that explicitly makes space for these, they end up as tribal knowledge, remembered by whoever happened to be in the room, and lost the moment that person moves on.

Does It Replace Your Existing Tools?

No, and it shouldn’t try to. A LOIR is a high-level register, not a replacement for Jira, Linear, or GitHub Issues. It should sync with whichever of those your team already runs, so the register reflects execution-level detail without you maintaining two disconnected sources of truth.

That same instinct, putting a consolidated view in front of the people who need it, is what I’ve argued for with an executive delivery dashboard pulling from Jira and GitHub data. A LOIR is the same idea at the requirement and change-request level: one place that stays consistent with the tools doing the actual work.

How Do You Measure Whether It’s Working?

Item counts tell you how much is open. They don’t tell you whether the register is actually doing its job. Three metrics do:

• Lead time: how long an item sits from being logged to being resolved
• Cycle time: how long active work on an item actually takes
• Resolution velocity: how fast the team is clearing items overall

Track these and you can spot a bottleneck before a client asks why their change request from two months ago is still pending. Without them, a LOIR is just a longer list than a RAID log, not a better-managed one. The same logic that makes a three-column change request framework useful applies here: categorising honestly only pays off if you’re also watching how fast items move between categories.

How Do You Roll This Out?

1. Set up the eight columns in whatever tool your team already uses. A spreadsheet works on day one; you don’t need new software to start.
2. Sync it with your execution-level tool (Jira, Linear, or GitHub Issues) so the register and the actual backlog don’t drift apart.
3. Put it on the agenda for stand-ups or sprint planning, not as a separate meeting, so updating it is part of the existing rhythm.
4. Track lead time, cycle time, and resolution velocity from the start, so you have a baseline before you need one.

None of this requires new software or a heavier process than the RAID log it replaces. It requires the discipline to log ad-hoc requests the moment they surface, name an owner and a next action instead of just a description, and open the register in the same meetings where the work gets decided. A register nobody reopens is a RAID log with extra columns. One that’s part of the daily routine is the single place a client’s question about what was delivered actually gets answered.