Statement of work
The SOW converts an agreed scope into a contractual plan. It is the scope baseline: after signature, anything not in it is a change.
The standard. A statement-of-work template for DevOps engagements that can be adapted to the customer's scope, risk and commercial model.
Structure
| Section | Content |
|---|---|
| 01 Introduction | Project objective in one paragraph |
| 02 Background | Customer context, the problem, the decision to change |
| 03 Current environment | Existing infrastructure and constraints |
| 04 Strategic objectives | The business goals the project serves |
| 05 Current technology | Limitations of the current estate |
| 06 Goals and objectives | Business, technical and service objectives |
| 07 Solution architecture | Target architecture diagram and expected AWS cost |
| 08 Scope of work | Phased plan, deliverables, milestones, out of scope |
| 09 Methodology | Delivery approach and standards applied |
| 10 Place of performance | Locations, remote/onsite split |
| 11 Applicable standards | Security, privacy, compliance standards |
| 12 Resource requirements | Qbits and customer roles |
| 13 Qbits responsibilities | What Qbits will do |
| 14 Customer responsibilities | What the customer must provide |
| 15 Project risks | Known risks and mitigations |
| 16 Acceptance criteria | How completion is determined |
| 17 Change control | The procedure after signature |
| 18 Legal and compliance | Confidentiality, IP, liability, termination |
Scope of work
In-scope plan
Tasks selected from the standard nine-phase menu, each with an effort estimate in days:
| Phase | Tasks | Days |
|---|---|---|
| 1. Planning and preparation | Kick-off, requirement confirmation, access, project setup | |
| 2. AWS account setup | Organisation, accounts, identity, guardrails | |
| 3. Network and baseline IaC | VPC, subnets, routing, Terraform baseline | |
| 4. Migration execution | Workload and data migration, cutover | |
| 5. DevOps practices and design | Pipelines, modules, environment topology | |
| 6. Security and observability | Controls, detection, monitoring | |
| 7. Testing | Functional, load, resilience, security | |
| 8. Knowledge transfer | Documentation, training, game day | |
| 9. Closure | Acceptance, review, report |
Deliverables
Each deliverable is tangible and verifiable:
- Architecture documentation and diagrams.
- Infrastructure as code repositories.
- CI/CD pipelines for each application.
- Security and compliance configuration.
- Monitoring dashboards, alarms and runbooks.
- Training materials and session records.
- Handover documentation.
- Completion report.
Milestones
| Milestone | Date | Decision or artefact |
|---|---|---|
| Kick-off complete | Scope confirmed, access granted | |
| Environments ready | Dev and stage available | |
| Pipeline live | Build and deploy working end to end | |
| UAT complete | Customer sign-off on functionality | |
| Production cutover | Workload serving production traffic | |
| Handover | Documentation and training accepted | |
| Closure | Completion report signed |
Out of scope
The out-of-scope list is explicit and specific. Typical exclusions:
- Application code changes beyond configuration required for the deployment.
- Data cleansing or migration of data not identified in the inventory.
- Third-party licensing and procurement.
- Changes to systems not in the inventory.
- Ongoing operational support beyond the hypercare period.
- Feature development.
An empty out-of-scope list is a scope dispute in waiting. If nothing is excluded, say so explicitly and explain why the boundary is unambiguous.
Expected AWS cost
Cost is estimated per service for the target architecture, with the assumptions stated:
| Service | Configuration | Monthly estimate |
|---|---|---|
| Compute | Instance type, count, hours | |
| Database | Engine, class, storage, Multi-AZ | |
| Storage | GB, class, requests | |
| Network | Data transfer, NAT, load balancer hours | |
| Observability | Logs ingest, metrics, retention | |
| Total |
The estimate states what it excludes: support plan, taxes, one-off migration transfer costs, and growth.
Acceptance criteria
Acceptance is defined in four parts:
Formal acceptance is a signed record. Silence is not acceptance — the SOW states what happens if the customer neither accepts nor raises issues within the review window.
Change control
After signature, the scope baseline changes only through the change process:
- Change request form submitted.
- Impact assessed — scope, schedule, cost, resources, risk.
- CAB reviews and decides approve, reject, defer or modify.
- Change register updated.
- Implementation planned and executed.
- Post-change review and closure.
See Change management.
Customer responsibilities
The SOW states what the customer must provide, because these are the most common causes of delay:
- Named technical owner with decision authority.
- Access to AWS accounts, repositories and systems.
- Timely review and approval at milestones.
- Availability of subject-matter experts for workshops and UAT.
- A representative who can accept deliverables.
- Communication of internal dependencies and constraints.