Er IT-prosjekter på vei ut?

Slik har vi da alltid gjort det

En av grunnene til at vi kjører prosjekter fortsatt, kan være at “slik har vi da alltid gjort det”. Organisasjonen har rutinene i orden og vet hvordan planlegge og styre prosjekter. Prosjektbudsjettet kan diskuteres og vedtas i ledelsen/styret. Prosjektleder styrer og rapporterer og sørger for at vi holder oss innenfor tid og kost, og oppnår målsetningen med prosjektet. Det føles trygt å gjøre det på denne måten og ledelsen kan til enhver tid bestemme hvilke prosjekter som er viktige og skal få prioritet.

Et team som kontinuerlig videreutvikler produktet krever at budsjettprosessen gjøres på en annen måte. Det må settes av en budsjettramme til teamet istedenfor til enkeltprosjekter. For ledelsen kan dette føles som å gi fra seg makt og kontroll. Det er teamet som bestemmer hva som skal utvikles. Ledelsen må definere strategiske produktmål for å sikre at teamene jobber i riktig retning. Dette er en ny og annerledes måte å jobbe på for mange organisasjoner.

Raskere endringstakt og nærhet til kunde

Men det kan være mye å hente for ledelsen på å gi et team mer av eierskapet til produktet og videreutviklingen. Teamet kan etter hvert sitte med en unik kompetanse om kunden og produktet og har en mye større mulighet til hele tiden å prioritere og levere det som er viktigst for kunden. Teamet blir mer motivert og jobber bedre når de får bestemme hva de skal gjøre.

Utvikling av produkter og tjenester krever tid til å eksperimentere og lære underveis og justere kurs. I et prosjekt får man ofte kun tid til å gå i én retning. Om mye funksjonalitet produksjonsettes sent i prosjektet får man sjelden tid til å undersøke og respondere på tilbakemeldingene fra kundene. 

Et prosjekt har en slutt, og teamet som jobbet i prosjektet flytter fokuset og eierskapet til andre områder når prosjektet er ferdig. Et fast tverrfaglig team vil gi mer rom for å se produktet/løsningen over tid. Det gir mer rom for å eksperimentere, måle respons og kontinuerlig vurdere hva som er viktigst å løse.

Krever endringer i organisasjonen

Å få til tverrfaglige produktteam krever endring i organisasjonen. Produktteamet kan ikke bare bestå av programmerere. Man kan ikke ha en avdeling der forretning sitter og bestemmer hva som skal lages og en IT-avdeling der utviklerne sitter og lager det som er bestemt. Teamene må bestå både av de som jobber med forretning og de som kjenner mulighetene IT gir. Det kan føles viktig for de som jobber med et fagfelt å sitte samlet og det kan føre til motstand mot endringen. 

Rammer kan skape kreativitet

Man kan tenke at rammer som et prosjekt gir med en gitt tid, et gitt sett av ressurser og en gitt målsetning kan være hemmende for kreativitet. Men forskning har vist at det faktisk kan være motsatt. Har man ingen rammer kan man lett gå for den mest intuitive idéen. Rammene derimot kan gjøre at man motiverer og utfordrer folk til å tenke kreativt og se andre muligheter.

Et prosjekt kan være en god ramme for å skape kreativitet. Skal man lage et nytt produkt eller en ny tjeneste kan dette gjøres som et prosjekt. Prosjektet kan skape en følelse av at man er med på noe unikt og betydningsfullt som skjer bare en gang og må lykkes. Å sette sammen folk fra forskjellige fagfelt som ikke har jobbet sammen før kan gi god grobunn for kreativitet og nytenkning. 

Ønsker man et prosjekt som ramme for å fremme kreativitet er det samtidig viktig at man ikke strammer for tett til. Er målsetningen i prosjektet et ferdig produkt eller tjeneste, kan det skape mer hast og “vi må komme i gang med å utvikle”-følelse, som gjør at man ikke får tid til å utforske idéene. Kanskje bør heller prosjektmålsetningen være å komme fram med en god produkt- eller tjeneste-idé, eller ganske enkelt å ha testet og forkastet noen idéer. 

Større løft og paradigmeskifter

Et produktteam vil være best til å videreutvikle et eksisterende produkt, gjøre kontinuerlig forbedring og lytte til kundene. Men hva dersom det skal gjøres et større løft på en løsning eller man skal bytte den helt ut. Er det behov for et prosjekt da? 

Kreativitet og fokus som rammer kan gi, kan være en grunn til å kjøre større løft og nyutvikling som prosjekter. En annen grunn er også det midlertidige behovet for flere folk. Men velger man å kjøre større løft som prosjekter må man også være på vakt:

Målsetningen med prosjektet må være rund nok til at man fremmer og ikke hemmer kreativitet. Om man for eksempel starter prosjektet basert på estimater og funksjonalitet som skal tas fram og krever endringsordre for hver ny idé er det ikke mye rom for kreativitet, da dreper man den. Prosjektet blir et sted utvikleren sitter og prøver å utvikle noe som allerede er tenkt ut og gir ikke rom for å tenke nye tanker. For man blir jo klokere og lærer underveis når man jobber med ting (heldigvis).

Hvor mange store prosjekter har vi ikke sett, som går over budsjett, aldri blir ferdig og ender opp med et produkt som ikke blir tatt i bruk. De fleste IT-prosjekter er per definisjon uforutsigbare. Store IT-prosjekter er stor risiko og klarer man å dele opp har man mye større forutsetning for å lykkes. 

Store prosjekter der man leverer sent i prosjektløpet gir lang tid til man får realisert verdi og lang tid før man får reell brukererfaring, slik at man kan justere kurs. Jeg har selv jobbet i Helseplattformen i noen år, prosjektet som nå går for å skifte journalsystemene både for spesialist-, kommune og fastleger i Midt-Norge. De satser på få og store leveranser, så langt er ingenting satt i produksjon. Det betyr at i de årene jeg jobbet der gav vi ikke noe verdi for brukerne, og fikk ikke samlet noen reell brukererfaring. Prosjektet er enormt stort og komplisert, og det skal integreres med mye. Det er derfor ikke er en enkel oppgave å dele opp. Men man kunne fått mye igjen for det gjennom redusert risiko og muligheten for å skape verdi tidligere. 

Jeg tenker at spesielt i store prosjekter bør man jobbe hardt med å levere tidlig. Man bør tenke MVP og hypotesedrevet utvikling. - Lage noe lite, test ut og snu kursen om den er feil. Prosjektene bør også ha stoppunkter der man virkelig vurderer, er det verdt å gå videre? Jeg har en følelse av at man ofte har lagt for mye prestisje inn i det når man først har startet et prosjekt. Da må man kjøre på selv om man ser at skuta går i feil retning. -Budsjettet skal brukes opp (og kanskje mer til).

En annen fare med prosjekter, er at et midlertidig prosjektteam ofte blir liggende litt for langt fra resten av organisasjonen. Prosjektteamet blir sittende for seg selv og lager noe som kan virke fint og flott. Det hjelper ikke om de som skal selge det (om det er en kundeløsning) eller bruke det (dersom det er en bedriftsintern løsning) ikke er nok involvert. Man får en overlevering tilbake til organisasjonen som ofte ikke har nok eierskap til det som er utviklet. Et prosjekt-team bør derfor alltid bestå også av de som skal forvalte og videreutvikle det i etterkant. For når man er ferdig med prosjektet bør man budsjettere med et fast tverrfaglig produktteam for videreutvikling.

Ferdig utviklet IT-løsning = nedlagt IT-løsning

Et prosjekts natur med en start og slutt kan gjøre at man tenker at når prosjektet er ferdig, så er IT-løsningen ferdig. Den eneste gangen en IT-løsning er ferdig utviklet er når den ikke treffer markedet og satsingen legges ned. Er det en vellykket løsning vil man alltid trenge videreutvikling og forvaltning. 

Av en eller annen grunn undervurderer man ofte behovet for videreutvikling og forvaltning. IT-løsninger i dag er som oftest nært knyttet til forretningen. Det er lett å forstå at forretningen stadig må endres og forbedres for å gi mer kundeverdi. Da er det jo likedan med IT-løsningene, de må også forbedres og endres i takt med forretningen. Det holder ikke å sette av en pott med penger til et “versjon 2.0” prosjekt neste år. Kundebehov må følges opp kontinuerlig. 

Så, er IT-prosjektet på vei ut?

Vi vil nok fortsatt se mange IT-prosjekter framover. Noen som burde vært IT-prosjekter og noen som ikke burde vært det. Har man et produkt som skal videreutvikles får man mest nytte av et tverrfaglig team som kan jobbe sammen over tid, lytte til kunden og få eierskap til produktet. Da bør man kaste seg ut i det og gjøre de endringene som trengs i organisasjonen for å få det til. Utviklerne og forretningsressursene kan ikke sitte hver for seg i to leire, så det krever både en annen organisering og en annen måte å lede på.

Større løft og paradigmeskifter, nye tjenester og produkter kan man fortsatt vurdere å kjøre i prosjekter. Gi rammer som fremmer kreativitet og del dem opp mest mulig. Tenk på hva som skjer når prosjektet er ferdig og om initiativet lykkes, da trenger man folk og budsjetter til kontinuerlig videreutvikling. 

Ta gjerne kontakt hvis du vil diskutere temaet videre.