A hagyományos projektmenedzsment-módszereknél az elvesztegetett idő és erőforrások 30%-át jellemzően olyan pazarló technikák emésztik fel, mint a rossz multitasking (különösen a feladatváltás), a diák-szindróma, a Parkinson-törvény, a dobozon belüli késések és a priorizálás hiánya.
A projekttervben a kritikus lánc mind az elsőbbségtől, mind az erőforrásoktól függő feladatok azon sorozata, amely véges erőforrások mellett nem teszi lehetővé a projekt rövidebb idő alatt történő befejezését. Ha az erőforrások mindig korlátlan mennyiségben állnak rendelkezésre, akkor a projekt kritikus lánca megegyezik a kritikus út módszerével.
A kritikus lánc a kritikus útelemzés alternatívája. A kritikus láncot a kritikus úttól megkülönböztető fő jellemzők a következők:
- A (gyakran implicit) erőforrásfüggőségek használata. Az implicit azt jelenti, hogy nem szerepelnek a projekthálózatban, hanem az erőforrásigényeket vizsgálva kell azonosítani őket.
- Az optimális megoldás keresésének hiánya – egy “elég jó” megoldás is elegendő, mert:
- Amennyire ismert, nincs analitikus módszer az abszolút optimum megtalálására (ill, amely az összességében legrövidebb kritikus lánccal rendelkezik).
- A becslésekben rejlő bizonytalanság sokkal nagyobb, mint az optimum és az optimumközeli (“elég jó” megoldások) közötti különbség.
- A pufferek azonosítása és beillesztése:
- Projektpuffer
- Táplálékpufferek
- Resszuspufferek (a vállalatok általában vonakodnak több erőforrást adni)
- A projekt előrehaladásának és állapotának nyomon követése a pufferek fogyasztási arányának, nem pedig az egyes feladatok ütemterv szerinti teljesítményének nyomon követésével.
AzCCPM-tervezés a projektben a feladatokhoz hozzáadott nagy mennyiségű biztonsági időt a pufferekbe aggregálja – az esedékességi teljesítmény védelmére és annak elkerülésére, hogy ez a biztonsági idő a rossz multitasking, a diák-szindróma, a Parkinson-törvény és a rosszul szinkronizált integráció miatt kárba vesszen.
A kritikus láncú projektmenedzsment a projekt teljesítményének értékelésére a megkeresett érték kezelése helyett a puffermenedzsmentet használja. Egyes projektmenedzserek úgy érzik, hogy a megkeresett érték menedzsment technikája félrevezető, mert nem különbözteti meg a projektszabályozáson (azaz a kritikus láncon) elért előrehaladást a nem-szabályozáson (azaz más utakon) elért előrehaladástól. Az eseménylánc-módszer meghatározhatja a projekt-, a táp- és az erőforráspufferek méretét.
PlanningEdit
A projektterv vagy a munkabontási struktúra (WBS) létrehozása nagyjából ugyanúgy történik, mint a kritikus útvonal esetében. A tervet a befejezési dátumtól visszafelé haladva dolgozzák ki, és minden feladat a lehető legvégén kezdődik.
Minden feladathoz hozzárendelnek egy időtartamot. Egyes szoftveres megvalósítások egy második időtartamot is hozzáadnak: egy “legjobb becslésű” vagy 50%-os valószínűségű időtartamot, és egy második “biztonságos” időtartamot, amelynek nagyobb valószínűséggel kell teljesülnie (talán 90% vagy 95%, attól függően, hogy a szervezet mekkora kockázatot tud vállalni). Más szoftvermegvalósítások végigmennek minden feladat időtartam-becslésén, és eltávolítanak egy fix százalékot, amelyet a pufferekbe kell összesíteni.
Az erőforrásokat minden feladathoz hozzárendelik, és a tervet az agresszív időtartamok felhasználásával erőforrás-szintűvé teszik. Ezután az erőforrás-szintű feladatok leghosszabb, a projekt elejétől a végéig vezető sorozatát kritikus láncként azonosítjuk. Az 50%-os becslések használatát az indokolja, hogy a feladatok fele korábban, fele pedig később fejeződik be, így a projekt során az eltérésnek nullának kell lennie.
A CCPM felismerve, hogy a feladatok a Parkinson-törvény, a Student-szindróma vagy más okok miatt nagyobb valószínűséggel vesznek igénybe több időt, mint kevesebbet, “puffereket” használ a projekt ütemezésének és pénzügyi teljesítményének ellenőrzésére. A kritikus lánc egyes feladatainak “extra” időtartama – a “biztonságos” időtartamok és az 50%-os időtartamok közötti különbség – a projekt végén egy pufferben gyűlik össze. Ugyanígy a pufferek a kritikus láncba táplálkozó feladatsorok végén is összegyűjtésre kerülnek. A projektpuffer végén lévő dátumot a külső érdekeltek a teljesítési dátumként kapják meg. Végül létrehoznak egy alapvonalat, amely lehetővé teszi a projekt pénzügyi nyomon követését.
Az időtartam becslésének alternatív módszere az időtartam valószínűségi alapú számszerűsítését alkalmazza Monte Carlo-szimuláció segítségével. 1999-ben egy kutató szimulációt alkalmazott a projekt munkamegosztási struktúra egyes elemeihez kapcsolódó kockázatoknak a projekt időtartamára, költségére és teljesítményére gyakorolt hatásának értékelésére. A Monte Carlo-szimuláció segítségével a projektmenedzser különböző valószínűségeket alkalmazhat a különböző kockázati tényezőkre, amelyek hatással vannak egy projektkomponensre. A bekövetkezési valószínűség 0% és 100% közötti valószínűséggel változhat. A kockázat hatása a bekövetkezési valószínűséggel együtt kerül be a szimulációs modellbe. A Monte Carlo-szimuláció iterációinak száma a hibatűrési szinttől függ, és egy sűrűséggrafikát ad, amely szemlélteti a projekt kimenetelére gyakorolt kockázati hatás általános valószínűségét.
ExecutionEdit
Amikor a terv elkészült és a projekt készen áll az indításra, a projekthálózat rögzítve van, és a pufferek mérete “zárolva” van (azaz, tervezett időtartamuk nem módosítható a projekt során), mivel ezeket a projekt ütemezésének és pénzügyi teljesítményének nyomon követésére használják.
Mivel az egyes feladatok időtartamában nincs lazaság, az erőforrásokat arra ösztönzik, hogy az adott feladatra összpontosítsanak, hogy azt befejezzék, és átadják a következő személynek vagy csoportnak. A cél itt a rossz multitasking kiküszöbölése. Ezt úgy érjük el, hogy minden erőforrás számára prioritási információt biztosítunk. A szakirodalom a váltófutással vonja párhuzamba. A projekt minden egyes elemét arra ösztönzik, hogy a lehető leggyorsabban haladjon: amikor a projekt “szakaszát” futják, arra kell összpontosítaniuk, hogy a kijelölt feladatot a lehető leggyorsabban elvégezzék, a figyelemelterelés és a multitasking minimalizálása mellett. Egyes esettanulmányokban a jelentések szerint valódi botokat akasztanak az emberek íróasztala mellé, amikor kritikus láncfeladatokon dolgoznak, hogy mások tudják, ne szakítsák félbe őket. A cél itt az, hogy leküzdjék azt a tendenciát, hogy késleltessék a munkát, vagy pluszmunkát végezzenek, amikor úgy tűnik, hogy van rá idő. A CCPM szakirodalom szembeállítja ezt a “hagyományos” projektmenedzsmenttel, amely a feladatok kezdési és befejezési időpontjait figyeli. A CCPM arra ösztönzi az embereket, hogy a lehető leggyorsabban haladjanak, függetlenül a dátumoktól.
Mivel a feladatok időtartamát 50%-os valószínűségű időtartamra tervezték, az erőforrásokra nyomás nehezedik, hogy a kritikus láncú feladatokat a lehető leggyorsabban elvégezzék, legyőzve a diákszindrómát és a Parkinson-törvényt.
MonitoringEdit
A hívei szerint a monitoring bizonyos szempontból a kritikus láncú módszer legnagyobb előnye. Mivel az egyes feladatok időtartama eltér az 50%-os becsléstől, nincs értelme arra kényszeríteni minden feladatot, hogy “időben” befejeződjön; a becslések soha nem lehetnek tökéletesek. Ehelyett a tervezési szakaszban létrehozott puffereket figyeljük. Lázdiagramot vagy hasonló grafikont lehet készíteni és közzétenni, amely a pufferek felhasználását mutatja a projekt befejezésének függvényében. Ha a pufferfogyasztás mértéke alacsony, a projekt a kitűzött célon belül van. Ha a fogyasztás mértéke olyan mértékű, hogy a projekt végére valószínűleg kevés vagy egyáltalán nem lesz puffer, akkor korrekciós intézkedéseket vagy helyreállítási terveket kell kidolgozni a veszteség helyreállítására. Ha a pufferfogyasztás mértéke meghalad valamilyen kritikus értéket (nagyjából: az az arány, amikor várhatóan az összes puffer elfogy a projekt vége előtt, ami késedelmes befejezést eredményez), akkor ezeket az alternatív terveket kell végrehajtani.