RAID Log: How to Catch Budget and Resource Risks Before the Report Turns Red

A RAID log lists a project's Risks, Assumptions, Issues and Dependencies, each with an owner, a next action and a date. It goes stale because it is filled from memory after meetings, while the risks are said inside them: a vendor's price that "may go up", an engineer at 140% load. Fill it from the meetings the same day, and let a written rule set the status. Averages hide the danger: across 1,471 IT projects the mean cost overrun was 27%, but one in six overran by 200% on average. In our three-meeting demo, the rule turned amber two weeks before the report did.

What a RAID log holds

A RAID log is one table with four kinds of rows. Each row has the same columns: what was said, who owns it, the next action and its date, and where it came from.

Rows move between columns. An assumption that breaks becomes an issue; a risk that happens becomes an issue. A log where nothing moves for three weeks is not being read. Some teams read the D as Decisions; the method below works the same either way.

Why the log stays green while the project is not

The risks of a project are rarely hidden. They are said aloud in status meetings, often by the person who will feel them first, and then left out of the written report. Researchers call it selective status reporting: in a survey of 561 project managers, optimistic biasing of status reports degraded reporting quality, and reporting quality was linked to how projects performed (Iacovou, Thompson & Smith, MIS Quarterly, 2009).

Practitioners have a name for the result: a "watermelon project", "green on the outside, red on the inside" (Hacker News, 2023).

The cost is in the tail, not the average. In a sample of 1,471 IT projects, the average cost overrun was 27%, but one in six projects overran its cost by 200% on average and its schedule by almost 70% (Flyvbjerg & Budzier, Harvard Business Review, 2011). A risk said aloud in week one is how a project starts its way into that sixth.

Three status meetings, one project

Here is a demo project: Harrow & Pine, an outdoor-gear retailer, moves its online store to a new commerce platform. Launch is Monday, November 9; the holiday code freeze starts November 16. On the weekly status call: Elena, the project manager; Dmitri, the lead engineer; Nate, QA; Rosa, e-commerce; Kofi, who builds the live stock feed from the warehouse system; and, in week one, Tom from the platform vendor. Gwen, the sponsor, reads Elena's status every Thursday. The people and the company are fictional; the calls were written as real ones. MeetWave's Deep Summary wrote the notes of weeks one and two, and every frame below is cut from them.

Week 1: the vendor's price "may go up"

At 01:41 Tom, the vendor's account manager, says the licence price for their order-volume tier is being reviewed for the February renewal: "it may go up… somewhere around fifteen to twenty percent." At 02:16 Dmitri does the sum aloud: they pay ninety-six thousand a year, "so that's like fifteen to twenty grand a year more." At 03:19 Elena closes it: "let's keep an eye on it." At 08:24 she reports the project green (demo notes).

Figure 1. Demo meeting, people are fictional. Week 1: the price signal and the first sign of overload, as risks, while the report says green. Source: demo status meeting, week 1 notes, September 2026.Analyzed with MeetWave·See the full notes·Try it on your next status meeting

The notes put the price on the risk list with what is being done about it: wait for the vendor's number. That is the moment to act on. A risk whose only action is "wait for someone outside the team" has no owner on your side. The RAID row reads: licence +15–20% from February, about $14,400–$19,200 a year (the notes' own arithmetic); owner Elena; action: get the number in writing and tell the budget holder now, before the number is final (demo notes).

The same block holds a second risk Dmitri said in passing at 06:37: he is on call for the old site and helping the warehouse team, "pretty full". It is a red dot in the notes and nothing in the report.

Week 2: 140% load and a slipping dependency, still green

At 00:56 Kofi says the stock feed will not land on October 9: the warehouse location codes do not match the ERP. Realistic is October 20, maybe the 22nd. At 01:41 Dmitri does the arithmetic out loud: three weeks of integration testing from October 20 ends November 10, and launch is November 9. At 03:37: "Honestly, I'm at about a hundred and forty percent right now." At 05:47 Elena: "I'm going to keep us green" (demo notes).

Figure 2. Demo meeting, people are fictional. Week 2: the resource risk with its number, and the single person a dependency rests on. Source: demo status meeting, week 2 notes, October 2026.Analyzed with MeetWave·See the full notes·Try it on your next status meeting

The notes did two things the report did not. They kept the load as a number, 140%, with the three jobs behind it and the fact that the fix (handing on-call to someone else) was not confirmed. And they found a second risk nobody named as one: Kofi's team needs Dmitri for the mapping because nobody else knows the old stock sync (demo notes).

Figure 3. Demo meeting, people are fictional. Week 2: the green status is reported before the date it depends on is known. Source: demo status meeting, week 2 notes, October 2026.Analyzed with MeetWave·See the full notes·Try it on your next status meeting

This is the line to take into the sponsor update: the status is decided on Thursday, the date it depends on arrives on Friday, and even the best case is a day late. The formula for the reader: when a dependency moves, add the work that follows it to the new date and compare with the deadline. If the result is past the deadline, the status is red, even if the gap is one day (demo notes).

Week 3: the date moves

At 00:32 Kofi moves the feed again, to October 27. At 01:07 Dmitri: three weeks from the 27th is November 17, a day into the freeze. At 01:27 Elena: "So we're red." A nightly stock file instead of the live feed is rejected at 02:00: on Black Friday it would sell stock they do not have. At 03:13 the launch moves from November 9 to January 11 (transcript minutes).

Then the cost of the two risks from weeks one and two arrives at once. The on-call hand-off agreed in week two did not happen (03:53), and Dmitri is "still at a hundred and forty percent". The fix is a contractor for eight weeks at $1,800 a week, $14,400, which needs Gwen's approval by October 16 (04:48–05:03). The forecast is about $534,000 against a $480,000 budget, roughly 11% over (05:25). The vendor's written price came: $96,000 to $113,000 a year, held at $96,000 only with a two-year term signed by October 31 (05:49) (transcript minutes).

Nothing in week three was new. Each piece had been said aloud one or two weeks earlier.

From notes to the RAID log

Each block of the meeting notes has one home in the log. The point is to copy, not to rewrite: the log keeps the words and the number as they were said.

Source: block names from MeetWave's Deep Summary notes of the demo series.

Here is the log for the demo project after week three. Every row points to the meeting and the minute it was said.

Source: demo status meetings, weeks 1–2 notes and the week-3 call; minutes are the transcripts' (how we calculated).

The RAG rule that keeps status honest

A status color set by feeling follows the project manager's hope. A color set by a rule follows what was said. Three lines are enough:

• Green: every risk said aloud has an owner and a next action with a date, and every date on the critical path holds.
• Amber: a risk said aloud has no owner or no action, or someone said they are over capacity and nothing has been taken off them.
• Red: a date or an amount on the critical path moved, and the slack left cannot absorb it.

Figure 4. The same three weeks of the fictional demo project, colored by the report and by the rule. Source: MeetWave demo status meetings, minutes from their transcripts, September–October 2026.

Applied to the demo, week by week (demo notes):

• Week 1, reported green, by the rule amber: the price risk was said at 01:41 and its only action was waiting for the vendor.
• Week 2, reported green, by the rule red: the feed moved, and October 20 plus three weeks is November 10, past the November 9 launch (01:41).
• Week 3, reported red, by the rule red: the launch moved to January 11 (03:13).

By the rule, Gwen would have seen amber two weeks and red one week before she did, while there was still time to approve help or move the date calmly.

The sponsor brief, from the same notes

A sponsor does not need the log. They need what is asked of them, what moved, and what to watch. Here is Elena's brief for Thursday, October 15, written only from what was said in the three meetings:

Subject: Store replatform: red. Launch moves to January 11; two decisions needed from you

Needed from you: (1) Approve a contractor for 8 weeks, $14,400, by Friday, October 16, so the agency can start October 19. Without it, our lead engineer stays at about 140% load for two more months. (2) Decide on the licence renewal by October 31: the price goes from $96,000 to $113,000 a year in February, or stays at $96,000 with a two-year term (which locks us in for two years).

Moved against plan: launch November 9 → January 11, because the live stock feed moved from October 9 to October 27 and three weeks of testing no longer fit before the November 16 freeze. Forecast: about $534,000 against $480,000, roughly 11% over (two more months of the team plus the contractor).

What to watch: the feed on October 27. Kofi posts a daily update at 5 pm; if the 27th slips, January 11 is at risk too.

What I should have said earlier: the price signal came on September 29 and the 140% load on October 6. Both were reported green. From today, the RAID log is updated the same day as the status meeting.

Source: demo status meetings and the week-3 call (how we calculated).

How often projects overrun budget and time

Most projects overrun something; a few overrun by multiples. A review of software estimation surveys found that 60–80% of projects ran over effort or schedule, with average overruns of 30–40% in the surveys reviewed (Moløkken & Jørgensen, ISESE, 2003). The same review warns that the much-quoted 89% average from the Standish Chaos report is far above what other surveys found.

The tail is what ends careers and budgets: in the 1,471 IT projects Flyvbjerg and Budzier studied, the mean cost overrun was 27%, while one in six projects overran cost by 200% on average and schedule by almost 70% (Flyvbjerg & Budzier, 2011). Their database holds projects whose data the authors could obtain, not a random sample.

We did not use the often-repeated "only N% of projects finish on time and on budget" figures: we could not open a method behind them.

Template: RAID log and RAG rules

Copy the table into a spreadsheet or your project tool. One row per item; never delete a row, close it.

ID,Type,What was said (words and number as said),Said in (meeting, minute),Owner,Next action,Due,Status,Closed (date, how)
R1,Risk,,,,,,Open,
A1,Assumption,,,,,,Open,
I1,Issue,,,,,,Open,
D1,Dependency,,,,,,Open,

The RAG rule, to paste under the log:

Green: every risk said aloud has an owner and a next action with a date, and every date on the critical path holds.

Amber: a risk said aloud has no owner or no action by the end of the meeting, or someone said they are over capacity and nothing has been taken off them.

Red: a date or an amount on the critical path moved, and the slack left cannot absorb it. Check it with arithmetic: the new date of the dependency, plus the work that follows it, against the deadline.

The status is set by the rule after each status meeting, before the report is written. If you report a different color, write why next to it.

For the agenda and notes of the status meeting itself, the free meeting minutes template has a Team/Project variant with a filled status-meeting example.

Recording status meetings: consent first

Record a status meeting only when everyone on it agrees, and say so at the start; in some US states every party must consent, and in the EU a recording of a person is personal data under the GDPR (GDPR, Article 4). Without a recording, the method still works: write the risks, the numbers and the dates as they were said, within an hour of the meeting, and fill the log from those notes. This is not legal advice.

Key numbers

• In a sample of 1,471 IT projects, the average cost overrun was 27%, but one in six overran cost by 200% on average and schedule by almost 70% (Flyvbjerg & Budzier, Harvard Business Review, 2011).
• 60–80% of software projects ran over effort or schedule, with average overruns of 30–40%, in a review of estimation surveys (Moløkken & Jørgensen, 2003).
• In a survey of 561 project managers, optimistic biasing degraded the quality of status reporting (Iacovou, Thompson & Smith, MIS Quarterly, 2009).
• In our three-meeting demo (September–October 2026), the RAG rule gave amber in week 1 and red in week 2; the report said green both weeks (demo notes).

How we calculated

• The demo series is three fictional weekly status meetings, 8–10 minutes each, written for MeetWave's test set; the risks they should contain were written before the transcripts. MeetWave's Deep Summary wrote the notes of weeks 1 and 2 once each (October 2026); Figures 1–3 and the linked notes are those runs, unedited.
• Week 3 has no notes here: its run did not complete, so the week-3 paragraphs, the log rows marked Wk 3 and the sponsor brief come from the week-3 transcript, with its minutes.
• Minutes are the transcripts' timestamps, [mm:ss] from the start of each call.
• $14,400–$19,200 is 15–20% of the $96,000 licence, as written in the week-1 notes. 11% over is $534,000 ÷ $480,000, as said in week 3.
• The rule's colors apply the three RAG lines above to what was said in each meeting; the reported color is what the project manager said she would report.

FAQ

What is a RAID log?

A RAID log is a project table of Risks, Assumptions, Issues and Dependencies, each row with an owner, a next action and a date. It is updated after every status meeting and read before every status report. See what a RAID log holds.

What is the difference between a RAID log and a risk register?

A risk register holds only risks: things that may happen. A RAID log holds the risks plus the assumptions the plan rests on, the issues that already happened and the dependencies outside the team. When a risk happens, it moves from the R column to the I column of the same log.

What does RAG status mean?

RAG is Red, Amber, Green: the color of a project's status. It is honest only when a rule sets it. A simple one: green when every risk said aloud has an owner and an action; amber when one does not; red when a critical-path date or amount moved past the slack. See the RAG rule.

Does the D in RAID stand for dependencies or decisions?

Both are in use. Most guides read it as Dependencies; some teams use Decisions. If you track decisions, keep them in the meeting notes and put only the dependencies they create in the log.

How often should a RAID log be updated?

After every status meeting, the same day. A risk said aloud on Tuesday that appears in the log on Friday has already missed one report.

Sources

1. Flyvbjerg, B. & Budzier, A. — Why Your IT Project Might Be Riskier Than You Think. Harvard Business Review 89(9): 23–25 (2011); author preprint on arXiv. Accessed 2026-10-26.
2. Iacovou, C. L., Thompson, R. L. & Smith, H. J. — Selective Status Reporting in Information Systems Projects: A Dyadic-Level Investigation. MIS Quarterly 33(4): 785–810 (2009). Accessed 2026-10-26.
3. Moløkken, K. & Jørgensen, M. — A Review of Surveys on Software Effort Estimation. Proceedings of ISESE 2003, IEEE, 223–231 (2003). Accessed 2026-10-26.
4. Hacker News — comment on "watermelon" projects (2023). Accessed 2026-10-26.
5. Regulation (EU) 2016/679 (GDPR) — Article 4 (2016). Accessed 2026-10-26.