Work breakdown structure
A WBS makes scope visible. The dictionary behind it makes the work estimable, assignable and verifiable — without it, a phase name is not a plan.
Structure
Work decomposes from phases to deliverables to tasks. A task is right-sized when it is:
- Completable within a few days.
- Assignable to one owner.
- Independently verifiable.
- Estimable without further decomposition.
1. Project
├── 1.1 Planning and preparation
│ ├── 1.1.1 Kick-off
│ ├── 1.1.2 Requirement confirmation
│ └── 1.1.3 Access and tooling
├── 1.2 AWS account setup
│ ├── 1.2.1 Organisation and accounts
│ ├── 1.2.2 Identity and SSO
│ └── 1.2.3 Guardrails
├── 1.3 Network and baseline IaC
├── 1.4 Migration execution
├── 1.5 DevOps practices and design
├── 1.6 Security and observability
├── 1.7 Testing
├── 1.8 Knowledge transfer
└── 1.9 Closure
WBS dictionary
Each element has an entry. The dictionary is what prevents two people from believing they agreed on the same thing.
| Field | Content |
|---|---|
| WBS ID | Unique identifier |
| Task description | What the work is and what it achieves |
| Assigned resources | The person or team accountable |
| Timeline | Start and end dates |
| Dependencies | Work that must complete first |
| Deliverables | Outputs produced |
| Acceptance criteria | Conditions that make it complete |
| Cost estimate | Effort or cost, if applicable |
| Risk | What could affect this task |
| Status | Not started, in progress, blocked, complete |
Example entry
| Field | Value |
|---|---|
| WBS ID | 1.3.2 |
| Task | Provision production VPC and subnets across two AZs |
| Resources | Cloud engineer |
| Timeline | 14–18 July |
| Dependencies | 1.2.1 accounts created; 1.2.2 identity configured |
| Deliverables | Terraform module; deployed VPC; network diagram |
| Acceptance | Subnets in two AZs; flow logs on; no public IPs on workload subnets; terraform plan clean |
| Cost | 2 days |
| Risk | CIDR overlap with existing on-premises ranges delays the design |
| Status | Not started |
Estimation
| Method | Use |
|---|---|
| Analogous | A similar task on a previous engagement; adjusted for differences |
| Parametric | Per-environment, per-service or per-pipeline rate |
| Three-point | Optimistic, likely and pessimistic, weighted for uncertain work |
| Decomposition | Break down further until the estimate is confident |
Estimates are stated in days and carry an explicit assumption. An estimate without an assumption is a number that cannot be defended when it changes.
Dependencies
The critical path determines the schedule. Typical dependencies in a DevOps engagement:
accounts → identity → network → baseline IaC → workload migration
↓
pipelines → security controls → testing
↓
observability → runbooks → handover
Access is the most common hidden dependency. If account access takes two weeks, every task after it moves by two weeks, and the plan that ignored it was never realistic.
Tracking
| Level | Cadence | Owner |
|---|---|---|
| Task | Daily / weekly stand-up | Assignee |
| Phase | Weekly status report | Project manager |
| Milestone | Per milestone review | Sponsor and PM |
| Change | Per change request | Change manager |
Progress is measured by completed deliverables, not by elapsed time or percent complete. "80% done" is a feeling; "the VPC module is merged and deployed to staging" is a fact.