Kunsten å kjøpe det ukjente

Du har identifisert et behov som vil fordre utvikling av et nytt programvareprodukt, og trenger å selge denne ideen inn til de som sitter med budsjett- og innkjøpsansvar. Du har gjort en gevinstanalyse, og den potensielle nytteeffekten er klar og overbevisende. Du har en klar visjon og en ide om den viktigste funksjonalitet du vil trenge. Du tenker videre at om jeg får de rette folkene på laget vil vi sammen kunne utvikle produktet og løse problemene vi støter på underveis. Hva svarer du da på det uunngåelige spørsmålet ”Hva vil det koste?” når selve sluttproduktet er ukjent?

 

En person med budsjettansvar vil selvsagt gjerne vite hva det vil koste å utvikle dette systemet, før beslutningen om å finansiere gildet tas. Dette initiativet må veies opp mot andre gode initiativer og vi trenger å gjøre en kost/nytte-vurdering. Så om du selger ideen din på denne måten kommer du garantert til å bli møtt med: “Du må spesifisere dette systemet og finne ut hva det vil koste!”

Du vet at komplett spesifisering av slike systemer er en illusjon. Det er alt for mye usikkerhet, kompleksitet og dynamikk til dette vil gi noen særlig verdi. All erfaring viser at det systemet du ender opp med er helt ulikt spesifikasjonen, samt at vi vil ha utviklet en masse funksjonalitet som ikke brukerne verdsetter. Og du vet på samme måte at kostnadsestimeringen er illusorisk og egentlig bare en takstisk lek med tall.

Du har nå to valg:

1. Kjøre tradisjonelt; Være taktisk, “spille spillet” og be om finansiering til å kjøre et forprosjekt, slik at du får spesifisert det nye systemet og estimert kostnadene så godt det lar seg gjøre. Deretter be om finansiering til selve prosjektet. Dette vil føles trygt og gjenkjennelig for innkjøperen og du kan regne det som ganske sikkert å i det minste få kjøre forprosjektet eller “konseptfasen”.

2. Kjøre smidig; Insistere på at det er tryggere og bedre å starte utviklingen raskt og å finansiere dette i fortløpende bolker, basert på evaluering av de resultatene som er oppnådd. Du argumenterer med lavere risiko og hurtigere gevinstrealisering samt optimalisering av brukerverdi. Dette vil allikevel føles utrygt og underlig for innkjøpere – en svært uvant måte å tenke på, og det er lite trolig at du vil få “GO”.

For å få muligheten til å gjøre dette smidig trenger du en god argumentasjon. Du må vise hvordan dette kan bli tryggere, raskere og bedre, på en pedagogisk måte. Dette er ingen enkel øvelse, men gitt at du får anledning kommer her noen gode svar på et par opplagte spørsmål:

“Hvordan kan det bli tryggere av å gjøre mindre forarbeid?”

Det blir tryggere ved at vi nå kan finansiere utviklingen løpende, i stedet for å legge store summer på bordet i starten. All erfaring viser at store leveranser er svært krevende, og at vi vil sitte med stor risiko på slutten av prosjektet, når alt til slutt skal integreres og testes.

 

RisikoNorsk

I figuren ser vi hvordan risikoen akkumuleres opp mot den store leveransen. Man vet aldri sikkert hvor vellykket et prosjekt er før det har vært i drift en stund. “The proof of the pudding is in the eating” sier Britene. Ganske riktig, det er sluttresultatet som virkelig teller. Og vi vet av bitter erfaring at når vi måler vellykketheten, må vi i tillegg ta vedlikeholdsbarheten, eller graden av teknisk gjeld med i regnestykket. Så de store, tidkrevende leveransene er per definisjon langt mer risikable enn et smidig løp der man leverer små, ferdige “puddingbiter” fortløpende og dermed “spiser opp risikoen” etter hvert som man jobber. At dette i tillegg gir en helt overlegen gjennomsiktighet og styringsmulighet, gjør ikke gevinsten mindre.

Store IT-prosjekter blir også svært krevende å organisere og styre på en fornuftig måte. Det er vanskelig for en prosjektleder å vite hva som faktisk foregår, fremdriftsmålingen usikker, og koordinering ofte et mareritt mot slutten av prosjektet.

“Hva med bruken av kalendertid?”

Vi vet at i IT-bransjen er de gode ideene “ferskvare”. Om vi ønsker en grad av innovasjon må vi evne å realisere gevinster rimelig raskt. Dette gjelder selvsagt også i ofentlig sektor. Programvare er ikke fysiske produkter slik vi er vant til i de flste andre ingeniørdisipliner. Programvare kan deles opp i små delleveranser, i stedet på å samle alt i en diger “pakke” på slutten av et prosjekt.

I figuren ser vi hvordan et tradisjonelt prosjekt typisk vil bruke svært mye kalendertid på å utvikle konseptet og å planlegge. Det gjelder naturlig nok å skaffe seg best mulig beslutningsgrunnlag for å totalfinansiere en diger leveranse et godt stykke inn i framtiden. Vi har erfaring for at slike prosjekter ofte går langt ut over rammene sine, så vi legger ekstra mye arbeid inn i forarbeidet for å redusere risikoen.

I det smidige løpet vet vi at vi kan senke skuldrene og klare oss med langt mindre analyse i forkant. Vi trenger ikke lenger å legge store beløp på bordet – dette kan finansieres fortløpende og hele satsningen kan evalueres og styres ut fra de resultatene som hittil er oppnådd. Det som blir svært viktig er å velge ut det aller viktigste å jobbe med –  i samarbeid med brukerne – slik at vi kan maksimalisere verdiskapning og læring. Rekkefølgen blir her helt avgjørende.

Gevinster realiseres dermed svært tidlig, og kommer i en ganske jevn strøm. Dette åpner for en løpende, tett dialog med brukerne slik at de kan få direkte inflytelse på de prioriteringene som gjøres og den gevinsten som skapes.

Konklusjon

Skal du kjøpe inn noe komplekst som krever kreativitet og innovasjon og som er utsatt for dynamikk mens vi jobber, bør du velge en framgangsmåte som er optimalisert for nettopp dette. Våg da å insistere på å bruke en gjennomføringsmodell som bygger på smidige prinsipper. Velg for eksempel Scrum som er et gjennomprøvd, enkelt rammeverk skreddersydd for denne virkeligheten.

Posted on January 21, 2014 at 5:23 pm by gamsjo · Permalink
In: ledelse, produkteier, prosjektledelse · Tagged with: , , , , ,

3 Responses

Subscribe to comments via RSS

  1. Written by Det smidige hjørne » Kunsten å planlegge det ukjente
    on 29/01/2014 at 12:14 pm
    Reply · WordPress › Error