Hva er et mislykket IT prosjekt?

Hva er et mislykket IT prosjekt, og omvendt, hva er et vellykket prosjekt? Gjennom hele IT historien har man diskutert hvorfor så mange prosjekt mislykkes. Det finnes utallige studier som forklarer hva man bør gjøre for å unngå å mislykkes.

Feil utgangspunkt

Problemet med disse studier er at definisjonen av et mislykket IT prosjekt er feil. Som oftest defineres tre måter å mislykkes på:

• Systemet som utvikles blir aldri satt i drift
• Prosjektet leverer ikke i tid
• Prosjektet overskrider sitt budsjett

Jeg skal ikke dvele ved den første grunnen. Et IT prosjekt som aldri setter noe i drift har selvfølgelig liten verdi. Men hva med et prosjekt som blir forsinket eller et prosjekt som bruker mer penger enn planlagt? Her både forenkles det og blandes sammen.

Sammenblandningen består i å ikke skille på prosjektstyringen og selve prosjektet. Dårlig prosjektstyring er ikke det samme som et dårlig prosjekt. Et prosjekt kan styres dårlig men likevel levere et bra produkt. Likevel må man kunne si at et prosjekt er vellykket selv om det leveres noen måneder etter tid hvis systemet har stor verdi.

Det er en grov forenkling å sette likhetstegn mellom et budsjett som overskrides og det å mislykkes. Det finnes mange eksempler på prosjekter som går langt over budsjett på grunn av at ambisjonen (scope) har økt. Et prosjekt som går over budsjett med 50 % men som også leverer 50 % mer verdi enn planlagt kan vel ikke kalles mislykket?

I henhold til spesifikasjon?

Hvis man snur på spørsmålet og ser på hva som kjennetegner et vellykket IT prosjekt så vil mange si at det må levere et system i henhold til spesifikasjon på tid og budsjett. Problemet er bare det at det finnes mange eksempler på prosjekt som oppnår akkurat dette men der systemet likevel har liten verdi. Forklaringen til dette paradokset er at spesifikasjonen er dårlig. Andre ganger har behovene endret seg underveis.

Et perfekt prosjekt

I et perfekt IT prosjekt skal hver funksjon som utvikles være den som tilfører kunden størst verdi. Et nytt system blir dermed en samling funksjoner som alle gir kunden mer verdi enn alternativene. Problemet er at det blir alt for kostbart å utføre en kost/nytte analyse av hver enkelt funksjon i et system. Et minimumskrav bør dog være at alle funksjoner i et system skal ha en verdi i det hele tatt. Litt forenklet kan man sette likhetstegn mellom at en funksjon blir brukt og at den har verdi. Den eneste forutsetningen som må gjøres i dette resonnementet er at brukerne av systemet utfører reelle arbeidsoppgaver.

Hva blir brukt?

I 2002 gjennomførte Standish group(1) en studie der de analyserte system i drift og målte hvilken andel av funksjonene som ble brukt. Systemene i studien var utviklet på bestilling og dermed ikke hyllevare. Studien konkluderte med at kun 20 % av funksjonene ble brukt ofte eller meget ofte. Hele 45 % av alle funksjoner ble aldri brukt! Hvis man utgår fra at kostnaden for å utvikle et IT system stiger eksponentielt som funksjon av mengden kode som skal utvikles så er det langt mer enn 45 % av utviklingskostnaden som er bortkastet.

Fokus på verdi

En fremstående bedriftsleder sa en gang at han var sikker på at 50 % av reklamebudsjettet var bortkastet. Problemet var bare at han ikke visste hvilken halvdel det var. Når man utvikler et IT system er det heller ikke alltid mulig å vite på forhånd hvilke funksjoner som vil bli brukt. Det som dog er sikkert er at dagens prosesser (særlig i offentlig sektor) med omfattende kravspesifikasjoner og deretter kontrakt basert på oppfyllelsen av disse ikke er veien å gå. Resultatet blir at kunden legger inn alt i spesifikasjonen som muligens kan bli etterspurt. Leverandøren har ikke heller noe incitament for å finne ut hva som egentlig vil bli brukt. Man vinner kontrakt gjennom å tilby det kunden ber om, ikke gjennom å tilby det kunden har behov for.

Smidig

I senere år har interessen for det som kalles smidige metoder (agile development) stadig vokst. Et av de store poengene med disse metodene er nettopp å dreie fokus fra å utvikle etter en spesifikasjon til å inkrementelt utvikle det som gir kunden mest verdi. Tanken er at hyppige leveranser skal gjøre kunden i stand til å justere sine mål og holde fokus på det som virkelig har verdi. En utfordring med å ta disse metodene i bruk er at mange kontrakter fortsatt binder både kunde og leverandør til en statisk spesifikasjon. Det er med andre ord fortsatt en lang vei å gå.

Niklas Bjørnerstedt

(publisert i Computerworld 11. januar 2008)

(1) Standish group studien har i ettertid blitt sterkt kritisert for manglende vitenskapelig stringens. Det er grunn til å tro at tallene i studien er oppblåste i forhold til virkeligheten. Selv om de virkelige tallene er lavere så kvartsår poenget at funksjoner som ikke blir brukt ikke gir verdi.

Posted on 2008.01.11 at 14:42

Comments are off for this post.