Skip to content

Create Statement of Work

ContributorsPaul Atkins

Purpose

Generate a contractual-grade Statement of Work (SoW) from a completed gap analysis and remediation plan. The SoW is designed for stakeholder sign-off and includes protective language for dependency management.

Prerequisites

Before invoking this skill, ensure the following documents exist:

  1. Gap analysis — completed, with priority actions and key decisions
  2. Remediation plan — phased work items with effort estimates, dependencies, and exit criteria
  3. Skills summary (optional) — maps engineering library skills to plan items

If starting from scratch (no gap analysis or plan yet), use the SoW Workflow Prompt which orchestrates the full end-to-end process: gathering inputs, running the gap analysis, collecting supplementary data, building the plan, and assembling the SoW.

If a CARES section already exists in the remediation plan, extract and adapt it for the SoW rather than duplicating.

Instructions

Step 1 — Read source documents

Read the gap analysis and remediation plan in full. Identify:

  • All work items grouped by phase
  • All effort estimates (T-shirt sizes or days)
  • All internal dependencies (between work items)
  • All external dependencies (decisions, approvals, or implementations by other teams)
  • All assumptions stated or implied
  • All exclusions stated or implied
  • All risks identified

Step 2 — Identify external dependencies

Scan every work item for references to teams, approvals, or decisions outside the delivery team. Categorise each dependency:

Category Examples
Business decisions IP agreements, source code access, service ownership
Technical Design Authority (TDA) Technology choices, architecture patterns, service tier classification
Central IT / Platform Azure subscriptions, DevOps provisioning, ACR access, identity (Entra ID), Key Vault, ServiceNow
Data / Architecture team Data connectivity, ETL design, database technology
Security Access policies, secret management, penetration testing

For each dependency, capture: - Owner — the specific team responsible - Blocks — which plan items or phases cannot proceed without it - Required by — the phase or milestone that needs it - Detail — one-sentence description

Step 3 — Build the CARES section

Caveats

State what limits the accuracy or completeness of the plan. Common caveats: - Plan based on documentation, not source code inspection - Effort estimates are indicative (T-shirt sizes) - Sizing depends on unconfirmed classifications (e.g. service tier)

Assumptions

State what the plan assumes to be true. For each assumption, include "Impact if Wrong" — what changes if the assumption is invalidated. Common assumptions: - User count / concurrency - Target platform (e.g. Azure DevOps) - Target database technology - Number of environments - Tests currently passing

Risks

Summarise the top risks from the remediation plan's risk register. Include likelihood, impact, and mitigation for each.

Exclusions

List what is explicitly out of scope, with rationale. Common exclusions: - Business logic changes - Full design system migration - Production data migration execution (vs tooling) - Load/performance testing - Disaster recovery / multi-region

Step 4 — Write the SoW

Use this structure:

# [System Name] — Statement of Work

## 1. Background
One paragraph: what the system is, current state, why remediation is needed.

## 2. Objectives
Numbered list of 4–8 high-level outcomes.

## 3. Scope of Work
### 3.1 In Scope — Phase summary table with key deliverables.
### 3.2 Out of Scope — Exclusions table with rationale.

## 4. CARES — Caveats, Assumptions, Risks, Exclusions
### 4.1 Caveats — table
### 4.2 Assumptions — table with "Impact if Wrong"
### 4.3 Risks — table with likelihood/impact/mitigation
### 4.4 Exclusions — reference to 3.2

## 5. External Dependencies
Full dependency table with owner, blocks, required by, detail.

## 6. Deliverables and Milestones
One milestone per phase with key deliverables and exit criteria.

## 7. Schedule and Dependency Management
### 7.1 Indicative Timeline — phase durations with prerequisites
### 7.2 Key Dates for Dependency Owners — illustrative calendar dates
### 7.3 Dependency Delay Clause
### 7.4 Information Sharing

## 8. Change Control
How scope changes are managed.

## 9. Acceptance Criteria
Checklist for engagement completion.

## 10. References
Links to source documents.

Step 5 — Key dates for dependency owners

If the timeline has an illustrative or agreed start date, derive a Key Dates table showing when each external dependency must be resolved. This makes dependencies concrete for non-engineering stakeholders.

Structure:

| Dependency | Owner | Required By | Illustrative Date |
|-----------|-------|-------------|-------------------|
| D1: [name] | [owner team] | [phase/milestone] | [calendar date] |

Rules: - Order by date (earliest first), not by dependency number - State explicitly that dates shift day-for-day if the start date changes - Group dependencies that share the same required-by date - If no start date is known, use relative timing (e.g. "Week 2", "Week 6") and note "Dates will be calculated once start date is confirmed" - Link to the timeline document for the full Gantt chart

Step 6 — Protective language

Include the following clauses:

Dependency delay clause:

Where an external dependency is not available or ready by the date required, the delivery timeline for all dependent work items will slip day-for-day. The delivery team will notify the project sponsor in writing within 2 business days of identifying a delay. If a delay exceeds 10 business days, the team may re-sequence non-dependent work but the overall milestone date will adjust.

Information sharing clause:

The Parties agree to share relevant technical information, access credentials, and decisions in a timely manner. Responses to clarification requests will be provided within 5 business days. TDA decisions will be scheduled for the next available session.

Change control clause:

Changes arising from diagnostic findings, TDA decisions that differ from assumptions, or additional scope discovered during implementation will be documented as change requests, assessed for effort and schedule impact, and require written approval before implementation.

Step 7 — Cross-reference check

Verify: - Every dependency in Section 5 maps to at least one plan item - Every dependency in Section 5 has an illustrative date in Section 7.2 - Every assumption in 4.2 has an "Impact if Wrong" - Every risk in 4.3 has a mitigation - Milestones in Section 6 align with plan phase boundaries - Acceptance criteria in Section 9 cover all Phase deliverables - No plan items are orphaned (every item appears in scope or exclusions)

Output

A single .md file named [system]-sow.md in the workspace root.

Troubleshooting

Error: SoW dependencies don't match plan work items. Cause: Plan was updated after SoW was drafted. Solution: Re-read the plan and regenerate the dependencies table. Use update-plan-from-evidence if the plan needs updating first.

Error: CARES section duplicates content from the remediation plan. Cause: CARES was already added to the plan before the SoW was created. Solution: Extract and adapt from the plan rather than writing from scratch. The SoW version should be slightly more formal in tone.