Free to read. Each topic is one section of the exam, so this is also your study guide. About two hours in total.
Topic 1 of 9
RAID fundamentals
What each letter means, how a RAID log differs from a project plan, and why it must be a living register.
- Risk: might happen. Issue: already happening. Assumption: believed true but not confirmed. Dependency: something you need from outside your team.
- Agree with the client at the start whether "D" means Dependencies or Decisions, and track both explicitly either way.
- Start the log at mobilisation and keep it live until closure; the delivery manager owns the log, a named role owns each item.
"The vendor might deliver the API late" is a risk.
"The API environment is down today" is an issue.
Writing good risks
Cause, risk event, effect, with a mitigation that is an action and a contingency for when it happens.
- Write: "Because <cause>, <event> may happen, leading to <effect>."
- A mitigation reduces likelihood or impact before the risk happens; "monitor" is not an action.
- Choose a response: avoid, reduce, transfer or accept, and record a contingency for high-impact risks.
Weak: "Clearinghouse risk."
Strong: "Because the clearinghouse certification slot is not booked, certification may finish after cutover, delaying go-live by two weeks."
Assumptions
Turning planning beliefs into checked facts before the plan depends on them.
- Write assumptions so they can be checked: who, what, when.
- Give each one an owner and a validation date; close it with who confirmed it.
- If an assumption proves false, raise a risk or issue for the impact and re-plan.
Weak: "Testers are available."
Strong: "The client's UAT team of four is available full-time for the three-week UAT window starting 2 March."
Issues
Recording, prioritising, working around and escalating problems that are already happening.
- Record what is happening, its impact and who owns the resolution; link the risk it came from.
- Rate issues by impact and urgency; escalate when a milestone is threatened or the team cannot resolve it in time.
- A workaround keeps work moving; the closure note says what fixed it, when, and who confirmed it.
Closure note: "Resolved 14 Oct: client IT granted VPN access to all 8 testers; testing resumed the same day (confirmed by QA lead)."
Dependencies
Tracking what you need from vendors, the client and other teams, before it becomes an issue.
- Name the provider, what is needed, the date needed and what it blocks.
- Watch the gap between "needed by" and "promised by"; a negative gap is an early warning.
- Review dependencies due in the next two to four weeks every week; a late one becomes a linked issue.
"Payment switch vendor to certify NEFT/RTGS message changes by 20 Nov, needed before SIT cycle 2."
Rating and the heat map
Impact × likelihood on a 3 × 3 scale, agreed definitions, and reading the exposure heat map.
- Score = impact × likelihood (High 3, Medium 2, Low 1); High × High = 9 needs attention now.
- Write down what High, Medium and Low mean for your project so the team rates consistently.
- Re-rate after every change and after mitigations complete; plot open risks and issues on the heat map.
A High-impact, Low-likelihood risk stays visible with a contingency plan; it is not closed just because it is unlikely.
Owners, actions and review
Who does what by when, and a weekly review that keeps the log honest.
- Owners are named roles, never "team" or "TBD"; actions say who, what, by when and how we know it is done.
- Weekly review: new and changed items first, then top risks, then overdue actions.
- Close items with a note; keep closed items for history, audits and lessons learned.
Weak action: "Follow up."
Strong action: "Integration Lead to confirm sandbox access with bank IT by Thu 17 Oct."
Weekly status and RAG
Green, amber and red with clear definitions, a summary that leads with what matters, and no watermelons.
- Green: on track. Amber: at risk, recovery within the team's control. Red: will miss without help or a decision from above.
- Report overall, schedule, scope and quality; include top risks and issues, overdue actions and dependencies due soon.
- Ask for decisions with options, impact, your recommendation and the date needed; show the week-over-week trend.
A "watermelon" report is green outside and red inside. Amber early is better than red as a surprise.
Governance and real situations
Steering committees, escalation, change control and go/no-go decisions in practice.
- Steering committees decide priorities, escalated risks, scope and budget; they are not for task updates.
- Escalate early with facts, options and a recommendation; take new requests through change control.
- Go/no-go uses agreed criteria; after hypercare, hand over open items and capture lessons learned.
Critical defect in a non-core feature two days before go-live: propose going live with that feature switched off, a hotfix plan and sponsor approval.
