For mange baller i luften er aldri bra

Dette er det andre innlegget i historien om Critical Chain prosjektledelse.

I foregående innlegg - critical-chain-startet-i-norge.html -  fortalte jeg om hvordan Statoil kontaktet Eli Goldratt for hjelp, og fikk han til å første gang tenke på prosjektledelse.   Dette ga Goldratt den første anelsen om hva som kunne føre til bedre prosjektledelse. Dette var i 1986,  og Goldratt jobbet ikke videre med prosjektledelse prinsipper før 5 år senere.

I 1991 blir Eli Goldratt kontaktet av det Israelske flyvåpenet - de er i krise.   Siden begynnelsen av 80 tallet,  hadde det Israelske flyvåpenet kjøpt over 200 F-16 fly,  som da var i kontinuerlig bruk for å verne Israels grenser.  Periodevis måtte de tas inn til overhaling.

Det var ingen enkel prosess, det betydde å ta hele flyet fra hverandre,  fikse alt som måttte fikses, erstatte deler som måtte erstattes, og så sette sammen flyet igjen.  Man visste ikke før man tok flyet ifra hverandre hvilke deler som måtte erstattes.  De lå på etterskudd, og brukte 14 måneder på hver overhaling.

Og det kom til å bli verre.  Saddam Hussein hadde sendt Scud raketter mot Israel,  og Israel var klar til å slå tilbake.  Amerikanske myndigheter var redd for en eskalering i midt østen og overbeviste Israel at de ikke skulle slå tilbake.  Belønningen for å forholde seg rolig og la USA håndtere dette,  var at de skulle få 50 brukte F-16 fra USA.

Men det betydde enda flere overhalinger  - disse flyene sto da å støvet ned på en base i Georgia, USA og ville trenge full overhaling før de kunne brukes.  Det Israelske flyvåpnet måtte gjøre noe med prosessene på de tekniske depotene og de håpet Goldratt kunne hjelpe til med dette.

Prosessen var rett frem:  Flyet ankommer depot,  man tar en forhåndsanalyse om det er en standard overhaling eller mer,  man åpner filene på flyet,  og man starter en prosjektplan som detaljerer alt som må gjøres.  Man utfører deretter alle reparasjoner og erstatter alle deler som må erstattes,  og etter at alt er ferdig,  gjør man en inspeksjon, tester og avslutter prosjektet.  Flyet skal nå være ferdig til å fly igjen.

Hvor oppstår problemet, og hva kan forbedres?  En analyse viste at det alltid (og nesten hele tiden) oppstår uforutsette problemstillinger.  Når disse er oppdaget blir de fordelt til en ingeniør som er spesialist, som da må lage en løsning eller reparasjon. Det er inget slingringsmonn i løsningen/reparasjonen - den må være eksakt,  ellers kan flyet dette ned!  Denne ingeniøren må så følge denne løsningen gjennom prosessen og sørge for at overhalingen eller reparasjonen utføres riktig.   Samtidig er ikke ressursene tilgjengelig til å ta tak i gjøremålene eller gjøre åpne gjøremål ferdig.   Ingeniørene må begynne på neste gjøremål uten å ferdigstille - og listen over åpne og uferdige gjøremål vokser.  Det blir flere og flere baller i luften.  De må skifte fra prosjekt til prosjekt, og hver gang de skal gå tilbake til et åpent gjøremål, må de sette seg inn i saken på nytt.   Dette kalles multitasking - å prøve å gjøre flere ting samtidig,  og man snakker her om "bad" multitasking, dvs dårlig multitasking.  Det går an å gjøre et par ting om gangen så lenge det ikke tar tid til å sette seg inn i saken på nytt - dette kalles "switching cost".   Men,  den såkalte "switching cost" som kommer fra å gå frem og tilbake mellom oppgaver er ikke det verste.  Det verste er at ingen av oppgavene eller prosjektene blir ferdige.

Som vist i bildet over (fra Critical Chain ltd) vil "switching costs" føre til en generell forlengelse,  men se hva som skjer med oppgave A.  På grunn av multitasking tar oppgave mer enn 3 ganger lengre å gjøre ferdig!  Og dette forplanter seg videre i prosessen, og hvis det er en kritisk oppgave så er hele prosjektet forsinket pga multitasking.

Dette var veldig tydelig i det Israelske flyvåpenet.  I hvert fly er det hundrevis av slike problemstillinger med på følgende oppgaver og gjøremål.  Hver ingeniør hadde over 50 åpne prosjekter,  hvert gjøremål tok i snitt 135 dager å gjøre ferdig.  Med hundrevis av disse problemene, og med multitasking mellom oppgavene,  forplantet det seg til at det tok 14 måneder å gjøre ferdig et fly.

Løsningen som Goldratt og ledelsen kom opp med var at hver ingeniør aldri fikk lov til å jobbe på mer en 3 oppgaver om gangen - de fikk ikke lov til å begynne på en fjerde selv om det betydde at de måtte stå vente.  Alle andre oppgaver er "fryst" og må stå på vent  - ikke ulikt Kanban-board prinsipper.  En minimalisering av multitasking og fokus på å få ferdig disse tre oppgavene var en dramatisk beslutning,  men det viste seg også å dramatiske resultater.

Ledetiden på disse spesialprosjektene etter denne implementeringen gikk fra 135 dager til 30 dager.   Men det var ikke alt.

Innvirkningen på ledetiden på overhalingen var ennå mer dramatisk. Ledetiden gikk fra 14 måneder til kun 7 uker!  Det er en forbedring på 800%

Hvordan er det mulig - hva skjedde?   Jo,  oppgaver som alle ventet på ble gjort ferdig.  Isteden for å vente på 50 åpne oppgaver,  ventet man nå på å gjøre ferdig 3 oppgaver.

Dette var Goldratts andre innspill til det som senere ble Critical Chain prosjektledelse.   Det første prinsippet som kom fra Statoil var å introdusere prosjektbuffer for å sørge for at oppgaver blir gjort,  og nå ble det andre prinsippet å redusere hvor mange baller hver enkelt prosjekt deltager har i luften. 

Men det var ikke nok til å designe en ny måte å jobbe i prosjekter på-  mer om det neste gang .........

Vil du vite mer om prosjektledelse? Ta kontakt!