tirsdag 19. april 2011

Ledertips: Utsett beslutninger til så sent som mulig!

Jeg har gitt dette ledertipset til mange, og blir ofte møtt med smil og hoderisting: Hva slags leder er dette som vil utsette beslutninger? Gode ledere er vel de som tar beslutninger like lett som de slipper en fis? Som prosjektleder er det mange oppgaver som må gjøres, og mange små og store beslutninger som må tas. Da kan det være deilig å ta beslutningene, alle som en, i starten av prosjektet. Da vet vi jo hva vi har å forholde oss til?

I Norge er det mange eksempler på beslutninger som er tatt for tidlig. Fra 90-tallet har vi Rikstrygdeverkets Tress 90 prosjekt hvor tusentalls innkjøpte og ubrukte PCer ble eksemplet på prosjektledelsens inkompetanse. Datamaskinene ble kjøpt da man hadde fått et knakandes godt tilbud, men grunnet forsinkelser ble de stående på lager. Et annet skandaleprosjekt fra dette tiår er Flexus prosjektet, hvor ledelsen hadde kjøpt inn enorme mengder med Flexus-kort som i årevis ble liggende på lager. Når kortene endelig kunne selges, sluttet de å fungere grunnet lang lagringstid.

Dette er eksempler på for tidlige beslutninger som er blåst opp i media, men den største synderen er alle oss tusentalls prosjektledere som kjører våre små prosjekter med budsjetter på noen få millioner kroner: Vi lager spesifikasjoner tidlig i prosjektet hvor vi i detalj forteller hva vi skal gjøre. Tradisjonelt businessliv verdsetter denne egenskapen høyere enn gode resultater: Prosjektledere som forteller hva de skal gjøre, når! Dersom du som prosjektleder holder dine løfter, vil du bli båret på gullstol inn i toppledelsen. Underordnet er prosjektets resultater: Er kundene fornøyd? Har vi en stabil drift av systemet? Det som teller er at du med jernhånd har levert akkurat det du sa du skulle levere, basert på tidlige beslutninger. Men dersom du er interessert i å levere løsninger kundene liker til en rimeligere kost, så bør du lese videre.

Prosjektoppstart er naturlig nok tidspunktet hvor vi vet minst om prosjektets suksess, men vi vil lære i løpet av prosjektet. De fleste prosjekter har elementer av nyhet i seg, og deltagere som gjør noe for første gang. Derfor bør vi gjøre kun de nødvendige beslutningene ved starttidspunktet, og skyve på alle andre beslutninger til vi vet mer. Dette er også fornuftig da forutsetningene kan og vil forandre seg i løpet av prosjektets gang. Ganske ofte utsetter jeg beslutninger andre vil at jeg skal ta, da vi har mulighet til å utsette dem. Kall det gjerne feig ledelse, men dette fungerer! Alle beslutninger som må tas i dag, blir selvfølgelig tatt med umiddelbar implementasjon.

Beslutninger på kø

I en ledergruppe jeg satt i for noen år siden fulgte vi ikke prinsippet om å utsette beslutninger. Faktisk tok vi så mange at vi ikke hadde oversikt over hvilke vi hadde tatt. På et tidspunkt laget vi hver vår prioriterte liste over beslutningene vi hadde tatt det siste året, til stor overraskelse for oss alle. Listene var jo ikke like? Så plukket vi ut hvilke av disse beslutningene vi hadde kommunisert ut til de ansatte, og hvilke vi hadde implementert. Omtrent 1 av 20 beslutninger var suksessfullt implementert, en gjennomføringsrate på 5%. Mengden av beslutninger vi hadde tatt forvirret ikke bare ledergruppen, men også de ansatte. Verden endret seg, og de gamle beslutningene vi hadde tatt, var ikke lenger gyldige. Ofte diskuterte vi om vi hadde tatt en beslutning, og hva den egentlig inneholdt. Faktisk så måtte vi starte med et beslutningsregister (i Excel), hvor vi kunne gå tilbake for å friske opp hukommelsen.

Beslutninger bør derfor tas når de må, det vil si etterfulgt av en umiddelbar implementasjon av beslutningen. Man slipper diskusjoner om hva man egentlig besluttet, og på hvilket grunnlag. Kommunikasjonen mellom lederne blir rensket for misforståelser, og ledelsen blir tydeligere for de ansatte. Du vil oppleve en enklere men mye mer effektiv ledelsesform rensket for unødvendig støy.

At man skal utsette beslutninger til så sent som mulig kommer fra Lean filosofien!

5 kommentarer:

  1. Godt poeng du har her Rune! Flexus sine kortlesere og sperrer er veldig synlige, talende eksempler på hvor galt det kan gå når man er for ivrig etter å låse løsningen.

    Tror forresten generalene var tidligere ute enn Lean. De hadde gjerne Plan A og B (og kanskje C) klar, men ventet til siste øyeblikket, da mest mulig informasjon var tilgjengelig, med å gi ordren.

    SvarSlett
  2. Veldig bra Rune! Jeg er midt oppi to prosjekter nå hvor jeg priser meg lykkelig at vi ikke tok beslutninger ved oppstart - for nå er begge prosjektene betydelig endret...

    SvarSlett
  3. Geir, Det er mye vi skal takke krig for (http://weburbanist.com/2010/01/12/weird-military-innovations/)!

    Thomas, da håper jeg at den detaljerte kravspesifikasjonen glimret med sitt fravær! Forandring er jo bra!

    SvarSlett
  4. Fin artikkel, Rune! Jeg deler synet ditt på å utsette beslutninger så lenge som mulig. Erfarer mye av det samme når vi arbeider med brukerintervjuer og konseptutvikling etter å ha mottatt en kravspesifikasjon fra kunden. Det hender jo at vi lærer noe nytt underveis :-)

    Jeg lurer på en ting... Hvordan jobber du med planlegging når du samtidig utsetter selve beslutningen? Ingen er tjent med kaos og plutselige innfall, vil jeg tro. Wikipedia-artikkelen om Lean sier litt om det, at planlegging bl.a. skal fokusere på de ulike alternativene. Hva mener du er riktig fremgangsmåte for smidig og ryddig prosjektstyring?

    SvarSlett
  5. For det første, hold planleggingen på et minimum. Du ønsker ikke å kaste bort tiden på å planlegge noe du ikke kan gjennomføre.

    Det viktige er å legge rammer og visjoner (som er romslige nok til å være almenngyldige). Rammene kan godt være absolutte (timeboxing). Når du så starter prosjektet, planlegg nok arbeid til 2 sprinter (1-2 måneder) men ikke mer. Det du planlegger å gjennomføre bør være noe som er realiserbart og nødvendig.

    Når du planlegger din 1-måneds sprint, bør du lage noe som er demonstrerbart. Dette fører til at de plattformkåte arkitektene blir skuffet, da du neppe rekker å lage noe stort rammeverk innenfor den korte tidshorisonten. Dette er hele poenget, man skal ikke bruke mye tid på å lage plattformer som står igjen når toget kjører. Istedet skal man bruke tid på å tilpasse teknologien til erfaringer man får utover i prosjektet (refactoring).

    Gjør du dette riktig, så vil du slippe å planlegge mange måneder inn i framtiden, og du utsetter alle beslutninger som du uansett ikke trenger å ta.

    Smidige prosjekter jobber etter detaljerte backlogger, og rapporterer daglig status. Så her er mer struktur og kontroll en i tradisjonelle planleggingsprosjekter! Når du utsetter de unødvendige beslutningene får du mer tid på å gjennomføre de nødvendige beslutningene, som gir deg et tydeligere prosjekt.

    Man må se på et prosjekt som en reise inn i det ukjente, hvor man trenger gode navigatører. Å ta beslutning på hvor vi skal sove om 6 uker er uansett bortkastet planleggingsarbeid da vi ikke vet hvor vi er om 6 uker. Man må istedet sørge for at man er beredt til å håndtere de eventuelle situasjonene som måtte dukke opp!

    SvarSlett