Kritische Kette versus Kritischer Pfad
Dargestellt mit MS Project
Warum die Kritische Kette (CCPM) im modernen Projektmanagement fehlt – und warum sie in der Praxis trotzdem Gold wert ist
Wer vor einigen Jahren den PMBOK Guide (bis zur 5. Auflage) aufschlug, fand sie noch detailliert erklärt: die Critical Chain Method (CCPM) nach Eliyahu M. Goldratt. Sie galt als mächtiger Hebel, um Terminpläne robuster zu machen, Ressourcenkonflikte zu lösen und das berüchtigte Parkinsonsche Gesetz auszutricksen. Doch mit der Version 6 begann der Wandel, und spätestens mit den neuesten Ausgaben und der aktuellen PMP-Ausrichtung ist die Kritische Kette aus dem offiziellen Standard praktisch verschwunden.
Für viele erfahrene Projektmanager ist das ein echtes Verlustgeschäft. Denn während globale Zertifizierungen heute stark auf universelle Prinzipien, Agilität und High-Level-Flow setzen, schwören viele Praktiker – gerade beim Einsatz von Tools wie MS Project – weiterhin auf die unschlagbare Logik von CCPM: Weg von aufgeblähten Einzelpuffern, hin zu zentralem Puffer-Management und echtem Ressourcen-Nivellement.
Warum hat sich der PMI-Standard so stark von der Kritischen Kette entfernt? Und warum lohnt es sich gerade jetzt, diesen vermeintlichen „Exoten“ wieder aus der Werkzeugkiste zu holen? Ein Blick zurück – und nach vorn.
Im Gegensatz zum klassischen „Kritischen Pfad“ bezieht die „Kritische Kette“ die tatsächlichen Ressourcen-Verfügbarkeiten und -Vakanzen zwingend mit ein. So berücksichtigt die Kritische Kette im Projektalltag das menschliche Verhalten, wenn Aufgaben durch das Aufschieben bis kurz vor knapp (das sogenannte Studentensyndrom), das Parkinsonsche Gesetz (wonach sich Arbeit in genau dem Maß ausdehnt, wie Zeit für ihre Erledigung zur Verfügung steht) sowie schädliches Multitasking durch paralleles Arbeiten an mehreren Fronten beeinflusst werden. Es „menschelt“ also im Projektmanagement gewaltig, und genau diesen Faktor ignoriert die klassische Netzplan-Theorie.
Eliyahu M. Goldratt argumentiert aus seinen Erfahrungen im Projektmanagement, dass eine Ressource einen im Arbeitspaket enthaltenen Zeitpuffer fast nie freiwillig „zurückerstattet“. Dies geschieht entweder aus Bequemlichkeit aufgrund eigener Präferenzen oder antizipierend, um künftige Terminzusagen nicht zu unterlaufen. Goldratt geht aufgrund empirischer Untersuchungen davon aus, dass in herkömmlichen Schätzungen etwa 50 % aller Aufwände in den Arbeitspaketen als versteckte „Sicherheits-Puffer“ eingebaut sind.
Unter diesem Aspekt – angesichts massiver, verdeckter Pufferzeiten in fast jedem einzelnen Arbeitspaket – müssten strenggenommen alle Projekte pünktlich fertig werden. In der Realität ist dies jedoch fast nie der Fall; im Gegenteil bleiben Projekte chronisch hinter dem Zeitplan zurück. Der Grund dafür liegt in der Vernichtung dieser Puffer durch die genannten menschlichen Verhaltensweisen sowie in der Ressourcenüberlastung durch Multitasking, bei dem Rüstzeiten und Unterbrechungen die effektive Arbeitszeit auffressen.
Warum dies in der Praxis so ist und warum klassische Tools hier an ihre Grenzen stoßen, soll nachfolgend anhand von MS-Project-Gantt-Diagrammen veranschaulicht werden. Während MS Project standardmäßig auf den kritischen Pfad und Ressourcenausgleich über Terminverschiebung setzt, zeigt die Analyse, wie durch das Eliminieren lokaler Puffer, das Zusammenlegen zu einem zentralen Projektpuffer und das konsequente Vermeiden von Multitasking auch mit MS Project die Methodik der Kritischen Kette erfolgreich umgesetzt werden kann.
„„Was ich heute kann besorgen, verschieb ich gern auf morgen“
„Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.“
Eine Ressource ist in mehr als einem Projekt verbucht.
"Undercover Puffer"
Im Normalfall sollten Puffer wie im folgenden Bild 1 angezeigt werden. Aber auch wenn Puffer angezeigt werden, bedeutet das nicht, dass die Ressource sich nicht noch einen „Undercover Puffer“ genehmigt. Die schwarzen Striche und Tagesangaben entsprechen dem expliziten Puffer, in dem Fall jeweils „Freie Puffer“. (Gesamter Puffer kann sich über die Summe der Freien Puffer der Nachfolger übergeben. Wenn die undercover Puffer nicht sichtbar dargestellt werden, ist der Anteil des freien Puffers in den Vorgängen/Arbeitspaketen ungleich höher. Das ist meistens der Fall. Ich kenne aus meiner 20 jährigen Praxis mit MS-Project max. 5% Fälle, in denen der Puffer explizit visualisiert wurde.
Warum werden Projekte nicht pünktlich fertig?
Diese „Praxisorientierte“ Vorgehensweise sehen Sie im folgenden Beispiel (Bild 2). Die Abstände zwischen den Vorgängen A, B und C sind Puffer, wären aber Abstände vergleichbar mit einer „Abschleppstange“ zwischen zwei Kfz, wenn dort keine Puffer explizit sichtbar wären (Bild 2). Falls dies der Fall ist, würde jede Verlängerung von A oder B eine Verschiebung von C nach sich ziehen. Das gilt natürlich auch für Vorgang D, da zwischen D und C keine Arbeitstage liegen, sondern ein Wochenende. Falls es sich bei A + B in Richtung C um fixe Abstände handelt (Abschleppstange), kann man bei allen Vorgängern implizieren, dass die Puffer in den Vorgängen enthalten sind oder auch nicht, falls es sich um Standardarbeiten handelt, die beispielsweise eine KI erledigt. Diese Dauern kommen in der Regel auf Nachfrage des Projektleiters an die Ressource zu Stande. Da die Ressource ihre Schätzung einhalten möchte und sie mit Risiken rechnet, baut sie einen impliziten Puffer ein. So agieren fast alle Ressourcen. Allerdings treten bei den meisten Ressourcen die Risiken nicht ein! Der „Freie Puffer“ wird nicht benötigt. Sie geben aber den „Freien Puffer“, der nicht benötigt wurde, nicht zurück. Warum?
- Sie denken an das nächste Projekt. Der Projektleiter wird sie auf die IST Werte aus dem aktuellen Projekt festnageln.
- Die Ressource hat persönliche Präferenzen in anderen Projekten.
- Trifft auf die Ressourcen der Vorgänge A + B zu: Aus Sicht der Ressource von Vorgang C, kann sowieso nicht weitergearbeitet werden, weil Vorgang D erst fertiggestellt sein muss. C wird durch 3 Vorgänger gesteuert, die eine Konvergenz (mehrere Vorgänge fokussieren auf einen Vorgang) bilden. C ist also einer Konvergenz unterlegen. (Vorgänge, die Konvergenzen anstatt Divergenzen unterliegen, sollten einer gesonderten Risikobetrachtung unterliegen. Eventuell könnte der Vorgang D im Bild 2 durch Crashing (Verkürzung des Vorgangs durch verschiedene Maßnahmen) beschleunigt werden.)
Die einzige Plausible Lösung für dieses Problem aus der Sicht von Goldratt ist die Halbierung der Vorgangsdauern oder Aufwände a posteriori. Goldratt beruft sich auf die Aussagen von Projektleitern aus der Praxis, dass 50% der Arbeitspakete in der Regel Freie Puffer sind. Die Hälfte der Dauern oder Aufwände verwendet Goldratt als „Puffer- Pool“, der weiter unten erklärt wird. Von daher würden die Freien Puffer (Bild 4) in MS Project nicht angezeigt, da der finale Puffer die Summer aller Freien Puffer dartsellt.
Die Ansicht der vier Vorgänge unterhalb der Tabelle ist eine spezielle Ansicht in MS-Project, um Vorgänger oder Nachfolger eines Vorgangs zentral visualisiert zu bekommen. Das wird dann interessant, wenn Vorgänge über längere Strecken miteinander verknüpft sind, beispielsweise für Vorgang 5 …. 123ea + 7t; 70ea; 85aa+3t. In dem Fall bekäme man analog zum Bild alle drei Vorgänger zentral angezeigt.
Im Bild 4 sehe Sie jetzt ein kleines Projekt, dass drei „Wege“ involviert. Rot, Grün und Hellblau. Für ein reales Projekt ist diese Formatierung nicht notwendig. Es dient hier nur zur Veranschaulichung. Der rote Weg „der kritische Pfad (CPM)“ oder in diesem Fall „kritische Kette (CCPM)“, wird in einer zu wählenden Ansicht durch MS-Project automatisch angezeigt (Es existieren Standardansichten und Ansichten, die User generiert werden können, mit unterschiedlichsten Informationskategorien).
Bei der Methode CPM würde der Vorgang I nicht auf dem kritischen Pfad liegen.
Bei CPM werden nur sachlich abhängige Vorgänge verknüpft. Bei „Kritischer Kette“ bezieht man zusätzlich die Ressourcen mit ein, die „Engpässe“ darstellen können. Die Fokussierung von „Engpässen“ bildet eine Kernkompetenz bei CCPM. Ressourcen z.B., die in mehreren Projekten arbeiten oder Ressourcen, die vielen Vorgängen zugeordnet sind. Aber auch ein unsicherer Lieferant, bezogen auf ein oder mehrere Arbeitspakete kann ein potenzieller Engpass sein. Die „kritische Kette“ assoziiert einen Teil des Risikomanagements.
Grundsätzlich, aus sachlicher Perspektive könnte der Vorgang I parallel zum Vorgang A abgearbeitet werden. Das Problem ist die Ressource, die nicht verfügbar ist in diesem Zeitraum. Dadurch ergibt sich ein längerer Weg als bei CPM. Ansonsten könnten Vorgang I und A gleichzeitig beginnen.
Bei allen Vorgängen handelt es sich nur um 50% der geschätzten Dauern der Ressourcen. Für jeden der drei Wege stehen also absolut äquivalente Puffer zur Verfügung (Bild 5).
Finale Puffer nach Goldratt
Im Bild 4 sehen Sie jetzt die äquivalenten Puffer für jede Weg – Dauer (ROT-BLAU-GRÜN). Die Dauer entspricht immer der Summe der Vorgänge des jeweiligen Wegs (Dies ist eine Pi mal Daumen Methode. Die Methode Goldratts wird weiter unten beschrieben). Allerdings muss mit MS-Project die „reine Lehre“ Goldratts etwas abgewandelt werden. Normalerweise würden die Puffer zwischen dem letzten Vorgang des blauen oder grünen Wegs auf Schnittstellen zwischen der kritischen Kette gesetzt werden (Von daher auch der Name „Zubringer – Puffer“). Das würde nur funktionieren, wenn die „Puffer – Vorgänge“ quasi senkrecht auf eine Schnittstelle der kritischen Kette stoßen würde, und damit keinen Einfluss auf die Länge der kritischen Kette nehmen könnte. Das ist mit MS-Project nicht möglich. Die Puffer sind eigentlich normale Vorgänge, die die kritische Kette verlängern würden.
Da aber die Verbräuche der Puffer äquivalent zu den Verlängerungen der Vorgänge stattfinden, kann man das auch sehr schön mit dieser Variante unter MS-Project überwachen. Voraussetzung ist, dass die Ressource a) die Ist – Dauer/ den Ist – Aufwand und b) die verbleibende Dauer über eine Schnittstelle eingibt (Bei einem kleinen Team bis zu 10 oder 12 Teammitglieder könnte man z.B. Excel verwenden). Sollte sich die ursprüngliche Dauer eines Vorgangs verlängern, muss der entsprechende Puffer verkürzt werden. Verkürzt sich dagegen ein Vorgang, muss der Puffer um die gleiche Dauer verlängert werden. Diese Vorgehensweise wird in den nächsten Beispielen visualisiert. In MS Project kann man die Verkürzung und Verlängerung des Puffers mit Formeln automatisieren.
Verschiedene MS Project Ansichten bezüglich der "Kritischen Kette".
Durch eine weitere Gliederung und Gruppierung, kann jeder Weg in einer Ansicht für sich angezeigt werden (Bild 5). Sie können 10 verschiedene Gliederungscodes – und damit 10 verschiedene Darstellungsformen des Netzplans erzeugen.
TRAINERKNOWLEDGE AI – Ihre smarte PMP®-Vorbereitung!
Bestehen Sie die PMP®-Zertifizierung sicher und flexibel über unsere innovative Online-Plattform. Wählen Sie passgenau: Komplettkurs inklusive der offiziellen 35-Stunden-Kontaktstunden oder als reines Prüfungstraining. Nutzen Sie KI-gestützte Lerneinheiten für maximalen Lernerfolg zu einem absolut unschlagbaren Preis. Jetzt informieren auf trainerknowledge-ai.training und die Karriere auf das nächste Level heben!
Trainer Live Videos – Storytelling – ECO 2026 Bezug
Mit einem Klick lässt sich die alte Konstellation wieder herstellen (Bild 7). Bei den Puffer – Enden sehen Sie jetzt grüne Punkte. Das sind Stichtage, die deutlicher zu sehen sind, wenn sie über- oder unterschritten werden. Außerdem sehen Sie in der Tabelle links unten kleine Vierecke mit roten Punkten. Das sind „Ende nicht später als“ Einschränkungen. Verlängerte sich einer der Wege über sein jetzt aktuelles Ende – Datum (durch die Ressourcen in den Vorgängen online initiiert), rechts neben den Zeitstrahlen, dann gibt MS-Project eine Warnmeldung aus. Dazu müsste ein Weg seinen gesamten Puffer aufgebraucht haben. In Worten ausgedrückt sieht die Situation so aus:
Der Vorgang E muss spätestens am 07.04 fertiggestellt sein.
Der Vorgang H muss spätestens am 12.04 fertiggestellt sein.
Der Vorgang F muss spätestens am 15.04 fertiggestellt sein.
Der Vorgang 13 wurde jetzt durch die Ressource aktualisiert. 1 Tag wurde als IST Dauer eingegeben und die Dauer wurde auf 2 Tage erhöht, weil die Ressource nicht fertig wurde (Der Zeitstrahl von Vorgang 13 verlängert sich erst nach Bestätigung des Planungs-Assistenten). Da jetzt der blaue Zubringerpuffer nach hinten geschoben wurde, erzeugt MS-Project die Warnmeldung. Die Warnmeldung erinnerte den Projektleiter oder die Ressource, dass der Puffer entsprechend verkürzt werden muss. Man müsste jetzt also die Option „Fortfahren“ wählen und anschließend den blauen Puffer um einen Tag verkürzen.
Sollte der die Warnmeldung übersehen werden, kann man in der Spalte Abweichung Vorgang 13 eine „1Tag“ Abweichung sehen. Die errechnet sich aus „Dauer – Geplante Dauer“. Da in der Abweichung des blauen Zubringer Puffers keinerlei Abweichung vorhanden ist, hat eine Aktualisierung des Puffers noch nicht stattgefunden. Im Bild Nummer 9 hat dann die Aktualisierung stattgefunden.
Im Bild Nr. 10 sehen Sie jetzt einen extremen Puffer Verbrauch auf der kritischen Kette. D.h., da wo die höchsten Puffer Verbräuche zu Stande kommen, liegen die Prioritäten des Projektleiters. Das können auch andere Wege sein, die mehr Aufmerksamkeit erfordern, falls die Puffer Verbräuche überproportional steigen.
In Bild 11 sehen wir jetzt, dass sich der Vorgang 16 (Grüner Puffer) über seinen Stichtag hinaus verschoben hat. Jetzt visualisiert MS-Project auch eine Warnung links in der Indikatoren spalte, ein rotes Ausrufungszeichen. Der grüne Pfeil für den Stichtag ist jetzt deutlich zu sehen.
Nutzen + Kritisches zur „Kritischen Kette“: Vor – und Nachteile
Der eigentliche Nutzen liegt in der „Psychologie“ begründet. Ressourcen können ihre Puffer nicht mehr aussitzen, geschweige denn, verschweigen. Es herrscht absolute Transparenz in Sachen „Puffermanagement“. Verschleppungen von Puffern sind nicht mehr möglich. Da die Puffer gebündelt werden, lassen sich auch leichter Erkenntnisse für zukünftige ähnliche Projekte sammeln.
Allerdings gilt für die Kritische Kette ebenso wie für alle anderen Vorgehensmodell, Disziplin und offener Umgang. Das Ressourcen sich über das „Studentensyndrom“ freie Zeit zuordnen, ist in den meisten Fällen wohl unbegründet. Das „Studentensyndrom“ greift wohl eher dann, wenn es darum geht, „was mache ich heute zuerst?“. Wir Menschen neigen natürlich dazu, immer erst das zu erledigen, was am interessantesten für uns ist. Unangenehme Arbeiten verschiebt man gerne bis auf den letzten Drücker. Allerdings interagiert da dann wohl auch das Multitasking. Das Multitasking ist meiner Erfahrung nach das größte Problem. Es kostet erheblich Ressourcen beim Menschen, mehrmals am Tag in unterschiedliche Projekte oder Arbeitsbereiche zu wechseln – auch wenn der Wechsel nur gedanklich erfolgt. Dies wird dann häufig in Kombination mit dem Studentensyndrom gemanaged.
–Das Commitment
Eines der Probleme liegt im Commitment. Der Projektleiter fixiert den Abgabetermin und erzeugt dadurch Druck, was zu impliziten Puffern führt. Bei Goldratt ist das nicht vorgesehen. Das heißt nicht, dass Arbeitspakete ohne Ende ausufern dürfen, nein, der zugeordnete Aufwand bildet natürlich auch eine terminliche Verpflichtung, allerdings immer unter der Maxime, das Ursachen von Verspätungen durch die Ressource kommentiert oder begründet werden müssen.
-„Puffer Diebstahl“
Ein weiteres Problem liegt in der nicht wieder Hergabe, nicht benötigter Puffer. Verfrühungen werden einbehalten, Verspätungen immer weitergereicht. Dieses Problem könnte mit der kritischen Kette gelöst werden, wenn die Ressourcen ihr Schätzverhalten aufgrund der neuen Umgebungsbedingungen nicht ändern würden. Einhergehen muss daher eine Veränderung der Managementkultur. Manager und Team müssen sich einig darüber sein, dass eine Schätzung keinen fixen Termin erzeugt. Wenn dann der Puffer aller Arbeitspakete zentralisiert verwendet wird, werden Verfrühungen in den meisten Fällen weiter gereicht. So kommt es zum Ausgleich zu den Verspätungen.
-Kritik an Goldratts „versteckten Puffern“
Die Kritik an den Goldratts These der „versteckten Puffer“ halte ich für falsch. Aus meiner Erfahrung als auch der Erfahrung meiner Teilnehmer zeigt sich immer wieder, dass Mitarbeiter dazu neigen implizite Puffer mit einzubauen. Manchmal gerechtfertigt aufgrund bestimmter Risiken, häufig aber auch nur zur eigenen Sicherheit, um die eigene Kompetenz durch Termin genaue Abgabe der Liefergegenstände sicher zu stellen. Wenn die Anfrage also durch den Projektleiter für ein Arbeitspaket gestellt wird, gehen den Ressource verschiedene Dinge durch den Kopf.
Wahrscheinlichkeiten: Warum implizite Puffer entstehen!
Annahmen:
- Wenn ich nicht gestört werde und jeden Tag 8 Stunden konzentriert arbeite, dann würde ich normalerweise 3 Tage benötigen.
- Wenn meine Anwesenheit in Projekt B notwendig wird, benötige ich mindestens 5 Tage.
- Fällt mal wieder die Rüttelmaschine aus, dauert die Reparatur mindestens 1 Tag, d.h. ich benötige mindestens 6 Tage.
- Falls der Praktikant dazu stößt, benötige ich einen weiteren Tag wegen der ständigen Erklärungen, also 7 Tage.
- Zur Sicherheit, falls alle Stricke reißen, setze ich noch einen Tag oben auf, also 8 Tage.
In der Annahme unter Punkt 1 geht die Ressource von einer Normalverteilung aus. Das entspricht einer Wahrscheinlichkeit von 50%.
Die Annahmen der Punkte 2 – 5 erzeugen eine Betaverteilung. Von daher werden 5 weitere Tage als Sicherheit mit eingeplant. Was die Ressource aber nicht bedenkt, ist, dass alle anderen Ressourcen ähnlich denken, aber nicht lateral mit einbeziehen, dass die vermuteten Risiken bei den meisten nicht eintreffen oder nur teilweise eintreffen. D.h., dass alle nicht eingetroffenen Risiken „Verfrühungen“ erzeugen, die i.d.R. nicht weiter gereicht werden.
In den obigen Beispielen haben wir unterstellt, dass die Ressourcen wie immer schätzen, aber nur 50% der Dauer/ Aufwände erhalten und die restlichen 50% in den Pufferpool fließen. Das wird und kann in der Praxis so gehandhabt werden. Lessons learned im Rahmen der Assets können diese Vorgehensweise in späteren Projekten verbessern.
Goldratt meinte allerdings, dass gemäß Bild 12 die Dauern/Aufwände der Ressource zugeordnet werden, die eine Eintrittswahrscheinlichkeit von 50% involvieren. Die Sicherheiten die sich über die Verteilung nach rechts ergeben, werden dagegen im Ressourcenpool erfasst.
Was aber nicht passieren darf, ist, dass Dauer und Aufwand gleichgesetzt werden. Die Dauer kann genutzt werden, wenn eine Ressource (100% Kapazität) jeweils 8 Stunden täglich in einem Arbeitspaket arbeitet. Variieren die Arbeitszeiten pro Tag oder arbeiten mehrere Ressourcen in dem Arbeitspaket, muss mit Aufwänden gerechnet werden. Dies ist in den meisten Projekten sowieso der Fall.
Meiner Ansicht nach überwiegen die Vorteile gegenüber der CPM Methode.
Was aber bei einer Einführung von CCPM nicht passieren sollte: „Wir machen ein Pilot Projekt.“ Dann konzentriert sich alles im Unternehmen nur noch auf das Pilotprojekt – entweder als Blockierer oder Unterstützer! Das sind keine realistischen Bedingungen.
Die Projektleiter sollten im CCPM ausgebildet werden und sukzessive in ihren Projekten die neue Methode einführen. Der Projektleiter erklärt den Ressourcen beiläufig den Unterschied einer 50% Wahrscheinlichkeit – Schätzung und einer 80% – 90% Wahrscheinlichkeit – Schätzung. Wenn bei 200 Arbeitspaketen eine Termin – Eintritts – Wahrscheinlichkeit von 50% unterstellt wird, dann werden etwa 100 Arbeitspakete pünktlich fertig. 100 Arbeitspakete benötigen also keine zusätzlichen Sicherheiten. Würde also jedes Arbeitspaket mit etwa 80% Eintrittswahrscheinlichkeit geschätzt werden, „verpufft“ eine Menge Puffer vollkommen nutzlos, weil Verfrühungen nicht weitergereicht werden! Von daher gilt es ausschließlich 50% Arbeitspakete zu schätzen sowie einen zentralen Puffer zu etablieren, der aber allen Arbeitspaketen zur Verfügung steht. Mit einer kleinen Begründung erhält also jede Ressource zusätzliche Aufwände für ihr Arbeitspaket ohne jegliche Kritik. Wenn das Top down gelebt wird, sollte CCPM große Vorteile bringen.
Egal welche Vorgehensweise sie präferieren, CPM, CCPM, Scrum usw., letztendlich geht es immer um Kommunikation und Menschenführung. Noch so gute Techniken und Methoden ersetzen nicht postheroische Führung mit einer Y-Denke.
Das Prinzip der zentralen Puffer nach Goldratt sollte jedem einleuchten können, die Umsetzung erfordert Teamgeist und Motivation.
Die Ansicht der vier Vorgänge unterhalb der Tabelle ist eine spezielle Ansicht in MS-Project, um Vorgänger oder Nachfolger eines Vorgangs zentral visualisiert zu bekommen. Das wird dann interessant, wenn Vorgänge über längere Strecken miteinander verknüpft sind, beispielsweise für Vorgang 5, der mit den Vorgängern …. 123ea + 7t; 70ea; 85aa+3t verknüpft ist. In dem Fall bekäme man analog zum Bild 2 alle drei Vorgänger zentral angezeigt obwohl sie im Gantt Chart enfernt auseinander liegen.
