Project Review Meeting — expectations
When to hold
- After SOW sign-off and before scaling execution / firm client date commitments.
- Again on major scope change or ~quarterly refresh (per account).
Roles
| Role | Expectation |
|---|---|
| Head of Delivery | Challenges plan for feasibility, clarity, and business risk; approves or sends back with required changes. |
| CSO | Presents narrative: objectives, milestones, client accountability, what “done” looks like. |
| SL | Technical sign-off on approach and effort before or during only if explicitly needed; not a co-presenter by default. |
| Client sponsor | Signs in §7 of the plan after internal lock (may be async) — in whichever system holds the working plan, or in the vault copy once filed. |
Prep bar
- SOW ↔ project plan complete through §6 in the working artifact (Notion, Google Doc, or client vault under
knowledge/clients/{client}/resources/). Same section structure; location is flexible until the post-review vault step in project-review-process.md. - Linear draft structure aligned with §§2–4 (Initiatives / Projects / milestones) where possible.
Success
- Shared understanding of dates, dependencies, and escalation path.
- No “we’ll figure out architecture later” for material commitments.
- After HoD approval (or internal lock): approved plan is copied or exported into
knowledge/clients/{client}/resources/(see sign-off-checklist.md) so the monorepo remains the durable internal source for delivery context.
Intuition (why this gate exists)
The PRM is a defense-style review: the CSO presents evidence for the plan’s claims, the Head of Delivery challenges weak spots, and the plan is either approved or sent back for revision—mirroring how a thesis committee validates work before “publication” (client commitment). This is one example of analogical grounding: we map delivery gates to recognizable precedents so teams immediately grasp the standard of rigor required. Full mappings: ../../06-reference/delivery-analogies.md.
Last updated: 2026-04-07