Purpose
The RAID Log Template (Shell) provides Project Managers with a structured format to capture, monitor, and manage four critical categories of project control: Risks, Assumptions, Issues, and Dependencies (RAID). This template ensures lean project teams (1–3 members) can systematically record uncertainties, commitments, and blockers from the earliest phases of a project, while maintaining traceability throughout the lifecycle.
Without a RAID log, projects risk losing visibility over commitments, ignoring assumptions that later prove invalid, or reacting too late to dependencies and risks. By consolidating these elements into a single template, the RAID log serves as a proactive control tool rather than a reactive record. It forces clarity on ownership, status, and response actions, enabling accountability and informed decision-making.
For Memorres, where projects often run with lean staffing and tight client timelines, the RAID log ensures small teams do not overlook crucial governance details. It provides visibility to sponsors, PMO, and stakeholders while remaining lightweight and execution-ready. This shell includes placeholders and example entries to guide new PMs and standardize documentation across projects.
Scope
This template applies to all projects initiated and managed under the Memorres Project Management Department. It is mandatory for every project to create and maintain a RAID log in MIC, beginning at initiation and continuing until closure. The RAID log supports planning, execution, and monitoring activities, serving as both a living document and an evidence trail for audits and retrospectives.
The scope of the RAID log includes:
- Risks: Potential events that could negatively impact objectives if they materialize.
- Assumptions: Hypotheses accepted as true without proof at the time of planning.
- Issues: Events or problems already occurring that threaten project success.
- Dependencies: External or internal conditions that must be met for progress.
This template excludes detailed mitigation plans, escalation workflows, or portfolio-level dashboards, which are covered in separate MIC documents. The RAID log must be owned and updated by the Project Manager, with responsibility for validation shared with the Project Sponsor and PMO.
Main Section
Table 1: Risks
| ID | Risk Description | Impact | Likelihood | Owner | Response Strategy | Status | Example |
| R-001 | Client SME may not be available during requirement workshops | High | Medium | Project Manager | Escalate to Sponsor if unavailable >2 days | Open | R-001 logged 01-Sep-2025 |
Table 2: Assumptions
| ID | Assumption | Impact if False | Validation Method | Owner | Status | Example |
| A-001 | All APIs will be provided by client within 2 weeks | Delayed integration | Confirm with client technical team | Tech Lead | Open | API delivery expected 15-Sep-2025 |
Table 3: Issues
| ID | Issue Description | Impact | Owner | Resolution Action | Target Date | Status | Example |
| I-001 | Kickoff meeting delayed due to sponsor availability | Moderate | Project Manager | Reschedule with alternate slot | 07-Sep-2025 | Closed | Delay resolved with new date |
Table 4: Dependencies
| ID | Dependency | Impact if Delayed | Owner | Monitoring Method | Status | Example |
| D-001 | Vendor must deliver test environment by 10-Sep-2025 | High – blocks testing phase | Vendor Manager | Weekly vendor call | Open | Awaiting environment setup |
Approval Record
| Approver | Role | Signature/Date | Example |
| [Sponsor Name] | Project Sponsor | [Signed] 01-Sep-2025 | CIO sign-off |
Closing Note & Cross-References
The RAID Log Template ensures risks, assumptions, issues, and dependencies are not only documented but actively managed. It must be updated continuously by the Project Manager and reviewed in status meetings. As projects progress, mitigation actions, validation of assumptions, and resolution of issues should be tracked directly in this log, ensuring no governance element is left unmanaged.