Død over de store IT-prosjektene

Det har blitt skrevet mange spaltemeter om IT-prosjekter som har mislykkes og om hvor mange millioner eller milliarder kroner som har vært bortkastet som en konsekvens av dette. Ikke minst knyttet til store markedslanseringer som ikke blir gjennomført, eller at løftet om et stort gevinstuttak aldri blir realisert. Hvordan kan vi forhindre dette?

Det kan være mange grunner til mislykkede IT-prosjekter, og jeg vil her påpeke en endring i måten å jobbe på som kan forhindre dette og forbedre utviklingsprosessene.

 

Del opp elefanten

Overgang fra en sekvensiell til en inkrementell (smidig) måte å gjennomføre prosjektene på innebærer hyppige lanseringer, fortrinnsvis knyttet til hver sprint. Dette gjør at risiko reduseres gjennom færre avhengigheter og ved at funksjonalitet installeres fortløpende. Ved gode rutiner for inkrementell utvikling og implementering, vil hyppige lanseringer gjøre at det å sette ny kode i drift blir en del av det rutinemessige utviklingsarbeidet. Om feil oppstår, vil det være mindre jobb å rulle tilbake eller rette feil.

Ved å dele opp elefanten gir det også en fleksibilitet slik at endringer raskt kan settes i drift sammenlignet med prosjekter som lanseres gjennom «big bang». Om det er slik at prosjektet blir stoppet underveis, har man i det minste lansert noe.

Arbeidsprosessen setter krav til at organisasjonen delegerer mer ansvar til utviklingsteamet, styringsgruppen jobber annerledes og prosjektlederen får en ny rolle. Dette inkluderer mindre rapportering og administrasjon og at teamet jobber mer autonomt.

Tiden for de store regnearkene og de innholdsrike planene er over. I stedet blir det viktig å ha fokus på hva som skal gjøres innenfor hver sprint, og man tester hyppigere for å sikre at den funksjonaliteten som ønskes etablert er i henhold til brukernes ønsker og behov. Da må også organisasjonen gi fra seg kontroll og godta at brukeren vet bedre enn virksomheten.

 

 

Nye krav til styringsgruppen

Styringsgruppen vil få en ny rolle for prosjekter som jobber etter smidige prinsipper. Deres primære funksjon vil være å sikre at teamet får den støtten og hjelpen de trenger for best mulig produktivitet. Medlemmene vil i mindre grad enn i plandrevne prosjekter være beslutningstaker, i stedet vil de gi rammer til teamet og overlate til brukerne å ta beslutninger om produktutvikling.

Styringsgruppen må også delegere den daglige beslutningstakingen til produkteier som representerer brukerne. Dette kan være en stor endring for medlemmer i styringsgruppen da de må gi fra seg en del av kontrollen og i større grad enn tidligere stole på at teamet leverer produkter til det beste for selskapet eller organisasjonen. Styringsgruppen må også gi fra seg kontrollen om hva som skal lanseres i markedet (Minimal Viable Product).

Man må godta at markedslanseringer endres i forhold til slik det var tidligere. Siden det nå kommer små drypp av forbedringer og nylanseringer, er tiden for de store markedslanseringene forbi. Man kan i stedet forklare fortløpende – for eksempel gjennom oppdateringer av apper - om de forbedringer som er gjort. Markedslanseringer må derfor tilpasse seg disse endringene, og til og med lansere løsninger som har vært i bruk en stund.

 

Den nye prosjektlederen – en kilde til motivasjon

Mens det tidligere var prosjektlederens viktigste oppgave å rapportere, er det viktigste nå å være tett på teamet og motivere til innsats og sørge for at teamet lærer og jobber effektivt. Det vil si å løse problemer og å sikre fokus og læring i stedet for rapportering.

Dette stiller også andre krav til prosjektlederegenskaper.

Mens man tidligere kom langt ved å være god på risikostyring, budsjettering og kostnadsstyring, gjelder det nå å ha gode kommunikasjonsegenskaper, være flink til å motivere samt være en god rådgiver overfor kunden og brukerne. Dette er en dreining fra fokus på «administrative egenskaper» til «lederegenskaper».

Ved å gjennomføre IT-prosjektene ved hjelp av smidig metode vil de store prosjektene og programmene, slik vi kjenner dem i dag, forsvinne. Hvordan er dette mulig når store prosjekter skal leveres?

Da må man se på hvordan det som skal leveres kan gjennomføres i mindre autonome team. Hvilke leveranser er avhengig av hverandre, og hvilke leveranser kan leveres på ulike tidspunkt. Ved å sette funksjonalitet i drift underveis vil dette øke sjansen for vellykket implementering.

Vi må heller ikke glemme at leveransene ikke trenger å være perfekte, og at vi kan gjennomføre forbedringer etter hvert. Brukerne er de som må definere hva som er «godt nok», og så må vi bygge videre (iterere) på det grunnlaget. På denne måten sikrer vi at produktet/tjenestene blir realisert. Omgivelsene endrer seg også, og ved å ha et kortere prosjektløp med færre bestanddeler vil evnen til å endre seg i takt med omgivelsene øke.

 

Dette blir fremtidens IT-prosjekter

Min erfaring er at med denne metoden vil vi erfare flere vellykkede IT-prosjekter enn det vi til nå har gjort. Man vil også levere mer innhold på kortere tid.

Et prosjekt er aldri bedre enn det svakeste ledd, og ved å innlemme mye scope som skal leveres samtidig øker risiko for at noe skal feile. Smidig gjennomføring er ikke bare relevant for produktutvikling, men også for alle typer implementeringsprosjekt. Man kan enten innføre en spesifikk metode (som Scrum eller Lean Startup), eller sette sammen elementer fra ulike metoder.

Endring fra mer planstyrte prosjekter og programmer til mindre selvstyrte team berører ikke bare IT-avdelingen i en organisasjon, men hele virksomheten. Kravstillere gjennom produkteier må jobbe tettere på prosjektet. Og de må ta hyppige beslutninger slik at teamet får nødvendig progresjon. Finansavdelingen må akseptere en annen rapporteringsform og færre detaljer.

Samtidig er erfaringen at det å jobbe smidig vil gi mer produktutvikling for investeringene som gjøres, og at løsningene treffer målgruppene bedre ved å involvere dem kontinuerlig.

Jeg ønsker velkommen en mindre topptung byråkratisk prosjektorganisering til fordel for en brukerdrevet autonom måte å jobbe på – også for store prosjekt og program!

Bloggartikkel
Hva vi gjør