Project review process (post-SOW gate)

Where the plan lives

Phase	Allowed locations
Before and during Project Review Meeting	Notion, Google Doc, or `knowledge/clients/{client}/resources/` (e.g. `sow-project-plan.md`). Use the same § structure as sow-project-plan-template.md.
After HoD approval (or internal lock pending sponsor)	CSO copies or exports the approved plan into the client vault — default `knowledge/clients/{client}/resources/sow-project-plan.md`. Optionally keep Notion/GDoc as the live editor; the vault file is still required as the internal knowledge record (link the live doc from §1 or the vault header when both exist).

CSO + SL complete the plan through §6 (in Notion, Google Doc, or vault) using sow-project-plan-template.md as the section model; SL signs technical sections.
CSO schedules Project Review Meeting with Head of Delivery (see project-review-meeting), sharing the working link or path 24h+ in advance.
Head of Delivery approves or requests revisions.
CSO adds the approved plan to knowledge/clients/{client}/resources/ (default filename sow-project-plan.md) if it is not already there; updates vault copy when the approved Notion/GDoc changes materially.
§7 sign-offs are completed in sequence as needed (CSO → SL → Head of Delivery → client sponsor).
CSO ensures Linear matches approved structure; communicates timeline narrative to client.
SL + ICs break milestones into Issues and execute; CSO tracks client-visible outcomes.

Material scope change, slip beyond agreed escalation threshold, or sponsor reprioritization → refresh plan and re-run PRM (full or lightweight per Head of Delivery).

Last updated: 2026-04-07