Project lifecycle
Purpose: Explain how delivery moves from signed SOW to approved plan to execution to change control, with explicit gates and systems of record.
This chapter answers:
- when work becomes real
- when work is ready for execution
- when work must go back through review
- how the plan, Linear, and the client narrative stay aligned
1. Literal lifecycle
The delivery lifecycle is:
SOW → project plan → Project Review Meeting → sign-offs → Linear structure → execution → re-gate on material change
This is the core sequence. Details vary by engagement, but the sequence should not.
2. Why this lifecycle exists
Delivery breaks when teams move from signed scope to execution without pressure-testing the plan, or when they keep executing after the assumptions have changed.
This lifecycle exists to enforce:
- plan before promise
- visible ownership
- review before hard commitment
- change control when reality shifts
- alignment between the plan, the board, and the client story
3. Analogy
The strongest analogies here are:
- Thesis defense — the plan must be defensible before execution hardens
- Investment committee — commitments should survive scrutiny before capital is effectively allocated
- Chef’s pass — work should clear a quality gate before it leaves the system
These analogies explain the structure. The policy remains literal.
4. What good looks like
- scope is translated into a coherent plan before detailed execution starts
- dates are pressure-tested before they become real commitments
- sign-offs mean something
- the board mirrors the approved structure
- execution updates remain truthful
- material change triggers review rather than quiet drift
5. Lifecycle stages
5.1 SOW signed
This is the commercial and scope commitment point. It is not yet an execution-ready plan.
What must be true:
- scope basis exists
- stakeholders are known
- commercial frame exists
5.2 Build the SOW ↔ project plan
This is where signed scope becomes an execution-capable plan.
What must be true:
- initiatives, projects, and milestones are defined
- dependencies are explicit
- ownership is visible
- technical approach is real enough to review
Primary artifact: sow-project-plan-template.md
5.3 Project Review Meeting
This is the main gate between planning and execution lock-in.
What must be true:
- the plan is defensible
- risks are explicit
- dates are pressure-tested
- open questions are known
- approval or send-back is decisive
Supporting detail: project-review-process.md
5.4 Sign-offs
Approval should move through the agreed sign-off sequence so the plan is not treated as real based on implied consensus.
What must be true:
- business, technical, and leadership sign-off are explicit
- sponsor sign-off happens when required
5.5 Mirror structure in Linear
Once approved, the plan should be reflected in the execution system of record.
What must be true:
- the board mirrors the approved structure
- milestones are client-meaningful
- issues can be broken down without distorting the plan
Supporting detail: linear-structure-guide.md
5.6 Execute with client cadence
Execution begins after the plan is approved and reflected in the system of record.
What must be true:
- updates reflect reality
- checkpoints continue to enforce standards
- blockers and slips are visible
5.7 Re-gate on material change
If the assumptions change materially, the work must return to review rather than quietly continuing under an invalid plan.
What must be true:
- the material change is named
- the plan is refreshed
- approvals are updated as needed
- the client narrative is aligned after internal review
6. Systems of record
This lifecycle depends on three aligned truth layers:
6.1 Project plan
The approved plan is the source of truth for what the team intends to deliver, by when, and under what assumptions.
6.2 Linear
Linear is the source of truth for current execution structure and current delivery state.
6.3 Client narrative
Client communication is the external expression of the current reality of the work.
6.4 Operating and capacity (service line layer)
Client execution is primarily visible in Linear (issues, projects, milestones) and the approved plan.
Resourcing and hours against SOWs / internal projects are maintained in Operating (and related portfolio views). Service Leads own keeping allocations and sub-service truth current as that system rolls out; CSOs remain accountable that the client story matches delivery, while SLs own that who is staffed where and for how many hours matches reality.
For a fuller role split, see client vs service line systems of record.
Rule
Plan, Linear, client narrative, and (where used) Operating capacity should not drift materially apart. If they do, the team has lost control of the work.
7. Re-gating doctrine
Re-gating is required when one or more of the following becomes materially different:
- scope
- timeline
- key dependency
- technical feasibility
- resourcing assumption
Re-gating does not mean every change requires ceremony. It means every material change requires a visible reset of the plan.
8. Relationship to checkpoints and roles
This lifecycle only works because checkpoints and roles reinforce it.
- Head of Delivery governs the bar and approves major plans
- CSO owns plan narrative and client-facing commitment story
- SL owns technical truth, feasibility, and technical execution integrity
- ICs execute within the approved structure and escalate clearly when reality changes
Checkpoint layer:
Role layer:
9. Core resources
| Resource | Purpose |
|---|---|
| sow-project-plan-template.md | Canonical per-client plan (initiatives, projects, milestones, sign-offs) |
| project-review-process.md | PRM gate and after-approval steps |
| linear-structure-guide.md | Initiative → Project → Milestone → Issue mapping |
| lifecycle-visual.md | Mermaid flow |
| client-vs-service-line-systems-of-record.md | Where client delivery vs service-line resourcing lives |
Playbook note: SOW authoring templates live in standards/02-writing/SOWs/. This folder should link to them rather than duplicate them.
Last updated: 2026-03-30