Project Scope Statement vs. SOW: Which One Drives Your WBS?

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.

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.

Documents That Feed the WBS (and in what order) #

1. Project Charter → authorizes the project and sets high-level objectives and boundaries (useful context, not enough detail).
2. Scope Statement (main source) → defines scope, deliverables, acceptance criteria, exclusions (perfect for decomposition).
3. SOW (when vendors) → adds contractual tasks and deliverables to integrate into the WBS.
4. Requirements Documentation → refines work packages (e.g., specs, user stories).
5. 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

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

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.