RAID Log Manager

The problem this kills

You ran a great kickoff. Someone built a beautiful RAID log — Risks, Assumptions, Issues, Dependencies — every item with an owner, a status, a due date. For two weeks it was the heartbeat of the project. Then it died. Owners stopped touching their rows, statuses went stale, the "high" risk from March is still open and nobody has looked at it since. By the time a risk becomes a problem, the log is the last place anyone trusts.

The reason RAID logs die is boring: nobody is responsible for keeping them alive. There is no cadence, no nudge, no gentle pressure on the owner of item 14 to review it. So you end up chasing people in standups, copy-pasting the same "can you update your RAID items?" message, and quietly rebuilding the log from memory before each steering committee. And when entries do change, they change in the spreadsheet with no record of who changed what or whether anyone agreed to it.

This is exactly the kind of small, rules-driven discipline that a tiny internal tool enforces better than any spreadsheet — and you do not need to be a developer to build it.

What you'll build

A simple internal web tool that makes your RAID log self-sustaining. You import your existing RAID list (or start fresh) and a list of people. Every item has a type (Risk, Assumption, Issue, or Dependency), an owner, a status, a due date, and a review cadence — how often that item needs a fresh look. The tool watches the clock: when an item passes its review-by date, it flags it as overdue for review and emails the owner a nudge so it never silently goes stale.

New entries and status changes don't just drop into the log. AI helps draft them — cleaning up the wording, suggesting the type and severity, catching likely duplicates — but the change sits as a proposal until an owner reviews and approves it. Only then is it committed to the live log. At any point you can export the whole thing as a clean CSV in the exact columns your PMO template expects.

What's inside the Implementation Plan

The plan is a single file you paste into an AI coding agent. It opens by interviewing you about your business — which RAID columns and statuses you actually use, how you name and identify your projects, who your owners are, what review cadence each RAID type should have, your approval rules, and your messy edge cases — and then tailors the data model, the required fields per type, the cadence rules, and every later step to your answers. This is a tool shaped around how your PMO runs, not a generic template.

From there it walks the agent through the database schema, importing your RAID list and people, the per-type required-field validation, the overdue-for-review engine and owner nudges, the propose-and-approve flow for new entries and status changes, and the CSV export. Every step ends with a ready-to-copy prompt. Because it runs on CSV in and clean CSV out, you can build and use it this weekend even if you have no connection to your existing project tools.

The governance it includes (this is the point)

The whole value here is that the log stays trustworthy, so it's built like it matters: login so only your project team can use it, row-level security so people only ever see their own organization's projects, and a complete audit trail of every entry, edit, status change, approval, and nudge — who did what, and when. Nothing changes the live log automatically: a new entry or a status change is a proposal until an owner approves it, and that approval is the hard human-in-the-loop gate. Duplicate guards on project + type + normalized title stop the same risk from being logged twice under slightly different wording.

Who it's for

Project managers, PMO leads, and delivery managers who own a RAID log across one or many projects and are tired of watching it rot after kickoff. If you can describe how your team reviews risks and who's allowed to sign off on a status change, you can build this.

You've got this — open the plan, paste the first prompt, and let it interview you about how your projects actually run.