Prosjektet har feilet!

Jeg har jobbet med it-prosjekter over 30 år og denne situasjonen har ikke endret seg nevneverdig. Tvert imot synes jeg problemet er økende, spesielt på grunn av digitaliseringen. Hvorfor er det slik?

Fra det øyeblikket en prosjektleder legger frem tidsplan, budsjett, kvalitetsplan og omfangsbeskrivelse, måles prosjektet opp mot dette. Dette kalles en baseline. Uansett hvor mange endringer prosjektleder får godkjent, altså en ny baseline, vil prosjektet i mange sammenhenger bli vurdert opp mot den opprinnelige baselinen. Man kan si at dette er urettferdig, eller feil, men dette er dessverre slik de aller fleste tenker rundt prosjekter. Og får en journalist nyss om økte kostnader eller en tidssprekk i et større offentlig prosjekt, så er det dette negative synspunktet som alltid trekkes frem.

Dette er sterkt ødeleggende for all den gode innsatsen som legges ned for å utvikle gode produkter, løsninger og tjenester. Resultat er at prosjektets resultat ender opp med et frynsete rykte fordi prosjektet gikk over tiden eller at man ikke fikk all den funksjonaliteten som ble lovet. Vi blir sittende igjen med fingerpeking på hvem som har skylden istedenfor å se fremover for å løse oppgaven.

Vi lever i endringenes tidsalder

Vi må innse at prosjektenes omgivelser er i kontinuerlig og økende endring. Brukernes og organisasjonens behov eller prioriteringer endrer seg, teknologien er i rask og økende endring, prosjektenes samarbeidspartnere er i endring, personer i prosjektet kommer og går og kundene blir utålmodige. Listen er lang. Prosjektets rammebetingelser derimot, tid, kost, kvalitet og omfang, forventes å bestå. Ikke rart prosjektene sliter med å levere.

Tenk litt på de produktene og tjenestene du bruker i hverdagen. Hvor mange av disse er i kontinuerlig endring? Hvis du tenker deg om tror jeg du vil finne at Spotify i dag er ganske forskjellig fra Spotify for et par år siden. Det samme gjelder Facebook, Instagram, Gmail og alle apper og websider du bruker i hverdagen.

Til og med AltInn, Skattemeldingen og mange tjenester fra f.eks NAV er i kontinuerlig endring. Produkter og tjenester oppstår ikke fra en dag til den andre, de utvikles over tid, helst dynamisk i forhold til brukernes behov. Det siste er spesielt viktig, ellers har ikke produktet livets rett. Det er derfor meningsløst å sette tidsfrister på produkt- og tjenesteutviklingen, da dette er en kontinuerlig prosess.

Prosjektenes tid er forbi

Vi må slutte å bruke prosjekter til produkt- og tjenesteutvikling! Prosjektmetoden er ikke laget for en dynamisk hverdag.

Produkt- og tjenesteutvikling krever kontinuerlige prosesser og bør ikke «låses ned» i et prosjekt over lengre perioder. På grunn av frykten for å feile dersom man ikke leverer på tid, kost, kvalitet og omfang skapes det bindinger som igjen skaper en egen selvoppholdelsesdrift i prosjektet som ikke er forenlig med dynamiske tilpasninger.

Det medfører prestisjetap dersom et prosjekt legges ned, både for prosjektet og prosjekteier, for ikke å snakke om den tapte tiden man bruker til å peke på hvem som var årsaken til at det feilet. Store budsjetter låses til prosjektarbeid i lengre perioder som betyr mindre handlingsrom for organisasjonen og prosjekteiere dersom det er behov for omprioriteringer.

Prosjekter er en risikosport

Prosjekters tilnærming til å redusere risiko er å bruke mye tid innledningsvis til analyse og behovsavklaring. Dette for å skape de rammebetingelsene som prosjektet skal forholde seg til. På grunn av forholdene diskutert over, så vet vi at det blir endringer. Har man ikke da kastet bort verdifull tid og kost ved å gjennomanalysere hele problemstillingen før man starter?

I tillegg til tiden det tar å analysere prosjektet brukes mye tid til å diskutere ressurser, risiko og finansiering for det er ofte store summer som må allokeres over lang tid. Når man endelig kommer i gang så er man ytterligere for sent ute og man ender opp med å gå fra skippertak til skippertak.

En bit av gangen

Er man opptatt av kundeverdi, tidlige gevinster, redusert risiko, mulighet for lære om, og dermed justere produktets utvikling og få mer verdi for pengene, så er det smidige utviklingsmetoder som gjelder.

Ved en smidig fremgangsmåte reduseres ikke risiko ved gjennomanalysering, men ved å dele opp oppgaven i mindre biter som prioriteres etter verdi. Hver mindre bit skal kunne brukes og testes opp mot kundenes og organisasjonens behov. Dette kutter time-to-market og brukes til å få tidlig verifisert om løsningen dekker de uttalte behov. Fordi omfanget på leveransen er relativt liten, er det enklere og billigere å korrigere retningen om det er nødvendig. Med mindre bundne midler er det lettere å få aksept for å komme i gang samtidig som man kan avvikle de oppstartede aktivitetene uten å ha tapt alt for mye penger.

Smidig fokuserer på kundeverdi og gevinster fra dag en. Det er dette som driver utviklingen og alle prioriteringene. Har ikke en funksjon verdi (for kunden) så skal den ikke lages. Alternativt hvis verdien er lav så skal den prioriteres lavere enn annet som har mer verdi. Dette er dynamisk og følger ikke en fastsatt timeplan som i et prosjekt.

Prosjekter skyr endringer, mens smidig omfavner de. Smidig er derfor som et risikoreduserende målsøkende missil med fokus på kundeverdi.

På denne måten endres fokus fra prosjekter som feiler, til kontinuerlig gevinstrealisering og kundeverdi.

Bjørn Meek, consulting director i Sopra Steria