Belønning av overestimering og sløsing i IT-utvikling

Dette skjer fordi IT-utvikling gir gode mulighet til å tilpasse leveranser og redusere produktivitet til tilgjengelig budsjett og tid og i mange tilfelle sterke insitamenter for å unngå under-budsjettering. I utgangspunktet for høye kostnadsbudsjetter kan lett brukes opp og fremstå som svært treffsikre, med påfølgende belønning over-budsjettering og ineffektiv gjennomføring av IT-utvikling.

Tryggest å overestimere

Forestill deg at du er ansvarlig for å estimere hva det vil koste å utvikle en ny IT-løsning. Du vet at de som finansierer utviklingen er svært lite glade for kostnadsoverskridelser, og at du kan bli hengt ut i media som syndebukk dersom det blir store kostnadsoverskridelser. Du vet også at eksisterende IT-løsning er bygget på teknologi som snart ikke støttes lenger, ikke oppfyller dagens krav til sikkerhet og personvern, og er svært kostnadskrevende å vedlikeholde. IT-utviklingen må altså gjennomføres og spørsmålet er bare hva det vil koste. Du vet i tillegg at de som skal finansiere IT-utviklingen, og også de som eventuelt skal kvalitetssikre kostnadsestimatene, ikke er i stand til å overprøve ekspert-estimatene gitt av deg og dine kollegaer. [1] Det finnes heller ingen gode målinger som i etterkant kan gi en vurdering om IT-utviklingen har blitt gjennomført med høy eller lav produktivitet. Det er av samme grunn heller ingen insentiver eller belønning for høy produktivitet. Du vet at dere vil bli evaluert som mindre kompetente, både i estimering og gjennomføring, dersom prosjektet får større kostnads eller tidsoverskridelser. Anta at det ikke er konkurranse om IT-utviklingen, og det på estimeringstidspunktet er en betydelig grad av usikkerhet til gjennomføringen av IT-utviklingen og hva denne vil kunne koste.

Magne Jørgensen

Magne Jørgensen er professor ved SimulaMet og forsker blant annet på prosjektledelse og kostnadsestimering av utviklingsprosjekter. Han skriver fast for Computerworld om disse temaene.

Man trenger ikke være særlig klarsynt for å se at denne nokså vanlige situasjonen gir sterke insentiver til å overestimere kostnader, for å være på den sikre siden for å unngå kostnadsoverskridelser. Det er lav risiko for å fremstå som inkompetent ved et antatt for høyt kostnadsestimat, gjennom tilpasning av leveranser og produktivitet. Risikoen for ubehageligheter ved et for lavt kostnadsestimat er på den annen side betydelig. Et for høyt estimat, med egnet tilpasning av leveranser og produktivitet, vil dessuten medfører at IT-utviklingen vil kunne fremstå som å ha treffsikre kostnadsestimater, god styring og kompetente medarbeidere.

En overestimering av kostnader kan være en bevisst strategi og/eller skje ubevisst. I vår forskning har vi eksempler på (anonymiserte) innrømmelser på bevisst overestimering av IT-utvikling. Av åpenbare årsaker vil det imidlertid være vanskelig å dokumentere i hvilken skala dette skjer. En ubevisst over-estimering kan også skje gjennom et fokus rettet mot det å unngå overskridelser, ofte beskrevet som "regulatory focus" (Hazlett m. fl. 2011). I tråd med dette så har flere forskere funnet en sterk tendens til overestimering av tidsbruk i situasjoner der estimeringsnøyaktighet og ikke produktivitet belønnes (Brown m. fl. 2009).

Parkinsons lov

Overestimering av kostnader ville ikke vært noe stort problem dersom det ikke hadde negative følger for selve gjennomføringen av IT-utviklingen. Andres og vår forskning tyder imidlertid på at det som i stedet kan skje, som motivert ovenfor, er at leveransene og produktiviteten tilpasses budsjett og tidsramme som er tilgjengelig. I forskningen beskrives dette ofte som Parkinsons lov [2] og er blant annet dokumentert i (Lorko m. fl. 2023, Nan og Harter 2009). Nan og Harter dokumenterer blant annet en U-form på sammenhengen mellom tidspress og produktivitet innen IT-utvikling. Den høyeste produktiviteten ble funnet i situasjoner med omtrent 10% under-estimering, med redusert produktivitet både for mer under-estimering og for over-estimering enn dette. Viktig å merke seg her er at sterk underestimering var verre for produktiviteten enn sterk overestimering.

Parkinsons lov bygger på observasjoner gjort i britisk offentlig sektor på 1950-tallet. Et relevant spørsmål er om lignende observasjoner kan gjøres i norsk offentlig sektor i dag. Offentlig sektor har automatisert og digitalisert i mange ti-år, noe som skulle føre til store kostnadsbesparelser. Samtidig har imidlertid antall ansatte i offentlig sektor stort sett økt. Skatteetaten, som anses som en av de mest vellykkede innen digitalisering av offentlig sektor, kan være et illustrerende eksempel. I dag har Skatteetaten litt over 7.000 ansatte. På 1970 og tidlig på 1980-tallet, da skattemeldingen var papir-basert og saksbehandling sort sett ble gjort manuelt, synes antall ansatte å ha vært rundt 6.500. Det er mye som har endret seg i denne perioden og som kanskje kan forklare hvorfor digitaliseringen og automatiseringen ikke har ført til færre ansatte. Det er likevel grunn til å undres om ikke Parkinsons lov har spilt en rolle. Kan det være at arbeidets innhold kontinuerlig har tilpasset seg budsjettet til Skatteetaten, og gjort at en økt produktivitet på vesentlige oppgaver ikke har fått utslag i færre antall ansatte eller lavere budsjett? Hvis så er tilfelle, hvor mye av det økte arbeidsinnholdet i Skatteetaten har bidratt effektivt til verdiskapning, og hvor mye av effektiviseringen burde i stedet vært gjort i form av nedbemanning?

Mye tyder altså på at det er mange situasjoner med sterke insitamenter for overestimering av kostnader i IT-utvikling og tilpasning av arbeidet til budsjettet, samt at dette kan ha ført til redusert produktivitet og sløsing med ressurser. Er det noe vi kan gjøre for å bedre situasjonen?

Parkinson selv kommer ikke med noen løsning, og dessverre har heller ikke ettertiden kommet opp med gode løsninger brukbare for IT-utvikling. En viktig grunn til dette er at vi mangler gode målestørrelser for produktivitet i IT-utvikling. Vi er derfor ikke i stand til å vurdere eller belønne om denne er gjennomført med lav eller høy produktivitet.

Veien mot riktige insentiver

Det er kanskje likevel noe vi kan gjøre for å bedre situasjonen. Det første er at vi blir bedre på å gjenkjenne situasjonene der insentivene for over-estimering av kostnader er vesentlige. [3] I situasjoner med overvekt av insentiver for over-estimering så bør tiltak settes inn for å tone ned fokuset på å unngå kostnadsoverskridelser og i alle fall prøve å gi insitamenter til høy produktivitet og effektiv fremdrift. Dette kan for eksempel gjøres gjennom at man innfører stegvis budsjettering med eksterne underveis-evalueringer av produktivitet og fremdrift. Ved at ikke budsjettet for hele perioden bestemmes i oppstartsfasen – man kan likevel ha anslag av totalkostnadene for å vurdere lønnsomhet – gjør at det ikke er avgjørende å ta i godt for å sikre gjennomføringen. Ikke minst vil det at produktivitet evalueres underveis, selv om det vil være mangler med denne evalueringen, kunne føre til at det å oppnå høy produktivitet og fremdrift gis mer oppmerksomhet.

Dessuten, funnene fra forskningen tilsier at IT-utvikling med litt, men ikke for mye, ambisiøse frister på leveranse og oppgave-nivå, for eksempel i form av underveis milepæler og sprinter, påvirker produktiviteten positivt. Selv om det helt sikkert finnes utviklere som jobber effektivt og med god kvalitet helt uten frister og tidspress, så tyder altså forskningen på at produktiviteten for de fleste går ned i slike tilfeller. [4]

Målet bør være å få til en situasjon der insentiver for planlegging og gjennomføring av IT-utviklingen er i tråd med hva en rasjonell investor vil vektlegge. I mange tilfelle vil det være å skape sterkest insitamenter for god kost-nytte til investeringen, dernest gode insitamenter for høy produktivitet i gjennomføringen, og til slutt tilstrekkelig insitamenter for god budsjett- og tidsstyring. Dagens insitamenter er dessverre stort sett ikke prioritert i henhold til dette.

Noter:

[1] Hvis noen synes kostnadsestimatene er høye, så er det bare å svare at "det er det våre eksperter har estimert vi vil trenge i vårt utviklingsmiljø og med våre utviklere".

[2] Parkinsons lov er selvsagt ingen generell lov, men kun en empirisk observasjon gyldig i enkelte situasjoner. Originalteksten fra 1955 i The Economist er en satirisk kommentar av historieprofessor C. Northcote Parkinson. Han observerte blant annet at antall ansatte i britisk offentlig sektor hadde økt uten at oppgavene som skulle utføres hadde økt, og foreslo mekanismer som forklarte dette.

[3] Det er selvsagt minst like viktig å gjenkjenne situasjoner som er utsatt for sterk under-estimering av kostnader innen IT-utvikling, og ha tiltak som skaper realisme i kostnadsestimatene. Dette gjelder blant annet anbudsrunder med fastpris på IT-utvikling og IT-oppgaver der de som har veldig lyst på oppgaven også estimerer den.

[4] Det er i dag noen som argumenterer for produktorienter IT-utvikling uten frister, for eksempel basert på prinsipper som kontinuerlig flyt og kanban. Det er ikke forsket nok på dette til å avvise at dette kan være effektivt for noen, men mye tyder altså på at for de fleste så vil mangelen på tidsfrister redusere produktiviteten. Dette kan blant annet skje ved at leveransene blir mer omfattende (inkludert høyere kvalitet) enn nødvendig, at utviklingsprosessen blir mer omfattende enn nødvendig eller at innsatsen blir redusert.

Referanser:

Brown, J. L., Evans III, J. H., & Moser, D. V. (2009). Agency theory and participative budgeting experiments. Journal of management accounting research, 21(1), 317-345.

Hazlett, A., Molden, D. C., & Sackett, A. M. (2011). Hoping for the best or preparing for the worst? Regulatory focus and preferences for optimism and pessimism in predicting personal outcomes. Social Cognition, 29(1), 74-96.

Lorko, M., Servátka, M., & Zhang, L. (2023). Hidden inefficiency: Strategic inflation of project schedules. Journal of economic behavior & organization, 206, 313-326.

Nan, N., & Harter, D. E. (2009). Impact of budget and schedule pressure on software development cycle time and effort. IEEE Transactions on Software Engineering, 35(5), 624-637.