Jeg mener stadig at IT-utvikling som oftest bør organiseres som produktutviklingsløp og ikke som prosjekter. I Teknisk Ukeblad 13/10 2011 uttaler Tone Bringedal i Difi at det ikke er noen motsetning mellom prosjektorganisering og mine poenger.

La meg først raskt oppsummere hva som er mine poenger: Gode IT-satsinger slutter ikke når verdiskapningen begynner. De lever side om side med brukerne og tilpasser seg kontinuerlig. Offentlige organisasjoner har spesielt behov for dette, på grunn av stadige endringer i politikk, budsjetter og regelverk. Hvordan skal for eksempel Oslo Universitetssykehus klare å modernisere virksomheten og samtidig bruke mindre penger, hvis ikke endringer i IT-systemene er en naturlig, integrert del av prosessen?

Definisjonen av prosjekt på Wikipedia: “Prosjekt betegner innsats som gjøres for å oppnå et definert mål, som oftest innenfor en planlagt tids- og ressursramme (…)”

Flyt av arbeid er viktigere enn kunstige tids- og kostnadsrammer lagt langt frem i tid. Jeg kommer stadig over historier om IT-avdelinger som utvikler ny funksjonalitet til tross for at det brukerne ba om kunne ha blitt løst av funksjoner de ikke visste om. Selv om kunnskapen som slikt dobbeltarbeid – sløsing –  finnes i organisasjonen som helhet, kommer den ikke frem.

Jeg finner like mange eksempler på det motsatte – feilaktige antagelser om at eksisterende funksjonalitet kan løse nye behov. Dette skjer hele tiden, i prosjekter både i offentlig og privat sektor. Det skjer hele tiden, også i prosjekter som hevder å bruke Scrum eller annen smidig metodikk. Det skjer fordi de involverte jager et kunstig mål.

Spørsmålet jeg stiller er derfor som følger: Hvordan kan vi organisere oss på en måte der samhandling mellom utviklere og brukere blir navet i utviklingsarbeidet? Der arbeidskulturen ikke tolererer misforståelser som følge av manglende samhandling?

Jeg mener løsningen må være å fjerne organisasjonsbarrierer. Ledelsen bør fokusere på flyt av arbeid: Hvor mye ny funksjonalitet leverer vi hver uke? Hvor lang tid tar det fra vi identifiserer et behov til vi leverer en løsning? I offentlige virksomheter med saksbehandlere: Hva er utviklingen i saksbehandlingstid?

Man kan selvfølgelig argumentere for at slik tankegang er mulig innenfor et prosjekt. Det finnes flere eksempler på prosjekter der man har levert underveis, og kanskje også realisert gevinster underveis. Men er dette på grunn av prosjekttankegangen eller er det på tross av den? Kan Difi eller andre som forfekter prosjekttankegang gi eksempler på IT-løsninger som ble en suksess fordi utviklingen ble organisert som et prosjekt istedenfor et produktutviklingsløp?

Jeg tror Difi har den riktige pulsen på offentlige IKT-satsinger, noe deres arbeid med kontraktsstandarder bærer preg av. Selv om de forstår mine poenger er imidlertid prosjektbegrepet innarbeidet hos oss alle, også fra politisk hold. Alt for mange offentlige IKT-satsinger har gått galt på grunn av utilstrekkelig styring. Fra politisk hold er det press på kostnadskontroll og risikohåndtering, og der gir prosjekter oss etablerte rammer.

Slike rammer står imidlertid i veien for gevinstrealisering, som seiler opp som det neste store temaet. Min advarsel går først og fremst til de som stiller forventingene til Difi og andre aktører som er toneangivende for hvordan gevinster skal realiseres for det offentlige Norge. Prosjektorganisering er en etablert sannhet. Det er også en selvpålagt begrensning.

Vi må ikke undervurdere de kulturelle konsekvensene av de føringer vi blir pålagt. Det er ikke de som lager prosjektmodellen som gjennomfører satsingene. Det er den enkelte virksomhet, ofte i samarbeid med konsulentselskaper. Det offentlige må sende et tydelig signal om hvordan slikt arbeid skal foregå. Ved å begrense fokuset til en felles prosjektmodell risikerer vi å misforstå poenget, gang på gang.