Metodene og mekanismene for å operasjonalisere et kontrollregime tilpasset smidig utvikling, finnes allerede. Bruk det.
«Statens prosjektledere har blitt sittende med sine smidige-team og scrum-metodikk og forsøker å manipulere, dikte opp og tåkeprate rapporteringen inn i fossefalls-rammer», skriver Digi-journalist Marianne Gjessing i analysen om UDIs milliardsatsing i spagat mellom smidig og fossefall.
Nemlig. Slik blir det når statens prosjektmodell legger til rette for plan-drevet rapportering og styring. Det ødelegger for det smidige potensialet vi ønsker å utnytte, men som krever verdi-drevne metoder for oppfølging.
Det er symptomatisk i debatten at det sjelden skilles mellom prosjektmodell og utviklingsmetodikk. Men selv om man i prosjekter benytter samme rammeverk for utvikling som XP, Scrum eller SAFe, kan prosjektene likevel måtte styres og kontrolleres ulikt.
Spesielt viktig for digitaliseringsprosjekter er hvor klare målene og løsningen er før gjennomføring. I boka Effective Project Management beskriver Robert K. Wysocki prosjektlandskapets fire kvadranter:
Prosjektlandskapet, Illustrasjon: Stefano A. Donati
Hvis målene og løsningen er klare, er prosjektet «tradisjonelt». Hvis målene er klare mens løsningen er uklar, er prosjektet «smidig». Hvis både målene og løsningen er uklar, er prosjektet «utforskende». Hvis løsningen er klar, men man må finne ut hvordan den bør brukes, er prosjektet «utprøvende».
Wysocki definerer så fem styringsmodeller basert på PMBOKs prosessgrupper, med ulike tilbakekoblinger i prosjektsyklusen.
Den lineære og den inkrementelle modellen egner seg for styring og kontroll av fossefallsprosjekter. Den iterative og den adaptive egner seg for smidige prosjekter, der sistnevnte håndterer størst usikkerhet i mål og løsning. Den ekstreme egner seg for R&D.
Wysockis fem styringsmodeller. Illustrasjon: Stefano A. Donati
Usikkerheten, behovet for kundeinvolvering og behovet for koordinering av utviklingsteam øker etter hvert som man går fra den lineære modellen til den ekstreme. Modellene setter klare føringer og begrensninger på blant annet:
- Hvordan prosjektnedbrytning (PNS) gjøres, slik at det ikke blir konflikt med intensjonene i den valgte modellen.
- Hvor tidlig i prosjektsyklusen kravnedbrytningen kan finne sted.
- Hvilke utviklingsrammeverk og artefakter (mekanismer og metoder for å måle prosjektets tilstand og fremdrift) som bør velges.
Verken statens prosjektmodell eller prosjektveiviseren tilbyr eksplisitte regler for tilpasning langs de linjene Wysocki trekker opp. Det er hovedproblemet!
Men la meg være mer spesifikk for digitaliseringsprosjekt.
Bytt ut konseptfasen med en ambisjonsfase
I konseptfasen vurderes løsninger. Skal man bygge en forbindelse over en fjord, må man utrede om man skal bygge tunnel eller bro. Mange digitaliseringsprosjekt er imidlertid i kvadrant Q2, der målet om at «man skal komme seg over i løpet av 10 min» er kjent, mens løsningen er ukjent. I et digitaliseringsprosjekt kan man like gjerne ende opp med å bygge det som ville tilsvare fem ziplines istedenfor bro eller tunnel. Den løsningen var ikke noe man med sannsynlighet kunne tenke seg til på forhånd.
Er prosjektet i kvadrant Q1, kan konseptfasen gjennomføres. Men fra konseptvalgutredningen (KVU) starter til gjennomføring begynner, går det 2,5 til 3 år. I løpet av den tiden vil sannsynligvis ny digitaliseringsteknologi ha kommet på markedet som gjør KVU-en utdatert.
Da burde man heller brukt mye mindre tid på en «ambisjonsfase», der man sa noe om verdien av å «krysse fjorden» på henholdsvis 15 minutter, 5 minutter og sågar 0 minutter, uten å diskutere løsning. For digitaliseringsprosjekter med stort mulighetsrom er det utvilsomt nyttig å forstå samfunnseffekten av relativt sett små eller til og med umulige forbedringer, som å «krysse fjorden på 0 minutter».
Legg til rette for verdidrevet rapportering
I forprosjektet lages styringsunderlag for det valgte konseptet. I veilederen for digitaliseringsprosjekter i statens prosjektmodell står det:
«Det vesentlige er at PNS og tilhørende kostnadsestimater gir styrbare «pakker», som gjør det mulig å styre prosjektets fremdrift og kostnadspådrag underveis i gjennomføringen, …».
Feil. Det vesentlige er at investeringene genererer akseptabel forretningsverdi. Det gjelder generelt, og spesielt for smidige utvikling, der det ofte ikke er mulig å måle progress annerledes. Det er derfor god smidig ledelse fokuserer på verdiene som skapes, og mindre på avvik fra planene.
Videre står det om PNS: «Eksempelvis kan dette være en overordnet beskrivelse av leveransepakke (epos), brukerhistorier og hvordan man spesifiserer dette inn i utviklingskrav.»
Epos og brukerhistorier er funksjonelt orienterte krav. En funksjonsorientert PNS krever at det foreligger en forholdsvis moden kravnedbrytningsstruktur (RBS). Det premisset oppfylles kun av prosjekter i kvadrant Q1.
Å skape verdi stegvis, samt etablere MVP-er (Minimum Viable Product), har blitt beste praksis. For å legge til rette for verdidrevet rapportering, må prosjektene brytes ned på den verdiskapningen som skal finne sted.
Finansier prosjektet trinnvis
I verdidrevne prosjekter er det forventet at den akkumulerte verdiskapningen tar form av en S-kurve. Med artefakter som måler prosjektets verdiskapning, blir kontrollen opplagt:
Skapes det ikke nok verdi tidlig og kontinuerlig i gjennomføringen, så stopp tildelingen av midler og bruk pengene på noe annet!
Bruk kontrollregime tilpasset smidig utvikling
Det meste i statens prosjektmodell trekker i retning av plandrevet kontroll og styring. Det er årsaken til at vi ser svært lite til styring og kontroll basert på verdiskapning. Men relevant teori og erfaring med et kontrollregime bedre tilpasset smidig utvikling, finnes allerede. Bruk det! Innlegget er publisert på Digi.no 18. mai 2023.