Set up a RAID log that captures risks, assumptions, issues and dependencies in one control tool.
Project Management
Managing Project Assumptions, Issues and Dependencies with RAID Logs
A practical course on setting up and running a RAID log that captures risks, assumptions, issues and dependencies as one disciplined control tool rather than four disconnected lists.
🗓️Duration5 training days
📚Content4 modules · 8 sessions
🎓On completionAccredited attendance certificate
About the programme
Course Overview
A risk register on its own misses three things that derail projects just as often as risk itself: an assumption nobody checked before building a schedule on top of it, an issue that has already happened but has no owner driving it to resolution, and a dependency on another team or project that surfaces only when a deadline is missed. The RAID log brings all four together, risks, assumptions, issues and dependencies, as a single disciplined control tool, and this course concentrates on running it well rather than simply formatting the template. Sessions work through capturing assumptions in a form that can actually be tested and closed, converting a vague concern into an issue with a named owner and a target resolution date, and mapping dependencies across teams and other projects so a delay is visible to everyone it affects before it causes damage. Equal weight goes to the discipline a RAID log needs to stay useful: a regular review rhythm, criteria for moving an item between categories as circumstances change, and language for escalating an item that is not being resolved. The course closes with a RAID log structure built for participants' own project, and habits for keeping it a living tool rather than a document updated once and forgotten.
Expected Learning Outcomes
Write assumptions in a testable form and assign an owner to confirm or correct each one.
Convert a vague concern into a tracked issue with a named owner and a target resolution date.
Map dependencies on other teams or projects so a delay is visible before it causes damage.
Reclassify a RAID item correctly when an assumption fails or a risk becomes an active issue.
Run a regular RAID review that closes stale items instead of letting the log grow indefinitely.
Escalate an unresolved issue or dependency with enough detail to prompt a timely decision.
Who Should Attend
Project managers and coordinators responsible for maintaining a project's RAID log.
Programme management office staff standardising RAID log practice across several projects.
Business analysts who capture assumptions and dependencies during project definition.
Team leads managing dependencies between their own team and other parts of a programme.
Project support officers who track and chase RAID items on behalf of a project manager.
Anyone inheriting a project's RAID log who needs to bring it up to a usable standard.
Course Modules
Select any module to see its sessions and points.
01Structuring the RAID Log
2 sessions · 8 points
Session 1Designing a RAID Log That Gets Used
- Design a RAID log structure with fields for owner, status, target date and next action.
- Decide which categories of information belong in the RAID log rather than a separate register.
- Set entry criteria so items are captured consistently rather than depending on individual habit.
- Choose a review cadence appropriate to the pace and risk profile of the project.
Session 2Distinguishing Risks, Assumptions, Issues and Dependencies
- Distinguish a risk that has not yet occurred from an issue that has already happened.
- Separate a genuine assumption from a decision that has already been made and should be confirmed.
- Identify a dependency that belongs in the log because another party's action controls the timeline.
- Resolve borderline cases where an item could reasonably sit in more than one RAID category.
02Capturing and Testing Assumptions
2 sessions · 8 points
Session 1Surfacing Assumptions During Planning
- Run a structured session to surface assumptions the schedule and budget are quietly built on.
- Write an assumption in a specific, testable form rather than a vague statement of hope.
- Prioritise assumptions by how much of the plan would be affected if they turned out to be wrong.
- Identify assumptions imported unchanged from a similar past project without being checked.
Session 2Validating and Closing Assumptions
- Assign an owner and a method for confirming or correcting each significant assumption.
- Set a deadline for validating an assumption before the plan depends on it irreversibly.
- Update the schedule or budget immediately when a validated assumption turns out to be wrong.
- Close validated assumptions formally so the log reflects only what still needs confirming.
03Managing Issues to Resolution
2 sessions · 8 points
Session 1Converting Concerns into Tracked Issues
- Convert an informally raised concern into an issue with a clear description and named owner.
- Set a target resolution date for an issue based on its impact on the schedule or budget.
- Distinguish an issue that needs a decision from one that only needs an update or explanation.
- Avoid recording the same underlying problem as multiple overlapping issues in the log.
Session 2Driving Issues to Closure
- Chase an issue owner for progress without the log becoming a source of blame.
- Recognise when an issue has stalled and needs a different owner or a management decision.
- Distinguish a genuinely closed issue from one that has simply stopped being discussed.
- Record the resolution and root cause of closed issues for use in future lessons learned.
04Mapping and Escalating Dependencies
2 sessions · 8 points
Session 1Identifying and Mapping Dependencies
- Identify dependencies on other teams, projects or external parties during planning, not after delay.
- Map each dependency to the specific date or milestone it would affect if it slipped.
- Confirm a dependency directly with the owning team rather than assuming it is understood.
- Track dependencies in both directions so other projects can see what depends on your delivery.
Session 2Escalating Unresolved RAID Items
- Judge when a RAID item has stalled long enough to warrant escalation beyond the project team.
- Escalate an item with the decision needed and options, not only a description of the problem.
- Use RAID log history to support an escalation with a clear record of prior attempts to resolve it.
- Close the loop with stakeholders once an escalated item is resolved so trust in the log is maintained.
What the participant receives
4 course modules
A structured syllabus
8 training sessions
across 5 days
32 detailed points
Applied, detailed content
Accredited attendance certificate
On completing the programme
Complete your registration
We will contact you within one business day to confirm.
Ready to start?
Reserve your seat and start building the skill.