Mesteparten av software prosjekt feiler.  Nyere undersøkelser viser at så mange som 70 % av alle utviklingsprosjekt enten går over tiden, koster mer enn planlagt, eller ikke har den funksjonaliteten som kunden forventet seg.  Hva kan du gjøre for at ditt prosjekt ikke faller i denne gruppen? Hva skal til for å få fram vellykkede prosjekt? 

Denne artikkelen er første del i en serie om emnet.

Risiko i IT utviklingsprosjekt er uungåelig, nettopp fordi det er et utviklingsprosjekt hvor teamet skal lage noe som man ikke har laget før, og hvor man har en oppdragsgiver som heller ikke er helt sikker på hva han vil ha.  Når man så prøver å estimere hvor mye det kommer til å koste og hvor lang tid det kommer til å ta å lage noe som man ikke helt vet hva er, er det ikke til å undres over at estimatene i beste fall blir usikre.

Alle programvare prosjekt måles på de samme tre hovedfaktorer: tid, kost, og funksjonalitet.  Alle tre estimeres, og det er disse estimatene som oppdragsgiver er mest interessert i, naturlig nok siden de beskriver prosjektets ytre rammer.  Statistikken forteller oss samtidig at rundt 70 prosent av prosjektene feiler fordi de ikke blir ferdig i tide, koster mye mer enn planlagt, eller ikke fungerer slik brukerne forventer.

Hvordan kan man så redusere risikoen for at prosjektet blir feilslått? 

Erkjennelsen av at man ikke helt vet hva man skal lage, er første skritt mot å reduser risiko.  Erfaringen viser oss at spesifikasjoner for stort sett alle forretningssystemer aldri er komplette, og at de vil forandre seg over tid.  Dette er naturlig siden verden systemet skal være i forandrer seg, bedriften forandrer seg, og ikke minst, brukerne forandrer mening dess mer de blir involvert i utviklingen.  Dette er ikke en ulempe, men sørger heller for at man får et system som brukeren faktisk har bruk for når det er ferdig.  I motsetning til et system som gjør det brukeren trodde han hadde bruk for to år tidligere, da spesifikasjonen ble laget.

Estimat for både tid og kost tar alltid utgangspunkt i spesifikasjonen og når dette er høyst usikker blir det utopisk å tro at disse estimatene kan bli mer sikre.  Det er dermed to typer risiko i utviklingen:

1. Risiko for at vi ikke lager det vi skal (spekken er feil)
2. Risiko for at vi ikke greier å estimere riktig.

Den eneste måten å redusere risiko i estimatene, er å redusere estimeringsperioden.  Vi kan si rimelig sikkert hvor mye vi får gjort i løpet av neste uke, men er ganske blank på hvor mye vi får gjort i løpet av de neste seks månedene.  Det er alså enkere og sikrere å estimere på kort sikt, enn på lang sikt.  Ikke akkurat noen verdensnyhet, men viktig å ta med seg og greit å huske på når du skal estimere tid og kost for ditt neste software prosjekt.

Ved å redusere estimeringsperioden, til noe som er mer oversiktlig, får vi automatisk bedre (og sikrere) estimat for tid og kost.  Men hva med spesifikasjonen?  Risikoen er jo fortsatt tilstede for at vi utvikler feil funksjoner.  Selv om vi får riktigere estimat for tid og kost. 

Løsningen her er å gjøre akkurat tilsvarende, vi reduserer tiden det går mellom brukeren (eksperten, kunden el.) forteller oss hva han vil ha og til han får det.  Vi gir han et ferdig program som gjør akkurat det han har fortalt oss at han vil ha, og som han kan teste og prøve ut at det faktisk stemmer.  I verste fall har vi lagd noe helt annet enn hva brukeren ville ha (vi misforsto hva han sa), og alt vi har gjort vil være bortkastet.  Dersom vi hadde arbeidet i to år, ville dette ganske effektivt ha stoppet prosjektet, og det ville ha vært mislykket.  Hvis vi derimot kun hadde drevet på i to til tre uker, ville konsekvensene ikke være de samme, vi ville få fortsette og brukeren vil nå kunne fortelle oss mer nøyaktig hva han vil ha (siden han allerede vet hva han ikke vil ha). 

Risikoen for at hele prosjektet feiler er redusert betraktelig, siden det i verste tilfelle kun er tre uker som er tapt av en prosjekttid på ett til to år.

Vi ser nå at vi kan redusere risiko for at prosjektet blir mislykket ved å korte ned på estimeringstiden.

I de neste artiklene skal vi se på hvordan vi kan gjøre dette i praktisk prosjektarbeide.