Critical chain startet i norge!

Dette er ikke en artikkel som beskriver alt om Critical Chain – det vil jeg beskrive i senere artikler – dette er historien om hvordan lille Norge og vårt statlige selskap Statoil var begynnelsen og inspirasjonen til Critical Chain prosjektledelse.
​
Critical Chain prosjektledelse som vi nå kjenner det ble introdusert i 1997 og har senere gått sin seiersgang, og er nå utbredt med suksess over hele verden,  med halvering av prosjekttider og prosjekter levert i tide og på budsjett.

Med det få mennesker vet er at det hele startet allerede i 1986 med et norsk firma vi alle kjenner -  Statoil.  Statoil kontaktet Eli Goldratt i 1986 etter at flere av lederene hadde lest boken ”the Goal”  - og et team fra Statoil besøkte Goldratt for å legge frem problemstillingen.

Statoil forklarte at de var eksperter i prosjektledelse,  faktisk var de kanskje verdensledende på gjennomføring av prosjekter.  Det var ikke skryt – Statoil var ansett som kanskje det beste selskapet i oljeindustrien på prosjekter.  Men uansett hvor godt de planla prosjekter,  ble det alltid overskridelser.  De fortalte Goldratt at uansett hvor lenge de estimerte et prosjekt vil vare,  så har standard praksis blitt at man tar estimater,  ganger med 4,  og håper at det går bra!  Men selv med å ta ”4 gangeren” på estimatene,  så er de fleste prosjekter forsinket,  og med kostnadsoverskridelser.  De fortalte Goldratt at de hadde lest ”the Goal” og de forsto at denne boken handlet om produksjon,  men de var overbevist om at hvis det var en man som kunne finne ut av dette, så var det Eli Goldratt.

Goldratt fortalte teamet at han var ekspert på produksjon, ikke prosjektledelse.  Men hvis de kunne kjapt forklare alt de visste om prosjektledelse i Statoil,  så skulle han tenke på det.  Teamet fra Statoil la frem to smale hefter de hadde med seg.  Goldratt var imponert  - hvis man kan forklare et komplisert tema som prosjektledelse i to smale hefter,  da har man fortstått det viktigste  - han tok oppdraget.

Statoil ønsket å få bedre ROI gjennom bedre prosjektledelse.  Statoils hefter forklarte at nøkkelen til god prosjektledelse var ledetid,  og at ledetid var bestemt av den kritiske stien  - Critical Path.  I et typisk Statoil prosjekt var det ca. 40,000 oppgaver,  men ”Critical Path” besto av kun 40 oppgaver.

Goldratt hadde hørt om Critical Path,  men ikke studert dette før.  Critical Path var utviklet på slutten av 50 tallet i USA av Univac og DuPont, som et ledd i bedre utnytte og selge inn datamaskiner.  Det kom mer og mer i bruk på slutten av 70 tallet, da det ble billigere å kjøpe mindre datamaskiner for å  kalkulere Critical Path.   Statoil hadde tatt dette konseptet i bruk i deres prosjektledelses system.    

Goldratt fikk en åpenbaring  - han hadde jobbet med organisasjoner i 6 år for å få de til å forstå hvor viktig fokus var, uansett hvilken prosess man jobbet med.   Nå hadde han kommet over et firma i et annet forretnings område,  på en mye større skala enn en enkel produksjonsbedrift,  som beviste hans konsepter om forenkling og fokus.

I produksjon,  som i boken ”the Goal”,  var nøkkelen å fokusere på flaskehalsen  - i en typisk produksjonsbedrift ville man finne at selv med over 100 ressurser,  var det kun en maskin eller ressurs var flaskehalsen / begrensingen i produksjonen  -  det betydde at ledelsen i en produksjonsbedrift kunne fokusere på kun  1% for å få forbedring.

Det samme prinsippet er i prosjektledelse.  Av 40,000 oppgaver,  var det kun 40 oppgaver som var de kritiske –man kunne også her fokusere på 1% for å få forbedring.

Goldratt fant at han hadde tenkt for smalt.  Fra Statoil hadde han fått innsikt i et nytt område , men med samme grunnprinsipp  - man kunne fokusere på begrensingen.   Dette var egentlig tidspunktet hvor navnet Theory of Constraints,  samt Constraint Management,  ble tatt i bruk.  Før dette,  også i første utgave av ”the Goal”,  hadde Goldratt kun omtalt ”bottlenecks” – flaskehalser.   Nå innså han at man måtte se videre på andre begrensinger.

I produksjon er begrensingen basert på kapasitet  - dvs en flaskehals i produksjonen.   I prosjektledelse er begrensingen basert på tid,  som da er Critical Path.

To uker senere hadde Goldratt skrevet om boken sin,  nå med navnet Theory of Constraints isteden for OPT  (Optimized Production Technology)  som det tidligere het.   Han introduserte i denne utgivelsen også femstegs prosessen for å finne begrensinger.

Goldratt tar så på seg oppdraget med å hjelpe Statoil,  men finner ut at han må komme med noe nytt  - han kan ikke fortelle Statoil at å fokusere på Critical path er nøkkelen, det gjør de allerede.  Han har booket en reise 
  
På reisen til Oslo tenker han for seg selv:  ”Critical Path gir organisasjoner en flott mulighet til å fokusere.  Men likevel er Statoils prosjekter forsinket,  selv etter at de har tatt 4 gangern for å sikre at det ikke er forsinket!    Og Statoil er en av de beste i verden på prosjektledelse.  Deres estimater er basert på lang erfaring og fra dyktige ingeniører  - hvordan er det mulig at gode estimater, og  med stor ekstra sikkerhet lagt inn,  ikke er nok?  Hvis en ingeniør estimerer at det tar 1 dag,  så legger Statoil på 3 ekstra dager slik at det lagt inn 4 dager i prosjektplanen  - hvordan er det mulig å bli forsinket med så mye sikkerhet og samtidig riktig fokus på Critical Path?”

Goldratt resonnerer at det må være en fundamental antagelse som er feil.  Ifølge Critical Path prosjektledelse så er lengden på et prosjekt summen av oppgavene på Critical Path.  I et prosjekt så vil lengden på oppgaver variere fra prosjekt til prosjekt  – og estimatene vil noen ganger være enten for lange eller for korte,  noen ganger vil det ta mye lengre en antatt.  Hvis en oppgave som er endel av Critical Path tar lengre enn antatt,  vil hele prosjektet ta lengre tid enn antatt.  Hvis det tar kortere tid en antatt,  så burde hele prosjektet ta mindre tid.  Med dette skjer ikke -  ingen prosjekter tar mindre tid – hvorfor ikke?

Innen Goldratt kom til møtet i Oslo, hadde han svaret – det lå i å aggregere eller slå sammen usikkerheten i et prosjekt.  Basert på hans bakgrunn i fysikk og hans erfaring med  hvordan mennesker generelt agerer fra å implementere OPT,  kunne han legge frem løsningen.

Et prinsipp som han tidligere hadde funnet,  var at mennesker agerer i henhold til hvordan de måles.  I prosjekter blir man målt på å få ferdig oppgaven i tide,  ikke om du får den ferdig tidligere.

Estimatet som hadde gått fra 1 dag til 4 dager,  hadde nå blitt en forpliktelse på 4 dager  - det vil si at man styrte mot når oppgaven skulle bli ferdig  - ikke hvor fort du får den ferdig.
 
Hva skjer i et prosjekt når du har fire dager på deg å gjøre ferdig en oppgave og du mener du kan klare det på en dag?  Du gjør andre ting imens fordi du har god tid  (dette kalles Student Syndrome),  du tar deg kansje god tid  ( det som kalles Parkinson’s law),  og vipps så er denne sikkerheten borte.  Hvis noe går galt i siste øyeblikk,  så blir plutselig ikke oppgaven ferdig i tide.  Hvis dette er en oppgave på Critical Path,  så er hele prosjektet forsinket. 

For Statoil betydde dette at man ikke fikk med seg besparelser,  men alle forsinkelser forplantet seg og resulterte i forsinkede prosjekter.

Løsningen Goldratt kom opp med var å aggregere all sikkerheten i  et buffer på slutten av prosjektet – det vil si at ingeniøren nå kun fikk den ene dagen å gjøre ferdig,  men de 3 dagene med sikkerhet ble flyttet til slutten av prosjektet i et felles buffer.

Desverre så tar ikke Statoil dette til seg,  de fortsetter som før.  Om denne lærdommen kunne reddet kostnadsoverskridelsene på Åsgård feltet er uvisst,  men uansett oppdager Goldratt et viktig prinsipp.

​Dette prinsippet er en av grunnstenene i det som senere ble Critical Chain prosjektledelse  (ikke Critical Path,  men Critical Chain),  men ikke hele løsningen.   Den neste brikken og grunnstenen i utviklingen av Critical Chain prosjektledelse kom 5 år senere,  men det er emnet i senere artikkel .......

Jeg vil vite mer om critical chain