Lärde mig igår att peacocking är när man förklarar något med beskrivande adjektiv, istället för med fakta. Vilket egentligen var det jag gjorde med boken Critical Chain. Så jag tänkte istället försöka berätta lite om vad boken egentligen tog upp.
Det börjar med en genomgång av projekt. Projekt består av många mindre arbetsmoment ihoplänkade till ett mål, projektmålet. Dessa arbetsmoment kan variera mycket. De kan ta lång tid eller kort tid. Kräva att andra arbetsmoment är utförda först, eller vara oberoende tidigare steg. De kan utföras av andra grupper/enheter/personer eller av samma hela tiden.
Då var det avklarat. Det intressanta börjar när man tittar på tid, och faktorer som påverkar tider. För projekt brukar dra över på tiden, detta har nog alla upplevt.
Det finns enligt boken 3 säkerhetsfunktioner som ska se till att tiden räcker.
1) När man uppskatar varje arbetsmoment gör man det med god tidsmarginal. Man räknar i boken med att uppskattningar görs så att chansen att klara av arbetsmomentet i den angivna tiden är 90%.
2) När många arbetsmoment räknas ihop av projektledningen lägger dessa ofta till ännu en tidsmarginal. För att de har lärt sig att allt tar mer tid.
3) Ledningen, som ska godkänna tidsplanen, kräver ofta att den ska förkortas, för att det tar för lång tid. En sådanförkortning drabbar ofta varje steg, och är jämt fördelat på hela projektet. Därför har varje steg lärt sig att man alltid ökar sin tidsplan med ca 20% extra säkerhetstid, så att dessa kan tas bort när tid ska strykas.
Detta är väldigt intressanta observationer. Speciellt intressant är 1). Hur mycket extratid uppskattar varje arbetsmoment att de behöver? Boken argumenterar att i ett vanligt fall, skulle arbetstidsuppskattningen se ut så här.
90% säkerhet känns helt ok, kanske är den så låg som 80% ibland. I ovanstående exempel skulle 90% säkerhet gå en tid på strax under två gånger tiden med 50% säkerhet.
Men tyvärr kan man inte använda vanliga gaussiska fördelningar på arbetsmoment. Dessa ser enligt honom snarare ut så här.
Anledningen är att arbetsmoment inte kan gå ner mot 0 i tid. Och samtidigt är risken inte försumbar att ett oförutsedd problem dyker upp, och då skjuter tiden lätt iväg. Om man jämför tidsskilnaden mellan 50% och 90% här, är tiden mer än dubbel så stort, snare 3 gånger så stort. Man kan argumentera här exakt hur mycket det är och den är garanterat olika för varje unik arbetsmoment. Men den viktiga observationen är att man har väldig hög säkerhetsmarginal, jämfört med vad medelvärdet på projekttiden är.
Slutsatsen är att ett projekt innehåller i grund och botten väldigt mycket säkerhetstid. Även en låg uppskattning skulle säga att projekttiden är minst till hälften säkerhetstid. Detta borde betyda att många projekt borde bli klara långt innan sin deadline. Men sker detta i verkligheten?
Det gör det så klart inte.
Anledningen är att det också finns 3 funktioner som äter upp den här säkerhetstiden.
1) The students syndrome – att man inte börjar med något förrän i sista stund, även om man har god tid på sig
2) Multitasking, som gör att varje enskild arbetsmoment blir klar senare än om man suttit med det enskilt.
3) Arbetsled, att vissa steg inte kan börja innan ett tidigare är klart. Är det tidigare steget försenad börjar nästa steg försenad.
Detta är intressanta observationer, som han sedan använder för att visa det som The Goal sade för produktion: säkerhetstider på moment som inte är flaskhalsen är onödig, till och med destruktiva. I ett projekt är flaskhalsen nästan alltid “the critical path”, dvs det led av arbetsmoment som tar längst tid att klara av. Alla andra tar ju mindre tid, och är därför inte avgörande för när hela projektet är klart.
Boken går sedan in på praktiskt tillämpning. Hur ska man sätta uppskattningen av arbetstid för olika moment, och var ska man sätta in buffertzoner för att minska risken för förseningar.
Den går också in på hur man belönar projekt på fel sätt. Mycket av detta man ser kommer ifrån att man inte uppmuntrar att man blir klar tidigare än planerat. Det existerar i många fall inte alls.
Där kommer bl.a. det där med 50% chans att hinna klart in. En 50% chans att hinna klart inom en given tid är en acceptabel uppgift, enligt Goldratt. Detta förutsatt att de som jobbar med uppgiften inte blir bestrafade för att bli klara för tidigt.
Han menar att man istället ska mäta efter tid kvar tills man är klar. Och varje dag göra en ny uppskattning (eller vecka, beroende på totala tiden). Denna uppskattning flukturerar starkt, men är mycket mer användbar. Dock bara på de moment som ingår i flaskhalsledet. De andra spelar ingen roll, så länge inte dessa blir till flaskhalsar. Goldratt förklarar det lite bättre förklarad bara, än vad jag lyckas på mina 10 rader.
Som jag sade i mitt förra inlägg, mycket intressant och ögonöppnande. Självklarheter, så klart. Men genomtänkta lösningar.
När man nu kommer till kritan dock, om denna nyvunna inblick hjälper mig i mitt projekt, måste jag säga att jag inte vet. I dagsläget har jag inte ens ett flödesschema på projektet, och har ingen aning om vad som är mitt flaskhalsled. Ska jag lägga tid på att ta fram detta? Kommer jag se resultat av en sådan sak? Mitt projekt är ju väldigt blandat, med många okändheter och många externa arbetsmoment. Kan jag uppskatta tiderna? 50% sannolikhet…?