24
Jul 2015
Meilenstein – Der Projektmanagement-Blog

Terminplanung? Selten beobachtet

Stellen Sie sich mal vor: Sie wollen sich eine Wohnung kaufen. Sie haben auch eine gefunden, die Ihnen gefällt und treten in Verhandlungen mit dem Verkäufer. Leider wissen Sie nicht, wie groß Ihr Eigenkapital ist, und deshalb auch nicht, ob Sie sich die Wohnung leisten können. – Undenkbar?

Anzeige

Oder dieses Beispiel: Der Vertrieb verhandelt mit dem Kunden den Preis für ein Produkt, das speziell für diesen Kunden hergestellt werden soll. Leider hat der Vertrieb keine Ahnung von den Herstellungskosten. Deshalb ist völlig offen, ob der endgültige Preis einen Gewinn oder wenigstens einen Deckungsbeitrag oder sogar einen Verlust bedeutet. – Gibt’s nicht?

Basisqualifikation Netzplan

Als ich mich erstmals professionell mit Projektmanagement befasste, da war die Standardfrage an den Kandidaten bei einem Einstellungsgespräch: "Haben Sie schon mal einen Netzplan erstellt?" Hatte man das mal in einer Übung getan, konnte man die Frage bejahen, ohne zu lügen, und hatte damit seine Qualifikation bewiesen; denn man wurde nie gefragt, wie gut der Plan gewesen sei oder ob die Umsetzung funktioniert habe.

Netzplantechnik war sozusagen die Basisqualifikation für Projektmanager. Ich hatte es damals so gelernt, wie es auch heute noch im PMBOK Guide (5th Ed.) steht:

  • Definiere Vorgänge
  • Lege Reihenfolge und Abhängigkeiten fest
  • Schätze die benötigten Ressourcen
  • Schätze die Vorgangsdauer
  • Entwickle den Terminplan

Von Anfang an habe ich dieses Vorgehen als lückenhaft empfunden. Auch heute findet man es noch so in Büchern und Seminaren, und es ist erstaunlich, dass man den sechzigjährigen Umgang mit diesem Kernthema des Projektmanagements so auf den Punkt bringen kann:

Der Weg zur Berechnung des kritischen Pfads hat mit Planung nichts zu tun.

Es ist Strukturierung, Datenerfassung (im besten Fall) und die Anwendung des kleinen "1+1" (man braucht nicht einmal das "Einmaleins"). Die Planung beginnt erst danach.

Vor kurzem bin ich erstmalig auf einen Artikel gestoßen, der das sehr schön präzisiert (das heißt nicht, dass dies der erste Artikel zum Thema ist; nur der erste, über den ich gestolpert bin). Sinnigerweise stammt er von einem Mann, der maßgeblich am PMBoK Guide, 1st Ed., beteiligt war: William R. Duncan (Duncan; Devaux: Scheduling Is a Drag, January 15, 2009, Projectsatwork.com).

Seine erste Kernaussage ist: Berechne den kritischen Pfad erst ohne und dann mit Einschränkungen (wie z.B. Ressourcenverfügbarkeit); die Differenz (in Zeit und Geld) zeigt Dir, was diese Einschränkungen kosten.

Die zweite Kernaussage ist: Konzentriere Dich nicht auf die Einhaltung aller Pfade, sondern versuche den kritischen Pfad zu reduzieren und mache dazu eine Kosten-Nutzen-Analyse. Und erst daraus entsteht m.E. ein Plan.

Worüber verhandeln?

Aber angesichts der Tatsache, dass alle Projekte unter Zeitdruck stehen und der Kunde gelegentlich unerfüllbare Wünsche hat, geht es meiner Meinung nach zuerst nicht um Optimierung, sondern um Ermöglichung:

Sie übernehmen einen Projektauftrag von einem Kunden, der eine klar formulierte Vorstellung vom Sachziel hat. Damit lässt sich der Projektumfang eindeutig ermitteln. Der Kunde nennt seine Wunschvorstellung bzgl. Kosten und Terminen. Sie gehen in der Planung nach PMBOK Guide vor (s.o.). Das Ergebnis: Sie können voraussichtlich die Kostenziele, aber nicht die Terminziele erreichen und müssen deshalb mit dem Kunden in Verhandlungen treten. Aber worüber verhandeln Sie?

Das können Sie nur wissen, wenn Sie zuerst das Projekt ohne jegliche Einschränkung, nur nach der Sachlogik, kalkuliert haben. So bekommen Sie den Best Case. Und ohne den kennen Sie den Verhandlungsspielraum nicht.

Folgende Szenarien sind möglich:

  • Der Wunschtermin des Kunden liegt noch vor dem berechneten Endtermin des Best Case. Dann brauchen Sie erst gar keine Ressourcenplanung durchzuführen oder sonstige Einschränkungen zu berücksichtigen. Sie müssen sofort die Ziele neu verhandeln.
  • Der Wunschtermin liegt weit hinter dem Best-Case-Endtermin. Dann berechnen Sie den realistischen Projekt-Netzplan unter Berücksichtigung der Ressourcenverfügbarkeit und anderer Einschränkungen und stellen fest, dass auch der daraus resultierende Endtermin, der sich aus der Länge des kritischen Pfads ergibt, noch vor dem Wunschtermin erreicht werden kann. Dann erübrigen sich weitere Verhandlungen.
  • Der Wunschtermin liegt zwischen dem Best-Case-Endtermin und dem realistischen Endtermin. Und jetzt erst beginnt die Planung: Sie suchen nach Möglichkeiten, den kritischen Pfad zu verkürzen (zusätzliche Ressourcen, Zukauf von externen Teilprodukten oder Leistungen, grundsätzlich andere Lösungskonzepte etc.) und sich auf diese Weise dem Best Case anzunähern. Sie berechnen die Extrakosten und diskutieren mit dem Auftraggeber das Kosten-Nutzen-Verhältnis: Was ist die Einhaltung des Wunschtermins wert bzw. die Reduzierung des Risikos einer Terminüberschreitung? Nur wenn man den Best Case kennt, sieht man, ob sich der Versuch der Optimierung überhaupt lohnt; und je mehr man sich dem Best Case annähern will, desto drastischer werden i.d.R. auch die Aufwände zur Überwindung der Einschränkungen und damit die Zusatzkosten steigen.

Ein simples Beispiel (nach Duncan und Devaux): Man müsste in einem Entwicklungsprojekt eine Million Euro mehr in die Hand nehmen, um den kritischen Pfad um drei Monate zu verkürzen. Jeder Monat, um den man den Markteintritt vorverlegt, bringt einen Zusatzgewinn von einer halben Million Euro. Wer würde da nicht einer Nachbudgetierung zustimmen?

Die Voraussetzung für diese Art von Planung ist eine saubere und von allen Beteiligten ernstgenommene Arbeit mit der Netzplantechnik und die Entwicklung von Best-/Realistic-/Worst-Case-Szenarien, damit man seine Planungsspielräume überhaupt kennenlernt. Und da scheint es, nicht nur nach den Beobachtungen von Duncan und Devaux, in der Praxis noch viel Verbesserungspotential zu geben.

Bisher gibt es 2 Kommentare
Hallo Herr Plagge,
ich kann Ihrer Aussage im letzten Satz zustimmen. Bezüglich der Argumentation erhebe ich jedoch Widerspruch. Wenn man nur die Abfolge der Einzel-Prozesse Erstellung des Terminplanes aus der Komplexität des Terminmanagements des Gesamtprojektes als losgelöste Einzelmaßnahme durchführt, kann wirklich nur die von Ihnen beschriebene Unvollständigkeit heraus kommen. Möglicherweise ist diese unvollständige Anwendung des Methodenkanons PMI auch ein Grund dafür, dass vielfach Terminpläne in der Projektrealisierung aus dem Ruder laufen.
Meines Erachtens nach sind die Prozesse der Wissensgebiete Termine, Kosten, Ressourcen, Qualitäten und Risikobewältigung zunächst nacheinander abzuarbeiten, aber erst in der Integration der jeweiligen Teilergebnisse lässt sich schlussendlich ein umsetzbarer Terminplan in Übereinstimmung mit den anderen Projektplänen erstellen. Nicht umsonst ist der 5. Prozessschritt mit Entwicklung des Terminplanes bezeichnet - sonst würde man es wohl berechnen, zeichnen oder darstellen nennen müssen.
Bei Änderungswünschen des Kunden kann man dann selbstverständlich nicht nur in einem Plan die Veränderung "einzeichne" und die absoluten Schlussfolgerungen ziehen. Hier ist ebenfalls eine integrative Gesamtbetrachtung über die Auswirkungen in allen Einzelplänen des Projektmanagementplanes erforderlich.
Auch deshalb ist in der DIN 69001 das Management als Gesamtheit aller Führungsaufgaben ... und nicht nur als Abruf und Addition der Ergebnisse aus den vielfältigen Teilaufgaben beschrieben.
Die Szenarien-Betrachtung ist auf jeden Fall notwendig, aber bitte nicht losgelöst nur unter Terminauswirkungen, sondern auch ganzheitlich - wie im Business Case.
vor 1 Jahr 18 Wochen Dipl.-Ing. Wolfgang Merten
Danke für Ihren Kommentar, Herr Merten. Sie rennen damit bei mir offene Türen ein.
Natürlich geben alle Standards und Normen diese integrative Gesamtplanung her; sie fordern sie sogar. Nur leider beschreiben sie nicht, wie man das macht. Gerade beim PMBoK, das ja extrem prozessorientiert aufgebaut ist, fehlt diese Beschreibung, wie dargestellt.
Ich glaube übrigens nicht, dass dieses Fehlen der Grund für die schlechte Umsetzung in der Praxis ist. Das würde ja bedeuten, dass die Praktiker sich in anderen Fällen tatsächlich an den Standards entlanghangeln, und das habe ich persönlich n o c h n i e erlebt (was nicht heißt, dass es keine Praktiker gibt, die das tun). Der Grund ist eher, dass es auf der PM-Weltkarte noch viele weiße Flecken gibt, wo Projektmanagement noch gar nicht als M a n a g e m e n t-Aufgabe gesehen wird, sondern als eine Art Zuliefer-Dienstleistung für die Wunscherfüllung der Stakeholder.
PM als Management-Disziplin kann man vielleicht auch beschreiben als die Aufgabe, mehrere realistische Optionen zu schaffen und die beste davon auszuwählen und zu realisieren. Betrachte ich die Großprojekte, die ich nur aus den Medien (auch Fachzeitschriften) kenne und die gern die Namen deutscher Großstädte tragen (Hamburg, Berlin, Stuttgart), gewinne ich dann den Eindruck, dass dort so gearbeitet wurde? Hm ...
Ich selber spreche viel mit Projektleitern und -mitarbeitern aus kleinen, mittleren und teils auch großen Projekten. In - und das ist jetzt sehr grob, aber dafür großzügig geschätzt - 10% davon findet in der Frühphase eine ganzheitliche Planung incl. Optionen statt, was Scope und Cost betrifft. Aber wie oft habe ich persönlich schon gehört, dass Terminpläne so gemacht wurden, wie von Duncan und Devaux beschrieben? Und da kann ich mich problemlos aus dem Fenster lehnen:
N o c h n i e ...
vor 1 Jahr 18 Wochen Walter Plagge
Wählen Sie hier Ihre bevorzugte Anzeigeart für Kommentare aus und klicken Sie auf „Einstellungen speichern“ um die Änderungen zu übernehmen.
Kommentar verfassen
Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
Bitte geben Sie Ihren Namen an: *
Tech Link