1. What They Are (and Who They’re For) #
Project Scope Statement (internal)
- Purpose: Defines what’s in scope, what’s out, the deliverables, and acceptance criteria for the project team and sponsor.
- How it’s used: It’s the primary input to create the WBS because a WBS is the decomposition of scope into manageable chunks.
Statement of Work (external)
- Purpose: A contract-facing document between client and vendor that spells out deliverables and obligations.
- How it’s used: When vendors are involved, the SOW provides contractual deliverables and tasks that you’ll map into your WBS—especially on outsourced work.
2. Which One Generates the WBS? #
- If both exist: Build the WBS from the Project Scope Statement (it’s written for decomposition).
- If only an SOW exists: Build the WBS directly from the SOW. In that case, the SOW effectively is your scope baseline.
The document title doesn’t matter — clarity does. You can’t break down work until you know what’s in, what’s out, and what “done” looks like.
3. Documents That Feed the WBS (and in what order) #
- Project Charter → authorizes the project and sets high-level objectives and boundaries (useful context, not enough detail).
- Scope Statement (main source) → defines scope, deliverables, acceptance criteria, exclusions (perfect for decomposition).
- SOW (when vendors) → adds contractual tasks and deliverables to integrate into the WBS.
- Requirements Documentation → refines work packages (e.g., specs, user stories).
- Project Management Plan (after WBS) → your WBS then informs schedule, cost, and resource baselines.
Practical flow: Charter → (optional/when vendors) SOW → Scope Statement → WBS → Schedule/Cost/Resource Plans
4. Examples You Can Steal #
Example 1: Internal project using a Scope Statement
Scope Statement: “Develop and launch an e-commerce website with payment gateway, product catalog, and order management.”
1.0 Website Development
1.1 Requirements Gathering
1.2 UI/UX Design
1.3 Frontend Development
1.4 Backend Development
1.5 Integration & Testing
2.0 Deployment
2.1 Hosting Setup
2.2 Security Configuration
3.0 Training & Handover
Example 2: Vendor project using only an SOW
SOW excerpt: Deliverables include iOS & Android apps, API integration, admin portal. Out of scope: Legacy migration, user training. Acceptance: Must pass security audit and store approvals.
1.0 Mobile App Development
1.1 Requirements & Wireframes
1.2 iOS Development
1.3 Android Development
1.4 API Integration
1.5 Testing & QA
2.0 Admin Portal
2.1 UI/UX Design
2.2 Backend Development
2.3 Testing
3.0 Compliance & Release
3.1 Security Audit
3.2 App Store/Play Store Submission
5. Industry Reality Check #
- Construction/Government: Often have both documents. Scope Statement = internal governance; SOW = legal clarity.
- IT/Consulting: Frequently only SOW; it doubles as the scope baseline.
- Internal corporate projects: Typically Scope Statement only; no SOW needed.