Foreldrepengeprosjektet og omlegging av leveransemodell
Torgeir Dingsøyr
Foreldepengeprosjektet var et av foreløpig fire moderniseringsprosjekter hos NAV hvor hovedmålsetningen var å lage en gjenbrukbar vedtaksløsning for individbaserte ytelser for foreldrepenger. Prosjektet gikk fra 2016, med en kostnadsramme på 1 316 millioner kroner, og fikk digitaliseringsprisen i 2019. I siste fase endret prosjektet leveransemodell fra en “førstegenerasjons”- til en “andregenerasjons” storskala smidig modell.
I 2016 vedtok Stortinget “oppstart av Prosjekt 2 i modernisering av IKT i Arbeids- og velferdsetaten”, senere omtalt som “Foreldrepengeprosjektet”. Arbeids- og sosialdepartementet beskrev prosjektet som “neste steg i modernisering av IKT i Arbeids- og velferdsetaten. I Prosjekt 2 er det planlagt å utvikle en gjenbrukbar vedtaksløsning for individbaserte ytelser. Vedtaksløsningen vil sammen med plattformen for digitale selvbetjeningsløsninger benyttes til å lage nye løsninger for foreldrepenger og engangsstønad”.¹ Prosjektet hadde en kostnadsramme på 1 316 millioner kroner, varte fra 2016 til 2019, og var et “ledd i en langsiktig og omfattende modernisering av IKT-systemene i Arbeids-og velferdsetaten. For å nå målene med NAV-reformen ble det i St.prp. nr. 46 (2004–2005) Ny arbeids- og velferdsforvaltning påpekt behov for modernisering av IKTløsningene i Arbeids- og velferdsetaten. Det ble vist til at dette ville være en krevende oppgave som ville måtte deles opp i flere store prosjekter og tas over tid.”¹
Den nye løsningen skulle erstatte deler av et system fra 70-tallet. Prosjektet ble planlagt med tre faser etter en “førstegenerasjons storskala smidig modell”² som kombinerte råd fra prosjektledelsesmodellen Prince² med råd fra utviklingsmetoder som Scrum og Ekstremprogrammering.² Leveransesmodellen ble endret til det vi beskriver som en “andregenerasjons storskala smidig modell”² i den siste fasen.
Materiale i det følgende er basert på publikasjoner fra kompetanseprosjektet Agile 2.0 som studerte utviklingsmetode i prosjektet, og hvor mer detaljert bagrunn finnes i en studie om endring i koordineringspraksis i prosjektet,² erfaringer fra omlegging til en “andregenerasjons”-modell,³ et “teaching case” om utviklingsmetode i store prosjekt⁴ og Concept-rapporten “Organisering av digitaliseringsprosjekter”.⁵
Prosjektet ble tildelt digitaliseringsprisen i 2019 for å ha «modernisert og digitalisert hele brukerreisen for kommende og nybakte foreldre».⁶
1 Det kongelige arbeids- og sosialdepartement: Stortingsproposisjon 67S (2015-2016): Oppstart av Prosjekt 2 i modernisering av IKT i Arbeids- og velferdsetaten.
2 Dingsøyr, T., Bjørnson, F.O., Schrof, J., and Sporsem, T.: ‘A longitudinal explanatory case study of coordination in a very large development programme: the impact of transitioning from a first- to a second-generation large-scale agile development method’, Empirical Software Engineering, 2023, 28, (1), pp. 49
3 Dingsøyr, T., Jørgensen, M., Carlsen, F., Carlström, L., Engelsrud, J., Hansvold, K., Heibø, M., Røe, K., and Sørensen, K.O.: ‘Enabling Autonomous Teams and Continuous Deployment at Scale’, IEEE IT Professional, 2022, 24, (6), pp. 47-53
4 Dingsøyr, T.: ‘Development method in a large-scale public sector IT programme’, Journal of Information Technology Teaching Cases, 2024.
5 Dingsøyr, T., Bjørnson, F.O., and Sporsem, T.: ‘Organisering av digitaliseringsprosjekter’, NTNU Concept Concept arbeidsrapport 2021-1, 39 sider.
6 https://www.cw.no/artikkel/priser-utmerkelser/digitaliseringsprisen-2019-til-nav
Prosjektmål og leveransesmodeller
Prosjektet hadde som målsetning å automatisere søknader om foreldrepenger, å la brukere administrere søknadene sine gjennom en selvbetjeningsløsning, og å gi bedre kvalitet og effektivitet i saksbehandling gjennom digitalisering.
Den første fasen av prosjektet brukte en leveransemodell med tradisjonelle prosjektstyringselementer, som faser og delprosjekter (se figur 1), kombinert med råd fra smidig programvareutvikling, som iterativ utvikling og involvering av prosjektorganisasjon og andre interessenter i jevnlige gjennomganger.³ Kravene til systemet ble beskrevet gjennom “epos”, som ble brutt ned i brukerhistorier og detaljert av domene-eksperter i delprosjekt “løsningsutforming”. Brukerhistoriene ble deretter overlevert til team i prosjekt “konstruksjon”. Teamene brukte Scrum og Extreme Programming (XP)-praksiser med tre-ukers iterasjoner. Løsningene som ble levert i første fase, ble satt i produksjon gjennom to store leveranser i en kompleks leveranseprosess. Prosjektet økte gradvis antall team, fra en innledende forprosjektfase med ett team høsten 2016, til ti team fra høsten 2018.
Figur 1. Organisering i første fase med utvalgte delprosjekter, figur modifisert fra ².
Innvendinger mot denne modellen var at få og store leveranser førte til forsinkelser i tilbakemeldinger på produktet, det var utfordringer i å koordinere arbeid mellom forretnings- og utviklingsprosjektene, og i siste fase ville prosjektet vedlikeholde en løsning i produksjon samtidig som de skulle lage ny funksjonalitet innen et område som var mindre utforsket enn tidligere. Dette utgjorde en høy risiko i prosjektet. Samtidig hadde NAV startet arbeidet med å endre den generelle leveransemodellen i retning av mer smidige tilnærminger. Prosjektleder satte da ned en arbeidsgruppe som ga anbefalinger om gjennomføring av siste fase.
I siste fase endret prosjektet leveransemodell til en “flytbasert modell” med kontinuerlig produksjonssetting av ny funksjonalitet. Dette førte til endringer for teamsammensetning, organisering, samt teknisk platform og arkitektur, men ikke i prosjektmilepæler eller planer for nyttestyring.³
Prosjektet hadde som målsetning å automatisere søknader om foreldrepenger, å la brukere administrere søknadene sine gjennom en selvbetjeningsløsning, og å gi bedre kvalitet og effektivitet i saksbehandling gjennom digitalisering.
Figur 2. Ny organisering med produktteam og støttefunksjoner. Fra forslag til ny leveransestrategi, gjengitt i ⁵.
Organisasjonsstrukturen i prosjektet gikk fra å skille team etter rolle og fase, til å kombinere roller fra forretning og utvikling i tverrfaglige autonome team, delt etter subdomene.³ De ti teamene hadde i snitt 12 medlemmer og ingen formell teamleder. Hvert team hadde sin egen produkteier.
Prosjektet ble fullført med suksess, med alle planlagte gevinster realisert innenfor tids- og kostnadsrammer. Brukerne opplevde at saksbehandlingstiden ble redusert fra måneder til sekunder. Et eksempel på et sentralt mål var graden av selvbetjening på søknader, som hadde et mål på 80%, men var 99,8 % våren 2019.3 Endringene opplevdes som vellykkede internt, der informanter rapporterte om en “mye tettere dialog” mellom forretning og utvikling, og at “det [prosessendringen] styrker utviklernes forståelse av domenet, produkteiernes forståelse av teknologien, man sparer mye tid og får gjort mer arbeid”.³
Lærdommer
En erfaringsrapport skrevet av forskere og deltakere i prosjektet trekker fram følgende lærdommer: ⁷
1) Start med et pilotteam og en nøye utvalgt leveranse
Prosjektet startet endringen mot en ny leveransemodell ved å etablere et pilotteam på et område med lav risiko. Teamet fikk frihet til å eksperimentere med smidige metoder og kontinuerlige leveranser, og lærte mye som resten av prosjektorganisasjonen kunne dra nytte av. Pilotarbeidet ga ledelsen trygghet på at endringene ville fungere. Samtidig førte ulik arbeidsmåte til utfordringer med koordinering og noe misnøye blant de øvrige teamene, som måtte følge mer tradisjonell utviklingsprosess.
2) Sørg for at tekniske forberedelser er på plass for å støtte overgangen Før overgangen til kontinuerlig leveranse måtte prosjektet koordinere sjeldne og store produksjonssettinger. For å muliggjøre hyppige leveranser ble det etablert en ny selvbetjeningsplattform og produktet ble delt opp i mindre, mer uavhengige moduler og mikrotjenester. Et erfarent teknisk team ledet arbeidet med nye prosesser, tekniske fora og et forbedret testregime, noe som la til rette for høy kvalitet og effektivitet i leveransene.
7 Lærdommer hentet fra referanse 3, automatisk oversatt men godkjent av forfatter.
3) Involver prosjektorganisasjonen tidlig og ofte i endringsprosessen
Prosjektet sikret tidlig og bred involvering i endringsprosessen ved å etablere en tverrfaglig arbeidsgruppe før beslutningen om ny leveransemodell ble tatt. Gruppen samlet inn ønsker og bekymringer, og utarbeidet en felles retning og plan for overgangen. Dette skapte eierskap, engasjement og en felles forståelse på tvers av organisasjonen, noe som var avgjørende for å lykkes med overgangen til kontinuerlig leveranse og autonome team.
4) Gi autonome team tilstrekkelig tid til å bli produktive
Prosjektet gikk fra separate forretnings- og utviklingsteam til tverrfaglige, autonome team for å møte behovet for tettere samarbeid og raskere leveranser. Overgangen var krevende, særlig med tanke på teamkultur og koordinering, men etter en innkjøringsperiode opplevde de fleste at de nye teamene leverte bedre. Autonomi ga teamene frihet til å tilpasse arbeidsprosesser, og fokus på produktdomene og redusert teknisk kompleksitet gjorde arbeidet mer effektivt. Kontinuerlig produksjonssetting og tettere samarbeid innad i teamene førte til økt effektivitet og bedre resultater.
5) Flytt fokuset fra tekniske leveranser til kontinuerlig arbeid med å levere brukerfordeler
Prosjektet flyttet fokuset fra tekniske leveranser til kontinuerlig arbeid med å realisere brukerfordeler, som automatisering, økt selvbetjening og færre feil. Gevinststyring ble integrert i prosjektet, og kontinuerlige leveranser ga mulighet for rask tilbakemelding og justering. Teamene fikk ansvar for både utvikling og drift, og gevinstene ble fulgt opp tett. Smidige prosesser gjorde det mulig å prioritere og identifisere nye gevinster underveis, noe som bidro til at prosjektet oppnådde sine mål om bedre tjenester og effektivisering.
Konklusjon
Foreldrepengeprosjektet er et interessant eksempel på et stort IT-prosjekt som endret leveransemodell underveis i prosjektet. Studier på prosjektet gir innsikt i hvordan koordineringspraksis endret seg, og en erfaringsrapport viser en del av lærdommene fra å gå fra det vi har kalt en “førstegenerasjon” smidig utviklingsmetode til en “andregenerasjons”-metode.
Om forfatteren:
Torgeir Dingsøyr forsker på prosessforbedring og kunnskapsforvaltning i programvarebedrifter som professor ved NTNU. Han ønsker å forbedre arbeidshverdagen for ansatte i ITbransjen innen tema som smidige utviklingsmetoder, teamarbeid i systemutvikling og koordinering i store utviklingsprosjekter.
