Hur skapar man en riktigt bra WBS?
Ett av de bästa verktygen för en projektledare är WBS:en.
Den började användas på i amerikanska försvaret på 50-talet, letade sig in på
NASA, och blev givetvis en del av best practice när PMI tog fram sin PMBOK®
Guide.
En WBS bör helst inte innehålla aktiviteter, utan ska
fokusera på leverabler eller resultat. På så sätt är det lättare att beskriva
acceptanskriterier för det som levereras. ”Att städa ett rum”, säger ingenting
om hur städat ett rum faktiskt blir, och vad man ska fokusera på, medan ”ett
rent golv” förutsätter undanplockning, dammsugning och kanske till och med att
man våttorkar. En bra WBS ska i de flesta fall styra diskussionerna mot VAD som
ska göras, och inte HUR det ska utföras.
För att få fram en riktigt bra WBS är det ofta en bra idé
att blanda in representanter för de olika kompetensområden som ett projekt
täcker. Det är också bra att försöka enas om vad som ska levereras på en
övergripande nivå, vilket kan kräva en del kravinsamling, undersöka alternativ
och gärna även konceptuella visualiseringar.
Hur tar man fram WBS:en?
En WBS kan byggas uppifrån och ner (bryta ner resultatet i
dess beståndsdelar), eller nedifrån och upp (att komma på delleverabler som man
sedan aggregerar upp), och i de flesta fall är en kombination av dessa två
angreppssätt att rekommendera. När man börjar uppifrån och ner, så är bra
frågor att utgå ifrån: ”vad kommer projektet att leverera?”, ”vilka
förändringar blir en konsekvens av projektet?” eller ”vad behövs för att kunna
leverera projektet?”.
Det är viktigt att komma ihåg att man kan bryta ner samma
projekt på lite olika sätt beroende på vilken ”lins” man betraktar ett projekt
genom, och att det därför i teorin kan finnas flera WBS:er för ett projekt
beroende på användningsområde.
För att tydliggöra det här kan ett exempel vara ett företag
som vill ta fram en webshop för att sälja till privatpersoner. De kan välja att
bryta ner det här projektet på lite olika sätt – antingen genom de komponenter
som resultatet består av (de servrar, mjukvaror, och bibliotek som används), de
sidor som webshoppen består av (kallas ibland också en sitemap) eller så kan
man bryta ner den funktionalitet man ska kunna utföra (t.ex. epics, features,
user stories).
Det är inte direkt så att någon av dessa nödvändigtvis är
mer korrekt än en annan, utan dessa perspektiv kan alla vara användbara i olika
situationer. För att kunna ta fram en bra WBS kan man behöva enas om vilket
perspektiv man ska utgå ifrån, eller så kan man prova att ta fram olika
versioner för att bedöma vilken som blev bäst.
En bra struktur för en WBS
Det man bör tänka på när det gäller själva strukturen är att
i den resulterande hierarkin finns det olika relationer mellan en förälder och
dess barn som kan variera lite beroende på projekt, domän och behov. Även inom
samma WBS kan man ibland kombinera olika angreppssätt. Här listas några möjliga
relationer:
1.En förälder består av sina barn
2.Ett barn behövs för att föräldern ska kunna
realiseras
3.Ett barn tillhör kategorin som föräldern
representerar
Här nedan beskrivs var och en av dessa lite mer i detalj.
1. En förälder består av sina barn
En relation där en föräldranod består av sina barn är den
mest klassiska relationen, och kan ibland även kallas PBS (Product Breakdown
Structure). En bil, t.ex., består bland annat av ett chassi, motor, växellåda.
En cykel av ram, styre, hjul och pedaler. Ett hus av husgrund, stomme, väggar,
tak, el, vatten och avlopp. Ibland kan beståndsdelarna fångas på lite olika
sätt, vilket exemplet med websidan tidigare visade (beståndsdelar kan vara
komponenter, funktionalitet eller sidor). Om man levererar konkreta leverabler
i ett projekt, så är det ofta bra att utgå från dessa, och bryta ner dem i sina
beståndsdelar som ett första steg i att ta fram en bra WBS.
2. Ett barn behövs för att föräldern ska kunna realiseras
I projekt krävs ofta vissa leverabler eller resultat under
projektets gång som krävs för att kunna leverera projektets resultat, men som
inte är en del av det. Det kan vara något av följande:
·tjänster som behövs under projektet, som t.ex.
projektledning, kvalitetssäkring eller inköp.
·leverabler som behövs under projektet, som t.ex.
projektdirektiv, projektplan, prototyper, kontrakt med leverantörer och
mötesprotokoll. Vissa leverabler används både under projektet men har ofta en
betydelse även efter projektet, som t.ex. bygglov, teknisk dokumentation och
·resultat/förändringar som behövs under
projektet, som t.ex. kompetenshöjning, buy-in från intressenter
3. Ett barn tillhör kategorin som föräldern representerar
Ibland kan man gruppera vissa resultat på ett annat sätt än
de som beskrivs ovan. Det kan handla om att gruppera sådant som ska göras på
olika sätt för att göra WBS:strukturen tydligare. Det kan t.ex. handla om att
gruppera efter fas, milstolpar, funktioner, prioritet eller plats. Även andra
egna kategorier kan underlätta förståelse, kommunikation och arbetet i
projektet.
Att tänka på
Förutom att ha ett bra angreppssätt att ta fram en WBS, och
att arbeta för att få till en bra struktur på WBS:en är det bra att tänka på
följande:
·En WBS är ett av de effektivaste sätten att
hålla ordning på projektets omfattning (scope), och det är därför en bra idé
att sätta en baselinje efter när projektets omfattning sätts, men också efter
varje granskning och godkännande av förändringar i projektet
·En WBS kan användas mer än bara som ett en del
av planeringen, det kan också vara ett kommunikationsverktyg för intressenter,
ett sätt att följa upp vad som levererats och ett sätt att tydliggöra leveranser
·Det går bra att arbeta med WBS även om man
arbetar agilt, och då kan man säga att WBS:en motsvarar backloggen, där
ordningen blir viktig. Tänk dock på att den traditionella bilden av en WBS är
att allt som ingår i WBS:en ska levereras (och att det därför formellt kanske
inte heller kan kallas en WBS enligt de flesta definitioner)
Viktigast av allt för att bli bra på att ta fram WBS:er är
nog ändå att träna på att använda det som ett verktyg, att använda det i
kommunikation med intressenter, och att utbyta erfarenheter med andra
projektledare.
Klas Skogmar, managementkonsult och utbildare inom projekt-, program- och portföljhantering.
2019-09-24