Work Breakdown Structure (WBS)
- Work Breakdown Structure (WBS)
- the management
work product
that provides an exhaustive, hierarchical (top-down) tree structure overview
of the work to be performed to complete an
endeavor
The typical objectives of a work breakdown structure are to
document the:
- Structure of the endeavor in terms of
hierarchically-decomposed WBS elements:
-
Work
Products,
(e.g., systems, subsystems) to be produced and
delivered
-
Work Units,
(e.g., activities and their component tasks and
subtasks) to be performed
- Planned and actual start and end dates (optional)
- Responsibilities of the endeavor teams (optional)
The typical benefits of a work breakdown structure
include:
- A WBS provides a clear understanding and statement of the
objectives and scope of the endeavor major in terms of its
hierarchical decomposition.
- A WBS provides a way of reporting work plans to executive
management and the customer organization.
- A WBS visually summarizes the status of work to be
done.
- A WBS clarifies the logical relationships between and
among work units and work products.
- A WBS supports planning and work assignment.
- Each line in the WBS provides a logical summary point
for:
- Assessing technical status.
- Extimating and measuring associated cost and schedule
performance.
A work breakdown structure typically has the following
contents:
- Work Breakdown Structure:
- WBS Element (e.g., Systems, Subsystems,
Subsubsystems, Activities, Tasks, and/or Subtasks):
- Name and/or brief description
- Planned start and end dates (optional)
- Responsible team (optional)
- Appendices:
- Major Issues
- TBDs
- Assumptions
A work breakdown structure typically has the following
stakeholders:
- Producer:
- Evaluators:
- Approvers:
- Maintainers:
- Users:
A work breakdown structure is typically produced and
maintained during the following phases:
A work breakdown structure can typically be started if the
following preconditions hold:
A work breakdown structure typically has the following
inputs:
- Work Products:
- Stakeholders:
- Planned and actual start and stop dates are optional on
the WBS. They m
- Use a standard project management tool to create and
maintain the WBS when the endeavor is not trivial in size and
complexity.
- A large WBS should typically be produced in the form of a
hierarchically indented list, whereas A small WBS can also be
produced in the form of a chart (e.g., a hierarchical
decomposition tree). A WBS may also be produced in the form
of a table.
- A WBS should primarily be hierarchically organized by
work products or by work units. Although a combination of
work products and work units is often used, care should be
taken to avoid any redundancy or overlap between WBS elements
except that which is implied by the decomposition
relationships between WBS elements.
- Use a work-product-oriented WBS when the endeavor exists
to develop and deliver a system. Use a work-unit-oriented WBS
when the endeavor exists to provide a service.
- When developing a WBS by work product decomposition:
- Start with the system (or system of systems) and
decompose until reaching the appropriate level.
- Include data, hardware, and software components within
the appropriate aggregate element rather than in a separate
WBS hierarchy. For example, a radar subsystem should
include both its hardware and software components.
- If a WBS is organized by work products, then the
following should
NOT be elements of the WBS:
- Documentation, which should be included with the
associated system, subsystem, etc.
- Phases of development
- Activities
- Cost savings efforts such as total quality management
(TQM), quality assurance, and warranties
- Rework, retesting, and/or refurbishing, which should be
included in the appropriate work product
- Organizational structure elements such a teams
- Secondary costs (e.g., computer support, meetings,
travel, etc.)
- Support facilities
- Where practical, specify the tasks in terms of the work
products being produced, possibly in terms of percent
completed.
- Include lines for all deliverable work products.
- Do not use the WBS to micro-manage the project; limit the
tasks on the WBS to those having a reasonable duration.
- Do not break down the work more than three levels unless
the endeavor is very large or the associated WBS elements are
of high cost or high risk.
- Begin developing the WBS early in the endeavor and
maintain it as a living document that evolves during the
endeavor lifecycle.
- Keep the WBS consistent with the endeavor process and
system architecture.
- It is difficult to produce a work product oriented WBS
before the system architecture is reasonably well known,
because such a WBS is organized according to the hierarchical
decomposition of the system architecture.
- If not already defined in the endeavor glossary, produce
a WBS glossary that properly defines the elements used in the
WBS.
- Use actual endeavor system names and terminology rather
than generic terms to avoid semantic confusion. If necessary,
repeat the name of the higher-level WBS element as part of
the lower-level WBS element to avoid ambiguity.
- Uniquely identify WBS elements.
- There should only be one WBS per contract and endeavor.
Note that this allows a subcontractor to have his own
subcontract-specific WBS.
Work breakdown structures are typically constrained by the
following conventions:
- Work Flow:
- Identify major deliverables and accomplishments.
- Decompose each major deliveable and accomplishment to
identify its major subdeliverables and
subaccomplishments.
- Repeat step 2 at successively lower levels as long as
is appropriate (i.e., continue decomposition as long as
the terminal leaf nodes remain sufficiently significant
to require management oversight).
- Optionally add ancellary information (e.g.,
deliverable, start and stop dates, cost, responsible
team), especially to the terminal nodes.
- Develop a hierarchical list or chart showing the
decomposition relationships between the deliverables and
accomplishments.
- Evaluate the resulting WBS against the WBS standards
and guidelines.
- Test the WBS to ensure that it will result in the
fulfillment of the endeavor’s mission or
objectives.
- Iterate and maintain the WBS as necessary.
-
Content and Format Standard
-
XML Template
-
Inspection Checklist
The following are simple examples of work breakdown
structures:
The following is a simple (three level) WBS for building a
science fair volcanoe. This WBS uses a decomposition tree
graphic to document the associated components. A real endeavor
WBS would be much larger and more complex.
The following is a simple (three level) WBS for having a
child’s birthday party. This WBS uses a hierarchically
indented list to document the associated work units. A real
endeavor WBS would be much larger and more complex.
- Birthday Party:
- Guests:
- Create guest list
- Fill in invitations
- Deliver invitations
- Confirm attendance with parents
- Location:
- Select location
- Clean location before party
- Decorated location
- Clean location after party
- Shopping:
- Make shopping list
- Buy presents
- Order cake
- Pick up cake
- Buy ice creme
- Buy decorations
- Buy party favors
- Celebration:
- Greet guests
- Collect presents
- Light candles
- Bring in cake
- Sing happy birthday
- Blow out candles
- Eat cake and ice creme
- Unwrap presents and thank guests
- Play party games
The following is a more realistic, although still very
small, WBS for a student project to conduct benchmarking
research on county e-government Web sites and then to present
the results in a Web site. More information about the project
can be found at
Innovations in eGovernment.
The following is typical of the output from a simple WBS
tool. More information about the tool can be found at
WBS Chart
Pro.
