twitterfacebookyoutubeflickrrssmail

Gjesteblogger Nils Magne Larsen skriver om å obdusere et prosjekt før det igangsettes.

Gjesteblogger Nils Magne Larsen skriver om å obdusere et prosjekt før det igangsettes.

Er det en idé å «obdusere» et prosjekt før det i det hele tatt igangsettes?

Når jeg leste Steven Levitt og Stephen Dubner’s bestselgende bok «Think like a Freak» kom jeg over en interessant metode, som i alle fall ved navn var ny for meg. I boken diskuterte de blant annet romfergen Challenger, hvor en av ingeniørene som jobbet for en av underleverandørene til NASA hadde foreslått utsettelse av oppskytningen nok en gang, etter en rekke utsettelser tidligere. Han mente at det uvanlig kalde været kunne svekke gummi O-ringene som forhindret gass fra å lekke ut fra romskipets gasstanker. En lekkasje ville lett kunne bli antent under oppskytningen og lede til en fatal eksplosjon. Disse O-ringene hadde aldri blitt testet i slike lave temperaturer. Anbefalingen ble ikke tatt til etterfølgelse da NASA var engstelig for hvilke reaksjoner en ytterligere utsettelse av oppskytningen ville få. Dette var første gang NASA overså en anbefaling som knyttet seg til sikkerhet. Som mange vet eksploderte Challenger i luften under oppskytingen i 1986. Foruten det fryktelige med tap av menneskeliv og verdier var dette en gedigen mediekatastrofe for NASA. Først og fremst fordi skolelæreren og sivilisten Christa McAuliffe var plukket ut for å være med på turen. Årsaken til eksplosjonen var nettopp en svikt i gummi O-ringene på grunn av det kalde været!

Obdusere (2)

On January 28, 1986, the Space Shuttle Challenger and her seven-member crew were lost when a ruptured O-ring in the right Solid Rocket Booster caused an explosion soon after launch. This photograph, taken a few seconds after the accident, shows the Space Shuttle Main Engines and Solid Rocket Booster exhaust plumes entwined around a ball of gas from the External Tank. Because shuttle launches had become almost routine after twenty-four successful missions, those watching the shuttle launch in person and on television found the sight of the explosion especially shocking and difficult to believe until NASA confirmed the accident ( Bildet er hentet på Wikimedia commons).

 Tør du pre- obdusere prosjektet ditt?

Det som gjør denne historien bemerkelsesverdig, og også tragisk, er at involverte i prosjektet allerede før romfergen ble skutt opp hadde prognostisert den eksakte årsaken til svikten. Levitt og Dubner stiller seg spørsmålet om hvordan man best kan lære om hvordan man kan mislykkes uten å faktisk gå gjennom trøbbelet med å mislykkes. Dette er kjernen i det som Gary Klein i en Harvard Business Review artikkel (september, 2007) kaller for «performing a project premortem». Han hevder at mange prosjekter mislykkes fordi for mange personer er tilbakeholden med å snakke om deres bekymringer for prosjektet og reservasjoner i løpet av den viktige planleggingsfasen. Det handler derfor om å skape tilstrekkelig takhøyde slik at de som er bekymret for svakhetene med prosjekter snakker ut åpent om dette, og at de blir hørt. Grunnen til at Gary Klein foreslår at man bør «obdusere» et prosjekt før det i det hele tatt igangsettes er at forskning utført av forskere ved The Wharton School og University of Colorado i USA har vist at etterpåklokskap – dvs. det at man innbiller seg at en hendelse allerede har inntruffet – øker sannsynligheten med 30% for at man greier å identifisere de korrekte årsakene til de fremtidige utfallene.

Aktivitetsplan

I motsetning til en obduksjon (et medisinsk uttrykk for undersøkelser av hva som har forårsaket en pasients død, og som gagner alle unntatt pasienten selv) er en pre-obduksjon noe man gjør i starten av et prosjekt i stedet for i slutten, slik at prosjektet kan forbedres (noe som gagner også dette prosjektet, og altså ikke bare andre fremtidige prosjekter). En pre-obduksjon gjennomføres således under forutsetning av at «pasienten har dødd», og det stilles spørsmål om hva som gikk galt. Oppgaven til prosjektgruppens medlemmer er å komme frem til plausible årsaker til hvorfor prosjektet har mislyktes. I følge Gary Klein starter en typisk pre-obduksjon rett etter at prosjektgruppen er brifet om prosjektplanen. Lederen begynner øvelsen med å informere alle om at prosjektet har mislyktes totalt. Alle i rommet blir deretter bedt om å notere ned individuelt hver enkelt årsak de kan komme på som kan forklare hvorfor prosjektet mislyktes. Dernest spør lederen hver enkelt medlem i prosjektgruppen, og prosjektlederen først, om å lese opp en årsak fra deres liste. Hver enkelt prosjektmedlem nevner så ulike årsaker etter tur inntil alle årsakene er utførlig notert ned. Når øvelsen er over går prosjektlederen igjennom hele listen og ser konkret etter måter å forbedre prosjektplanen.

Gary Klein hevder at denne metodens rikelige anvendelse av etterpåklokskap gir fordeler som andre metoder for evaluering av en prosjektplan ikke gir. Ikke nok med at metoden bidrar til å identifisere potensielle utfordringer/problemer tidlig, den reduserer også risikoen for at konstruktiv kritikk blir ignorert av personer som har overinvestert i et prosjekt. Prosjektgruppens medlemmer vil også føle at deres kunnskaper og erfaringer blir verdsatt, i alle fall når de beskriver svakheter som ingen andre har nevnt. Denne øvelsen gjør også prosjektgruppen mer sensitiv til signaler underveis i prosjektet om trøbbel eller utfordringer som synes å være i anmarsj.

Tør du pre- obdusere prosjektet ditt?

Nils Magne Larsen
Skrevet av Nils Magne Larsen