DEBATT: Vi mennesker liker å planlegge. Det gir oss en følelse av kontroll. Men gir det oss egentlig bedre resultater enn om vi ikke planlegger, eller planlegger mindre?
Vi er i større eller mindre grad nødt til å planlegge, enten det er dagen vi har foran oss, den personlige økonomien eller hvordan vi skal anlegge hagen. Dette er små prosjekter som er oversiktlige og dermed få ting som kan gå galt.
I den andre ytterkanten av skalaen finner vi gigantprosjekter — jeg kaller dem supertankere. Det er prosjekter det tar årevis å planlegge og like mange år å realisere.
Hvor kommer planlegging fra?
I en del bransjer er slike supertankere uunngåelige, for eksempel i bygg- og anleggsbransjen. Man er for eksempel nødt til å planlegge detaljert og grundig når man skal bygge en oljeplattform. Når plattformen først står midt ute på havet, er det vanskelig, kostbart og tidkrevende å erstatte den hvis man har gjort noe galt. Derfor planlegger man godt, før man starter med selve arbeidet.
I en del bransjer er slik planlegging helt nødvendig. Men jeg ønsker å adressere et problem: behovet for planlegging i noen bransjer har etablert en tro på at planlegging er nødvendig for alle bransjer. Det eksisterer nærmest en tro om at mer planlegging gir bedre resultater, uavhengig av bransje.
Arven fra bygg- og anleggsbransjen
Prosjektmetodikken man arbeider etter for eksempel i bygg- og anleggsbransjen, kalles fossefallsmetoden. Når man først er ferdig med ett steg, er det vanskelig å returnere til et avsluttet steg. Bygger man en oljeplattform er det kanskje best slik.
IT-bransjen var en av de nye bransjene som lenge led — og fortsatt lider — under å ha arvet fossefallsmetodikken når IT-prosjekter ble gjennomført. Fortsatt gjennomføres mange IT-prosjekter på samme måte som byggeprosjekter. Planlegge først. Bygge etterpå. Også for programvare.
Eksempelvis leveres fortsatt mange IT-prosjekter i offentlig sektor på denne måten. Bekjente i slike prosjekter forteller meg for eksempel at planleggingen de avsluttet i mars produksjonssettes i disse dager. I Estland har de en alternativ tolkning av begrepet «den norske modellen»: det er hvordan IT-prosjekter gjennomføres i Norge, med en påfølgende skandale. (Finansavisen 2. november 2013.)
Planlegging i en verden i kontinuerlig endring
I IT-bransjen, en bransje hvor forutsetninger endrer seg nesten fra dag til dag, er en slik tilnærming umulig å forholde seg til. Verden omkring har endret seg, men det har ikke planene. Og når forutsetningene endrer, seg bommer man på planen. Det koster tid og penger og prosjektet blir definert som en enda et skakkjørt IT-prosjekt.
Naturlig nok har flere sett utfordringene med en slik måte å gjennomføre prosjekter på. For programvare, som ikke skaper fysiske produkter, er det ingenting som forhindrer en i å korrigere tidligere utført arbeid når som helst i prosessen. Kodelinjene du skrev i fjor kan fint endres i morgen. Kanskje får det konsekvenser, men ingen i samme grad som et bein som må byttes på en oljeplattform.
Smidish
Misnøyen har så langt resultert i en rekke nyere prosjektmetodikker, såkalte smidige prosjektmetodikker. Hovedmålet med smidige metodikker er å eliminere fossefallsmetodens irreversible prosess, og erstatte dem med repeterende sykluser.
Men også i de mest populære smidige metodikkene er planlegging en sentral del av prosessen. Ta for eksempel Scrum, en av de mest populære prosjektmetodikkene. Scrum består av sprinter, for eksempel på tre uker.
Hver sprint innledes med et planleggingsmøte. Her planlegger man hva skal lage gjennom de neste tre ukene. Deretter bruker man de neste tre ukene på å lage det man har planlagt. Samtidig måler man fremdrift og ser hvor godt man treffer på estimatene.
Sammenliknet med fossefallsmetoden er Scrum et glimrende alternativ. Men sett isolert er Scrum en merkelig metodikk. Hvorfor ikke bare fjerne sprinten helt? Hvorfor skal man operere med disse syklusene overhodet? Hvorfor bruke så mange dagsverk på planlegging? Hvorfor så mye fokus på prosess og metodikk? Hvorfor ikke bare gjennomføre?
Smidig
I Posten har vi gått vekk fra Scrum, nettopp for å få utviklingsprosessen enda bedre. Planleggingsmøter, sprinter, retrospekt, Scrum Master, alt ble forkastet. Det eneste vi har beholdt er en backlog som holdes kontinuerlig prioritert av produkteier. Resultatet er at vi kontinuerlig leverer funksjonalitet til produksjon.
Det har gitt flere positive effekter:
- Redusert stress i utviklingen fordi man slipper å treffe en sprint med estimatene.
- Jevnere flyt i utviklingsarbeidet. Ikke alle trenger å bli ferdige for å nå en sprint til samme tid.
- Bedre kvalitet på arbeidet som følger av redusert stress for å rekke en deadline (sprint).
- Mer fleksibilitet til å omprioritere på kort varsel. Man trenger ikke vente til sprinten er ferdig.
- Mindre tid til planlegging = mer tid til gjennomføring.
- Redusert administrasjon ved å fjerne blant annet burn down charts.
- yppigere leveranser = mindre leveranser = lavere risiko.
Dette låter lettvint
Den rasjonelle delen av hjernen din har nå en konflikt med seg selv. Hvordan kan mindre planlegging gi meg mer kontroll? Tenk da på følgende: det viktige er ikke at du planlegger i detalj det du har tenkt å gjøre. Lag deg en liste over det du kan tenke deg å gjøre, prioriter listen og sett i gang! Prioriterer du feil er det bare å omprioritere og fortsette. Omprioritere, fortsette. Omprioritere, fortsette. Selvsagt vil du prioritere feil, men det gjør du også hvis du planlegger mer detaljert.
Metoden er ikke målet
Jeg har tidligere skrevet at metoden ikke er målet. Det viktigste er hvordan du får realisert dine forretningsmål raskest mulig, til lavest mulig pris, med forventet kvalitet.
Eller som Henrik Kniberg, en av mine gode inspirasjonskilder, sier:
«So, the important thing isn’t your process; the important thing is your process for
improving your process»
I en verden hvor alt er abstrakt er det du som lager reglene. Eventuelt kvitter deg med dem. Det er opp til deg!
Martin Bekkelund arbeider som direktør for produkt- og forretningsutvikling i Posten, og har arbeidet i IT-bransjen siden 1999. Følg ham gjerne på Twitter, @MartinBekkelund Dette debattinnlegget er også publisert på Bekkelunds egen blogg.
