Zurück zur Methodenübersicht

Terminplanung

Terminplanung: Basis

Einleitung Terminplanung

Mit der Erzeugung eines vernetzten Balkenplans sind für die Projektleitung viele Vorteile verbunden.

Bei der Anwendung planbasierter und hybrider Projektmanagementansätze sollte man deshalb als Projektleiter die Funktionsweise eines Tools wie MS Project in den Grundzügen kennen.

Bei rein agilen Ansätzen ist die Verwendung von vernetzten Balkenplänen eher ungewöhnlich.

Mit einem Profi-Tool einen detaillierten Terminplan als vernetzten Balkenplan erstellen und zahllose nützliche Funktionen für Planung und Steuerung nutzen

Der Ablaufplan wird am besten mit professionellen Tools wie MS Project in einen detaillierten Terminplan als vernetzter Balkenplan überführt.

Ein vernetzter Balkenplan (Gantt-Chart) ist ein Projektplanungsinstrument, das Vorgänge als zeitlich skalierte Balken darstellt und zusätzlich deren logische Abhängigkeiten miteinander verknüpft, sodass Ablauf, Dauer und kritischer Pfad eines Projekts sichtbar werden.

In Planungstools wie MS Project erfolgt eine automatische Terminierung der Vorgänge, die sogenannte „Kalendrierung“: Die Vorgänge werden als Balken auf einer Zeitskala dargestellt. Die Kalendrierung basiert auf den folgenden Parameter:

  • erfasster Projektstart
  • erfasste Vorgänge und deren Dauer
  • erfasste Anordnungsbeziehungen
  • ausgewählte Kalender
  • enthaltene Tool-Logik des „Netzplanrechnens“

💡 Wenn das Projekt viele sachlogische Abhängigkeiten und hohen Zeitdruck hat, sollte man ein professionelles Gantt-Chart-Tool zur Darstellung des vernetzten Balkenplans nutzen. Klassisches Netzplanrechnen sollte in diesem Tool enthalten sein.

Netzplanrechnen ist eine Methode der Projektplanung, bei der Vorgänge und ihre zeitlichen Abhängigkeiten in einem Netzplan dargestellt und rechnerisch ausgewertet werden. Dabei werden früheste und späteste Anfangs- und Endzeiten sowie Pufferzeiten ermittelt, um den kritischen Weg zu bestimmen. Ziel ist es, Termine, Abläufe und Ressourcen eines Projekts realistisch zu planen und zu steuern.*

Auf das Netzplanrechnen wird im Grundlagenkapitel nicht weiter eingegangen. Bei Nutzung eines Planungstools sind Detailkenntnisse zum Netzplanrechnen nicht unbedingt erforderlich. Erfahrungsgemäß erleichtert die Kenntnis des Netzplanrechnens den Zugang zum Toolverhalten und erleichtert das Verständnis einiger wichtiger Pufferbegriffe (siehe Pufferarten).

💡 Nicht in jeder Phase bringen Vernetzung und Netzplanrechnung einen Mehrwert: Wenn der Zeitdruck gering ist und die Vorgänge keine sachlogischen Abhängigkeiten haben (oft zum Beispiel bei der detaillierten Beschreibung von Anforderungen verschiedener Fachbereiche), kann man sich für solche Phasen auch die Steuerung zum Beispiel mit einem Kanban-Board überlegen.

Zweck der detaillierten Terminplanung:

  • Simulation der Wirkung von Störungen auf die Meilensteine (in geeignetem Tool)
  • Schaffung einer Orientierung für die Arbeitspaketowner und Ermöglichung von selbstorganisiertem Arbeiten. Ein guter vernetzter Balkenplan beantwortet dem AP-Owner die folgenden Fragen:
    • Wann bin ich mit meinem Arbeitspaketen dran
    • Welcher Vorgang liefert mir wann welche Vorarbeiten
    • An welche Vorgänge muss ich wann meine eigenen Ergebnisse übergeben

Optimierung von vernetzten Balkenplänen Nach der ersten Erfassung eines vernetzten Balkenplans wird man einen Vergleich mit der groben Terminplanung bzw. dem Phasenplan machen. Dabei stellt man oft fest, dass das Projekt nach der Detailplanung später fertig wird. Erster „Angriffsfläche“ für terminliche Optimierungen ist immer der kritische Pfad bzw. der längste Weg durch das Projekt.

Die erste terminliche Grobplanung über den Phasenplan basiert oft einer spontanen Rückwärtsterminierung ausgehend von einem ggf. vorhandenen und oft zu optimistischen Kundenwunschtermin. Bei der Detailplanung in einem Planungstool sollte man aber anders vorgehen. Der erste Entwurf des Terminplans sollte immer eine Vorwärtsterminierung der Vorgänge sein, die sich letztlich konsequent aus den Zielen und daraus abgeleiteten Arbeitspaketen, den sachlogischen Abhängigkeiten und den Dauern ergeben. Oft bleibt dann der ausgerechnete Termin hinter den Wunschvorstellungen des Kunden zurück. Aber dann folgen individuell passende Optimierungen wie zum Beispiel mit Fast Tracking oder Crashing.

Fast Tracking: Verkürzung des kritischen Pfads durch zeitliche Überlappung von Vorgängen

Fast Tracking mit negativen Zeitabständen kann zum Risiko von Ineffizienzen führen. Wenn zum Beispiel am Ende eines Vorgangs doch noch eine wesentliche Erkenntnis mit Relevanz für den Nachfolger erzielt wird, müssen unter Umständen bereits vorgenommene Arbeiten des Nachfolgers wiederholt werden.

Crashing: Beschleunigung von Vorgängen durch Einplanung von zusätzlichen Ressourcen auf die kritischen Vorgänge

“Zusätzliche Ressourcen” können dabei zusätzliche Einheiten der Einsatzmittel sein (zum Zukauf externer Berater) oder die Erhöhung der Einsatzzeit der vorhandenen Ressourcen (Überstunden am Wochenende, Erhöhung Einsatzzeiten durch Höherpriorisierung des Projekts im Vergleich zu anderen Projekten).

💡 In der Regel ist es sinnvoll, zunächst Fast Tracking zu versuchen, bevor man sich mit Crashing versucht. Erfahrungsgemäß ist die Überlappung von Vorgängen durch Fast Tracking günstiger (sofern nicht das Risiko von Ineffizienzen eintritt) die Bereitstellung von zusätzlichen Ressourcen.

⚠️ Oft werden Tools wie MS Project nicht ideal genutzt. Ausgehend von dem Kundenwunschtermin wird nach dem guten alten Baustellenprinzip “was nicht passt, wird passend gemacht” verfahren. Die entstehenden Pläne sind dann in aller Regel unrealistisch und nicht belastbar: Dann werden gerne mal alle Dauern werden nach dem Gießkannenprinzip solange gekürzt, bis der Kundenwunschtermin herauskommt.

⚠️ Eine ebenso gerne genutzte und was noch problematischere Praxisvariante: Alle Anfangs- und Endtermine werden manuell gepflegt, bis es passt.

Mit der manuellen Pflege zerstört man sich die sehr nützliche Simulationsfunktion. Tools wie MS Project sind Terminberechnungsprogramme und keine Termineditierprogramme. Man sieht in der Info-Spalte nach manueller Terminpflege Einschränkungssymbole, welche die Simulation von Änderungen oder Störungen auf den weiteren Projektverlauf oft unmöglich machen. Einschränkungen sind für definierte Ausnahmefälle vorgesehen, sollten aber in aller Regel vermieden werden. Wenn man einen Vorgang einschränkt, dann nur bewusst (und nicht wie so oft aus Versehen) und im Bewusstsein, dass genau für das jeweilige Szenario die Einschränkung sinnvoll ist. Auf diese definierten Ausnahmefälle von Einschränkungen wird im Grundlagenkapitel nicht eingegangen.

💡 Statt Reduktion der Dauer nach der Gießkanne oder manuelle Festlegung der Einzeltermine sollten besser individuelle und konkrete Optimierungsmaßnahmen (Überlappung, effizientere Methoden, zusätzliches Personal…) vorgenommen werden. Einige der Maßnahmen haben dann natürlich auch eine Reduktion der Dauer zu Folge, aber nur aufgrund einer inhaltlich begründeten Maßnahme.

⚠️ Bei vielen parallelen Aktivitäten in der Ablaufplanung steigt zwar die Komplexität der Ressourcenplanung, aber es geht schneller. Es gibt einige Autoren, die hier eine Art Optimum zwischen Parallelisierung und damit Zeitersparnis sowie Beachtung einer zu großen Komplexität durch parallel eingesetzte Ressourcen empfehlen. Davon halte ich eher wenig. Natürlich ist es sinnvoll, das Risiko im Kopf zu haben, dass bei vielen parallelen Aktivitäten, die von denselben Ressourcen erfüllt werden sollen, eine versehentliche Überplanung stattfinden kann. Insofern ist die hier beschriebene Methode eine Art “Qualitätscheck” für die Ressourcenplanung. Aber es ist nicht so, dass man eine beliebig freie Entscheidung treffen kann, ob man durch viel Parallelisierung oder auch Überlappung Zeit spart und damit das Risiko einer erhöhten Ressourcenkomplexität eingeht. Wenn die Abhängigkeiten so sind wie sie sind, kann man nicht einfach im Sinne der Zeitersparnis zwei Vorgänge parallel abwickeln, obwohl sie voneinander abhängig sind. Ggf. sind Optimierungspotenziale beim Thema Überlappung aber möglich, hier lohnt sich immer eine detaillierte Betrachtung. Aber die sachlogischen Abhängigkeiten sollten immer beachtet werden: Es macht ja keinen Sinn, eine scheinbare Beschleunigung durch ein großes Chaos zu erkaufen.

In diesem Zusammenhang siehe auch iterativer Prozess der groben Phasenplanung ohne fachliches Detailwissen und der späteren detaillierten Ablauf- und Terminplanung mit Fachspezialisten: Realitätscheck Phasenplan

Ausgewählte Tipps für MS Project siehe Vertiefung

Mit verschiedenen Pufferarten arbeiten und den Unterschied zur Reserve kennen

Gesamtpuffer ist die Zeitspanne, um die ein Vorgang verlängert oder nach hinten verschoben werden kann, ohne das Projektende zu verschieben.

Freier Puffer ist die Zeitspanne, um die ein Vorgang verschoben werden kann, ohne die früheste Lage anderer Vorgänge zu beeinflussen.

⚠️ Von Puffer spricht man bei der Ablauf- und Terminplanung eigentlich nur bezüglich der Zeiten, die durch Netzplanrechnung vom System rein rechnerisch erzeugt werden. Alleine durch die logische Vernetzung der Vorgänge, der Daueransätze sowie der Vorwärts- und Rückwärtsrechnung der Netzplanrechnung können Gesamtpuffer und freie Puffer entstehen.

Wann entstehen die Gesamtpuffer und freier Puffer?

  • Beim Netzplanrechnen entsteht immer mindestens ein kritischer Pfad (der die Projektdauer bestimmt) mit einem Gesamtpuffer = 0.
  • Rechnerisch können auch mehrere kritische Pfade beim Netzplanrechnen entstehen.
  • In der Regel werden aber aufgrund der Sachlogik der Vernetzung parallele Vorgänge zum kritischen Pfad angelegt werden, deren Dauer eben nicht zu einem weiteren kritischen Pfad führt, sondern den oder die Vorgänge “nicht-kritisch” werden lässt. Nicht-kritisch heißt wie gesagt, dass eine Verschiebung oder Verlängerung dieser Vorgänge nicht zu einer Verschiebung des Projektendes führt. Solche Vorgänge haben dann immer einen Gesamtpuffer > 0.
  • Freier Puffer entsteht nur dann, wenn der Vorgänger verlängert oder verschoben werden kann, ohne dass der früheste Anfangszeitpunkt des Nachfolgers auch verschoben wird. Der Vorgänger respektiert sozusagen die “Intimsphäre” seines Nachfolgers.
  • Verhältnis von Gesamtpuffer und freier Puffer / früheste Lage und späteste Lage:
    • Es kann Gesamtpuffer ohne freien Puffer geben: Im obigen Beispiel hat zum Beispiel Vorgang 4 denselben Gesamtpuffer wie Vorgang 6. Wenn Vorgang 4 verlängert oder verschoben wird, wird Vorgang 6 solange aus seiner ursprünglich frühesten Lage nach rechts geschoben, bis er seine späteste Lage erreicht hat und auch sein Gesamtpuffer aufgebraucht ist. Zwischen Vorgang 4 und 6 gibt es aber in dieser Konstellation - sozusagen im Binnenverhältnis nur dieser zwei Vorgänge - keinen freien Puffer.
      • Die früheste Lage (definiert durch den frühesten Startzeitpunkt und frühsten Endzeitpunkt) von Vorgängen entsteht beim Netzplanrechnen nach der Vorwärtsrechnung. Bei der Vorwärtsrechnung wird - ausgehend vom Startpunkt des Netzplans für jeden Vorgang sukzessive ermittelt, wann er unter Berücksichtigung seiner Vorgänger frühstens starten und enden kann. Daraus ergibt sich der früheste Projektendtermin. Nach der Vorwärtsrechnung kann auch der freie Puffer “im Binnenverhältnis” zwischen zwei Vorgängen frühster Lage ermittelt werden.
      • Die späteste Lage (definiert durch den spätesten Startzeitpunkt und den spätesten Endzeitpunkt) entsteht beim Netzplanrechnen immer nach dem Rückwärtsrechnen, welches sich an das Vorwärtsrechnung anschließt. Beim Rückwärtsrechnen werden - ausgehend vom definierten Endpunkt des Netzplans - die spätestens Lagen der Vorgänge rechnerisch ermittelt. Es wird als klar, wann ein Vorgang spätestens starten und enden muss, um das ermittelte Ende des Netzplans zu erreichen.

💡 Nutzen Gesamtpuffer: Der Gesamtpuffer dient in erster Linie dem Schutz des Projektendtermins. Der Gesamtpuffer zeigt der Projektleitung, um wie viel sich ein Vorgang maximal verzögern darf, ohne den Endtermin des Projekts zu gefährden. Insofern kann er für die für Priorisierung und Terminsteuerung auf Gesamtprojektebene. Insbesondere kann bei einer Unterdeckung von Ressourcen zu einem bestimmten Zeitpunkt bei vorhandenem Gesamtpuffer darüber nachgedacht werden, den Vorgang nach hinten zu verschieben und den Gesamtpuffer aufzulösen, ohne den Projektendtermin zu gefährden. Natürlich nur unter der Voraussetzung, dass es zum späteren Zeitpunkt diese Unterdeckung nicht gibt.

💡 Nutzen freier Puffer: Der freie Puffer dient in erster Linie dem Schutz des direkten Nachfolgers. Er zeigt, um wie viel sich ein Vorgang verzögern darf, ohne einen nachfolgenden Vorgang zu verschieben. Damit ermöglicht er eine flexible Steuerung einzelner Arbeitspakete, ohne Folgeprozesse zu stören.

Unterschiede zwischen den Begriffen “Reserve” und “Puffer” siehe Vertiefung

Mit der späteren Ablauf- und Terminplanung den Vermutungen der frühen und grobe Phasenplanung einem Realitätscheck unterziehen

Oft wird die Projektleitung bei der ersten groben Dauerschätzung des Phasenplans alleine oder mit einem Sparringspartner gemeinsam planen müssen. Gleichzeitig werden Wunschvorstellungen des Auftraggebers mehr oder weniger stark in die Zeitplanung einfließen. Nicht wenige Projekte werden ja recht kurzfristig vom Top-Management in die Linie getragen - oft verbunden mit einer klaren zeitlichen Vorstellung, die eher kurzfristig ist. Solche Vorstellungen fließen dann oft in die Phasenplanung ein.

Leider stehen dem Projektleiter zu diesem Zeitpunkt oft noch nicht die Fachspezialisten zur Verfügung, mit denen er eine fachlich fundierte Detailplanung (den Projektstrukturplan) machen kann. Und auf deren Basis sich eine realistischere und meist längere Terminplanung ergibt. Selbst wenn sich die Projektleitung dieser Tatsache bewusst ist und bei der Phasenplanung eine Reserve vorsieht. Insofern ist es völlig normal, die Ablaufplanung und den kritischen Pfad zur Validierung des Phasenplans zu verwenden, sobald man eine realistische und belastbare Planungsgrundlage hat. Das nennt man auch “rollierende Planung” oder nach dem PMBOK der PMI (“Rolling Wave Planning”):

  • Erst wird die grobe Phasenplanung erledigt. Die nötige Detailplanung folgt erst dann, wenn die nötige Information z.B. durch die oft erst später verfügbaren Fachexperten vorliegen.
  • Aber selbst, wenn die Fachexperten im Projektteam alle an Board sind, plant man weit in der Zukunft liegende Aspekte im Detail erst später. Im PMBOK spricht man dann von sogenannten “Planungspaketen”, die man als Platzhalter frühzeitig schätzt und später durch konkrete Arbeitspakete ersetzt. Im Prinzip ist nichts anderes als der spätere Ersatz von groben Epics durch bearbeitbare Userstories.

Ein willkommener Effekt, die konkrete Planung möglichst mit den Fachexperten zu machen, die später auch die Umsetzung verantworten: Man plant mit mehr Engagement und Realitätssinn, wenn man die eigene Planung später umsetzen soll und zeigt dann auch später ein höheres Commitment bei der Umsetzung der “eigenen” Planung (und nicht einer oft unrealistisch wirkenden anonymen “Expertenplanung”).

Der Ablauf- und Terminplan spiegelt also mit der Vorwärtsterminierung die Realität wider, das ist klassische Netzplanrechnung. Erst rechnet man sich ehrlich mit der Vorwärtsrechnung. Die Rückwärtsrechnung dient nur der Ermittlung des Puffers und der Festlegung möglicher spätester Anfangszeiten der Vorgänge. Das ist natürlich etwas völlig anderes als die “Rückwärtsterminierung” vieler Projektleiter, die nichts mit diesem Schritt des Netzwerkrechnens zu tun hat. Da wird die Netzplanrechnung oft zu Unrecht als Zeuge für ein nicht optimales Planungsverhalten herangezogen. Die Rückwärtsrechnung ist nur der erste Teil der klassischen Netzplantechnik. Das ist ein rein mathematischer Schritt innerhalb eines bereits realistisch aufgebauten Netzplans:

  • Die Vorwärtsrechnung ermittelt, ausgehend vom Projektstart und den realen, fachlich fundierten Vorgangsdauern und Abhängigkeiten, die frühesten Anfangs- und Endzeitpunkte (FAZ/FEZ) jedes Vorgangs – und damit auch den frühestmöglichen Projektendtermin. Das ist die “Wahrheit” des Plans.
  • Die Rückwärtsrechnung setzt an diesem so ermittelten (oder alternativ an einem separat vorgegebenen Zieltermin) an und berechnet davon ausgehend die spätesten Anfangs- und Endzeitpunkte (SAZ/SEZ) jedes Vorgangs. Der Sinn dieses Schritts ist ausschließlich die Pufferermittlung (Gesamtpuffer, freier Puffer) und die Identifikation des kritischen Pfades (die Vorgänge mit Puffer = 0) und natürlich auch die Ermittlung der spätesten Anfangstermine der Vorgänge (wann muss ich spätestens beginnen, damit ich noch zum ermittelten Termin fertig werde).
  • Diese Rückwärtsrechnung verändert an den Vorgangsdauern selbst gar nichts. Sie ist ein Analyseinstrument, kein Eingriffsinstrument. Sie beantwortet die Frage “Wie viel Spielraum habe ich wo?”, nicht die Frage “Wie kürze ich die Dauer?
  • Das, was viele Projektleiter mit ihrer “Rückwärtsterminierung” (und oft auch das Management, das den Druck erzeugt) tun, ist etwas völlig anderes: Ein Zieltermin wird extern gesetzt (meist aus der groben Phasenplanung oder rein politisch), und dann werden die Vorgangsdauern selbst so lange manipuliert – gekürzt, überlappt, ignoriert –, bis der Netzplan “zufällig” genau auf diesen Termin passt. Hier wird nicht gerechnet, sondern die Rechnung wird dem gewünschten Ergebnis angepasst. Das ist im Kern eine Verwechslung von Terminplanung und Terminwunsch-Bestätigung.
  • Problem des “Praktikerbegriffs Rückwärtsrechnung”: Weil der Begriff “Rückwärtsrechnung” tatsächlich ein etablierter, seriöser Fachbegriff aus der Netzplantechnik ist, kann sich die zweite (unseriöse) Praxis hinter der Terminologie der ersten (seriösen) Methode verstecken. Wer die Kürzung der Vorgangsdauern als “Rückwärtsterminierung” bezeichnet, suggeriert methodische Sauberkeit (“das machen wir doch immer so, das ist doch Standard-CPM”), obwohl der eigentliche Kernschritt – die ehrliche Vorwärtsrechnung auf Basis realistischer, von Fachleuten geschätzter Dauern – gerade übersprungen oder nachträglich überschrieben wird.
  • Man könnte es so zuspitzen: Echte Rückwärtsrechnung ist Erkenntnisgewinn (wo ist mein Puffer, wo ist mein kritischer Pfad), die Pseudo-Rückwärtsterminierung ist Erkenntnisverweigerung (ich will die unbequeme Wahrheit der Vorwärtsrechnung nicht hören und überschreibe sie).

Der kritische Pfad, der längste Weg durch das Projekt, ist naturgemäß die erste Anlaufstation für Optimierungen. Und zwar für ausgewählte Einzelvorgänge mit spezifischen, zum Vorgang passenden Maßnahmen wie Fast Tracking, effizientere Methoden oder Crashing bzw. mehr Ressourcen. Und in der Endkonsequenz: Durch unangenehme Diskussionen über das Streichen von Leistungen mit niedrigerer Priorität, wenn man den Termin noch halten möchte.

Stattdessen praktizieren viele Projektleiter reine Rückwärtsterminierung: Mit der Gießkanne werden von jedem Vorgang ein paar Tage abgezogen. Oder es werden willkürlich Deadlines ohne Realitätsbezug gesetzt. Dieses Verfahren hat viele Nachteile bzw. interessante Aspekte, die im folgenden besprochen werden:

  • Geringere Planungsqualität mit einer Gießkannenkürzung oder willkürliche Termine statt spezifische Einzeloptimierung. Das Problem dabei: Der Aufwand ist keine beliebig komprimierbare Größe. Wenn in einem Vorgang, den z.B. nur eine Ressource sinnvoll ausführen kann oder soll, 10 Personentage Arbeit drin stecken, dann wird er durch bloße Verkürzung auf dem Papier nicht in 6 Tagen fertig. Die Dokumentation lügt, die Realität lügt leider nie. Die bittere Realität zeigt sich nur später, mit oft weiteren und vermeidbaren negativen Konsequenzen.
  • Oft keine Diskussion über Streichen von Leistungen.
  • Unrealistische Termine
    • die zu Frust, Fatalismus und Zynismus im Projektteam führen
    • meist viel vermeidbaren Zusatzaufwand durch hektischen Aktionismus und Eskalationsmeetings angesichts absehbarer Terminprobleme
    • Vertrauensverlust des Auftraggebers in die Kompetenz der Projektleitung. Hier interessiert es in der Regel nicht, dass oft der Auftraggeber selbst durch mehr oder weniger verbindliche Termine das Chaos angerichtet hat. Nein, er wird den Projektleiter zur Verantwortung ziehen: “Sie sind doch der Profi. Sie müssen mich “challengen”. Warum haben Sie sich nicht mehr gewehrt. Ich habe doch nur - und das muss doch mein gutes Recht sein - einen ehrgeizigen Termin genannt, angesichts eines attraktiven Business Cases. Sie hätten mir einfach energischer widersprechen müssen, dafür bezahle doch gutes Geld für eine professionelle Projektleitung”.
  • Viele Projektleiter kennen sich mit Netzplanrechnen nicht aus und verstehen nicht, wie leistungsfähige Tools wie MS Project arbeiten. Weil diese Projektleiter nicht verstehen, dass man alle Vorgänge (inklusive der Meilensteine, die auch Vorgänge sind) für ein funktionierendes Netzplanrechnen miteinander verknüpfen muss, tun sie es nicht. Das Tool zeigt dann also entweder keinen realistischen kritischen Pfad. Oder er zeigt ihn eher durch Zufall, aber der Projektleiter ignoriert die Bedeutung. Und “optimiert” prompt nicht nur die kritischen Vorgänge mit Gießkanne oder unrealistischen Deadlines sondern auch die nicht kritischen Vorgänge. Statt vorhandene Puffer auszunutzen, wird unnötig Druck und Frust erzeugt. Und Managementaufmerksamkeit verschwendet. Und falsche Prioritäten, weil man die AP-Owner nicht gezielt bitten kann, bei z.B. Zusatzbelastung durch das Tagesgeschäft doch bitte nicht ausgerechnet bei den Projektarbeiten ohne Puffer (kritischer Pfad) das Engagement zurückzufahren sondern bei den Projektarbeiten mit Puffer.
  • Ein Termin, der nie fachlich geprüft bzw. validiert wurde, sollte keine Verpflichtung sein, sondern in Rücksprache mit dem Auftraggeber als eine Art Arbeitshypothese behandelt werden. Mit der Möglichkeit einer späteren Anpassung, sobald neue Erkenntnisse vorliegen. Bei internen Projekten ist es oft leichter, eine Anpassung des Projektauftrags nach der Detailplanung zu verabreden als bei einem Kundenauftragsprojekt mit Werkvertrag.
    • Auf jeden Fall sollte man mit dem Management verabreden, dass eine frühe Annahme oder Vermutung des Phasenplans nicht als unverrückbar ins Top-Management kommuniziert werden darf.
    • Es ist mir ein Rätsel, warum viele Projektleiter hier nicht energischer darauf beharren, die frühe Vermutung als wertvollen Beitrag zum gemeinsamen Brainstormen mit dem Auftraggeber zu erklären. Stattdessen müssen orientieren sie sich später mit deutlich besseren Detailwissen an dem unrealistischen Phasenplan, der in einem 5-Minutengespräch mit dem Auftraggeber gemeinsam an einem Whiteboard entstanden ist.
  • Man sollte immer bedenken, dass die meisten Projekt später besonders teuer sind, z.B. weil man einen Vertrag mit einer Unternehmensberatung hat und ein Kontingent teuer Berater eingekauft hat, die sich nicht so schnell skalieren lassen. Eine unrealistische Terminvorgabe verlagert das unvermeidliche Terminproblem dann oft ausgerechnet in die teuerste Projektphase.
  • Wie schon an anderer Stelle beschrieben, spart man sich die unangenehme, aber wertvolle Diskussionen über den inhaltliche Projektprioritäten. Es wird bis zuletzt am unrealistischen Termin festgehalten. Das magische Dreieck lässt sich aber nicht durch Willenskraft aushebeln, obwohl sich nach meiner Beobachtung viele Auftraggeber verhalten wie ein Kleinkind und sinnbildlich mit dem Fuß aufstampfen: “Ich will aber alles haben. Termin und versprochene Qualität und natürlich im Budget bleiben”. Wenn man sich durch eine professionelle Vorwärtsterminierung und anschließende Optimierung die Chance nimmt, eine gezielte Entscheidung zwischen Termin und Qualität bzw. ausgewählte und niedrig priorisierten Scopebestandteilen zu treffen, dann provoziert man damit neben Hektik, Frust und Vertrauensverlust oft einen - der knappen Zeit geschuldeten unkontrollierten Qualitätsverlust.
  • Auch Projektleiter wollen beruflich weiterkommen, das ist natürlich legitim. Eine wichtige Voraussetzung ist, dass sie fair miteinander vergleichen werden. Wenn aber immer die frühen Phasentermin als sakrosankt behandelt werden, werden gerade die Projekte und Projektleiter bestraft, die eine gründliche Auftragsklärung und eine seriöse Detailplanung gemacht haben. Wenn es nämlich egal ist, wenn später - basierend auf einer seriösen Detailplanung - eine Arbeitshypothese “Phasenplan” noch veränderbar erscheint, oder ob man ein Projekt chaotisch ohne seriöse Auftragsklärung und Detailplanung einfach mal begonnen hat, dann erscheint das alles andere als fair. Natürlich ist es auch bei so einer Praxis, eine grobe Phasenplanung als verbindlich zu definieren, trotzdem besser, mit einem realistischen Detailplan eine klare Orientierung und Leitplanke zu haben, sich an ihr zu orientieren und den Schmerz auf das notwendige Minimum zu reduzieren. Man darf sich aber als Organisation nichts vormachen: Die guten Projektleiter werden in solchen Strukturen nicht lange bleiben. Wer übrig bleibt, sind die Chaoten, mit denen man als Auftraggeber nicht viel Freude haben wird.
  • Kein seriöses Vorgehensmodell arbeitet mit “Aufwandskompression”, die es nicht geben kann. Selbst das Timeboxing agiler Vorgehensmodelle wie Scrum arbeitet mit einem variablen Scope. Da wird nicht künstlich der Aufwand - bei gleich bleibendem Scope - einfach klein gerechnet. Userstories, die nicht fertig geworden sind, wandern am Ende des Sprints ins Product Backlog.
  • Muss-Termine als Randbedingung im Netzplan: Um es klar zu sagen: Natürlich ist es legitim, fixe Termine unter bestimmten Voraussetzungen vorzugeben. Aber sie gehören dann in einen serös per Vorwärtsrechnung ermittelten Netzplan, damit dann durch Netzplanrechnen klar wird, wo ein negativer Puffer entsteht. Das ist dann eine ehrliche Diagnose (“wir haben ein Problem von x Tagen) und keine Manipulation von Daten. Nach der ehrlichen Vorwärtsrechnung: Erst wenn klar ist, dass der Wunschtermin nicht erreichbar ist, beginnt die gezielte Optimierung (Fast Tracking, Crashing, Scope-Diskussion) – auf Basis von Fakten, nicht unabhängig von den Fakten.

Verschiedene Anordnungsbeziehungen (AOB) und Zeitabstände für eine realistischere Ablauf- und Terminplanung nutzen

Normalfolge: Nachfolger kann erst beginnen, wenn Vorgänger abgeschlossen ist (z.B. 1. Etage erst nach Erdgeschoss)

Anfangsfolge: Nachfolger (Betonieren) kann beginnen, sobald Vorgänger begonnen hat (Anlieferung mehrerer Chargen Beton)

💡 Oft ist es nicht leicht, sich zwischen Normal- und Anfangsfolge zu entscheiden. Ich würde es immer davon abhängig machen, ob der Beginn des Nachfolgers eher vom Ende oder Start des Vorgängers getriggert wird. Selbst, wenn das manchmal nur ein Bauchgefühl ist.

Endfolge: Der Nachfolger kann erst enden, wenn der Vorgänger abgeschlossen ist. Beispiel: Nutzung altes Büro (N) kann erst enden, wenn Umzug in neues Büro (V) abgeschlossen ist. Die Endfolge bringt zum Ausdruck, dass die miteinander verknüpften Vorgänge zwar parallel durchgeführt werden können, aber nicht unabhängig voneinander beendet werden können. Das ist oft der Fall, wenn der Vorgänger eine Leistung statt des Nachfolgers erbringen soll.

Sprungfolge: Der Nachfolger kann erst enden, sobald der Vorgänger gestartet ist. Beispiel: Erst nach Start des Vorgängers (Einschalten neuer Server) darf der Nachfolger (Ausschalten alter Server) enden, damit man nicht ohne funktionierenden Server dasteht.

Positiver Zeitabstand, technische Wartezeit: Auf dem Bau kann der Nachfolger erst nach den Betonarbeiten (Vorgänger) starten, sobald der Beton getrocknet ist. Oder man muss auf eine Genehmigung warten.

⚠️ Bitte konsequent die Realität von Wartezeiten über die vorgesehene Methode abbilden und nicht - wie in der Praxis häufig zu besichtigen - über eine Verlängerung der Vorgänge. Etwas weniger problematisch, aber trotzdem abzulehnen ist die Darstellung der Wartezeiten mit einem eigenen Vorgangsbalken. Methodische Grundlegel: Vorgangsbalken repräsentieren immer Ressourcen (Personalmittel oder Sachmittel). Linien tun das nicht. In dem Moment, wo man als Projektleiter seinen Plan anderen Teammitglieder oder externen Dienstleister zeigt, muss man damit rechnen, dass sich der ein oder andere Ansprechpartner eine professionelle Toolschulung besucht hat. Insofern sollte man sich hier meiner Meinung nach immer an methodische Standards halten, um unnötige Missverständnisse zu vermeiden.

Negativer Zeitabstand: Solche Abstände können meines Erachtens zum Beispiel für Abschlussarbeiten des Vorgänger ohne sachliche Voraussetzung für Start des Nachfolgers gesetzt werden. Beispiel: Der Test (Nachfolger) eines entwickelten Moduls (Vorgänger) kann 2 Tage vor dem Ende des Vorgängers starten, weil dort die letzten beiden Tage mit Dokumentation verbracht werden. Die Dokumentation stellt aber keine sachlogische Voraussetzung für den Nachfolger dar.

Negative Zeitabstände ja oder nein: Ich habe mal einen etwas absurd wirkenden Projektmanagement-Blog über 5 Seiten gelesen, in dem sich Methodenpuristen erbitterte Debatten geliefert haben, ob ein negativer Zeitabstand denn methodisch erlaubt sei. Nur, weil MS Project und andere Tools diese technisch erlauben würden, sei das noch lange nicht methodisch geboten. Als Alternative wurden zusätzliche Meilensteine und der konsequente Verzicht auf negative Zeitabstände gefordert. Ich bin der Meinung, dass das zu puristisch ist und sehe die sporadische Nutzung negativer Zeitabstände entspannt. Eine Meilenstein-Inflation sehe ich allerdings sehr skeptisch: Damit Meilensteine sinnvoll gesteuert werden können, müssen sie näher beschrieben werden. Jeder, der schon mal versucht hat, im Wochenrhythmus Meilensteine - z.B. in einer Testphase - zu erreichen, weiß, dass das ein riesiger Projektmanagementaufwand ist. Von dieser - in der PM-Community oft formulierten Empfehlung - rat ich jedenfalls dringend ab.

Terminplanung: Vertiefung

Ausgewählte MS Project Tipps

💡 Wenn man den ursprünglichen Meilensteintermin als Information bei der Simulation behalten möchte, gibt es mehrere Möglichkeiten:

  • Eine beliebtes Vorgehen noch in der Planungsphase: Fixierung der kommunizierten MST-Termine über eine Spezialfunktion (z.B. Termin, Stichtag), die den Simulationsmodus nicht einschränkt.
  • Typisches Vorgehen in der Steuerungsphase: Die meisten Profi-Tools erlauben die Pflege eines Basisplans, gegen den der jeweils aktuelle Plan übersichtlich gespiegelt werden kann

Weitere ausgewählte Hinweise zur Toolnutzung:

  • Alle Vorgänge müssen vernetzt sein: Wenn auch nur ein Vorgang nicht vernetzt ist, funktioniert das Netzplanrechnen nicht mehr. Gerade bei größeren Plänen, die sich in Tools wie MS Project über mehrere Seiten erstrecken, verliert man schnell den Überblick und bemerkt unter Umständen gar nicht, dass sich aufgrund einer Verlängerung oder Verschiebung eines Vorgangs nicht - wie eigentlich gewünscht - die inhaltliche abhängigen Vorgänge und auch das Projektende im Simulationsmodus verschoben haben. Dieses erwünschte Verhalten der Störungs- oder Änderungssimulation ist nur gewährleistet, wenn die abhängigen Vorgänge im Tool auch im Plan hinterlegt werden.
  • Qualitätskontrolle in der Netzplanansicht: Bei vielen parallelen Vorgängen ist es in der normalen Ansicht oft schwer zu erkennen, ob man versehentlich eine Lücke eingebaut hat. Auch in der Vorgängerspalte ist diese Qualitätskontrolle nur schwer möglich. Deshalb ist meine Empfehlung, die oft vernachlässigte Netzplanansicht von Tools wie MS Project zu nutzen. Dort ist der Ablaufplan grafisch hinterlegt. Er ist in Tools wie Project zwar nicht geeignet, um eine grafische Simulation des Ablaufplans per Drag and Drop durchzuführen, davon rat ich ab. Aber was man sehr schnell erkennt: Sind irgendwelche Vorgänge noch nicht miteinander vernetzt.
  • Meilensteine in die Vernetzung einbeziehen: Jeder Vorgang hat immer mindestens einen Nachfolger und mindestens einen Vorgänger bis auf den Start-MST (kein Vorgänger) und den End-MST (kein Nachfolger). Vorgänge sollten zumindest mit dem nächsten Meilenstein verbunden werden, wenn sich kein konkretes Arbeitspaket anbietet. Dieser Meilenstein würde sich dann verschieben, wenn sich der Vorgänger zu weit verzögert, was im Sinne eines sauberen Phasenabschlusses ja auch sinnvoll ist. In vielen vernetzten Balkenplänen habe ich schon gesehen, dass die Meilensteine nicht in die Vernetzung einbezogen werden, dass ist ein methodischer Fehler.
  • Darstellung von steuernden Projektmanagementaktivitäten werden erst am Ende entsprechend der wertschöpfenden Aktivitäten zu reinen Informationszwecken visualisiert. Sie dürfen nicht auf dem kritischen Pfad liegen. Grund: Gegenüber dem Auftraggeber, der schon ungeduldig auf die Fertigstellung des Projektergebnisses für die Nutzungsphase wartet, kann man schlecht wie folgt argumentieren: „Lieber Auftraggeber, leider musst du noch zwei Wochen auf die Abnahme deines gewünschten Produktes warten. Es ist zwar bereits fertig, aber vor der eigentlichen Abnahme würde ich gerne noch diverse Projektmanagementaktivitäten (wie Statusbericht schreiben, Projektpläne aktualisieren usw.) hinter mich bringen“. So eine Aussage dürften nur die wenigsten Auftraggeber akzeptieren.
  • Es ist jedoch unter Umständen sinnvoll, ausgewählte PM-Vorgänge wie „initiieren, definieren und planen“ auf den kritischen Pfad zu legen. Das gilt vor allem dann, wenn darauf ein Meilenstein „Freigabe Projektplan“ folgt. So kann der AG besser darauf hingewiesen werden, welche Auswirkung eine verzögerte Entscheidungsfindung und verzögerte Freigabe des Projektplans und auch damit des Starts des Projekts auf das hochgerechnete Projektende haben.

Unterschiede zwischen Reserve und Puffer - kritischer Pfad vs. kritische Kette

Reserve versus Puffer Umgangssprachlich und bei Verwendung bestimmter Methoden, werden diese beiden Begriffe gerne gleichgesetzt. Insofern sollte man sicherheitshalber gerade im Umgang mit wichtigen Projektstakeholdern immer kurz erläutern, was man insbesondere mit dem Begriff “Puffer” überhaupt meint und wie er entstanden ist.

  • Puffer: Beim klassischen Netzplanrechnen (Critical Path Method) bedeutet Puffer im engeren Sinne, dass ein Planungstool wie MS Project über die hinterlegte Logik des Netzplanrechnens einen Terminspielraum erzeugt. Wenn man Starttermin, Vorgänge, Abhängigkeiten und Dauer hinterlegt und den ein oder anderen Vorgang parallelisiert, wird automatisch berechneter Puffer erzeugt, den man z.B. bei der Ressourcenplanung als Manövriermasse in Anspruch nehmen kann.
  • Reserve: Wenn ich mit meinem VW-Bus von München in die Bretagne fahre, weiß ich, dass ich zwei Reservekanister mitnehmen sollte, weil unter Umständen eine Tankfüllung nicht reicht und ich in der geplante Nachfahrt über unbekannte französische Landstraßen keine offenen Tankstellen finde. Das Setzen dieser Reserve ist ein bewusster Vorgang, sich gegenüber Risiken abzusichern und im Gegensatz zum Puffer nicht das rechnerische Ergebnis von Netzplanrechnen.
  • Critical Chain Projectmanagement: Diese “Reserve” wird in speziellen Methoden, die sich um den Umgang mit Engpassressourcen kümmern, auch Projektpuffer genannt. Dort stellt er das zentrale Sicherheitsnetz für den Terminplan dar und wird nach einem bestimmten Praktikerverfahren rechnerisch zwar erzeugt. Aber der Ursprung des “Puffers” stammt aus der Entnahme von Vorgangspuffern zugunsten einer aggressiv gesetzten realistischen Dauer mit zum Beispiel 50% Wahrscheinlichkeit. Die zuvor individuell in den Vorgängen versteckten Sicherheitsreserven werden bewusst entfern und an bestimmten Stellen - zum Beispiel am Ende der sogenannten Critical Chain - als Projektpuffer über ein rechnerisches Verfahren gesetzt. Der Projektpuffer ist hier also nicht das rechnerische Ergebnis von Netzplanrechnen, sondern im wesentlichen das Ergebnis einer bewussten Management-Entscheidung, Sicherheiten zu bündeln statt sie dezentral zu verstecken.
  • CPM (Critical Path Methode) ist ein deterministisches, geschlossenes Rechensystem. CCPM (Critical Chain Project Management) beschäftigt sich mit dem “Management der kritischen Kette” ist ein verhaltensorientierter Managementansatz, der:
    • Parkinsons Gesetz (Arbeit dehnt sich entsprechend der komplett verfügbaren Zeit aus, auch wenn man früher fertig werden könnte durch Perfektionieren, Zeit “ausschöpfen”, keinen frühen Abschluss melden wollen)
    • Studentensyndrom (Die Arbeit wird erst kurz vor dem Abgabetermin begonnen, es erfolgt eine Prokrastination, bis der Zeitdruck hoch genug ist. Es erfolgt also ein später Start trotz verfügbarer Zeit.
    • Multitasking-Effekte explizit adressiert. Das ist konzeptionell ein völlig anderes Verständnis von „Puffer“.
  • **Die Unterschiede und Gemeinsamkeiten von kritischem Pfad und kritischer Kette sind aus meiner Sicht nicht sehr groß und hängen davon ab, wie stark man schon konkrete Ressourcenverfügbarkeiten berücksichtigt:
    • Klassischer kritischer Pfad (CPM): Rein zeitlich-logisch Betrachtung des längsten Wegs durch das Projekt. Im Hinterkopf hat man ggf. noch nicht vereinbarten und konkret benannten Ressourcen sondern erst eine “normale” Ressourcenanzahl, mit der man die betroffenen Vorgänge bearbeiten kann. Umgangssprachlich wird m.E. kaum unterschieden, wo weit die Ressourcenplanung schon vorangeschritten ist: Bei MS Project z.B. werden ja im Fortgeschrittenenmodus Ressourcen in einem Ressourcenpool abgebildet und den Vorgängen zugeordnet. Trotzdem spricht man hier meist von “kritischem Pfad”.
    • Kritische Kette (CCPM): Das ist nach meiner Interpretation der längste Weg durch das Projekt immer nach Berücksichtigung der Ressourcenverfügbarkeit. Auf klassischen kritischen Pfaden arbeiten allerdings nicht unbedingt immer nur “Engpass-Ressourcen” nach CCPM oder dem Lean-Management. Um sich etwas näher mit dieser Frage zu beschäftigen, empfehle ich, etwas tiefer in die einschlägige Fachliteratur einzusteigen.
    • Wenn man “Engpass-Ressource” anders definiert (z.B. “prinzipiell knapp in der gesamten Organisation” oder “teuer und stark nachgefragt”), dann könnten aktuelle Tools wie MS Project diese Definition meines Erachtens aktuell nicht im Netzplanrechnen operationalisieren. Ich würde beim Einsatz von MS Project im betroffenen Projekt den Engpass wie folgt definieren: Ein Engpass ist eine Ressource, die im konkreten Projekt den kritischen Pfad verlängert. Und nicht eine Ressource, die in der gesamten Organisation knapp ist. Schließlich könnte ein Vorgang auf dem kritischen Pfad unter Umständen nur deshalb länger dauern, weil das Projekt niedriger priorisiert ist und von einer - grundsätzlich gut verfügbaren - Ressource nur eine niedrige Einsatzzeit bekommt. Goldratt definiert für seinen CCPM-Ansatz einen Engpass nach meiner Interpretation ein eher organisationsbezogen, was mit dem klassischen projektbezogenen Netzplanrechnen nicht ohne weiteres kompatibel ist. Die organisationsbezogene Engpass-Definition ist aus meiner Sicht eher für strategisches Ressourcenmanagement oder Multi-Projektsteuerung interessant. Aber das mögen eingefleischte Experten des CCPM-Ansatzes anders sehen.