Martin Bekkelund

Under IT-tinget 2010 snakket Karl Philip Lund (Shortcut) og Robert Isaksen (Hurtigruten) om en av mine kjepphester i prosjektledelse av IT-prosjekter; fortreffeligheten av å levere ofte.

En av de vanligste årsakene til at IT-prosjekter feiler er at de ikke leverer den funksjonaliteten de skal. Det blir gjerne nedsatt en prosjektgruppe som gjennomfører et stykke arbeid som til slutt ender ut i en leveranse. Tidligere gjennomførte man gjerne én prosess som resulterte i én leveranse, mens man i dag ofte gjennomfører denne prosessen med flere leveranser.

Det viktigste et IT-prosjekt gjør er å levere lite funksjonalitet ofte. I motsatt fall, ved å levere mye funksjonalitet sjelden, tilfører man løsningen mer funksjonalitet og dermed økt kompleksitet og risiko, slik figuren under viser.

Alternativet med å levere lite funksjonalitet ofte, reduserer kompleksiteten og risikoen for at noe går galt. Ved å levere lite funksjonalitet gjør man det enklere å korrigere feil i løsningen, samt å gjøre endringer i funksjonaliteten dersom den ikke er i henhold til brukernes forventninger, slik figuren under viser.

Når man skal prioritere funksjonalitet som skal leveres, lager man først en tabell som lister opp alle hovedfunksjonene man ønsker i løsningen. I tabellen putter man også inn estimater for pris og kompleksitet. Tabellen kan for eksempel se slik ut:

Deretter omsetter man tabellen i en matrise. Den gjør det lett å velge hvilken funksjonalitet man bør prioritere først, slik.

Figuren gjør det enkelt å velge det man kaller lavthengende frukt først.

Spesielt i store IT-prosjekter er denne formen for smidig prosjektgjennomføring både viktig, effektiv og gir umiddelbare resultater. Prosjektet leverer raskt og fortløpende, risikoen reduseres og brukerne blir fornøyde.

Merk at dette ikke er en beskrivelse av selve metodikken. Artikkelen er ment å illustrere prinsipper for å redusere risiko. Selve prosjektmetodikken kan gjennomføres etter forskjellige kjente smidige metodikker.

I stedet for å starte med lange forprosjekter, utredninger, diskusjoner i overdimensjonerte prosjektgrupper og annen tidkrevende akrobatikk som gjør en løsningsblind, bør man starte med å levere noe raskt. Man har tross alt en viss idé om hva man skal levere.

Sett i gang!