In any project, unknowns are inevitable, but they don’t have to become crises. A RAID log—Risks, Assumptions, Issues, and Dependencies—consolidates everything that can affect delivery into a single, living document. When kept up‑to‑date, the log turns “what‑ifs” into manageable items and gives the team a clear view of what needs attention each week.
Risks
Risks are events that might happen but haven’t yet. For each risk record the likelihood (e.g., low, medium, high) and the potential impact (e.g., schedule slip, cost overrun). A risk entry is useless without a mitigation plan: describe what you will do to reduce either probability or impact. Example: “Delay in third‑party API delivery could push integration testing by two weeks; mitigation: negotiate a fallback stub and schedule weekly status calls with the vendor.”
Assumptions
Assumptions are statements taken as true but not yet verified. Typical examples include “the vendor API will be ready by June” or “the new library will be compatible with our existing codebase.” Treat every assumption as a hidden risk: validate it early, and if validation fails, promote it to a risk or issue with an appropriate response.
Issues
Issues are risks that have already materialized. They require immediate action, an owner, and a due date. For instance, “the API endpoint returned 500 errors during testing” becomes an issue with a designated developer responsible for fixing it by a specific sprint. Logging an issue without follow‑up leads to a backlog of forgotten problems, so the RAID log must show the current status and next steps.
Dependencies
Dependencies are work items that your team relies on from outside sources—another team, a vendor, or a shared platform. Capture the needed‑by date and the responsible party. If a dependent component slips, the log highlights the breach before it blocks your own work. Example: “Database schema migration required from the infrastructure team by 10 Oct; owner: infra lead; risk of delay: medium.”
Do / Avoid
Do
- Review the RAID log weekly, not just at kickoff.
- Assign an owner to every item, not just a description.
- Convert realized risks into issues immediately.
Avoid
- Let assumptions sit unvalidated for the whole project.
- Log a risk without attaching a mitigation plan.
- Treat RAID as a one‑time kickoff document.
Keep the RAID log simple, actionable, and current, and the “unknowns” will stop catching you off guard.
Top comments (0)