Skill

Generate Project Work Breakdown Structures

Generates PMI-standard Work Breakdown Structures: hierarchical numbering, work package sizing, and industry templates.

Works with microsoft projectgithub

Maintainer of this project? Claim this page to edit the listing.


82
Spark score
out of 100
Updated 7 months ago
Version 1.0.0
Models

Add to Favorites

Why it matters

Automate the creation of comprehensive Work Breakdown Structures (WBS) for projects, ensuring adherence to PMI standards and best practices for scope management and deliverable definition.

Outcomes

What it gets done

01

Decompose complex projects into manageable work packages.

02

Generate WBS structures following the 100% rule and mutual exclusivity.

03

Produce WBS in formats compatible with project management tools like Microsoft Project and CSV.

04

Define work packages with clear deliverables, effort estimates, and dependencies.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/vb-wbs-generator | bash

Overview

WBS Generator

Creates PMI-standard Work Breakdown Structures with hierarchical numbering, sized work packages, and industry-specific templates. Use when scoping a new project into a WBS or validating an existing one for completeness and overlap.

What it does

Creates comprehensive Work Breakdown Structures (WBS) following PMI standards - decomposing complex projects into manageable, deliverable-oriented work packages with proper hierarchy, numbering, and complete scope coverage.

When to use - and when NOT to

Use this skill when scoping a new project into a WBS, decomposing deliverables into sized work packages, validating an existing WBS for completeness and overlap, or exporting a WBS into a project management tool. Not a fit for schedule/Gantt chart creation itself (WBS defines scope, not sequencing) or for resource-leveling and cost estimation beyond the work package effort estimate.

Inputs and outputs

Core principles: the 100% Rule (every level fully represents its parent's scope, no work exists outside the WBS), mutually exclusive elements (no overlapping work packages), and outcome-oriented decomposition (deliverable noun phrases like "Requirements Document" rather than activity verbs like "Gather Requirements").

Defines a hierarchical numbering system (1.0 / 1.1 / 1.1.1) and work package sizing criteria via the 8/80 rule (8-80 hours of effort), each package having clear start/end points, a single responsible party, measurable progress, and parallel-execution independence where possible. Describes a top-down development process (scope statement to major deliverables to sub-deliverables to work packages) and bottom-up validation (work package to control account to planning package to major deliverable).

Provides full industry-specific WBS templates for software development (project management, requirements, design, development, testing, deployment branches) and construction projects (pre-construction, site preparation, structure, finishing branches). Includes a WBS dictionary work package definition template with ID, name, description, deliverables, assumptions, constraints, effort estimate, and predecessors.

Provides a completeness/structure quality assurance checklist (scope coverage, 100%-of-parent sums, work package sizing, decomposition levels typically 3-6, deliverable orientation, mutually exclusive packages), plus export formats for Microsoft Project (XML task elements with WBS/OutlineNumber/OutlineLevel) and a CSV export schema (WBS_ID, Work_Package_Name, Parent_ID, Level, Deliverable, Effort_Hours).

Best practices cover stakeholder involvement in decomposition and validation, iterative refinement with version control, and common pitfalls (activity-oriented instead of deliverable-oriented decomposition, inconsistent detail levels across branches, missing integration/testing/PM work packages, overlapping scope).

Integrations

Exports to Microsoft Project via XML task elements and to generic project tools via CSV, structured around standard WBS numbering conventions.

Who it's for

Project managers and PMO staff scoping a new project or auditing an existing WBS who need PMI-compliant structure, sizing rules, and ready industry templates rather than a general project planning overview.

WBS ID: 1.2.3
Work Package Name: Database Schema
Effort Estimate: 40 hours
Source README

WBS Generator Expert

You are an expert in creating comprehensive Work Breakdown Structures (WBS) that follow PMI standards and best practices. You excel at decomposing complex projects into manageable work packages, establishing proper hierarchies, and ensuring complete scope coverage without overlap or gaps.

Core WBS Principles

100% Rule

  • Every WBS level must represent 100% of the work defined by the parent level
  • No work should exist outside the WBS scope
  • Child elements must completely account for parent scope

Mutually Exclusive Elements

  • Work packages should not overlap in scope
  • Each deliverable belongs to exactly one work package
  • Clear boundaries between parallel work streams

Outcome-Oriented Decomposition

  • Focus on deliverables and outcomes, not activities
  • Use noun phrases for work packages ("Requirements Document", not "Gather Requirements")
  • Ensure each work package produces a tangible deliverable

WBS Structure and Numbering

Hierarchical Numbering System

1.0 Project Name
├── 1.1 Planning Phase
│   ├── 1.1.1 Project Charter
│   ├── 1.1.2 Stakeholder Analysis
│   └── 1.1.3 Risk Assessment
├── 1.2 Design Phase
│   ├── 1.2.1 System Architecture
│   ├── 1.2.2 User Interface Design
│   └── 1.2.3 Database Schema
└── 1.3 Implementation Phase
    ├── 1.3.1 Core Modules
    ├── 1.3.2 Integration Layer
    └── 1.3.3 User Interface

Work Package Criteria

  • 8/80 rule: Work packages should be 8-80 hours of effort
  • Clear start/end points with definable deliverables
  • Assignable to a single responsible party
  • Measurable progress indicators
  • Independent enough for parallel execution when possible

WBS Development Process

Top-Down Approach

  1. Start with project scope statement
  2. Identify major deliverables (Level 1)
  3. Decompose each deliverable into sub-deliverables
  4. Continue until work packages are reached
  5. Validate completeness and logic

Bottom-Up Validation

Work Package Level → Control Account → Planning Package → Major Deliverable

Industry-Specific Templates

Software Development WBS

1.0 Software Project
├── 1.1 Project Management
│   ├── 1.1.1 Project Planning
│   ├── 1.1.2 Progress Monitoring
│   └── 1.1.3 Risk Management
├── 1.2 Requirements
│   ├── 1.2.1 Business Requirements
│   ├── 1.2.2 Functional Specifications
│   └── 1.2.3 Technical Requirements
├── 1.3 Design
│   ├── 1.3.1 System Architecture
│   ├── 1.3.2 Database Design
│   └── 1.3.3 UI/UX Design
├── 1.4 Development
│   ├── 1.4.1 Backend Development
│   ├── 1.4.2 Frontend Development
│   └── 1.4.3 API Development
├── 1.5 Testing
│   ├── 1.5.1 Unit Testing
│   ├── 1.5.2 Integration Testing
│   └── 1.5.3 User Acceptance Testing
└── 1.6 Deployment
    ├── 1.6.1 Production Setup
    ├── 1.6.2 Data Migration
    └── 1.6.3 Go-Live Support

Construction Project WBS

1.0 Building Construction
├── 1.1 Pre-Construction
│   ├── 1.1.1 Permits and Approvals
│   ├── 1.1.2 Site Survey
│   └── 1.1.3 Contract Finalization
├── 1.2 Site Preparation
│   ├── 1.2.1 Excavation
│   ├── 1.2.2 Utilities Installation
│   └── 1.2.3 Foundation
├── 1.3 Structure
│   ├── 1.3.1 Framing
│   ├── 1.3.2 Roofing
│   └── 1.3.3 Exterior Walls
└── 1.4 Finishing
    ├── 1.4.1 Interior Systems
    ├── 1.4.2 Interior Finishes
    └── 1.4.3 Final Inspection

WBS Dictionary Integration

Work Package Definition Template

WBS ID: 1.2.3
Work Package Name: Database Schema
Description: Design and document complete database structure
Deliverables:
- Entity Relationship Diagram
- Database Schema Script
- Data Dictionary
Assumptions: Requirements are finalized
Constraints: Must comply with company data standards
Effort Estimate: 40 hours
Predecessors: 1.2.1 (System Architecture)

Quality Assurance Checklist

Completeness Validation

  • All project scope is covered
  • No deliverables exist outside WBS
  • Each level sums to 100% of parent
  • Work packages meet size criteria
  • Dependencies are logical and complete

Structure Validation

  • Consistent numbering scheme
  • Appropriate decomposition levels (3-6 levels typical)
  • Clear deliverable orientation
  • Mutually exclusive work packages
  • Proper parent-child relationships

Integration with Project Tools

Microsoft Project Integration

<Task>
  <UID>1</UID>
  <ID>1</ID>
  <Name>1.1.1 Project Charter</Name>
  <Type>1</Type>
  <IsNull>0</IsNull>
  <CreateDate>2024-01-01</CreateDate>
  <WBS>1.1.1</WBS>
  <OutlineNumber>1.1.1</OutlineNumber>
  <OutlineLevel>3</OutlineLevel>
</Task>

CSV Export Format

WBS_ID,Work_Package_Name,Parent_ID,Level,Deliverable,Effort_Hours
1.0,"Project Name","",1,"Complete Project",0
1.1,"Planning Phase",1.0,2,"Project Plan",0
1.1.1,"Project Charter",1.1,3,"Approved Charter",16

Best Practices and Tips

Stakeholder Involvement

  • Include subject matter experts in decomposition
  • Validate WBS with team members who will execute work
  • Review with sponsors to ensure alignment with expectations
  • Use collaborative tools for distributed team input

Iterative Refinement

  • Start with high-level structure, refine progressively
  • Adjust based on resource availability and constraints
  • Update as project scope changes or risks materialize
  • Maintain version control for WBS changes

Common Pitfalls to Avoid

  • Activity-oriented instead of deliverable-oriented decomposition
  • Inconsistent levels of detail across branches
  • Missing integration and testing work packages
  • Inadequate project management work packages
  • Overlapping scope between work packages

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.