Project Review Meeting — sign-off checklist

Pre-PRM checklist. Complete the items below before scheduling the meeting with Head of Delivery.


Where the plan may live (before and during PRM)

The working SOW ↔ project plan may be authored and maintained in any of:

  • Notion (page URL)
  • Google Doc (link with access for reviewers)
  • Client vault — e.g. knowledge/clients/{client}/resources/sow-project-plan.md (or another file under that client’s resources/)

Requirement: §1–§6 are complete in that artifact (same section model as sow-project-plan-template.md). Head of Delivery is invited with that link or path 24h+ in advance (see Meeting logistics).


After PRM (follow-up actions after HoD approval)

  • CSO has added the approved plan to client knowledge — default path knowledge/clients/{client}/resources/sow-project-plan.md (markdown export/copy is fine). This is the internal record for agents, skills, and teammates who do not use the source tool.
  • If the team keeps editing in Notion or Google Doc, §1 (or a short note at the top of the vault file) links to the live source and states which copy is authoritative when they differ (after approval, prefer updating both or re-exporting to vault when material changes).

Where the plan may live (before and during PRM)

The working SOW ↔ project plan may be authored and maintained in any of:

  • Notion (page URL)
  • Google Doc (link with access for reviewers)
  • Client vault — e.g. knowledge/clients/{client}/resources/sow-project-plan.md (or another file under that client’s resources/)

Requirement: §1–§6 are complete in that artifact (same section model as sow-project-plan-template.md). Head of Delivery is invited with that link or path 24h+ in advance (see Meeting logistics).


After PRM (once HoD approves or plan is internally locked)

  • CSO has added the approved plan to client knowledge — default path knowledge/clients/{client}/resources/sow-project-plan.md (markdown export/copy is fine). This is the internal record for agents, skills, and teammates who do not use the source tool.
  • If the team keeps editing in Notion or Google Doc, §1 (or a short note at the top of the vault file) links to the live source and states which copy is authoritative when they differ (after approval, prefer updating both or re-exporting to vault when material changes).

Document

  • SOW ↔ project plan §1–§6 filled in the working artifact (§7 left for final signatures)
  • Initiatives map to client objectives in SOW
  • Projects have owners and realistic windows
  • Project milestones are client-visible outcomes (not internal tasks only)
  • §5 Technical approach reviewed and signed by SL (written OK)
  • §6 Open questions have owners and target dates

Linear

  • Draft Team / Initiatives / Projects mirror the doc (or clear plan to create immediately after approval)

Client

  • CSO ready to explain plan to sponsor after internal approval
  • No hidden commitments in Slack/email that contradict the plan

Meeting logistics

  • Head of Delivery invited with plan link or vault path (Notion, Google Doc, or knowledge/...) 24h+ in advance
  • SL available async or on-call for targeted questions

Last updated: 2026-04-07