3WORK BREAKDOWN STRUCTURE

A Work Breakdown Structure (WBS) is a decomposition of all the work necessary to complete a project. A WBS is arranged in a hierarchy and constructed to allow for clear and logical groupings, either by acti ities or deli erables. !he WBS should represent the work identified in the appro ed "roject Scope Statement and ser es as an early foundation for effecti e schedule de elopment and cost estimating. "roject managers typically will de elop a WBS as a precursor to a detailed project schedule. !he WBS should be accompanied by a WBS #ictionary, which lists and defines WBS elements. !he goals of de eloping a WBS and WBS #ictionary are $) for the project team to proacti ely and logically plan out the project to completion, %) to collect the information about work that needs to be done for a project, and &) to organi'e acti ities into manageable components that will achie e project objecti es. !he WBS and WBS #ictionary are not the schedule, but rather the building blocks to it. !he progression of WBS and WBS #ictionary de elopment is as follows(
WBS WBS (#iagram (#iagram or or /ist) /ist) )$al #efine comprehensi e list of project acti ities WBS WBS #ictionary #ictionary )$als #escribe task Se.uence acti ities 4stimate duration 4stimate resources 5dentify constraints #etailed #etailed Schedule Schedule )$al 5ntegrate detailed list of project acti ities, dependencies, constraints, and resources to reflect complete timeframe

!he WBS and WBS #ictionary should not be static documents. WBS construction is subject to project management progressi e elaboration, and as new information becomes known, the WBS should be re ised to reflect that information. A "roject !eam that has substantial changes to its WBS should reference the project)s *hange +anagement "lan for guidance on management of changes to project scope.

EXAMPLE
Below is a simplified WBS e,ample with a limited number of organi'ing le els. !he following list describes key characteristics of the sample WBS( Hierarchical Levels - contains three le els of work Num eri!" Se#ue!ce - uses outline numbering as a uni.ue identifier for all le els /e el one is $.0, which illustrates the project le el. /e el two is $.1 ($.$, $.%, $.&, etc.), which is the summary le el, and often the le el at which reporting is done. /e el three is $.1.1 ($.$.$, $.$.%, etc.), which illustrates the work package le el. !he work package is the lowest le el of the WBS where both the cost and schedule can be reliably estimated. L$%es& Level Descri'&i$!s ( e,pressed using erbs and objects, such as 2make menu.3

Page 1 of 6

WBS NUMBER*N)
5n a WBS, e ery le el item has a uni.ue assigned number so that work can be identified and tracked o er time. A WBS may ha e arying numbers of decomposition le els, but there is a general scheme for how to number each le el so that tasks are uni.uely numbered and correctly summari'ed. Below is the general con ention for how tasks are decomposed( Level + - #esignated by $.0. !his le el is the top le el of the WBS and is usually the project name. All other le els are subordinate to this le el. Level , - #esignated by $.1 (e.g., $.$, $.%). !his le el is the summary le el. Level 3 - #esignated by $.1.1 (e.g., $.$.$, $.$.%). !his third le el comprises the subcomponents to each le el % summary element. !his effort continues down until progressi ely subordinate le els are assigned for all work re.uired for the entire project. 5f tasks are properly subordinated, most project scheduling tools will automatically number tasks using the abo e con ention.

WBS CONSTRUCT*ON METHODS

Although there are different methods of decomposing project work and creating a WBS, the most straightforward and effecti e way is to use some form of isual display of the deli erables, phases, or acti ities. 5deally, all "roject !eam members will con ene and brainstorm all work re.uired to complete project deli erables successfully. 5n ol ement of all team members in this process increases the likelihood that the resulting WBS will be comprehensi e. !ypically, team members start by identifying all project deli erables or milestones and then decompose them one

Page 2 of 6

at a time into a detailed and se.uential list of the detailed acti ities re.uired to complete the deli erable or milestone. 6ne way of isually conducting this process is by using post7it notes to represent each deli erable and sub7acti ity.

WBS T-PES
#eli erable7oriented WBS "rocess7centered WBS

DEL*.ERABLE/OR*ENTED WBS
A deli erable7oriented WBS is built around the project)s desired outcomes or deli erables. !his type of WBS would likely include the following characteristics( /e el % items are the names of all endor project deli erables that are e,pected to be re.uired as part of a contract. /e el % should also include any agency deli erables tasks. /e el & items are key acti ities re.uired to produce the /e el % deli erables. Additional le els are used depending upon the magnitude of the deli erables and the le el of detail re.uired to reliably estimate cost and schedule. 5n the deli erable7oriented WBS, all deli erables are identified, and all work is included. Statewide projects procured as 8irm78i,ed7"rice contracts are well suited to the deli erable7 oriented approach. 6rgani'ed this way, project managers and agency management can re iew interim progress against deli erables and easily determine the percentage of the work that is complete. Sometimes, a deli erable7oriented WBS and its associated schedule can be confusing to read because their items are not organi'ed se.uentially at the highest le el. !hey are, howe er, ery useful in demonstrating progress against contracted deli erables.

PROCESS/CENTERED WBS
A process7centered WBS is similar to a deli erable7oriented WBS e,cept that it is organi'ed, at the highest le el, by phases or steps in a process rather than by deli erables. !he benefit of using a process7centered WBS is that it encourages the inclusion of process7re.uired deli erables, such as System #e elopment /ife *ycle (S#/*) deli erables. 9egardless of the type of WBS employed, project teams should ensure that all contractual and S#/* deli erables are accounted for in the WBS. A process7centered WBS typically includes the following( /e el % acti ities are phases or schedule checkpoints:milestones. !hese acti ities could be S#/* phases such as 5nitiation, "lanning, etc. /e el & acti ities are those acti ities re.uired to complete /e el % phases or milestones. +ultiple tasks are included for any work that needs to be done in multiple phases. Additional le els are used depending on the duration of the phase or schedule and the le el of detail re.uired to reliably estimate cost and schedule. 5n the process7centered WBS, all deli erables are identified, and all work is included. !his comprehensi eness will reduce the risk of 2off balance sheet3 work tasks, which might ha e une,pected impacts on the project schedule.

Page 3 of 6

HOW MAN- LE.ELS0

!wo industry7standard methods e,ist for determining how many le els a WBS should ha e( !raditionally, the Project Management Body of Knowledge ad ocates a predetermined se en7le el model, which has the ad antage of clear labels and definitions of each le el (e.g., program, project, task, subtask, work product, and le el of effort); the disad antage to this model is that it re.uires a le el of detail that may be unnecessary. +odels:methods with predetermined le els and le el definitions make clear what information needs to be included and where, but they lack fle,ibility. !he more contemporary approach is to let the project characteristics dictate the number of le els used in the judgment of the "roject +anager. 5t is a good practice to identify the number of le els to be used so that a project maintains consistency when building the WBS. !he number of le els must be sufficient to allow the "roject +anager to reliably estimate schedule and cost and effecti ely monitor and control work packages.

HOW MUCH DETA*L0

!he WBS should be sufficiently detailed to allow the "roject +anager to reliably estimate schedule and cost. 6ne point of iew is that the lowest le el of project detail should be no more than <0 total hours of work and should be assignable to only one person. !his le el of detail allows the "roject +anager to easily assess what project work is complete, who is responsible for e,ecuting what work, and what tasks are at ariance with the baseline plan. Another good measure is the 2= - =03 rule, which recommends that the lowest le el of work should be no less than = hours and no more than =0 hours. /e el of detail for work packets should be documented in the WBS #ictionary or the "roject +anagement "lan.

SAMPLE WBS D*CT*ONARAs the "roject +anager and !eam discuss and define the WBS and address how many le els and how much detail should go into the WBS, the "roject !eam should create a WBS #ictionary to capture task characteristic information, including task names, work products, le el of effort, resources, dependencies, and others. !he WBS #ictionary should be consistent with the WBS. !he information captured in the WBS #ictionary will help the "roject +anager to later de elop the detailed baseline schedule. !he WBS #ictionary may be in table or e,cel format.

Page 4 of 6

WBS 12 Es&4 Level $5 E55$r&2 Res$urces Nee6e62 Descri'&i$! $5 Tas32 *!'u&2 De'e!6e!cies2 Ris32 WBS 12 Es&4 Level $5 E55$r&2 Res$urces Nee6e62 Descri'&i$! $5 Tas32 *!'u&2 De'e!6e!cies2 Ris32

$.$.$ <0 hrs Subject +atter 4,perts

Tas32 O%!er2 W$r3 Pr$6uc&s2

*reate "lan "roject +anager +S "roject "lan

#e elopment of a detailed project plan that lists all key resources, tasks, milestones, dependencies, and durations. Appro ed "roject *harter S+4s Appro al of Budget *hanges to 5! Apps plans and deli erables 5! Apps implementation releases, which conflict with implementation $.$.% W$r3 *&em2 +ake Budget $> hrs *86, *56, 4,ecuti e Sponsor #e O%!er2 W$r3 Pr$6uc&s2 "roject +anager 5!"9

elopment and documentation of the project budget based on plan and resources. Appro ed "roject *harter S+4s Appro al of "roject *harter *hanges to 5! Apps plans and deli erables 5! Apps implementation releases which conflict with implementation WBS Dic&i$!ar7 / Ta le 8$rma& E9am'le

WBS 8*ELDS WBS 1 + $.$ $.$. $ Tas3 PLANN*N) "lan and Super ise *reate "lan #e elopment of WBS, work package identification, schedule formulation, staffing projection, resource estimation. 8ollowed by de elopment of a detail project plan that list all the key resources, task, milestones, dependencies, and duration. #e elopment and documentation of the project budget based on plan and resources #e elopment of disbursement process for the project including acceptance:appro al forms. 6ngoing planning acti ities for the project including weekly meetings Descri'&i$! $5 Tas3 All &as3 ma!a"eme!& a!6 ma!a"eme!& ac&ivi&ies 9oll7up !ask WBS, WBS #ictionary, +S "roject "lan "roject +anager "roject +anager ?:A <0 hrs W$r3 Pr$6uc&s O%!ers Es&4 Level $5 E55$r&

$.$. % $.$. &

*reate Budget

5!"9

"roject +anager *86

<0 hrs

"repare #isbursement : 9econciliation *oordinate Acti ities

"urchase 6rders, #eli erable "roduct Acceptance 8orm +eeting +inutes

<0 hrs

$.$. <

"roject +anager

= hrs:week

WBS Dic&i$!ar7 / E9cel 8$rma& E9am'le

Page 5 of 6

SUCCESS CR*TER*A
!he key to a good WBS and WBS #ictionary is the engagement of project team members to comprehensi ely identify and discuss acti ities for the project. A "roject +anager must ensure that all the work that needs to be accomplished for the project is contained within the WBS #ictionary and is understood by team members. All work should ha e clearly defined duration, resources, dependencies, and le el of effort. A "roject +anager should elicit feedback from all team members to ensure that the WBS and WBS #ictionary are alid and comprehensi e prior to de eloping the detailed schedule.

Page 6 of 6