WBS och nedbrytning av projektets resultat

Någonting som är viktigt för en framgångsrik leverans av projekt är nedbrytning av resultatet i dess beståndsdelar. PMBOK® Guide kallar det här för WBS – Work Breakdown Structure, och principen förekommer även i många andra metoder. Det är en hierarkisk nedbrytning av omfattningen i projektet, och kan anta en grafisk trädform, en text-outline eller i vissa fall som en hiearki i Excel. 

En WBS är en leverabelorienterad nedbrytning, och består alltså inte av aktiviteter.  I PMBOK® Guide beskrivs ”work” så här:

 ”In the context of the WBS, work refers to work products or deliverables that are the result of activity and not to the activity itself.”

Fokus i WBS:en ligger alltså på resultaten av aktiviteterna. Däremot kan vissa ”metaleverabler” finnas som t.ex. projektledning, som man kan se som den administration som krävs för att få samtliga leverabler på plats. Det blir lätt förvirrande, och därför har t.ex. projektmetodiken PRINCE2 valt att helt fokusera på utkomsten av projektet och istället namngivit deras nedbrytning PBS – Product Breakdown Structure. Den gör det tydligare att det är produkten, och bara produkten, som levereras som ska brytas ner.

I vissa situationer så är det inte helt lätt att definiera resultatet som ett projekt i termer av produkt, t.ex. för organisatoriska förändringsprojekt. Då kan man flytta fokus till resultatet snarare än produkter eller leverabler.

En generell fördel med att bryta ner projekt i mindre delar är att det är lättare att estimera, det underlättar kommunikation kring projekten och det förbättrar uppföljningen under exekveringen. Eftersom en av de viktigaste fördelarna med WBS:er är som ett verktyg för kommunikation, så kan ett projekt ha flera typer av WBS:er som belyser omfattningen från olika perspektiv.

Själva nedbrytningen måste innebära att det som bryts ner resulterar i minst två delleverabler, och samtliga delleverabler måste tillsammans utgöra 100% av leverabeln som bryts ner. En WBS ska bara beskriva det som ingår i projektet, och inte sådant som man vet är utanför projektets omfattning.

I mjukvaruindustrin så kan det bli ännu mer krångligt, eftersom omfattningen kan brytas ner på flera olika sätt, t.ex. baserat på funktionalitet som har någon nytta för användaren (use cases, user stories, features, etc.), arkitekturell nedbrytning (komponenter, klasser, etc.), strukturell nedbrytning (användargränssnitt, back-end, middle tier, etc.) o.s.v. Om var och en av dessa görs i form av en hierarkisk nedbrytning, så kvalar de in på konceptet WBS, men man måste då också veta vilken man använder för att estimera och följa upp projektet. Agila metoder förespråkar ett användarnyttoperspektiv, och nedbrytningen bör därför göras utifrån funktionalitet.

WBS:er är ett kraftfullt verktyg som gör det effektivare att arbeta i projekt. Skriv gärna kommentarer här på bloggen med er syn på hur man kan arbeta med nedbrytningar i projekt.

Skriv en kommentar

Du kan använda följande HTML HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>