Dette innlegget beskriver kort en tilnærming som avdekker faktisk fremdrift i et prosjekt og benytter dette til å kvantifisere når og til hvilken kostnad et prosjekt faktisk vil bli ferdig.
Innlegget bygger på begrepet «omarbeid*» og kvantifiserer konsekvensen av manglende kvalitet i prosjektleveranser. Denne konsekvensen kan være svært stor, og det er overraskende at «omarbeid» ikke blir brukt mer styring av prosjekter.
Noen år tilbake var jeg var ansvarlig for et prosjekt som skulle introdusere et nytt produkt. En del av prosjektet forutsatte utvikling av et nytt IKT-system, anslått til 100 månedsverk (10 fulltidsekvivalenter i 10 måneder). Oppdraget med å utvikle det nye system var satt ut til en underleverandør og denne rapporterte innledningsvis god fremdrift. Noen måneder senere bremset fremdriften nesten helt opp og systemet var "mer enn 80 %" ferdig i nærmere ett år. Etter nærmere to år hadde prosjektet fortsatt ikke levert i henhold til spesifikasjon. Derav tittelen på dette innlegget. Hva skjedde?
*«Omarbeid brukes her for det engelske «Rework»
Teori
Vi vil først introdusere en modell for å forstå hva som skjedde i prosjektet over.
Et prosjekt skal utføre en viss mengde arbeid. Fremdriften i prosjektet avhenger av tre faktorer: Antall ressurser, produktivitet og kvalitet i utført arbeid. Dette er illustrert under.
Figur 1. Prosjekt som "flyt"
Kvalitet kan her angis med en indeks med en verdi mellom 0 og 1. En kvalitetsindeks lavere enn 1 innebærer at deler av utført arbeid må gjøres på nytt. Dette er en kjent problemstilling i f.eks. utvikling av programvare som sjelden blir levert feilfritt i første syklus av et prosjekt og hvor feil blir oppdaget i testing eller produksjon. Forskjellen mellom produktivitet og kvalitet er viktig. Prosjekt-teamet kan høy produktivitet (output), men levere med lav kvalitet som senere vil kreve omarbeid. Figur 1 kan dermed utvides som vist under:
Figur 2. Omarbeid
Figuren illustrerer at deler av det arbeidet som er rapportert som «ferdig utført» ikke nødvendigvis er ferdig, men bør kategoriseres som «Uoppdaget omarbeid». I de fleste prosjekter er omfanget av «Uoppdaget omarbeid» ikke estimert og heller ikke hensyntatt i planlegging og rapportering.
På et tidspunkt blir manglende kvalitet i leveranser oppdaget, arbeidet blir kategorisert som «Oppdaget omarbeid» og må rettes opp av prosjektet. Tiden det tar før dette blir oppdaget (forsinkelsen) har en stor effekt på prosjektets varighet.
LES OGSÅ: To årsaker til dårlige prosjektplaner og Om (mangel på) rasjonalitet i prosjektstyring
Praksis
Tilbake til prosjektet i innledningen: Systemutviklingen var budsjettert med 10 personer i 10 måneder. Dette er illustrert under. X-aksen er måneder, y-aksen er månedsverk, og planlagt fremdrift er gitt ved den røde linjen.
Figur 3. Budsjett
Prosjektteamet hadde flere deltakere som hadde liten erfaring med utviklingsmiljøet, og med testing. Det resulterte i at kvaliteten i leveransene var lavere enn forutsatt. I etterkant ble kvalitetsindeksen i prosjektet anslått til å være i størrelsesorden 0,4 – 0,5*. Det tok også i snitt ca. 5 måneder før feil ble oppdaget.
*Anslaget ble gjort bl.a. basert på faktisk vs. rapportert fremdrift. Tallet på 0,4 er lavt, men ikke eksepsjonelt.
Når disse to parameterne (kvalitetsindeks og tid før omarbeid blir avdekket) er kjent, er det mulig å kvantifisere konsekvensene for prosjektet. Figur 4 viser beregnede tall for dette prosjektet:
Figur 4. Faktisk fremdrift i prosjektet
- Jf. Figur over: De første fem månedene ble ikke noe vesentlig omarbeid oppdaget, og rapportert fremdrift var iht. budsjett. Den blå linjen for Budsjett/Prognose er horisontal, på 100 månedsverk.
- I måned 6 ble det første behov for omarbeid oppdaget. Dette utgjorde 6 månedsverk (10 personer x 1 mnd x 0,6). Prognosen (blå linje) ble justert tilsvarende.
- Ved periode 10 (planlagt ferdig) var prognosen økt til 130 månedsverk og rapportert fremdrift var 70 %. Faktisk (reell) fremdrift var på dette tidspunkt 40 % ifølge modellen.
- Deretter ble det løpende avdekket ytterligere behov for omarbeid, og prognosen måtte justeres løpende. I figuren er prognosen justert til nær 250(!) månedsverk i periode 30.
Det er viktig å understreke at det ikke var noen bevisst feilrapportering.
Figur 5. Fremdrift % - faktisk og rapportert
Hvis man ser på faktisk og rapportert fremdrift i % får man et bilde som vist i figur 5. Den øverste (grå) linjen viser rapportert fremdrift og den nederste (røde) linjen viser faktisk fremdrift. Det er verdt å merke seg at hvis man måler fremdrift som (faktisk ressursbruk/prognose) vil man rapportere en fremdrift som er 80 % eller høyere allerede fra og med periode 13. Et korrekt mål på fremdrift forutsetter et korrekt estimat på samlet innsats ved prosjektslutt.
For å sammenfatte:
- Omarbeid følger av dårligere kvalitet i leveranser enn forutsatt. Dette kan skyldes mangel på kompetanse, utstyr osv.
- Omarbeid kan bli svært omfattende og er ofte en av de viktigste årsakene til at prosjekter ikke leverer på sine målsettinger. I dette prosjektet ble endelig omfang nær 2,5 x opprinnelig plan.
- Omarbeid blir sjelden identifisert og tatt inn i løpende prosjektplanlegging og -rapportering.
- Omarbeid og tiden det tar før dette blir oppdaget forklarer «90 % ferdig» syndromet, dvs. at prosjektet rapporterer «90 %» fremdrift altfor tidlig – og deretter bare rapporterer langsom fremdrift.
Hva kan vi gjøre for å håndtere dette?
Konsekvensen av teori og erfaringer fra «omarbeid» er at prosjektleder må:
- Forstå mekanismene som beskrevet over.
- Etablere målinger for å anslå omfanget av merarbeid (kvalitetsindeksen for prosjektet), og hvor lang tid det tar før man oppdager dette*.
- Korrigere både planlegging og rapportering av fremdrift tilsvarende.
For mer informasjon om «omarbeid», se f.eks.:
https://www.scribd.com/document/231222892/Managing-the-Rework-Cycle
*Det finnes erfaringstall for kvalitetsindeks i ulike typer prosjekter. Programvareutvikling ligger ofte i intervallet 0,4 – 0,9. forsvarsprosjekter kan være i intervallet 0,1-0,3.
