Introduksjon til Critical Chain prosjektledelse

Dette er det tredje innlegget om Critical Chain,  men er første artikkel i en serie om hva det er,  hvorfor man bør bruke det,  og hvordan implementere.

​Før vi begynner gjennomgangen av hva Critical Chain er og hvordan man implementerer Critical Chain, må vi definere hva et prosjekt er og hvorfor prosjektledelse oppfattes som vanskelig.

Hva er egentlig et prosjekt? 

Man kan definere et prosjekt som en serie med relaterte oppgaver og gjøremål som til sammen leder til et ønsket resultat.  Prosjekter er per definisjon et unikt engangs foretak.  Aktivitetene er uvissse ,  ukjente konsekvenser  -  man deler ressurser med andre prosjekter. 

Prosjekter er en viktig del av organisasjoner, bedrifter og det offentlige.  Ifølge Deutche Bank Research vil 25% av verdens BNP være som et resultat av prosjekter.

Prosjekter er ikke enkelt.  I prosjekter må man balansere budsjetter,  kvalitet og planer med variasjon, med  naturlig variasjon, menneskelige faktorer og gode gamle «murphy’s law»  - alt som kan gå galt, vil gå galt.

Det resulterer i mange negative resultater-  forsinkede prosjekter,  mange endringer, over budsjett,  manglende ressurser, og arbeide som må gjøres om igjen.  Vi har alle hørt om katastrofe prosjekter i det offentlige,  og det er ikke unikt. Ifølge CHAOS rapport ( fra Standish Group) går 74% av prosjekter over tiden, 60% over budsjett,  og 31% av leverte prosjekter mangler elementer som skulle vært tilstede.

Hva betyr dette?

For kundene betyr det at de for leveransen eller produktet for sent,  som kan bety at de må utsette andre prosjekter,  produktlanseringer,  eller forbedringer  - og dette betyr at kunden taper økonomisk på forsinkede prosjekter.
For firmaet som har prosjektet, betyr det kanskje at man må betale bøter eller gi rabatt for forsinkede prosjekter,  det kan bety at kunden slutter å kjøpe, forsinkede betalinger og problemer med kontantstrøm,  og dårligere bunnlinje.

Hvorfor er så mange prosjekter forsinkede og over budsjett?

Det er mange ting,  det kan være enkelt oppgaver som er forsinket og forsinker hele prosjektet,  det kan være for mange endringer i planene ,  det kan være at ressurser ikke er tilgjengelig til avtalt tid,  man kan mangle forskjellige underlag som design, godkjenninger, eller «specs»,  eller man kan mangle materialer.
Det kan også være uklare prioriteringer,  som f.eks. ressursallokering og budsjetter.  Det kan også være at man må omgjøre ferdige oppgaver,  og mange flere ting.

Med andre ord  - det mange, mange grunner til at prosjekter kan bli forsinkede, over budsjett eller ikke levere ihht hva som var avtalt.

Hvorfor klarer vi ikke bedre?

Som kom frem av min tidligere blogginnlegg om prosjektledelse hos Statoil,  sliter selv de mest erfarne og fremste eksperter med å få til prosjekter.  Er det slik at man ikke klarer det her med prosjekter,  eller er det kanskje selve prosjekt metodikken som er problemet?

Som henvist til i tidligere artikler,  fant Eli Goldratt akkurat ut dette  - metodikken som ble brukt i de fleste firmaer førte faktiske til flere forsinkede prosjekter,  ikke færre.

Fra Statoil prosjektet var lærdommen at man kan ikke planlegge som om det ukjente er sikkert,  men kan redusere risiko ved å aggregere usikkerheten i et felles buffer.

Fra prosjektet med det Israelske flyvåpnet lærte Goldratt at man må stoppe «bad» multitasking, dvs å stoppe en aktivitet for å starte en annen, og da gå tilbake og begynne den første oppgaven – og da ha flere oppgaver som man prøver å gjøre samtidig.  Ikke bare taper du tid hver gang du må avslutte en oppgave og begynne en ny (switching cost),  men du taper tid på å sette deg inn i oppgaven når du tar tak i den på nytt.  Og denne start og stopp prosessen forplanter seg på samme måte som bilkøen inn til Oslo mandag morgen.

Etter å ha analysert flere organisasjoner,  fant han at det var flere prinsipper om menneskelig natur som standard prosjektledelse ikke tok hensyn til.

I tillegg til å prøve å planlegge det ukjente og prøve å gjøre flere ting samtidig,  fant Goldratt den underliggende begrensingen.  Man tar ikke hensyn til den menneskelige natur og realiteter.

Hva er disse menneskelige faktorene?   Det er faktorer og fenomener som vi alle kjenner til når vi hører om de.  De er :

• Parkinsons law – tid ekspanderer i forhold til tiden man er gitt.
• Student syndrome – mennesker har en tendens til å utsette oppgaver
• Murphy’s law – alt som kan gå galt, vil gå galt m.m.
• Hofstadter’s law – det tar alltid lengre enn planlagt ,  selv når du har tatt med Hofstadter’s law  - dette er da i referanse til komplekse oppgaver
• Planning fallacy – man undervurderer hvor lang tid et prosjekt kan ta
• m.fl.

Nå kan det høres ut som om noen av disse prinsippene er i opposisjon,  men jeg vil gå nærmere inn på hvordan hver enkelt av disse på virker prosjekter.  Men ikke i dag.  
​
Jeg vil over de neste blogg innleggene gå igjennom disse og hvordan de påvirker prosjekter,  og hvordan Critical Chain metodikken håndterer disse og andre prinsipper.