PMI I80 Breakfast Roundtable December 2006 Meeting Topic
The following content has been extracted from:
； The Project Management Institute Practice Standard for Work Break Down Structures
； The PMBOK? Guide – 2000 Edition
1.0 Project Charter (high level scope)
2.0 Statement of Scope (breaks down the high level scope defined in the charter)
3.0 Work Breakdown Structure is used to define project scope and to estimate to a cost and time
level (in terms of work packets)
5.0 Project tasks and schedule defined.
The WBS as defined in the PMBOK? Guide – 2000 Edition is:
A deliverable-oriented grouping of project elements that organizes and defines the
total work scope of the project. Each descending level represents an increasingly
detailed definition of the project work (Project Management Institute 2000)
The WBS is used in projects to define
； The project’s work in terms of deliverables (a measurable, tangible, verifiable outcome or result
that must be produced to complete a project or part of a project) and further decomposition of these
deliverables into components. Depending on the decomposition method used, it may also define the
project’s life-cycle process in terms of process deliverables appropriate to that project and organization
And is the basis for establishing:
o All the effort/cost to be expended on supporting processes and the creation of the deliverables.
o The assigned responsibility for accomplishing and coordinating the work.
The two goals of the WBS are:
; To ensure that the project includes all the work needed.
; To ensure that the project includes no unnecessary work.
The WBS is the primary Input to four core processes and one facilitating process:
； Activity Definition
； Resource Planning
； Cost Estimating
； Cost Budgeting
； Risk Management Planning
The WBS also serves to facilitate communication between the Project Manager and all Project
Stakeholders (regarding scope, dependencies, risk, progress and performance).
The WBS provides the project management team with a framework on which to base project status and progress reporting.
Preparing a WBS
； The WBS evolves through an iterative consideration of:
; The project’s purpose and objectives
; The functional/performance design criteria
; The project scope
; The technical performance requirements
; Other technical attributes.
A high level WBS can often be developed early in the conceptual stage of the project. Once the project is defined and specifications are prepared, a more detailed WBS can be developed.
； The following should stimulate thought when developing a WBS to manage the project: ; Think through the entire project (What is to be provided /what is required)? ; Think deliverables (What is to be provided/what is required?)
; Think with the end in mind. (How will this component contribute to the finished
; Think through the production of the deliverables.
； What methods will be used?
； What special processes?
； What quality requirements?
； What inspections?
; What are the constituent parts?
; How do the pieces work together?
; What needs to be done?
； Factors to be considered
; Each WBS element should represent a single tangible deliverable.
; Each WBS element should represent an aggregation of all subordinate WBS elements
listed below it.
; Each subordinate WBS element must belong to only one single parent (or superior) WBS
; The deliverable should be logically decomposed to the level that represents how they will
be produced (designed, purchased, subcontracted, fabricated). The portioning of
deliverables from higher levels within the WBS to lower levels must be logically related. ; Deliverables must be unique and distinct from their peers, and should be decomposed to
the level of detail needed to plan and manage the work to obtain or create them. ; Deliverables should be clearly defined to eliminate duplication of effort within WBS
elements, across organizations , or between individuals responsible for completing the
; Deliverables should be limited in size and definition for effective control—but no so small
as to make cost of control excessive and not so large as to make the item unmanageable or
the risk unacceptable.
; The WBS development process should provide a vehicle for flexibility, particularly when
the scope of the project effort may change. A well-managed project, however will
incorporate a rigorous change control processs to document and manage scope changes.
When work scope changes do take place, the WBS must be updated.
; Each entry in the WBS representing subcontracted or externally committed deliverables
should directly correspond to matching entries in the subcontractor’s WBS.
; All deliverables are explicitly included in the WBS.
; All significant reporting items (e.g. review meetings, monthly reports, test reports, and so
on) are included and identified in the WBS.
; All WBS elements should be compatible with organizational and accounting structures. ; A coding scheme for WBS elements that clearly represents the hierarchical structure when
viewed in text format should be used.
; Technical input should be obtained from knowledable technical subject matter experts
(SMEs) , and communicated to and validated by other key SMEs assigned to the project.