Å planlegge for det ukjente

Hvor langt kan vi se klart?

Erkjennelsen om at fremtiden er høyst usikker synker inn hos de fleste. Heldigvis. Vi vil opplagt tjene på å ha et realistisk syn på den virkeligheten vi befinner oss i. Hvilke konkrete implikasjoner har denne usikkerheten på måten vi setter mål, lager strategier, planlegger og følger opp? Og har det følger for hvordan vi bør organisere oss?

Virksomheter vil fortsatt sette seg store, ambisiøse mål som vil ta lang tid å oppnå. Vi må selvsagt fremdeles lage planer for dette.

En slik plan vil måtte basere seg på antagelser og forutsetninger. En leder- eller styringsgruppe bør nå snarest stille seg noen vitale spørsmål:

Det er altså en grense for hvor lenge en langtidsplan har verdi. Problemet er at den ofte vil få leve alt for lenge! Det er tross alt investert arbeid, penger og prestisje i denne planen. Dessuten har vi en tendens til å innbille oss at vi har med kontroll enn vi har grunnlag for.

“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.”

Mark Twain

Så vi reagerer alt for ofte alt for sent.

Den ene, lineære langtidsplanen har altså utspilt sin rolle. Hvordan ser et mer realistisk planleggingsbilde ut da? Slik?

Å navigere mot mål i bevegelse

Jeg vil her ta til orde for 5 essensielle tankesett for vellykket planlegging i dagens virkelighet:

  1. Hold opsjoner åpne
  2. Innhent status basert på fakta
  3. Unngå indirekte kommunikasjon
  4. Bygg inn retrettmuligheter
  5. Endring er positivt

1. Hold opsjoner åpne

Det vil fremdeles kunne ta år å oppnå ambisiøse mål. Samtidig må vi ha stor ydmykhet i forhold til at forutsetninger kan endre seg underveis, slik at vi må endre mål og strategi. Og kanskje terminere først som sist før vi bruker for mye tid og krefter på noe som ikke har livets rett.

Så det første budet er altså å unngå å låse seg for tidlig. Det er i prinsippet to ulike måter å oppnå dette på

A) Løs problemet i korte, etterfølgende iterasjoner der flest mulig er egnet til å få realitetssjekket forutsetninger.

B) Jobb fram ulike løsninger i parallell, før en av disse velges.

Disse to strategiene kan utmerket godt kombineres. A) legger til rette for å raskt (og billig) få gjort en avsjekk på om vi er på vei mot et godt resultat. En “bieffekt” av denne fremgangsmåten er at gevinster kan realiseres tidlig og deretter fortløpende. B) vil naturlig nok koste en del og kan være egnet der usikkerheten er spesielt stor. I en tidlig designfase på et større delproblem vil man på denne måten kunne gjøre A/B testing eller Set based design for å validere ulike mulige valg opp mot hverandre.

Det er her fornuftig å se på valgmuligheter som verdifulle. Chris Matts og Olav Maassen argumenterer godt for dette under Real Options i boka Commitment :

Options have value

Options expire

Never commit early unless you know why.

I klartekst betyr dette at vi må holde planer og spesifikasjoner åpne så lenge som mulig. Langtidsplaner må ikke oppfattes som forpliktende. Dette er jo akkurat det smidige metoder som Scrum legger opp til. Omfanget er en kø med elementer som realiseres i en prioritert rekkefølge. Denne køen er ikke “komplett”. Løsningen leveres i små inkrementer som hele tiden integreres i totalproduktet.

Unngå dette: Definert prosesskontroll, tradisjonell prosjektstyring, grundig analyse og planlegging, separate roller.

Forsøk i stedet dette: Empirisk prosesskontroll, Lean Start-up, Scrum og permanente, tverrfaglige, selvstyrte team.

2. Innhent status basert på fakta

Vi må altså unngå å la antagelser få leve for lenge. Problemet er at det er svært krevende for de som er midt oppe i en problemstilling å vurdere disse på en objektiv måte. Man blir alt for lett “forelsket i ideen sin” og mister nødvendig kritisk sans.

Alle prosjekter baserer seg på en rekke mer eller mindre velfunderte antagelser. Hvor mye verd er utsagnet Status er “på plan” – hvis dette baserer seg på antagelsene om at brukerne aksepterer brukergrensesnittet, at systemet tåler mange samtidige brukere, at sikkerhetsløsningene er gode nok og at lite endrer seg underveis?

Så hva er alternativet? Jo det er lett – bare overlat dette til brukerne. Vel, det er ikke nødvendigvis lett, men ekte brukerne er en alt for lite benyttet ressurs.

I en oppstartsfase trenger vi å eksponere noe håndfast til et antall potensielle brukere. Disse første inkrementene kan godt være prototyper, så lenge vi kan få svar på grunnleggende spørsmål som “sett at denne var helt ferdig, er dette noe du kunne tenke deg å betale for?” eller “hva må vi gjøre med denne for at du vil bruke den?” På denne måten forsøker vi å validere selve ideen. Når vi så har kommet lenger og har levert noen “ekte produktinkrementer” må vi forvisse oss om at brukerne faktisk tar det i bruk i et slikt omfang vi håpet. Spørsmål som “hvor mange faste brukere må vi ha før vi er rede til å finansiere videre satsning” blir da helt avgjørende.

Når vi så har opparbeidet en kundebase kan vi logge brukeradferden i mer detalj og få rikelig med fakta å styre videre framdrift i forhold til. “Har vi tilstrekkelig mange førnøyde kunder nå til at vi skal skalere ytterligere opp?”

3. Unngå indirekte kommunikasjon

Det er altså helt vesentlig å ta beslutninger raskt, basert på faktisk status. Så hvordan designer vi raske, trygge beslutningsprosesser? Hvordan sikrer vi at de som faktisk fatter beslutninger er tett på virkeligheten og ser bildet klart? Hvordan minsker vi gapet mellom strategisk og taktisk nivå?

Det optimale er helt opplagt at de som sitter tett på brukerne og som samtidig er oppdatert på trender og teknologiutvikling bidrar sterkt i beslutningsprosessene. Ledergrupper er alt for ofte langt unna “den virkelige verden” og må basere seg på rapporter som forenkler virkelighetsforståelsen. Noen ser bare tallene, uten å ha grunnlag for å forstå hva som ligger bak disse.

Ergo; raske beslutninger må fattes av tverrfaglige, operative team. Kundesupport, drift, utvikling, test, markedsføring vil alle ha sine verdifulle perspektiver. Når et slikt team har kommet til en konklusjon må de kunne iverksette raskt. Noen tiltak vil utgjøre mindre justeringer slik at ledelsen bare trenger å informeres. Andre tiltak kan utgjøre en strategisk retningsendring, som naturlig nok må godkjennes (raskt) av ledelsen.

Om beslutninger skal fattes effektivt av operative team, må disse naturlig nok ha en like klar målforståelse som ledelsen. Så her er det ingen vei utenom å involvere bredt når nye strategiske mål og visjoner skal meisles ut. Dersom tverrfaglige team har et solid eierskap til selve visjonen de jobber mot vil de i stor grad kunne styre seg selv. Gjør som google og forsøk å gi tverrfaglige team best mulige betingelser for å lykkes.

Både hierarkier og fagorienterte avdelinger (“siloer”) fører til indirekte kommunikasjon, noe som igjen vil føre til misforståelser, kødannelser, sub-optimalisering og forsinkelser. Disse tradisjonelle mekanismene må aktivt bekjempes dersom man ønsker å skape en endringsdyktighet.

4. Bygg inn retrettmuligheter

Løsningene som fører fram mot målet må være fleksible av natur, slik at det ikke koster alt for mye å gjøre om på det som allerede er laget. Det er klart at en strategisk retningsendring vil ha en kostnad i form av at noe utført arbeid vil måtte “kastes” eller gjøres om. Ingen vei utenom dette. Trikset er å bygge opp tjenesten og produktet på en slik måte at ikke alt for mye berøres når ting må endres.

Det finnes utallige måter å strukturere programvarebaserte produkter på. Noen vil hevde at brukerfunksjonene må stå på en solid og veldefinert plattform. Noen vil si at det viktigste er å lage gjenbrukbare felleskomponenter. Andre vil vektlegge autonomitet der løst koblede tjenestemoduler kan operere mest mulig uavhengig av hverandre. Andre vil fokusere mest på svært enkle og veldefinerte API-er. Ikke noe av dette er fullstendig riktig eller galt, men moderne systemer må ta høyde for endringsevne og skalerbarhet. I det perspektivet kan noen basale prinsipper være til hjelp:

Arkitektur laget for fleksibilitet og ikke stabilitet. Ikke forvent at strukturen til systemet vil være stabil i lang tid – forvent at denne må jobbes med hele tiden. Og for all del, unngå at sentrale felleskomponenter får bli så store at selv små endringer får omfattende konsekvenser – og følgefeil – for brukerne av komponenten.

Akseptere duplisering. Duplisering av kode og data virker intuitivt uøkonomisk og skummelt, men må allikevel aksepteres dersom man skal klare å være mer styrt av brukernes behov enn av gamle tekniske valg.

Utnytt skyen. Skyen gir helt nye muligheter for å jobbe i raske sykluser og å unngå at man bli låst fast i egne løsninger som opprinnelig var laget med andre forutsetninger enn dagens for øye.

Rulle raskt tilbake. Når brukerne får noe annet enn de behøver og gir negativ feedback, må vi kunne respondere rask med å korrigere eller evt fjerne det vi lagde. Ta da jobben med å fjerne koden, slik at systemet ikke pådrar seg mer kompleksitet enn nødvendig.

5. Endring er positivt

Når omgivelsene endrer seg må vi altså hurtig tilpasse oss endrede forutsetninger. Hvis vi har på plass punkt 1-4 over vil vi etter hvert se at endringer ikke nødvendigvis er noe problem. Endring gir muligheter. Endring er verdi og ikke kostnad! Vel, endrede forutsetninger kan selvsagt også utgjøre trusler, men en endringsdyktig, robust organisasjon vi kunne omstille seg raskt nok til å utnytte situasjonen.

Når endring kommer inn i “virksomhetens DNA”, vil den begynne å oppføre seg annerledes. Folk venner seg til at vi stadig lærer og det blir tydelig at vi godt kan koste på oss og ta sjanser. Vi kan faktisk utføre små eksperimenter og på den måten teste ut mer eller mindre gjennomtenkte ideer.

Med disse 5 prinsippene på plass vil organisasjonen – offentlig som privat – være rustet for fremtiden og utnytte ressursene bedre enn det som ofte er tilfelle. Hvorfor ikke starte året med å legge en plan for endringsdyktighet?

Posted on February 27, 2017 at 5:44 pm by gamsjo · Permalink
In: Endringsledelse, ledelse, Planlegging, produkteier, Uncategorized · Tagged with: , , , ,

2 Responses

Subscribe to comments via RSS

  1. Written by Jon Steinar Kjøllesdal
    on 28/02/2017 at 3:55 pm
    Reply · WordPress › Error