Work Breakdown Structure Guide
Work Breakdown Structure Guide
What This Is
First of a series of six templates for project plan and schedule development. This guideline lists the
process steps for developing a work break down structure that identifies all the tasks in the project’s
work, the first step in creating a detailed project plan and schedule. Several Work Breakdown Structure
examples are provided to demonstrate the results.
Plan
Development Trade-offs, Optimization, and Risk Management
The Guideline and Template Content for Creating a WBS Starts on the Following Page
Plan and Schedule Development – (1) Task Identification and Work Breakdown Structure
The WBS is the first step in developing a detailed work plan for the project. Task Identification and WBS
Creation bridges from the early Scope definition to creation of a detailed project schedule.
Task Identification,
Project Work Breakdown
Task Task Task Work & Project
Scope Resource Relationships and Duration Schedule
Structure (WBS) Assignment Dependencies Estimates
Use the following top down approach to iteratively create your WBS:
Noun-Type
Physical Decomposition – product building with summary approach
Functional Decomposition – system functionality focus
Verb-Type
Design-Build-Test-Implement – methodology or lifecycle phase focus
Objectives – senior management or customer focus on reporting to deliverables
Others
Geographical – coordination and communication focus across locations
Business Function – focus on business process with integration complications
Departmental – focus is on organizational control of one manager
2. Identify the next level of work (Level 2) under each major component and list them under their
top-level groups. This can be done with indented lists or graphically in an organization chart.
Level 1 Level 1
Level 2-1
Level 2-2 Level 2 Level 2
Level 3-1
Level 3-2
Level 3 Level 3 Level 3
Level 3-3
The following is one possible work breakdown approach starting with project lifecycle phases at Level 1,
major deliverables of each phase as Level 2, and the activities, then tasks, to create each deliverable as
levels 3 and 4.
Phases Identify major phases of work (e.g. specify, design, build, test…)
Major Project Identify the major component deliverables of work required (e.g.,
Deliverables and subsystems that must be designed, built, tested, during each phase.)
related milestones
Activities Identify the activities needed to create those deliverables. (Some
interim, smaller deliverables such as documents may be involved.)
Level 1 – Phases: A project plan, or schedule, is made up of the deliverables and milestones of the
project, and depending on the level of detail required, the activities/tasks. Typically, this information can
be organized into a number of natural groupings. In project planning, each group is called a phase and a
name is given to it for ease of communication and reporting.
Level 2 – Deliverables & Milestones: Deliverables are the clearly defined and recognizable results or
tangible work products of successfully completed activities/tasks performed during the project. They
appear on a project plan in the past tense, to represent the completed activity/task and the accomplished
result.
“Receivables” should also appear on the project plan. They are deliverables owed to the project by others
outside of the project (usually other project teams), and upon which the project is dependent.
Milestones are interim events or points in time during the project which identify the completion of a
significant segment. They are most useful as measuring or tracking points to gauge the progress of the
project.
Some milestones are “business-critical” milestones, in that they are not just a mechanism for giving the
team interim targets; they have special significance, such as a contractual date with a customer.
Different individuals may identify different numbers of milestones based on their role in the project. For
example, the project sponsor may identify three significant milestones as indicators of how the project is
progressing, whereas a team leader may identify eight milestones or checkpoints within a particular
phase.
A milestone should be identified to indicate the completion of each phase of the project.
Levels 3 and 4+ – Activities & Tasks: Each phase of a project is composed of a number of major
activities that will lead to achieving one or more deliverables. Activities are composed of a series of tasks
that are the lowest level of detail that can comfortably be managed. Team members who will be
performing the tasks should be involved in the activity/task planning process. Estimates of time to
complete each task should be based on typical work effort required and then may be adjusted to reflect
"real world" conditions.
The ultimate goal in breaking the work tasks down is to ensure that all of the work that is
needed to meet the project’s objectives is recognized and planned for accurately from the
beginning.
The level to which you break down elements of your WBS may result in some tasks having less detail and
longer duration, if the work in that area is clearly understood and represents well-known work in which the
team is experienced and successful.
One owner per task: The tasks must be defined such that they can be assigned to one person
who will be doing that work.
Clear measurable deliverable with measurement specified: The tasks must be defined such
that the task owner can be given completion criteria that are clear and measurable.
Small enough task duration for tracking: Task duration at lowest level should be less than 5%
of total project time, to ensure visibility into task progress, at a small enough resolution to
recognize quickly if the project is off track (e.g. 2 weeks if 1 year; 2 days if 2 months).
Greater levels of detail are generally required for projects which are:
larger
more risky
dissimilar to past projects
difficult to define (susceptible to change)
performed by internal work groups
planned for the near future
See the WBS completion checklist on the following page.
The WBS will continue to be updated during the Plan and Schedule development process; generally as
the process goes forward, additional tasks come to light and must be incorporated into the WBS.
The checklist below will help the team know that a WBS has been created that forms a sound basis for
the project’s schedule going forward.
Appropriate level of detail: Continue to break the work down until a task list is developed which
meets the following criteria:
one (and only one) owner can be assigned to each of the lowest level tasks
clearly defined outputs are evident for each task
quality can be monitored through performance criteria associated with each output
the tasks communicate the work to be accomplished to the person who is accountable
the likelihood that a task is omitted or work flow forgotten is minimized
each task is well enough defined and small enough so that estimates of duration are credible
the project is broken down to the level at which you want to track
as a general rule, the lowest level tasks should have durations between two and twenty days
and effort that equates to not more than 1 person week
No forgotten tasks: Project delays are often caused by forgotten tasks, rather than inaccurate
estimates. Ensure you have included tasks for:
planning the project
approval cycles
key project meetings
management/customer interfaces
quality inspections/fixing defects
training
management
test planning, development & execution
project reviews and project closing
See the following pages for several examples of Work Breakdown Structures
WBS Examples
The following WBS examples illustrate using the top-down breakdown approach for several different
project types.
IV. UTILITIES
A. Electrical
1. Rough In
2. Building inspection
3. Finish work
B. Plumbing
1. Rough in
2. Building inspection
3. Finish work
C. Gas
1. Rough in
2. Building inspection
3. Finish work
CONCEPT (Phase)
(Detailed deliverables and tasks here)
DESIGN (Phase)
(Detailed deliverables and tasks here)
See also a number of Work Breakdown Structure example files on the site.
1.1. Design
1.2. Development
1.2.1. Web Front End
1.2.1.1. Code Web Pages
1.2.1.2. Conduct Unit Test
1.2.1.3. Review Web Page design/functionality
1.2.1.4. Obtain User Signoff
1.2.2. SQL Database
1.2.2.1. Identify table relationships
1.2.2.2. Build database tables
1.2.2.3. Review Tables with project team
1.2.2.4. Obtain Signoff
1.2.3. Interfaces
1.2.3.1. Build Interfaces
1.2.3.2. Conduct Unit test of import/export functionality
1.2.3.3. Obtain Signoff
1.2.4. Reports
1.2.4.1. Code Reports
1.2.4.2. Conduct Unit test
1.2.4.3. Review Reports with project team
1.2.4.4. Obtain Signoff
1.4. Training
1.4.1. Create system documentation
1.4.1.1. Assemble Tech Specs
1.4.1.2. Develop System Flowcharts
1.4.1.3. Deliver Source Code
1.4.1.4. Complete System Documentation manual
1.4.2. Create training materials
1.4.2.1. Assemble Functional Specs
1.4.2.2. Develop “As Is” and “To Be” documentation
1.4.2.3. Update Business Processes
1.4.2.3.1. Write new business processes
1.4.2.3.2. Obtain User Signoff
1.4.2.4. Complete User Training Manuals
1.4.3. Train users
1.4.3.1. Train IT Support Staff
1.4.3.1.1. Identify trainees
1.4.3.1.2. Identify trainers
1.4.3.1.3. Construct training schedule
1.4.3.1.4. Train users
1.4.3.2. Train Business Partners
1.4.3.2.1. Identify trainees
1.4.3.2.2. Identify trainers
1.4.3.2.3. Construct training schedule
1.4.3.2.4. Train users
1.4.3.2.5. Verify user readiness
1.5. Implementation
1.5.1. Hardware
1.5.1.1. Determine hardware needs
1.5.1.2. Make Hardware selections
1.5.1.3. Purchase hardware
1.5.1.4. Deploy
1.5.1.5. Perform System test
1.5.1.6. Verify production readiness and signoff
1.5.2. Packaged Software
1.5.2.1. Determine software needs
1.5.2.2. Make software selections
1.5.2.3. Purchase software
1.5.2.4. Deploy
1.5.2.5. Perform System Test
1.5.2.6. Verify production readiness
1.5.3. Develop Implementation Plan
1.5.3.1. Construct Timeline
1.5.3.2. Identify Team
1.5.3.3. Identify Components
1.5.3.4. Finalize Plan
1.5.4. Installation
1.5.4.1. Convert hardware to production-ready status
1.5.4.2. Convert packaged software to production ready status
1.5.4.3. Install new programs into production environment
1.5.4.4. Verify code
1.5.4.5. Initiate limited production run for user acceptance
1.5.4.6. Turn over system to users
1.6. Post-Implementation
1.6.1. Verify System
1.6.1.1. Obtain user acceptance of production system
1.6.1.2. Log issues
1.6.2. Monitor system
1.6.2.1. Verify performance
1.6.2.2. Verify functionality
1.6.3. Project Wrap-up
1.6.3.1. Obtain Final Project Signoff
1.6.3.2. Document and Review Lessons Learned