SOW ↔ Project Plan (per client)
Purpose: Bridge after the SOW is signed and before Linear Issues are created (Issues are what people often call “tickets”). Aligns CSO, Service Lead (SL), Head of Delivery, and the client sponsor on the same objects you will use in Linear—Initiatives, Projects, Project milestones, and the technical approach—plus sign-offs. Where to author (before / during Project Review Meeting): Notion, Google Doc, or
knowledge/clients/{client}/resources/sow-project-plan.md— any is valid for the working draft; see project-review-process.md. After HoD approval: CSO must place the approved plan in the client vault — defaultknowledge/clients/{client}/resources/sow-project-plan.md(export from Notion/GDoc if needed). Link the live Notion/GDoc in §1 or at the top of the vault file if collaboration continues there. Last updated: [Date]
Terminology: this document ↔ Linear
Use Linear’s product names when talking in Linear; this table ties each section of this plan to the object in Linear so CSO, SL, and delivery mean the same thing.
| This template | Linear object | Notes |
|---|---|---|
| §1 Linear Team | Team | Workspace-side container for this client’s delivery (all Issues below belong to a Team). |
| §2 Initiatives | Initiative | Groups related Projects under one client objective. |
| §3 Projects | Project | Lives under one Initiative; use start/target dates on the Project where you track delivery. |
| §4 Milestones | Project milestone | Attached to a Project; client-visible outcomes (not every internal task). |
| Work broken down for engineers | Issue | Atomic unit of work; one assignee; link to the relevant Project and optional Project milestone. Same as “ticket” in casual speech—prefer Issue in Linear and in written process. |
| §3 Service line & Subservice | (none) | Service line and subservice are catalog / org labels only (playbook atomic chain §8.2); do not create extra Linear layers for them unless the team explicitly chooses to. |
Phases in the offering implementation-plan.md | Project milestone(s) and/or Issue scope | Offering “Phase 0 / Phase 1” is a sales/delivery framing; in Linear you express timing through Project milestones and Issues, not a separate “Phase” entity. Matches playbook §8.2: Phase → Milestone (use Project milestone in Linear). |
| Playbook Deliverable (§8.2) | Project milestone and/or Issues | §8.2 labels this layer “Epic” in the ASCII key; Linear has no object named Epic—use Project milestones for client-visible bundles and decompose into Issues (optionally parent Issues for grouping). |
How to use this template
Duplicate this page for each new client engagement. Fill in §1 Engagement Overview together (CSO + SL), then the CSO completes §§2–4 before handing off to the SL for §5. Resolve §6 Open Questions, and collect all four sign-offs in §7 before the plan is considered locked.
Section order note: Complete §3 Projects (Linear: Projects) before §4 Milestones (Linear: Project milestones) so each milestone references its parent Project—in Linear, Project milestones always attach to a Project.
Linear naming conventions (for import)
| Linear object | This template § | Naming convention | Example |
|---|---|---|---|
| Initiative | §2 | [Client] | [Objective] | ABC | Data Platform |
| Project | §3 | [Client] — [Offering] | ABC — dbt Audit |
| Project milestone | §4 | [Offering] — [Customer deliverable] | dbt Audit — First model set live |
| Issue | (after this plan is locked; not a section in this doc) | Atomic unit of work; one assignee; link to Project (and milestone when helpful) | — |
Services → subservices → service leads (update names/handles as the org evolves):
- AI → @Sam Roberts
- Workflow Automation
- Knowledge Engineering
- Copilots & Agents
- Data → @Awaish Kumar
- Data Platform
- Data Modeling
- Strategy & Analytics → @Robert Tseng, @Jasmin
- Data Strategy
- Measurement & KPIs
- Reporting & Insights
Standard project plan examples: Use the offering’s canonical implementation-plan.md (knowledge/sales/services/{line}/{subservice}/{offering}/) and the At a Glance / phase tables there for timeline patterns; this doc maps that scope onto this client’s Linear structure.
1. Engagement overview
Owned by: Both (CSO + SL) — Fill in at kickoff before starting any other section.
- SOW: Link to signed SOW
- Client: Client name
- CSO: CSO name
- Engagement period: Start date → End date
- Total revenue: Per signed SOW
- Total est. hours: Estimated hours across all projects
- Linear Team: Link to the client’s Team in Linear (workspace container for their Initiatives / Projects / Issues)
2. Initiatives (Linear: Initiatives)
Owned by: CSO — One Linear Initiative per major client objective. Propose from the SOW before close; SL confirms high-level feasibility.
Initiative 1
- Initiative name (Linear Initiative title): Short label (e.g. Data Platform, AI Automation)
- Business unlock: One sentence — capability or outcome for the client
- Delivery date: Target completion
- Services used: Data / AI / Strategy & Analytics (all that apply)
Initiative 2 (duplicate as needed)
- Initiative name (Linear Initiative title):
- Business unlock:
- Delivery date:
- Services used:
3. Projects (Linear: Projects)
Owned by: Both (CSO proposes → SL validates) — Each row becomes one Linear Project. Every Project must sit under exactly one Linear Initiative from §2. CSO proposes scope and timing from the SOW; SL validates feasibility and dates.
[Offering / Project name]
- Parent Initiative (Linear): From §2 — name of the Initiative this Project belongs to
- Service line: Data / AI / Strategy & Analytics
- Subservice: e.g. Data Platform
- Service lead: Name
- Start date: Date
- Target date: Date
4. Milestones (Linear: Project milestones)
Owned by: CSO — Client-visible capability deliveries, demos, go-lives. Capture each as a Project milestone on the right Project in Linear and review sequencing in that Project’s Timeline view (Linear’s project timeline—not a separate Gantt tool). Project milestones = what the client receives, not internal build steps. Small internal checkpoints → Issue due dates or labels; client-facing outcomes → Project milestones. Example: “MCP complete” → Issue target; “Andy AI live in staging” → Project milestone.
[Customer deliverable]
- Parent Project (Linear): From §3 — Project this Project milestone rolls up to
- What the client receives: One sentence — handoff or demo
- Target date: Date
5. Technical approach
Owned by: SL — One subsection per Linear Project from §3. CSO and Head of Delivery review for effort and feasibility. (Technical steps here inform Issues later; they are not themselves Project milestones unless the client receives something at that step.)
[Project / offering name] (same Project as §3)
Relevant playbook(s):
- e.g. Reusable epic for Edge-to-Activation
Target process (step-by-step)
Purpose: One sentence on what this project achieves for the client.
- Step 1 — e.g. Ingest raw data from source system
- Step 2 — e.g. Transform via dbt models and write to warehouse
- Step 3 — e.g. Surface outputs in Omni dashboard
Tools & stack
- Primary tools: e.g. dbt, Snowflake, Omni
- Integrations: e.g. Linear webhook, Google Drive API
- Infrastructure: e.g. Dagster on Railway, Supabase
Architecture notes / dependencies
- Key architectural decision or constraint
- External dependency — e.g. client provides warehouse access by kickoff
- Risk — e.g. PII restrictions on transcript data
Performance / accuracy targets
- e.g. Duplicate detection precision ≥ 90%
- e.g. Dashboard query p95 latency < 3s
- N/A if not applicable
Resourcing
- e.g. 1 Data Engineer · 1 Data Analyst
Risks
- e.g. Dependency on Polytomic → Amazon connector
6. Open questions
Owned by: Both — Resolve before §7 sign-offs.
CSO questions (client / scope)
- e.g. Preferred demo format and channel (Slack vs doc)
- e.g. Does the SOW cover PII handling for transcript data?
- e.g. Client technical POC for access provisioning?
SL questions (technical blockers / unknowns)
- e.g. Where do source transcripts live and how are they keyed?
- e.g. What Snowflake permissions at kickoff?
- e.g. Existing dbt models vs greenfield?
Head of Delivery
- e.g. Capacity and priority vs other active engagements
- e.g. Escalation path if timeline slips two weeks
- e.g. Cross-pod dependency (shared platform / infra)
7. Sign-offs
Owned by: Both — All four sign before the plan is locked. Order: CSO → SL → Head of Delivery → Client sponsor. Changes after lock require CSO visibility and explicit acknowledgment.
- CSO — Business scope, Project milestones (§4), client accountability — [ ] Signed off?
- SL — Technical approach, effort, delivery accuracy (Issues will reflect this) — [ ] Signed off?
- Head of Delivery — Feasibility, business case, leadership alignment — [ ] Signed off?
- Client sponsor (name) — Client alignment on scope + timeline — [ ] Signed off?
Reference documents
- Offering implementation plan (phases/weeks):
implementation-plan-template.md— offering phases roll forward into this doc as Projects / Project milestones / Issues in Linear (see Terminology above). - Playbook §8.2 — Full atomic chain (canonical catalog vs Linear):
standards/PLAYBOOK_DEVELOPMENT_PLAN.md— Service line → Subservice → Offering → Phase → Deliverable → Ticket with Linear key Initiative / (no layer) / Project / Milestone / Epic / Issue. This template uses Linear product names: Milestone in §8.2 = Project milestone here; Ticket = Issue; Epic = milestone + Issue structure (see Terminology). Initiative in §8.2 is tied to Service line in the catalog; on a client engagement, §2 Initiatives are still Linear Initiatives, often named by client objective (may span multiple service lines—use §3 Service line / Subservice for catalog tags).
Retro / update log (optional)
| Date | Engagement | What changed |
|---|---|---|
| [YYYY-MM-DD] | [Client] | [e.g. Extended Phase 1; added access prereq] |