Om risiko, innovasjon – og pudding

Hvilken strategi bør vi velge for å håndtere den uungåelige risikoen?

Det vil alltid være en sammenheng mellom vår vilje til å finne nye, fremtidsrettede, spennende løsninger og faren for å mislykkes. Dette vet alle som er opptatt av å lykkes bedre enn andre, enten de er idrettsutøvere eller aktører i et innovativt marked.

“Du kommer ikke først av å gå i andres fotspor”, “No pain – no gain”, “Den som intet våger, intet vinner”.

Alle forstår at man må tøye grensene og tråkke ut av komfort-sonen for å oppnå en utvikling litt utover det ordinære. Om målet ditt er “det ordinære” kan du slutte å lese her.

Tradisjonell prosjektstyring og tankegang er opptatt av å minimalisere risiko. Grundige analyser og detaljert planlegging skal gjøre prosjektet trygt. Fungerer dette egentlig? La oss se litt nærmere på årsakssammenhengene.

ForarbeidRisiko1

I figuren betyr ringen at det er en omvendt sammenheng, mao jo grundigere forarbeid, desto lavere risiko. Dette er en intuitiv og svært konvensjonell antagelse. Men hva om vi tenker oss at vi skal i gang med å utvikle et nytt IT-system. I våre tidlige analyser finner vi ut at brukerne ikke kan gi oss noe klart svar på hva de trenger. Videre ser vi at dette er et område vi ikke er helt trygge på, det er ganske nytt for oss. Dessuten vet vi at i dette markedet skjer det stadige endringer og skal vi være helt oppriktige er det sannsynlig at noe helt uventet vil komme til å skje det neste året. Hva om vi legger inn disse faktorene i årsakssammenhengen?

ForarbeidRisiko2

I fiiguren står C-ene for constraints (beskrankninger). Under slike rammebetingelser begynne vi å ane at det grundige, tidkrevende forarbeidet kanskje ikke vil redusere risikoen.

Usikre brukere: Man kan intervjue brukere, lage prototyper og be om brukernes tilbakemeldinger på om dette virker fornuftig. Om de liker det. Men det vil være grenser for hvor mye kunnskap vi kan få på denne måten. Historien er full av gode forsøk på brukerundersøkelser, der man setter sin lit til det brukerne uttrykker og baserer kravspesifikasjonene på dette. Men når systemet vel er ferdig, viste det seg at brukerne ikke likte det de fikk allikevel. Man kan si det er “overraskende vanskelig” å komme til bunns i brukernes behov og ønsker på et teoretisk plan. Det er først når de sitter med løsningen foran seg og får prøvd det ut at den endelige dommen vil falle. I en ren analysefase er det overveiende sannsynlig at vi vil måtte spikre noen antagelser for å få framdrift. All erfaring viser at dette er svært risikabelt!

Dynamikk: I vår tid er det i de fleste markeder en betydelig dynamikk. Behov endrer seg, ny teknologi dukker opp, alternative løsninger finnes – alt dette mens vi kjører prosjektet. Om vi oppdager dette må vi kjøre kostbar endringsbehandling. Om vi ikke oppdager det underveis, ender vi opp med et utdatert produkt. Hva om endringer skjer mens vi analyserer behovene og beskriver løsningene? Om vi tar oss god tid her, risikerer vi jo at spesifikasjoner og planer er utdaterte allerede før vi starter!

Stor nyhetsgrad: Om vi er innovative og det vi skal lage er helt nytt må vi selvsagt bruke en del tid for å finne mulige løsninger. Men det vil også være begrenset hva vi kan få ut av en slik analyse. Antallet ukjente faktorer vil være stort, og disse faktorene kan til alt overmål påvirke hverandre. Faren vil være stor for at vi her vil basere oss på antagelser som er vage, og kun egnet til å gi oss en falsk trygghetsfølelse.

ForarbeidRisko3

Så under slike rammebetingelser vil vi med andre ord få en sammenheng der grundigere forarbeid vil øke risikoen(!)

Oppsummert: Når vi har rammebetingelser som gir dynamikk og usikkerhet – som de fleste IT-prosjekter har – må vi være bevisste på å ikke bruke for mye tid og energi på forarbeide før vi setter i gang.

Alternativet til grundig analysearbeid

Alle tyr vel fra tid til annen til “prøve-og-feile-metoden”. Når vi er på utrygg grunn lønner det seg å gjøre noen tester før vi tar på oss for store forpliktelser.

Vi hadde en forholdsvis nyinnkjøpt hytte med furu vegger, tak og gulv. Etter noen år var vi enige om at det kanskje var litt for mye gulnet furu, så vi bestemte oss for å tilføre veggene og taket noe farge. Men vi ville fremdeles at treverket skulle være synlig, så vi trenge noe som var transparent. Vi (les: kona) gikk i gang og sjekket markedet og fant fort ut at det veldig mye å velge imellom av beis og oljebaserte produkter. Men det er jo vanskelig å få et godt inntrykk av farge og gjennomskinnelighet i brosjyrer og på nett, så vi skjønte fort at her måtte vi teste ut alternativer. Heldigvis har malingsbransjen forstått dette og gjort det mulig å kjøpe små kvanta for å gjøre tester. Så vi testet ulike farger og produkter på løse planker, og deretter på selve hytteveggen før vi var trygge nok til at vi kunne gå til innkjøp av store kvanta. Vi endte opp med et for oss helt nytt produkt basert på voks. Denne skulle i følge oppskriften på boksen påføres i ett strøk, og overskuddsfarge tørkes av etter ca 20 minutter. Når vi så var i gang med å påføre dette produktet, oppdaget vi raskt at resultatet på ingen måte var gitt ved å følge oppskriften på boksen til punkt og prikke. Vi trengte fremdeles å vinne erfaring med hvordan den skulle påføres og ikke minst hvor lenge vi skulle vente med å tørke av overskuddsfarge. Antageligvis er det stor forskjell på treverk og slike detaljer kan ikke spesifiseres på forhånd.

Her kommer  Lean-prinsippet “Last Responsible Moment” til sin rett. Vi venter med å binde oss til endelig løsning før vi har validert antagelsene våre gjennom å ha få ting i arbeid.

“The proof of the pudding is in the eating”

Det første nødvendige skrittet å ta er å innse at vi ikke har – eller kan få – full kontroll. Vi må leve med usikkerheten: Det er bare sluttresultatet som vil fortelle oss om vi lykkes eller ikke. Selv det å lage en perfekt pudding er overraskende vanskelig og usikkert – vi må faktisk smake på det ferdige produktet før vi kan evaluere resultatet og konkludere om vi har lykkes eller ikke.

I klartekst betyr dette at fram til det tidspunktet vi ferdistiller noe, vil alle påløpte kostnader måtte betraktes som økonomisk risiko. Vel, det kan hende at noe av arbeidet kan ha verdi, selv om sluttresultatet var ubrukelig, men det er slett ikke sikkert.

KostRisikoVannfallPudding

Historien er full av IT-prosjekter som etter alt for lang tid og akkumulerte kostnader finner ut at de har feilet. Kanskje de har løst feil problem. Kanskje de har løst problemet feil. Uansett – de har oppdaget dette alt for sent!

Smidig tankegang anerkjenner virkeligheten. Vi må forstå dynamikken og usikkerheten vi står overfor og vi må ta denne virkeligheten på alvor. I stedet for å bekjempe usikkerheten må vi forsøke å absorbere den! Dette gjør vi ved “prøving og feiling” eller kanskje et bedre uttrykk: Empirisk Prosesskontroll. Vi må skaffe oss empiri så raskt og billig som mulig slik at vi kan validere antagelsene vi har gjort. Og vi er ydmyke for at vi kan ha tatt feil.

KostRisikoSmidigPudding

I figuren ser vi hvordan man kan kjøre små tester eller eksperimenter med det for øye å vinne erfaring og få validert antagelser. De første inkrementene vi ferdigstiller lager vi bare for å få i gang en valideringsprosess i tett samarbeid med brukerne. Dette blir veldig tilsvarende den vitenskapelige metode. Her ser vi også at konsekvensen ved å feile blir liten. Vi kan med andre ord senke skuldrene og våge oss utpå litt dypere vann en tidligere. Om noen av inkrementene ikke er vellykkede blir ikke konsekvensen så stor. Dessuten gir også disse inkrementene vedifull læring!

Så dette slitter helt andre krav til organisasjonen enn tradisjonell prosjektstyring. Vi har et annet syn på virkeligheten og vi trenger helt andre sett av metoder og ferdigheter.

 

 

2 Responses

Subscribe to comments via RSS

  1. Written by Johannes Brodwall
    on 27/11/2014 at 9:36 am
    Reply · Permalink

    En spennende provoserende påstand med det siste effektdiagrammet, Geir.

    Jeg ville tipse deg om en blogpost som tar opp samme temaet: “Action precedes clarity” av Naresh Jain: http://blogs.agilefaqs.com/2014/06/19/action-precedes-clarity/

    Jeg synes tittelen til Naresh sin blogpost er underfundig og understøtter ditt poeng godt. Blogposten minnet meg også på Poppendieck’s Predictability Paradox.

Subscribe to comments via RSS

Leave a Reply