Projects rarely fail from the risk everyone talked about. They fail from the thing everyone assumed.
What it is
A RAID log is a standard project-management tool. It's one list with four kinds of entries:
| Letter | What it is | Example |
|---|---|---|
| Risk | Something that might happen and would hurt | Supplier may raise prices |
| Assumption | Something we're treating as true without proof | Tooling arrives by May 1 |
| Issue | Something already going wrong | Prototype failed the drop test |
| Dependency | Something we need from someone else | IT has to open the firewall |
Each entry gets an owner, a date and a status.
The most valuable column is usually Assumptions. An assumption is a risk nobody has noticed yet.
Why people skipped it
Keeping a RAID log current is a chore. Assumptions are scattered through emails, meeting notes and chat. Someone has to read all of it and write them down. Usually nobody does after the first week.
How a bot does it
- Give the bot the project's paper trail. Meeting notes, emails, the charter, the schedule.
- Have it pull out every R, A, I and D. Especially assumptions hiding in sentences like "once the tooling arrives" or "assuming the customer signs off."
- Have it update the log, not rewrite it. New items added, old ones marked changed, with the source.
- Have it flag assumptions that are due. "Tooling arrives by May 1" is no longer an assumption on May 2. It's either true or an issue.
- A person reviews the changes each week. Five minutes.
The bot brief
Update the RAID log for [project].
Inputs: current RAID log [file]; new meeting notes and emails since [date] [files].
Find every risk, assumption, issue and dependency in the new inputs.
Pay special attention to hidden assumptions: phrases like "once", "assuming",
"should be", "they said", "by [date]".
For each: type (R/A/I/D), one-line description, source (file and date), suggested owner, due/check date.
Do not delete existing entries. Mark changed ones and say what changed.
Flag every assumption whose check date has passed: it must become CONFIRMED or an ISSUE.
Output: the changes only, then the full updated log.Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.
An example
From one week's meeting notes:
| Type | Entry | Source | Owner | Check by |
|---|---|---|---|---|
| A | Customer will accept the current drawing revision | "once they sign off on Rev C," notes 10/14 | Sales lead | 10/25 |
| A | Second-shift operator trained by launch | "Jim will train second shift," email 10/15 | Plant manager | 11/1 |
| D | Purchasing releases the steel PO | "waiting on PO," notes 10/14 | Purchasing | 10/20 |
| I | Fixture prototype doesn't hold tolerance | Test report 10/16 | Tooling engineer | — |
Nobody wrote "assumption" in any of those notes. The bot found them in the wording.
Where bots differ
A project manager knows which casual remark was a real promise and which was a hopeful guess. A bot can't always tell. It will over-collect, which is fine. A person can delete a non-assumption in a second. Missing one costs much more.
What this means for you
- Keep one RAID log per project.
- Have a bot update it from notes and email every week.
- Watch the assumptions most closely.
- When an assumption's date passes, it's confirmed or it's an issue. Nothing in between.