The 9:40 update

The steering call is at ten. At 9:40, the delivery lead opens the RAID log and starts refreshing rows. Row 14, dependencies: "Platform API — on track," carried forward from the last three updates. Except Platform re-scoped that API ten days ago, mentioned it in their own standup, and moved on. Nothing was hidden. The information just lived in another team’s Jira, and a register only learns what someone remembers to type into it.

By the time the log says "at risk," the slack is gone. The log wasn’t wrong. It was late.

What a RAID log gets right

RAID logs earn their place. Risks, assumptions, issues, dependencies: naming all four at planning is real discipline, and it is exactly the evidence a team weighs when it commits to a date. When a room full of engineers votes its confidence on a release, that vote is expert judgment — and the RAID log is a large part of what the judgment stood on. Teams that keep one plan better than teams that don’t.

So this isn’t an argument against the register. It’s an argument about what happens to it after the commitment.

The refresh-rate problem

A register records; it doesn’t watch. Most RAID logs update on meeting cadence — weekly if you’re disciplined, the night before steering if you’re honest. Between edits, the three things that erode a committed release date keep moving at their own speed.

The D column goes stale first. A dependency is a promise someone else made, and other teams re-plan without consulting your spreadsheet — especially the dependencies that live in someone else’s backlog. The R column fails more subtly: a RAG status that is re-asserted at each meeting rather than derived from data tends to stay green while the date underneath it quietly moves. It’s the same decay that turns the SAFe program board into an artifact of planning day — accurate for one afternoon, decorative after that.

And capacity — the third eroder — usually isn’t a RAID column at all.

Keep the R and the D live in Jira

In Jira, risks and dependencies don’t have to be rows that someone retypes. Release Management, Roadmaps, Portfolio PPM & Timeline derives both from the work itself.

Dependencies are Jira links — hard or soft — sitting on a computed critical path with visible slack. When a linked item moves in another team’s plan, the committed date re-forecasts immediately, in days, not at the next steering call.

Risk stops being a value someone asserts and becomes a reading. The committed date is carried with its confidence — June 7 at 85%, say — on a 50/85/95% band derived from the team’s real throughput. On or after P85: green. Between P50 and P85: amber, and time to renegotiate scope, resequence a dependency, or adjust capacity while there is still slack to trade. Below P50: red — and you’re re-planning in week two, not discovering it in week six.

The team still owns the A column, and that’s by design. Which throughput window to trust, whose capacity is really in, what is actually in scope — those assumptions are the team’s judgment, exactly as they were at the vote. The app does the arithmetic at Monte Carlo scale and keeps it current. (See how the four RAID columns map onto live tracking in the docs.)

What to keep the log for

Keep the register — for what registers are good at. Assumptions and decisions are narrative: they need an owner, a date, and a sentence of context, and they are invaluable in audits and handovers. Issues already live in Jira. But the two columns that decay fastest between meetings, the R and the D, deserve better than a Tuesday-night refresh.

A RAID log is memory. It was never a radar.

Your register, still green?

If the log says "on track" and it’s been eleven days since anyone edited row 14, the honest answer is: nobody knows. Put the R and the D on live data instead — see your committed date with its confidence on your next Fix Version, free for 30 days. It Runs on Atlassian, so your Jira data never leaves Atlassian.

Frequently asked questions

What does RAID stand for in project management?

Risks, Assumptions, Issues, and Dependencies — the four sections of a RAID log. Risks are events that could hurt the plan; assumptions are things believed true but not yet proven; issues are problems active right now; dependencies are work that relies on another team or outside party. Some organizations use the D for Decisions instead and track dependencies elsewhere.

What’s the difference between a RAID log and a risk register?

A risk register tracks the R alone; a RAID log adds assumptions, issues and dependencies. Both are registers, so both share the same limit: they are accurate as of the last edit. For release work in Jira, the two fastest-moving columns — risk status and dependency state — can be derived live from the work itself and read against the committed date, which is what keeps a commitment honest between meetings.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio