Software projects are complex, dynamic, and full of uncertainties. To manage these uncertainties, project managers rely on structured tools like Risk Logs and RAID Logs. While they sound similar, they serve different purposes and complement each other in project governance.
🔹 Define Risk Log
A Risk Log (or Risk Register) is a document that records potential risks that may negatively impact a project. It ensures risks are identified, assessed, and mitigated before they become issues.
📑 Structure of a Risk Log (Mandatory Fields)
- Risk ID
- Risk Description
- Probability (High/Medium/Low)
- Impact (High/Medium/Low)
- Severity (Probability × Impact)
- Mitigation / Contingency Plan
- Owner
- Status (Open/Closed/Mitigated)
- Target Date
🔹 RAID Log
Definition
A RAID Log expands beyond risks. It tracks Risks, Assumptions, Issues, and Dependencies in one place, giving a holistic view of project health.
Structure (Mandatory Fields)
- Risks → Description, Probability, Impact, Owner, Status
- Assumptions → Statement, Validation Plan, Owner, Status
- Issues → Description, Resolution Plan, Owner, Status
- Dependencies → Description, Linked Task/Team, Owner, Status, Due Date
Detailed Example
Same mobile banking app project, RAID Log entries:
| Category | Description | Owner | Status | Action / Plan | Due Date |
|---|---|---|---|---|---|
| Risk | Server downtime during migration | Infra Lead | Open | Add backup server | 20 Sept |
| Assumption | Client will provide test data by 10 Sept | Client PM | Pending | Validate in kickoff | 10 Sept |
| Issue | Test environment not ready | QA Lead | Open | Escalate to infra team | 05 Sept |
| Dependency | Compliance approval required before go‑live | Compliance Officer | Pending | Submit docs early | 25 Sept |
👉 This log captures all blockers in one place, not just risks.
🔹 When to Use Each
- Risk Log → For deep risk analysis, compliance documentation, and executive reporting.
- RAID Log → For day‑to‑day project tracking, Agile ceremonies, and holistic visibility of blockers.
- Best Practice: Use both together — RAID for operational visibility, Risk Log for formal risk management.
🔹RAID LOGS Vs RACI Vs RACI Matrix
RAID logs track project risks and issues. RACI defines responsibilities. A RACI matrix is the table used to document those responsibilities.
| Aspect | RAID Log | RACI | RACI Matrix |
|---|---|---|---|
| Meaning | Risks, Assumptions, Issues, Dependencies | Responsible, Accountable, Consulted, Informed | A table applying RACI to tasks and deliverables |
| Purpose | Track uncertainty, problems, and dependencies | Clarify roles and decision ownership | Show who does what across the project |
| Key question | “What could affect delivery, and how are we managing it?” | “Who does the work and owns the outcome?” | “What is each person’s role for each task?” |
| Typical contents | Description, impact, owner, action, due date, status | Four role definitions | Tasks in rows, people or roles in columns |
| When used | Updated throughout the project | Agreed during planning and reviewed as roles change | Maintained as the project’s responsibility reference |
RAID log example — an e-commerce project
| Type | Example | Action |
|---|---|---|
| Risk | ERP integration might miss the launch deadline | Test connectivity early and agree a fallback |
| Assumption | Product data will be ready before migration | Confirm readiness with the data owner |
| Issue | Payment transactions are failing in testing | Assign a developer and track resolution |
| Dependency | Checkout testing requires payment gateway credentials | Track delivery with the gateway provider |
RACI Matrix Example
| Task | Project Manager | Tech Lead | Developer | Business Owner |
|---|---|---|---|---|
| Approve requirements | R | C | I | A |
| Approve technical design | C | A/R | C | I |
| Build integration | I | A | R | I |
| Approve business acceptance | R | C | I | A |
🎯 Conclusion
- Risk Log = deep dive into risks only.
- RAID Log = broader tool covering risks, assumptions, issues, dependencies.
- Combined Approach = ensures both breadth and depth in project governance.
Together, they form a powerful toolkit for proactive management, stakeholder trust, and successful delivery in software development.