HVA:

Dette er den første i en serie av instruksjoner for utviklingen av en prosjektplan. Vi vil forklare hva som må til for å kunne utvikle en arbeidspakkestruktur som identifiserer prosjektets arbeidsomfang.

HVORFOR:

Å dele opp arbeid ned i arbeidspakker og derfra ned i individuelle oppgaver uten detaljer som dato, avhengighet og navngitte ressurser hjelper oss å: Utvikle en objektiv og rasjonelt syn på mengden med arbeid som kreves. Støtte teamets evne til å forstå nødvendig ressurs behov og de kunnskaper som er nødvendig Gi et klart rammeverk for å tildele klare oppgaver med ansvar klart definert til ressurser Definere underlaget for å analysere oppgave avhengighet og for å kunne isolere og lede risiko Definere underlaget for å lage en ”fra bunn og opp” estimat for prosjektplanen

HVORDAN:

Nøkkelen til å gjøre en god WBS er å dele prosjektarbeidet inn i individuelle oppgaver FØR du begynner å vurdere datoer, ressurser, og oppgave avhengighet. Dette hjelper deg i å være objektiv og ikke la virkelig arbeid bli utelatt for å kunne skvise planen rundt en satt leveringsdato.

5.3.16 STRUKTUR

Det er mange syn på hvordan en WBS skal struktureres, det finnes ikke ett svar, men noen er bedre en andre. Her er noen eksempler på grupperings strukturer som kan brukes: Produkt eller komponenter Kronologisk Funksjonelle disipliner Organisasjonen Geografiske områder Kost konto Karakteristikker Leveranser Funksjon Subsystem av et produkt Kalendertid Faser Din organisasjon må definere hvordan de ønsker å strukturere arbeidet. Men prøv å fokuser på Faser, Organisasjon, Produkt og Leveranse som hovedregler for oppdeling. Du må kanskje kombinere flere strukturer på de forkjellige nivåene, dette er ikke feil på noen måte.

5.3.17 PROSESS:

Begynn med å dele hovedarbeidet inn i fornuftige pakker. Begynn ved å bruke Prosjektforslaget, Prosjektdefinisjonen og Prosjektprofilen som referanse.

• Få teamet til å dele opp prosjektet i oppgaver som reflekterer det som prosjektet skal levere.
• Identifiser 5-10 hovedarbeidsgrupper, primært satt opp med fokus på ”Hvordan” arbeidet vil organiseres.
• Identifiser så det neste nivået av oppgaver (nivå 2) og list disse opp under topp nivået (nivå 1).

Bruk så dette underlaget for å la teamet finne en fornuftig sekvens og organisering på oppgavene. Et godt utgangspunkt kan være å lage en indentert liste som er relativt enkelt og kan brukes av de fleste prosjektverktøy. Hovedmålet er å få teamet til å samarbeide om å tilføre deres syn på definisjonen av arbeidet som skal inn i prosjektet. I praksis gjøres dette gjerne i flere omganger hvor man ender opp med svært spesifikke oppgaver som har en spesifikk ressurs med 1-2 ukers varighet (80 timers regelen). En oppgave kan være mindre spesifikk og mye lengre en 2 uker om teamet har en klar forståelse for arbeidet som skal utføres samt representerer arbeid gruppen har mye erfaring med.

Målet er selvsagt å kunne bryte alt ned til pakker som kan enkelt kontrolleres, samt vise helt klart at man har inkludert alt det arbeidet som kreves for å kunne møte prosjektets krav. Hver oppgave må være identifisert, ha en ansvarlig ressurs knyttet til seg og ha ferdigstillelses krav som er klare og målbare. Den hierarki strukturen man ender opp med gir en logisk struktur på arbeidet og krever mange typer av input. Mange ganger er strukturen en miks av organisasjons strukturer og prosess strukturer.

DETALJ NIVÅ

Del vært nivå inn i ett fornuftig detaljnivå. Detaljer under en komponent kan deles opp i 3-4 nivå. Andre komponenter trenger kanskje bare ett nivå. Flere detaljnivå er generelt påkrevd for prosjekt som er:

• Store
• Risikofylt
• Ukjent
• Vanskelig å definere (endringer)
• Har høy gjennomføringshastighet

Fortsett å bryt ned nivåene til du har en oppgaveliste som oppfyller følgende kriterier:

• En og bare en eier er tildelt oppgavene på laveste nivå
• Det som skal leveres ut av oppgaven er klart definert
• Kvalitet kan monitorers gjennom de måleparameter som er satt
• Hver oppgave kommuniserer det arbeidet som hver enkelt skal gjøre
• Hver oppgave er så små at estimatet på tid og arbeid er til å stole på
• Prosjektet er delt opp til det nivået du ønsker å måle framdrift på

Det er en generell regel at de minste oppgavene ikke skal overstige 80 timers arbeid, 2 ukers varighet og bare en person er ansvarlig. Dette er ikke alltid lett, men mulig.

Ofte glemte oppgaver:

• Planlegging av prosjektet
• Godkjennelse
• Møter
• Kommunikasjon
• Opplæring
• Ledelse
• Testplanlegging
• Prosjektgjennomgang
• Prosjektavslutning

TIPS for god WBS/arbeidspakkestruktur

• En eier pr. oppgave
• Det som kommer ut av oppgaven skal være klart målbart med måleparameter klart definert.
• Den minste oppgaven i strukturen skal aldri være mindre en 5 % av total prosjektets varighet. F. eks 2 uker om prosjektet varer 1 år, 2 dager om prosjektet varer 2 måneder
• Status og ferdigstillelse er målbart
• Klart definert start og slutt
• Kost og tid er enkelt estimert

5.3.18 EKSEMPEL

Vi avslutter med et eksempel. Eksempelet viser strukturering basert på faser i nivå 2, mens nivå 3 viser hovedleveranser, nivå 4 viser detaljerte oppgaver.

Indentertliste Figur 5 7

WBS Figur 5 8

Kommentarer

Ludvig prosjektarbeider

0

 

 

Håper du kan legge inn flere eksempler, ser at det er mange måter å gjøre dette på...

lørdag 12 desember 2009, 14:36

Send svar

Navn *
Kode   

Send kommentar

Avbryt

Navn *
Kode   

Send kommentar