2.2.2. Registers and Project Closure

💡 First Principle: A register is a living log, not a one-time report — it's created early and updated continuously as new information appears. Treating a register as something you fill out once and file away is the most common way associate-level candidates misuse these tools on the exam.

Using a risk register. The risk register captures identified risks, their likelihood and impact, and the planned response. Scenario questions typically describe a newly discovered risk and ask what the team should do with it — the answer is almost always "log it in the risk register and assess it," not "ignore it" or "escalate immediately without assessment" (unless the scenario describes an issue, not a risk — see 2.1.2).

Using a stakeholder register. The stakeholder register identifies stakeholders and captures information relevant to engaging them — their interest, influence, and expectations. When a scenario introduces someone new who has influence over the project (a newly assigned executive sponsor, a regulator who just became relevant), the correct first action is usually to add them to — or update — the stakeholder register, not to immediately schedule a meeting or make a decision on their behalf.

Project closure and transitions. Closing a project means more than finishing the deliverable — it includes formal acceptance of the outcome, releasing resources, capturing lessons learned, and transitioning the result to whoever owns it going forward (often an operations team, tying back to Phase 1's project-vs-operations distinction). A project that quietly "just stops" without a formal closure and handoff is a common wrong-answer pattern on the exam.

⚠️ Exam Trap: Formal closure applies even to a canceled or terminated project — not just successful ones. If a scenario describes a project being shut down early, the correct next steps still include documenting lessons learned and releasing resources properly, not simply walking away.

A register entry doesn't disappear once resolved. A risk that was logged three months ago and never materialized should still have its status updated to reflect that outcome, rather than being deleted or left showing as an open, active concern. Deleting the entry loses the historical record the register exists to preserve; leaving it marked as still-open misrepresents the project's current risk picture. The same logic applies to a stakeholder register — someone whose influence has genuinely changed should have their entry updated, not left frozen at whatever it said when they were first logged.

What skipping closure activities quietly costs later. A team that accepts the final deliverable and immediately disbands, without holding a lessons-learned session or formally releasing shared resources, doesn't create an obvious, visible failure — the deliverable itself is still fine. What's lost is less visible: future projects can't benefit from this project's hard-won insights, and resources may stay tied up longer than necessary because no one formally freed them. This is exactly why closure is a defined set of activities rather than a single deliverable-acceptance checkbox.