Welche einzige Aufgabe in Ihrem Projekt darf sich um keinen Tag verschieben, ohne dass der Endtermin kippt? Wer diese Frage nicht aus dem Stand beantworten kann, steuert sein Projekt im Blindflug - und verschenkt genau die Stellschraube, mit der sich die Projekteffizienz steigern lässt. Denn solange unklar ist, welche Aufgaben den Endtermin wirklich bestimmen, verteilt sich die Aufmerksamkeit gleichmäßig auf alles, und das Wichtigste bekommt zu wenig davon.
Die Szene kennt jeder Projektleiter: 40 Aufgaben im Plan, drei Teams parallel im Einsatz, alle arbeiten auf Anschlag, und trotzdem rückt der Liefertermin Woche für Woche näher an die Schmerzgrenze. Meist liegt es nicht am fehlenden Einsatz. Es fehlt die Unterscheidung zwischen Aufgaben, die Luft haben, und Aufgaben, bei denen jeder verlorene Tag direkt auf das Projektende durchschlägt.
Ein kritischer Pfad ist die längste Kette voneinander abhängiger Aufgaben in einem Projekt - also die Abfolge, deren Gesamtdauer die minimal mögliche Projektdauer festlegt. Ermittelt wird er mit der Critical-Path-Methode, auch Critical Path Analysis oder kurz CPM genannt, einem Verfahren der Netzplantechnik. Die Methode hilft Projektleitern, Teamleads und allen, die Vorhaben mit vielen Aufgabenabhängigkeiten planen und überwachen. Zum Einsatz kommt sie immer dann, wenn ein fester Endtermin steht und mehrere Arbeitsstränge parallel laufen. Am Ende ist klar, welche Aufgaben keinerlei Verzögerung vertragen und wo Pufferzeiten Spielraum lassen. Wer seine Projekteffizienz steigern will, braucht genau diese Unterscheidung.
Dieser Artikel führt Sie in fünf Schritten zur eigenen Pfadberechnung, rechnet ein kleines Beispiel mit drei parallelen Strängen durch und zeigt, wie Pufferzeiten im laufenden Projektcontrolling helfen.
Effizienz bedeutet im Projektalltag nicht, dass alle Beteiligten schneller arbeiten, sondern dass die richtige Arbeit zur richtigen Zeit passiert. Genau hier setzt die Pfadlogik an: Von allen Aufgabenketten eines Projekts bestimmt nur die längste den Endtermin. Alle anderen Ketten besitzen Spielraum, weil sie kürzer sind als der bestimmende Strang.
Diese Erkenntnis verändert die Prioritäten grundlegend. Eine Verzögerung auf dem kritischen Pfad verschiebt das Projektende eins zu eins: Ein Tag Verzug bei einer kritischen Aufgabe kostet einen Tag am Ende. Dieselbe Verzögerung bei einer Aufgabe mit Puffer kostet dagegen erst einmal gar nichts, solange der Puffer reicht.
Wer das weiß, hört auf, jede rote Markierung im Plan gleich zu behandeln, und konzentriert Eskalationen, Nachfragen und Zusatzressourcen auf die Engpassaufgaben, die den Termin tatsächlich tragen.
Umgekehrt gilt: Wer die Projektlaufzeit verkürzen möchte, muss am kritischen Pfad ansetzen. Eine unkritische Aufgabe zu beschleunigen bringt für den Endtermin exakt nichts, denn das Projekt wartet ohnehin auf den längsten Strang. Beschleunigung lohnt sich nur dort, wo null Spielraum herrscht - eine einfache Regel, die in der Praxis erstaunlich oft missachtet wird, etwa wenn das Team ausgerechnet die angenehmste statt der terminbestimmenden Aufgabe vorzieht.
Für Sie als Verantwortlichen heißt das: Der Pfad ist kein akademisches Konstrukt, sondern ein Priorisierungswerkzeug. Er zeigt, wo Sie eingreifen müssen, um Projekttermine einhalten zu können, und wo Gelassenheit angebracht ist. Wie Sie diesen Pfad in fünf Schritten selbst ermitteln und damit Ihre Projekteffizienz steigern, zeigt der folgende Abschnitt.
Die Berechnung folgt einer festen Reihenfolge, und jede Etappe baut auf der vorherigen auf. Für ein Projekt mit 20 bis 40 Aufgaben brauchen Sie dafür kaum mehr als einen Nachmittag, ein Whiteboard oder eine Tabelle reichen für den Anfang aus.
Am Anfang steht eine vollständige Liste aller Arbeitspakete, die zum Projektergebnis beitragen. Vollständig ist dabei das Schlüsselwort: Eine vergessene Aufgabe verfälscht später den gesamten Pfad, weil eine Kette ohne dieses Glied kürzer wirkt, als sie ist. Bewährt hat sich die Zerlegung vom Groben ins Feine - erst die großen Blöcke wie Konzept, Umsetzung und Abnahme, dann pro Block die einzelnen Arbeitspakete.
Achten Sie auf eine handhabbare Granularität. Aufgaben von einem halben Tag bis etwa zwei Wochen Länge lassen sich gut planen; alles darunter bläht den Plan auf, alles darüber versteckt Risiken. Wichtige Zwischenergebnisse markieren Sie schon jetzt als Meilensteine, also als Prüfpunkte mit der Dauer null, an denen ein Ergebnis fertig vorliegen muss.
Jede Aufgabe erhält nun eine geschätzte Dauer in Arbeitstagen. Die Vorgangsdauer ist die Zeitspanne, die eine Aufgabe unter normalen Bedingungen von Beginn bis Abschluss benötigt - nicht der Wunschwert und nicht der Idealfall mit ungestörter Konzentration. Fragen Sie die Personen, die die Arbeit tatsächlich ausführen, statt selbst zu schätzen: Wer eine Aufgabe schon dreimal erledigt hat, schätzt sie besser als jeder Plan von außen.
Bei unsicheren Aufgaben hilft eine Dreipunktschätzung: bester Fall, wahrscheinlichster Fall, schlechtester Fall. Als Planwert nehmen Sie den wahrscheinlichsten Fall und notieren die Spannweite daneben. So bleibt sichtbar, welche Schätzungen auf festem Boden stehen und welche auf Hoffnung - ein Unterschied, der in Schritt 5 noch wichtig wird.
Jetzt klären Sie für jede Aufgabe, welche anderen Aufgaben vorher abgeschlossen sein müssen. Diese Aufgabenabhängigkeiten bilden das Gerüst des Netzplans: Texte lassen sich erst korrigieren, wenn sie geschrieben sind; ein Template lässt sich erst befüllen, wenn es umgesetzt ist. Der häufigste Typ ist die Ende-Anfang-Beziehung, bei der eine Aufgabe erst starten kann, wenn die Vorgängeraufgabe endet.
Widerstehen Sie der Versuchung, Abhängigkeiten zu erfinden, die keine sind. Zwei Aufgaben, die dieselbe Person erledigt, sind nicht automatisch logisch voneinander abhängig - das ist ein Ressourcenkonflikt, kein Reihenfolgezwang. Je weniger echte Abhängigkeiten der Plan enthält, desto mehr Aufgaben können parallel laufen, und Parallelität ist der kürzeste Weg, die Projektdauer zu senken.
Mit Dauer und Reihenfolge berechnen Sie nun zwei Terminpaare pro Aufgabe. Zuerst die Vorwärtsrechnung: Vom Projektstart aus ermitteln Sie für jede Aufgabe den frühesten Anfangs- und den frühesten Endtermin, indem Sie die Dauern entlang der Ketten aufaddieren. Das Ergebnis am letzten Glied der längsten Kette markiert zugleich das frühestmögliche Projektende.
Danach folgt die Rückwärtsrechnung: Vom Endtermin aus rechnen Sie zurück und bestimmen für jede Aufgabe den spätesten Anfangs- und den spätesten Endtermin, zu dem sie starten beziehungsweise enden darf, ohne das Projektende zu gefährden. Diese beiden Rechenläufe klingen technisch, sind aber schlichte Addition und Subtraktion - und sie liefern den Rohstoff für den letzten Schritt.
Der Gesamtpuffer (auch Gesamtschlupf) einer Aufgabe ist die Differenz zwischen spätestem und frühestem Anfangstermin. Er sagt aus, wie viele Tage sich eine Aufgabe verschieben darf, ohne den Endtermin zu gefährden. Überall dort, wo diese Differenz null beträgt, gibt es keinerlei Spielraum: Diese Aufgaben bilden den kritischen Pfad, und jede einzelne von ihnen ist eine Engpassaufgabe.
Markieren Sie diese Kette farblich im Plan und prüfen Sie sie gegen Ihre Schätzunsicherheit aus Schritt 2: Liegt eine wackelige Schätzung ausgerechnet auf dem Pfad, verdient sie sofort eine zweite Prüfung. Ab jetzt kennt Ihr Team die Aufgaben, bei denen Tempo zählt, und die Aufgaben, bei denen ein Tag Verzug niemanden nervös machen muss - die Grundlage, auf der Sie im laufenden Betrieb die Projekteffizienz steigern können.
[BANNER type="lead_banner_1" title="Kritischer Pfad Werkzeugkasten: Vorlagen, Puffer, Risikoliste" description="Geben Sie Ihre E-Mail-Adresse ein, um eine umfassende Schritt-für-Schritt-Anleitung zu erhalten" picture-src="/upload/medialibrary/c0f/04zrwoo0jpzvirn15czqu595pynw0yl9.webp" file-path="/upload/medialibrary/c8c/x896hqti0zprz5k8i9ozd20r34vomc8f.pdf"]Wie sich die fünf Schritte in Zahlen übersetzen, zeigt ein bewusst kleines Beispiel: ein Website-Relaunch mit drei parallelen Arbeitssträngen, die nach dem Kickoff gleichzeitig starten und am Ende in eine gemeinsame Abnahme mit Go-live von zwei Tagen münden.
Strang A umfasst die Inhalte: Inhaltsaudit (3 Tage), Texte schreiben (8 Tage), Korrekturschleife (2 Tage). Strang B deckt Design und Umsetzung ab: Design-Konzept (5 Tage), Template-Umsetzung (7 Tage), Schnittstellen anbinden (4 Tage), Funktionstests (3 Tage). Strang C kümmert sich um die Infrastruktur: Hosting einrichten (2 Tage), Migration vorbereiten (4 Tage). Die Tabelle zeigt, was die Addition ergibt:
|
Strang |
Aufgabenkette |
Dauer |
Gesamtpuffer |
Status |
|---|---|---|---|---|
|
A: Inhalte |
Inhaltsaudit (3) + Texte schreiben (8) + Korrekturschleife (2) |
13 Tage |
6 Tage |
unkritisch |
|
B: Design und Umsetzung |
Design-Konzept (5) + Template-Umsetzung (7) + Schnittstellen anbinden (4) + Funktionstests (3) |
19 Tage |
0 Tage |
kritisch |
|
C: Infrastruktur |
Hosting einrichten (2) + Migration vorbereiten (4) |
6 Tage |
13 Tage |
unkritisch |
Strang B ist mit 19 Tagen der längste und damit der kritische Pfad. Zusammen mit den zwei Tagen für Abnahme und Go-live ergibt sich eine Projektdauer von 21 Arbeitstagen - schneller geht es mit diesem Plan nicht, egal wie flott die anderen Stränge arbeiten. Strang A darf sich um bis zu 6 Tage verschieben, Strang C sogar um 13 Tage, ohne dass der Go-live wackelt.
Das Beispiel macht die Steuerungslogik greifbar. Braucht das Texteschreiben in Strang A statt 8 plötzlich 11 Tage, passiert am Endtermin nichts, denn der Puffer von 6 Tagen fängt die Abweichung auf. Verzögert sich dagegen die Template-Umsetzung in Strang B um nur einen Tag, verschiebt sich der Go-live um genau diesen Tag. Wer hier die Projektlaufzeit verkürzen will, setzt gezielt bei Strang B an: Teilen sich beispielsweise zwei Entwickler die Template-Umsetzung und drücken sie von 7 auf 5 Tage, sinkt die Projektdauer von 21 auf 19 Arbeitstage.
Eine Feinheit verdient dabei Beachtung: Kürzt jemand Strang B weiter, etwa auf 12 Tage, wird plötzlich Strang A mit seinen 13 Tagen zur längsten Kette - der Pfad springt um. Nach jeder größeren Planänderung gehört die Berechnung deshalb auf den Prüfstand, sonst optimiert das Team an einer Kette, die längst nicht mehr den Termin bestimmt.
Puffer wirken auf den ersten Blick wie ein Nebenprodukt der Berechnung, tatsächlich sind sie ihr wertvollstes Ergebnis. Pufferzeiten beziffern für jede Aufgabe präzise, wie viel Verzögerung das Projekt an dieser Stelle verkraftet - und machen damit aus dem Bauchgefühl „das wird schon noch“ eine belastbare Zahl.
Für das laufende Projektcontrolling sind schrumpfende Puffer das früheste Warnsignal überhaupt. Ein Strang, dessen Puffer innerhalb von zwei Wochen von 6 auf 2 Tage gefallen ist, meldet ein Problem, lange bevor ein Termin offiziell reißt. Wer nur auf verpasste Termine schaut, reagiert zu spät; wer Pufferverläufe beobachtet, kann Terminverzug vermeiden, bevor er entsteht. Ein kurzer wöchentlicher Prüfblick reicht dafür aus:
Der letzte Punkt zeigt die zweite Funktion der Puffer: Sie sind verteilbare Reserve. Eine Aufgabe mit 13 Tagen Spielraum kann problemlos eine Woche warten, wenn ihre Bearbeiterin auf einer kritischen Aufgabe dringender gebraucht wird. Genau diese Umverteilung von unkritisch zu kritisch ist der Hebel, mit dem Teams ohne einen einzigen zusätzlichen Arbeitstag ihre Projekteffizienz steigern können - vorhandene Kapazität fließt dorthin, wo sie den Endtermin schützt.
Ein Wort der Vorsicht gehört ebenfalls hierher: Puffer sind kein Freibrief. Ein Team, das jeden Spielraum sofort ausschöpft, weil „ja noch Luft ist“, verwandelt nach und nach alle Stränge in kritische - und steht am Ende ohne jede Reserve da, wenn das erste echte Problem auftaucht.
[BANNER type="lead_banner_2" blockquote="\"Nach der Einführung von Bitrix24 haben wir die Geschäftsprozesse in unserem Unternehmen maximal vereinfacht.\"" user-picture-src='/upload/optimizer/converted/upload/iblock/1f0/5znenimejlwyevt3s1tfd1gxgx08i7ew.png.webp?1742972973130' user-name="Geschäftsführer, Alexander Dortmann" user-description="DortmannKids" button-message="KOSTENFREI STARTEN"]
So klar die Logik ist, so ehrlich sollte der Blick auf ihre Schwachstellen sein. Drei Grenzfälle tauchen in der Praxis regelmäßig auf.
|
Grenze der Methode |
Wann sie auftritt |
Gegenmaßnahme |
|
Schätzfehler |
Neuartige Aufgaben werden eher zu optimistisch geschätzt |
Dreipunktschätzung, Neuberechnung mit Ist-Werten |
|
Zu viele Verknüpfungen |
Netze mit mehreren hundert quervernetzten Aufgaben |
Werkzeugunterstützung statt manueller Pflege |
|
Dynamischer Umfang |
Anforderungen ändern sich alle paar Wochen |
Planung in kurzen Zyklen, Pfad nur für stabile Anteile |
Die erste Grenze sind Schätzfehler. Der komplette Pfad steht und fällt mit der geschätzten Vorgangsdauer, und Schätzungen für neuartige Aufgaben liegen erfahrungsgemäß eher zu optimistisch als zu pessimistisch. Weicht die tatsächliche Dauer einer einzigen Kettenaufgabe um 30 Prozent ab, kann eine rechnerisch unkritische Kette in Wirklichkeit längst kritisch sein. Abhilfe schaffen die Dreipunktschätzung aus Schritt 2 und eine regelmäßige Neuberechnung mit Ist-Werten statt Planwerten.
Die zweite Grenze erreichen Projekte mit sehr vielen Verknüpfungen. Bei einem Netz aus mehreren hundert Aufgaben mit Quervernetzungen zwischen allen Strängen wird die manuelle Pflege zur Vollzeitaufgabe, und schon kleine Änderungen erzwingen eine komplette Neuberechnung. Ohne Werkzeugunterstützung veraltet der Plan dann schneller, als das Team ihn aktualisieren kann - der Pfad an der Wand zeigt den Stand von vor drei Wochen und stiftet mehr Verwirrung als Nutzen.
Die dritte Grenze sind dynamische Vorhaben, bei denen der Umfang selbst in Bewegung bleibt. Ein Entwicklungsprojekt, dessen Anforderungen sich alle zwei Wochen ändern, kennt keinen stabilen Endpunkt, den eine Kette bestimmen könnte. Hier planen Teams besser in kurzen Zyklen und nutzen die Pfadlogik nur innerhalb eines Zyklus oder für die stabilen Anteile wie Infrastruktur und Abnahmen. Verschwiegen sei auch nicht: Die klassische Rechnung kennt nur Zeit, keine Menschen. Dass zwei parallele Aufgaben derselben Person gehören und in der Praxis nacheinander laufen, sieht ein reiner Netzplan nicht - erst die Ressourcenansicht eines Planungstools deckt solche versteckten Engpässe auf.
Keiner dieser Punkte entwertet das Verfahren. Sie zeigen nur, wo eine Software die Pflege übernehmen sollte und wo gesundes Urteilsvermögen die Rechnung ergänzen muss.
Spätestens ab 30 verknüpften Aufgaben lohnt sich der Umstieg von der Tabelle auf ein Werkzeug, das Termine und Abhängigkeiten selbst nachführt. Bitrix24 bringt dafür im Bereich Aufgaben und Projekte eine Gantt-Ansicht mit, die Ihre Aufgabenliste als Zeitbalkenplan darstellt: Jede Aufgabe erscheint als Balken mit Start- und Endtermin, Verantwortlichem und Fortschritt.
Abhängigkeiten legen Sie direkt im Diagramm an, indem Sie Aufgaben miteinander verbinden – alle vier gängigen Beziehungstypen stehen zur Verfügung, vom klassischen Ende-Anfang bis zu Anfang-Anfang für parallel startende Arbeiten. Der praktische Gewinn zeigt sich bei der ersten Planänderung: Verschieben Sie einen Balken, zieht das Gantt-Diagramm alle abhängigen Aufgaben automatisch mit und macht sofort sichtbar, ob der Endtermin noch hält. Die Neuberechnung, die auf dem Whiteboard einen Nachmittag kostet, passiert hier mit einem Mauszug. Meilensteine markieren Sie als eigene Punkte im Plan, Fristen und Erinnerungen sorgen dafür, dass Verantwortliche rechtzeitig reagieren.
Für den Website-Relaunch aus dem Rechenbeispiel sieht das konkret so aus: Sie legen die drei Stränge als Aufgabenketten an, verbinden die Glieder per Ende-Anfang-Beziehung und setzen den Go-live als Meilenstein ans Ende. Meldet der Entwickler in Woche zwei, dass die Schnittstellen zwei Tage länger brauchen, verlängern Sie den Balken – und sehen im selben Moment, dass der Meilenstein nach hinten rutscht, während die Inhaltskette weiter Luft hat. Auf dieser Basis entscheiden Sie in Minuten statt in Meetings, ob Sie Kapazität umschichten oder den Termin neu verhandeln. Ergänzend behalten Auslastungsansicht und Berichte im Blick, wer überbucht ist und welche Aufgaben überfällig sind – das oben beschriebene Projektcontrolling per Pufferblick bekommt damit eine laufend aktuelle Datenbasis.
Wenn Sie Ihre Projekteffizienz steigern und den nächsten Terminplan nicht mehr von Hand nachrechnen möchten: Erstellen Sie ein kostenloses Bitrix24-Konto und bilden Sie Ihr erstes Projekt mit Abhängigkeiten und Meilensteinen im Gantt-Diagramm ab.
Mit Bitrix24 bringen Sie Struktur in Ihre Projekte. Nutzen Sie unser Tool zur Analyse des kritischen Pfades und steigern Sie so die Effizienz Ihrer Projekte. Starten Sie jetzt kostenlos!
Jetzt startenSie können die Projekteffizienz steigern, indem Sie den kritischen Pfad Ihres Projekts ermitteln und Aufmerksamkeit, Eskalationen und Ressourcen gezielt auf dessen Aufgaben lenken. Aufgaben mit Puffer geben dabei Kapazität ab, statt sie zu binden - so fließt vorhandene Arbeitszeit dorthin, wo sie den Endtermin tatsächlich schützt.
Der kritische Pfad in einem Projekt ist die längste Kette voneinander abhängiger Aufgaben und bestimmt damit die minimal mögliche Projektdauer. Jede Verzögerung auf dieser Kette verschiebt den Endtermin eins zu eins, weil ihre Aufgaben keinerlei Pufferzeiten besitzen.
Den kritischen Pfad berechnet man in fünf Schritten: alle Aufgaben sammeln, die Vorgangsdauer (die geschätzte Aufgabendauer) je Aufgabe schätzen, Abhängigkeiten festlegen, per Vorwärts- und Rückwärtsrechnung früheste und späteste Termine bestimmen und daraus den Gesamtpuffer ableiten. Alle Aufgaben mit einem Puffer von null bilden den kritischen Pfad.
Pufferzeiten spielen für die Projekteffizienz eine doppelte Rolle: Sie dienen als Frühwarnsystem, weil schrumpfende Puffer Probleme lange vor dem ersten gerissenen Termin anzeigen, und als verteilbare Reserve, weil Aufgaben mit Spielraum Kapazität an kritische Aufgaben abgeben können.
Verzögert sich eine Aufgabe auf dem kritischen Pfad, verschiebt sich das Projektende um exakt dieselbe Zeitspanne, da diese Kette keinen Puffer besitzt. Gegensteuern lässt sich nur durch Beschleunigung auf dem Pfad selbst, etwa durch zusätzliche Bearbeiter, verkleinerten Umfang oder das Parallelisieren von Teilaufgaben.
Kritischer Pfad und Meilensteine ergänzen sich, beschreiben aber Verschiedenes: Der Pfad ist die terminbestimmende Aufgabenkette mit echter Dauer, ein Meilenstein ist ein Prüfpunkt mit der Dauer null, an dem ein Ergebnis fertig vorliegen muss. Meilensteine machen Fortschritt sichtbar, der Pfad erklärt, welche Aufgaben diesen Fortschritt zeitlich begrenzen.
Ja, der kritische Pfad kann sich während des Projekts ändern - immer dann, wenn Verzögerungen oder Beschleunigungen die Längenverhältnisse der Ketten verschieben. Schrumpft der bisher längste Strang oder verlängert sich ein anderer über dessen Dauer hinaus, springt der Pfad um. Nach jeder größeren Planänderung gehört die Berechnung deshalb auf den Prüfstand.