Projektplanung mit Hilfe der

Program Evaluation and Review Technique

Eine kritische Betrachtung am Beispiel des Polaris-Projekts

Michael Wendt4. Dezember 2008

Seminar "Das virtuelle Labor" Wintersemester 2008 / 2009

Otto-von-Guericke-Universität MagdeburgFakultät für Informatik

Abstract

Die Program Evaluation and Review Technique ist eine ereignisorientierte Netzplantechnik. Als solche soll sie helfen, Projektabläufe zu analysieren, optimieren und grafisch darzustellen.Im Laufe dieser Arbeit sollen zunächst die Grundlagen der Netzplantechnik erarbeitet werden. Darauf aufbauend werden Ideen vorgestellt, die die Program Evaluation and Review Technique auszeichnen, und diese in das allgemeine Modell der Netzplantechnik eingewebt.Schließlich wird die Theorie an einem praktischen Beispiel dargestellt; der Entwicklung der Polaris-Raketen, strategische Mittelstreckenraketen für U-Boote.Dieses Projekt konnte 2 Jahre früher als erwartet dank eines sehr guten Managements trotz immens schwieriger Umstände fertiggestellt werden. Diese Tatsache soll zugleich auch als Motivation bei der Entwicklung der Netzplantechnik dienen und anhand des praktischen Nutzens für die Projektplanung wird die Technik schließlich auch kritisch bewertet. Allerdings sieht das Ergebnis nicht so positiv aus, wie anfangs noch erwartet.

Inhaltsverzeichnis:

1. Einführung und Motivation

1. Projektmanagement2. Zeit-/Kostenschätzungen

2. Netzplantechnik

1. Grundbegriffe2. Entwurf und Zeitanalyse3. Methode des kritischen Pfads4. Vorteile und Nachteile der CPM

3. Program Evaluation and Review Technique

1. Grundbegriffe2. Dreizeitenschätzung3. Implementierung von PERT

4. Das Polaris-Projekt 1. Entwicklung von PERT2. Das Polaris-Projekt und PERT im Jahr 19603. Weiterentwicklung von PERT im Verteidungsministerium

5. Kritik und Ausblick

1. Schwächen von PERT2. Abschließender Kommentar

Quellen

Anhang

1. Einführung und Motivation [GA04]Eine der größten intellektuellen Erfolge der modernen Welt ist die Transformation des Risikos. Wo unsichere Ereignisse in vergangener Zeit noch vom Schicksal vorherbestimmt waren, können sie heute mit Wissenschaft im voraus analysiert werden.

In einer Zeit, als die Menschheit noch von Okkultem und Übernatürlichem gelenkt wurde, glaubte man daran, nur außerordentliche Dinge vollbringen zu können, wenn die Chancen äußerst schlecht für das Gelingen des Vorhaben standen. Je höher das Risiko, desto größer der Erfolg. Habe man in diesem Fall doch die Gunst der Götter auf seiner Seite.

1.1 Projekte und deren Management

Heute, in einer Zeit der Wissenschaft, sieht es genau anders herum aus und es wird versucht jedes Risiko zu vermeiden, dass einem Projekt im Weg stehen könnte.

Leider sind Projekte, also komplexe, einmalige Prozesse, die einen festen Start- und Endpunkt haben und durchgeführt werden, um unter Berücksichtigung von Zwängen bezüglich Zeit, Kosten und Ressourcen ein Ziel zu erreichen, das spezifische Anforderungen erfüllt, schon nach ihrer Definition risikoreich und voller Unsicherheiten, denn wie will man etwas, dass einzigartig ist und erst noch stattfinden muss, einschätzen und planen können.

Will man ein Projekt managen, es also führen, koordinieren, steuern und kontrollieren können, muss versucht werden, eine Risikoabschätzung durchzuführen und dies von Projektanfang bis -ende. Das bedeutet, dass man sich immer folgende Fragen stellen muss:

Bleibt das Projekt im Zeitplan? Übersteigt es die vorgegebenen Kosten nicht? Sind die Ergebnisse zufriedenstellend?

Sollten alle oder auch nur eine Frage verneint werden müssen, sind sofortige Gegenmaßnahmen einzuleiten.

Es muss also stets darauf geachtet werden, wie groß die Unsicherheiten sind, mit denen man es zu tun hat und was sie für Auswirkungen haben könnten.

1.2 Zeit-/Kostenschätzungen [VISO]

Projektplanung basiert also immer auf Prognosen, nicht auf Tatsachen.

Eine der wichtigsten und gleichzeitig undankbarsten Aufgaben der Projektplanung ist das Einschätzen der Kosten sowie der Zeit, die nötig ist, das Projekt erfolgreich zu beenden.

Wenn nun also der Projektmanager fragt, wie lange es denn wohl dauert, eine bestimmte Teilaufgabe zu erledigen, wie sollte ihm dann geantwortet werden?

Ist man mit dem Schätzen noch nicht so sehr vertraut, gibt man meist eine zu optimistische Antwort, da längst nicht alle Hindernisse im Verlauf des Vorgangs berücksichtigt werden.Bleibt man dagegen zu pessimistisch und gibt sich zu viel Zeit, so sagt Parkinsons Gesetz, wird der Vorgang trotzdem genau die Zeit einnehmen, die ihr zugesprochen wurde, was äußerst ineffizient ist.

Mitte der 50er Jahre leitete Vizeadmiral William F. Raborn, das Polaris Special Project Office (SPO), Abteilung des Verteidigungsministeriums (Department of Defense / DoD) der Vereinigten Staaten. Das Polaris Projekt war eine direkte Antwort auf den Sputnikschock (die Sowjetunion bewies mit dem Start des ersten künstlichen Erdsatelliten Sputnik 1, dass sie technologisch den USA überlegen oder mindestens ebenbürtig waren), man war also äußerst bestrebt, das Projekt so schnell wie möglich zum Ziel zu bringen.

Also setzte der Vizeadmiral seine Leute darauf an herauszufinden, welche Projektmanagementtechniken es gibt, um technologische komplexe Projekte zu planen und zu leiten.Sie fanden wenig.

Als Folge setzten sie sich zusammen und schon einige Wochen später hatten sie selber eine Netzplantechnik entwickelt, die es ihnen ermöglicht haben soll, das Projekt 2 Jahre früher fertig stellen zu können (45% eher als erwartet!).

Aber bevor zu viel vorgegriffen wird, soll erst einmal erklärt werden, was eigentlich eine Netzplantechnik ist.

2. NetzplantechnikMithilfe der Netzplantechnik sollen die aufgeworfenen Fragen der Risikoabschätzung beantwortet werden können.

2.1. Grundbegriffe [NETC]

Um mit dem Netzplan eine übersichtliche Darstellung des Projekts und dessen Verlauf haben zu können ist es natürlich notwendig, bestimmte Begriffe exakt zu definieren.

„Ein Vorgang ist ein Ablaufelement, das ein bestimmtes Geschehen beschreibt.“ Es handelt sich dabei also um eine abgegrenzte Arbeitseinheit, die zu einem bestimmten Zeitpunkt begonnen und beendet wird.Damit hat der Vorgang eine sehr wichtige Eigenschaft; die Dauer. Unter Berücksichtigung der Dauer und der Abhängigkeiten der einzelnen Vorgänge kann nun mithilfe der Netzplantechnik herausgefunden werden, „wann“ die jeweiligen Vorgänge stattfinden.

Die Pufferzeit ist der zeitliche Spielraum, den ein Vorgang für seine Ausführung hat. Mit den nötigen Zeitreserven kann der Vorgang zeitlich verschoben oder aber sogar seine Dauer verlängert werden, ohne dass es Auswirkungen auf andere Prozesse des Projekts hat.Es gibt verschiedene Pufferarten, interessieren soll hier aber nur der Gesamtpuffer. Dieser beschreibt die Zeitspanne, die ein Vorgang gegenüber seinem frühsten Beginn verschoben werden kann, ohne das Projektende zu gefährden.Wenn der Gesamtpuffer 0 beträgt, handelt es sich um einen kritischen Vorgang.

Die Verkettung derjenigen Vorgänge, bei deren zeitliche Änderung der Endtermin des Netzplans verschoben wird, nennt man kritischen Pfad. Im Netzplan ist es die Kette von Vorgängen, welche in der Summe die längste Dauer vorweisen.Da diese Vorgänge für die Gesamtdauer des Projekts verantwortlich sind, können alle anderen Vorgänge verschoben oder verlängert werden. Anders ausgedrückt handelt es sich bei den Vorgängen des kritischen Pfads um kritische Vorgänge.

Es sei angemerkt, dass kritische Vorgänge nicht zwangsweise auf dem kritischen Pfad liegen müssen. Auch außerhalb dieser Kette kann es Vorgänge mit einem Gesamtpuffer von 0 geben. Das soll in dieser oberflächlichen Betrachtung von Netzplantechniken aber nicht weiter interessieren.

Ein Ereignis ist das Eintreten eines definierten Zustands. Dieser Zustand ist der Zeitpunkt, in welchem Vorgänge beendet worden sind oder beginnen sollen.Dies bedeutet, dass am Anfang und am Ende eines Vorgangs Ereignisse stehe. Die Ereignisse selber haben keine zeitliche Ausdehnung.

Die logische Beziehungen zwischen Ereignissen und Vorgängen werden Anordnungsbeziehungen genannt. Diese herzustellen ist die schwierigste und wichtigste Aufgabe beim Erstellen eines Netzplans.

Die Gesamtheit der Anordnungsbeziehungen stellt die Ablaufstruktur dar.

2.2 Entwurf und Zeitanalyse [GA04]

Das Erstellen eines Netzplans für ein Projekt erfolgt in 2 Schritten.

Im Entwurf wird die Aufgabe in Ereignisse und Vorgänge unter Berücksichtigung kausaler und logischer Zusammenhänge zerlegt. Wie schon erwähnt ist dies der wichtigste und schwierigste Schritt, denn die Zerlegung ist grundlegend und sinngebend für das Projekt.

Nachdem die einzelnen Vorgänge und Ereignisse bestimmt wurden, erfolgen in der Zeitanalyse Schätzungen oder Berechnungen der Dauer der Vorgänge.

Im weiteren Verlauf des Projekts muss natürlich mithilfe des erstellten Netzplans der Projektfortschritt überwacht und gegebenenfalls der Netzplan korrigiert werden.

2.3 Methode des kritischen Pfads [NETC]

Zwar wurden bereits die nötigen Begriffe für einen Netzplan definiert, nicht aber ihre grafische Darstellung.

Als Beispiel für einen Netzplan soll die Methode des kritischen Pfads (CPM) genommen werden. Diese wurde 1956 von amerikanischen Chemiekonzern DuPont entwickelt und ist aufgrund ihrer leichten Verständlichkeit gut zum Veranschaulichen geeignet. Sie ist dafür gedacht, komplexe Projekte übersichtlich darzustellen, die Dauer des ganzen Projekts vorherzusagen und den kritischen Pfad herauszustellen.

Sie baut auf den Grundlagen der Netzplantechnik auf, die oben genannt wurden. Dazu soll vorgegeben werden, dass Vorgänge als Knoten eines Graphen und Ereignisse als gerichtete Kanten, die die Ereignisse miteinander in Beziehung setzen, dargestellt werden.

Diese Darstellungsweise wird Activity on Node (AON) genannt. Viele Projektplaner bevorzugen allerdings ihren Graphen nach einer Activity on Arc-Vorgehensweise zu zeichnen. Die Netzplantechnik, die im nächsten Kapitel in den Vordergrund rückt, stellt ihre Vorgänge ebenfalls mit gerichteten Kanten dar, während die Ereignisse Knoten sind. Da die CPM aber eigentlich als AON konzipiert wurde, soll diese Darstellung für dieses einführende Beispiel auch genutzt werden.

Abbildung 1: CPM-Netzplan – Der kritische Pfad ist rot dargestellt

Das Projekt wurde in 6 Vorgänge unterteilt. Die folgende Tabelle der Anordnungsbeziehungen benennt die Vorgänge, gibt die Dauer an und stellt sie mit den anderen Vorgängen in Beziehung:

Vorgang A B C D E FVorangegan-gener Vorgang A A B C

Dauer 3 Tage 4 Tage 1 Tag 2 Tage 2 Tage 3 Tage

Tabelle 1: Beispiel für einen CPM-Graphen

Mit vorangegangenem Vorgang wird der Knoten bezeichnet, dessen Kante auf den eigentlichen Vorgang zeigt. Natürlich könnten das auch mehrere sein.

Das Zeichnen des Graphen mit den Daten, die aus dem Entwurf und der Zeitanalyse hervorgegangen sind, ist trivial. Der Übersicht wegen bekommen Knoten, die nach der Tabelle keine ausgehende Kante haben, eine Verbindungskante zum Endknoten und Vorgänge, die noch keine eingehende Kante haben, werden mit dem Startknoten verbunden.

Die Start- und Endknoten sind keine Vorgänge im eigentlichen Sinn. Sie sollen bloß den Anfang und das Ende des Projekts deutlich kennzeichnen und besitzen damit auch keine Dauer.

CPM ist ein deterministisches Modell. Das bedeutet, dass Zeitschwankungen nicht berücksichtigt werden. Demzufolge wird auch nur eine Zahl als Schätzung der Dauer angegeben.

Die Verkettung der Vorgänge A, C und F bildet den kritischen Pfad. Insgesamt wird das Projekt wahrscheinlich 7 Tage dauern. D hat einen Gesamtpuffer von 2 Tagen, B und E gemeinsam einen von einem Tag. Diesen Zeitraum können diese Vorgänge länger andauern, ohne dass die Projektdauer darunter leiden muss. A, C und F allerdings sind kritische Vorgänge und bedürfen besonderer Aufsicht.

2.4 Vorteile und Nachteile der CPM [NETC]

Das Projektplanen mithilfe einer Netzplantechnik bietet viele wichtige Vorteile, weswegen diese Technik bei großen und komplexen Projekte gar nicht wegzudenken ist.

Das Erstellen eines Netzplans zwingt zum exakten Durchdenken des Projektablaufs. Die übersichtliche Darstellung der Abhängigkeiten hebt Projektengpässe hervor, gibt die Möglichkeit zur Minimierung der Projektdauer und erhöht die Sicherheit in der Termineinhaltung. Im weiteren Projektverlauf können rechtzeitig mögliche Verzögerungen erkannt werden.

Die CPM wurde speziell für komplexe Projekte entwickelt, welche aber keine größeren Unsicherheiten vorweisen und routiniert ablaufen sollten.Ein entscheidender Nachteil bei der CPM ist, dass bei den Vorgängen von festen Zeitintervallen ausgegangen wird. Diese Schätzungen erleichtern zwar das Arbeiten mit dieser deterministischen Methode, da sie leicht verständlich ist, berücksichtigt aber keine Zeitschwankungen oder Unsicherheiten, welche aber einen großen Effekt auf den zeitlichen Ausgang des Projekts haben können.

Nun sind es aber gerade jene Projekte, bei denen diese Schwierigkeiten auftreten, auf welchen der Fokus dieser Arbeit liegen soll.Es soll nun also versucht werden, das bisher entworfene Graphenmodell so anzupassen, dass der Faktor Zeit als wichtigste Komponente und gerade zeitlich schwer einzuschätzende Vorgänge besonders berücksichtigt werden sollen.

3. Program Evaluation and Review TechniqueWie schon erwähnt ist Zeit in einem Projekt oft wesentlich wichtiger als die Kosten. Gerade bei Projekten aus der Forschung und Entwicklung ist es sehr schwer vorauszusagen, wie lange verschiedene Vorgänge wohl bis zu ihrer Beendigung benötigen werden, da diese oft zum ersten Mal in Angriff genommen werden müssen und so noch keine Daten darüber vorhanden sind.

Genau das traf auch auf das Polaris-Projekt zu. Die Technik, die unter der Leitung von Vizeadmiral Raborn entwickelt wurde, soll nun in den Fokus gestellt werden.

Die Program Evaluation and Review Technique (PERT) wurde für große und komplexe Projekte konzipiert, bei denen man von vielen Vorgängen nicht den genauen zeitlichen Verlauf vorhersagen kann. Es handelt sich dabei um eine ereignisorientierte Netzplantechnik.

3.1 Grundbegriffe [NETP]

An dieser Stelle sollen noch einmal die Begriffe Ereignis und Vorgang im Bezug auf PERT definiert werden, um noch einmal deutlich zu machen, wie sie mit den Ressourcen und der Zeit in Beziehung stehen. Auf den kritischen Pfad und die kritische Aktivität wird verzichtet. Es gelten die Definition aus dem letzten Kapitel.

Ein PERT-Ereignis ist ein Punkt, der den Anfang oder die Fertigstellung einer oder mehrerer Aufgaben markiert. Es sei hervorgehoben, dass ein Ereignis keine Zeit verbraucht und keine Ressourcen benötigt.Bevor nicht alle Vorgänge beendet wurden, die dem Ereignis vorhergehen, kann dieses nicht statt finden.

Ein PERT-Vorgang beschreibt die eigentliche Umsetzung einer Aufgabe.Im Gegensatz zu einem Ereignis verbraucht ein Vorgang Zeit und benötigt Ressourcen. Bevor er anfangen kann, muss das Ereignis, welches ihm vorausgeht, eingetreten sein.Man kann sich den Vorgang als Repräsentation der Dauer, des Aufwands und der benötigten Ressourcen vorstellen, die nötig sind, um von einem Ereignis zum nachfolgendem zu gelangen.

3.2 Dreizeitenschätzung [VISO]

Eine der besonderen Eigenschaften von PERT ist der Umgang mit der Zeit. Statt einen skalaren Wertes für die Zeit zu schätzen wird von einer Wahrscheinlichkeitsverteilung ausgegangen. Jedem Vorgang liegen 3 Zeitschätzungen zu Grunde.

Die optimistische Dauer (O) beschreibt den kürzesten Zeitraum, in dem der Vorgang erfolgreich beendet werden kann, indem angenommen wird, dass alles besser läuft als erwartet. Die Wahrscheinlichkeit, dass dies eintritt, beträgt allerdings nur etwa 1%.

Die pessimistische Dauer (P) ist genauso unwahrscheinlich und beschreibt den längsten Zeitraum, den der Vorgang beanspruchen könnte. Hier wird angenommen, dass alles nicht nach Plan verläuft (ohne allerdings wirklich große Katastrophen zu berücksichtigen).

Die realistische Dauer (M) nimmt an, dass alles normal verläuft. Sie wird nach „bestem Wissen“ geschätzt.

Die erwartete Dauer (E) berechnet sich nun nach der folgenden Formel:

E=O4∗M P6

Es stellt sich die Frage, woher die „4“ in dieser Formel kommt. Dabei handelt es sich allerdings bloß um eine Festlegung, die auf Annahmen beruht, die dem PERT-Modell zu Grunde liegen.

Bei dieser Wahrscheinlichkeitsverteilung wird von einer Beta-Verteilung ausgegangen. Die mathematischen Grundlagen seien an dieser Stelle nicht wichtig, doch soll zumindest die Kurve interessieren, die diese Verteilung beschreibt.

Abbildung 2: Beta-Verteilung der Dauer eines Vorgangs [VISO]

In diesem konkreten Beispiel wurden die unterschiedlichen Dauern für einen Vorgang wie folgt geschätzt:

O = 10 Tage P = 25 Tage M = 13 Tage

Mithilfe der oben genannten Formel, wird die erwartete Dauer berechnet: E = 15 Tage

Die 15 Tage werden nun zum Planen der Vorgänge benutzt, die anderen Zeitschätzungen werden allerdings auch dokumentiert.

Diese Verteilung lässt sich leicht intuitiv erschließen. Es kann natürlich wesentlich mehr in einem Vorgang fehlschlagen, als dass etwas besser läuft als normal. Dies erklärt den kleineren Abstand zwischen der optimistischen und den größeren zwischen der pessimistischen und der realistischen Dauer. Dass nun die erwartete Dauer etwas größer ist als die wahrscheinlichste ist, erscheint auch nicht besonders verwunderlich.

Die Dreizeitenschätzung bringt viele Vorteile. Zum Beispiel gibt es keine uninterpretierten Schätzungen und der Grad der Ungewissheit ist dokumentiert, sodass die Manager wissen, mit welchen Abweichungen sie rechnen müssten.Im Verlaufe des Projekts, wenn die Dauer der Vorgänge immer wieder neu berechnet werden, sollte der Intervall der Unsicherheit stetig abnehmen. Tut er das nicht, ist das ein Zeichen dafür, dass die Person, die die Schätzung abgegeben hat, dies nicht mit Überzeugung tat, was wiederum Grund zur Annahme gibt, dass etwas dabei ist, falsch zu laufen, was dem Manager aber noch nicht gesagt wurde.

3.3 Implementierung von PERT

Nun soll versucht werden mit dem theoretischen Hintergrundwissen ein PERT-Diagramm zu zeichnen.Um die Möglichkeit des Vergleichs zur CPM aus dem vorigen Kapitel zu bieten soll das gleiche Beispiel wieder aufgegriffen werden. Allerdings wird nun neben der realistischen Dauer auch die optimistische und die pessimistische Dauer benötigt. Die erwartete Zeit wird nach der bekannten Formel berechnet.

Beendendes Ereignis

Startendes Ereignis

Optimistische Dauer (O)

Realistische Dauer (M)

Pessimistische Dauer (P)

Erwartete Dauer (E)

20 10 2 Tage 3 Tage 5 Tage 3,17 Tage30 10 2 Tage 4 Tage 6 Tage 4 Tage40 20 ½ Tag 1 Tag 2 Tage 1,08 Tage50 20 1 Tag 2 Tage 4 Tage 2,17 Tage50 30 1 Tag 2 Tage 3 Tage 2 Tage50 40 2 Tage 3 Tage 6 Tage 3,33 Tage

Tabelle 2: Beispiel für einen PERT-Graphen

Die Tage mit einer nicht-natürlichen Zahl anzugeben erscheint gewöhnungsbedürftig, ist aber üblich.

Die Ereignisse wurden in 10er Schritten nacheinander benannt. Das erleichtert das Einfügen zusätzlicher Ereignisse, sollte das nötig sein.

Der kritische Pfad ist immer noch die Verkettung der Vorgänge A,C und F (oder mit Ereignissen gesprochen: 10 → 20 → 40 → 50). Die Projektdauer beträgt nun 7,58 Tage.

Natürlich kann sich jederzeit der kritische Pfad verändern. Es gibt schließlich in diesem Projekt Vorgänge, die schwer einzuschätzen sind, weswegen auch PERT als Netzplantechnik eingesetzt wird.Sollte alles wie „erwartet“ verlaufen, nur Vorgang B (10 → 30) unglücklicherweise seine pessimistisch geschätzte Dauer erreichen, verändert sich der kritische Pfad in 10→ 30 → 50 und die Gesamtdauer des Projekts beträgt 8 Tage.Gut, dass PERT für solche Vorfälle konzipiert wurde. Da neben der erwarteten Dauer auch die anderen Werte dokumentiert werden, kann schnell auf solche Vorfälle reagiert und entsprechende Gegenmaßnahmen eingeleitet werden.

Das Activity on Arc-Diagramm sieht also wie folgt aus:

Abbildung 3: PERT-Netzplan – der kritische Pfad ist rot dargestellt

Dies sollte als Einführung genügen und einen groben Überblick über die Program Evaluation and Review Technique gegeben haben.Nun wird es an der Zeit, PERT angewendet an einem realem Beispiel zu betrachten. Dafür soll nicht irgendein Beispiel herhalten sondern das Projekt, für welches es entworfen wurde: Polaris.

4. Das Polaris-Projekt [SA72]PERT wurde 1958 im Rahmen des Polaris-Projekts des Verteidigungsministeriums der Vereinigten Staaten entwickelt. (Polaris-Raketen sind strategische Mittelstreckenraketen, die von U-Booten aus abgefeuert werden.)Wie erwähnt gab es keine Techniken um so große und komplexe Projekte wie dieses zu modellieren, insbesondere mit der Gewichtung des Faktors Zeit, also setzte man selber Wissenschaftler an, Lösungen für diese Probleme zu finden. Innerhalb von ein paar Wochen wurde PERT entwickelt.Wie schon vorweggenommen soll PERT die Effizienz des Projekts so sehr gesteigert haben, dass die Raketen 2 Jahre eher als erwartet fertiggestellt werden konnten. Eine interessante Behauptung, die nun näher beleuchtet wird.

4.1 Entwicklung von PERT [REVP]

Das SPO war bekannt für sein Managementmethoden. (An dieser Stelle sei erwähnt, dass das SPO noch viele weitere beeindruckende Maßnahmen unternommen hat, die ebenfalls nicht unbedeutend für den positiven Ausgang des Projekts waren.) Sie mussten sogar eine eigene Abteilung dafür einrichten, die Regierung und Industrie stetig auf auf dem Laufenden zu halten, was SPO Managementtechniken anging. PERT war eine dieser Techniken und wahrscheinlich auch die bekannteste.

Die SPO-Manager wussten, dass das Projekt vom Einfluss der Navy oder der Politik nur gebremst werden würde, also versuchten sie ein Modell zu entwickeln, was neben Effektivität auch Sicherheit und Erfolg vermitteln würde. In der Hinsicht war PERT so erfolgreich, dass das SPO nicht nur weitestgehend eigenständig arbeiten konnte, ohne dass sich der Kongress oder das DoD einmischten, PERT wurde sogar für einige Jahre vertraglicher Standard und Pflicht in militärischen Projekten, da die Verantwortlichen so angetan von den vielen bunten Diagrammen und Graphen waren.

4.2 Das Polaris-Projekt und PERT im Jahr 1960 [TE60]

Das DoD hat die Verlaufsprotokolle der PERT Coordination Task Group Meetings der Öffentlichkeit zur Verfügung gestellt.Die Unterlagen des Meetings enthalten auch einen PERT-Netzplan.

Abbildung 4: PERT-Netzplan des Polaris-Projekts (gestrichelte Linien deuten weitere Vorgänge an) [TE60]

Wie im letzten Kapitel beschrieben wurde der Netzplan aufgebaut. Es handelt sich also um eine Activity on Arc-Notation. Der Inhalt der Ereignisse benennt den Vorgang, der mit diesem Ereignis beendet wurde. An den Vorgangspfeilen wurden ebenfalls die drei Zeitschätzungen und die erwartete Dauer notiert. Der komplette Netzplan ist im Anhang zu finden.

Zu dieser Zeit war PERT fast wichtiger als das Projekt selber. Viel interessanter als die Modellierung des Projektablaufs mit Hilfe von PERT waren die Ergebnisse, die die praktische Anwendung, und das Polaris-Projekt war die erste Möglichkeit, praktische Daten zu der Program Evaluation and Review Technique zu sammeln, brachte.Es stellte sich heraus, dass die anfänglichen Schätzungen oft weit von der tatsächlichen Dauer lagen, wie folgendes Diagramm zeigt.

Abbildung 5: Typischer Verlauf einer PERT-Analyse eines Vorgangs [TE60]

Das Diagramm ist von oben nach unten zu lesen. Die waagerechte Achse gibt die Zeit an, zu der geschätzt wird, wann der Vorgang beendet sein sollte, die senkrechte von oben nach unten gelesen nachfolgende PERT-Schätzungen. Der erste Punkt ist die erste Schätzung, der Stern markiert die Zeit, zu der der Vorgang tatsächlich beendet werden konnte.Es ist zu sehen, dass nachfolgende PERT-Schätzungen immer pessimistischer werden. In den meisten dieser Fälle, wo so ein Graph entstand, lagen die drei zugrunde liegenden Schätzungen nicht sehr weit auseinander (etwa 3 Wochen +/- ½). Anscheinend arbeitet PERT verlässlicher bei längeren Zeitintervallen.Das aber überhaupt so eine Kurve entstehen kann und nicht einfach durchgehend von einem konkreten Mittelwert ausgegangen wird, war zur damaligen Zeit aber eine beeindruckende Sache. Es mag auf den ersten Blick nicht den Anschein haben, aber dieses Diagramm sprach für, nicht gegen PERT.Bei vielen Vorgängen entstand auch folgende Kurve.

Abbildung 6: Weiterer typischer Verlauf einer PERT-Analyse eines Vorgangs [TE60]

PERT schätzte anfangs sehr pessimistisch, wurde aber danach zunehmend optimistischer. Man würde annehmen, dass PERT so arbeiten sollte, zeigen doch die optimistischeren Schätzungen, dass das Management eingegriffen hat und die richtigen Entscheidungen getroffen wurden.An einer Stelle entwickelt sich die Kurve genau so wie in der vorherigen Abbildung weiter und wird zunehmend pessimistischer. Anscheinend handelt es sich nun nicht mehr um Fehler im Management sondern in den Schätzungen wie im vorherigen Fall.Dass die eigentliche Fertigstellung etwa zur gleichen Zeit wie von PERT anfangs ermittelt erfolgt, ist eine sehr interessante Tatsache. Viele Vorgänge zeigten dieses Verhalten auf.

Abbildung 7: Anstieg der pessimistischen Schätzung in Abhängigkeit der Dauer eines Vorgangs [TE60]

Die vertikale Achse beschreibt in diesem Diagramm die Wochen, die mit der Dreizeitenschätzung mehr geschätzt wurden, als die realistische Dauer vorhergesagt hätte. Die horizontale Achse gibt an, wie lange insgesamt der Vorgang andauern soll. Wenn ein Ereignis also etwa erst in einem Jahr eintreten soll, schätzt PERT ungefähr 3 Wochen pessimistischer als die Variante mit der realistischen Dauer.

Nun soll der Punkt der Geraden bei der Stelle „6 Monate“ detaillierter betrachtet werden.

Abbildung 8: Vorgänge mit einer Dauer von 6 Monaten und ihre pessimistische Schätzung [TE60]

Diese Abbildung zeigt die Anzahl der Vorgänge, die 6 Monate andauerten, sortiert nach der Anzahl der Wochen, die sie pessimistischer geschätzt wurden im Vergleich zur realistischen Dauer.Die meisten Vorgänge wurden eine Woche pessimistischer geschätzt, wie schon das vorangegangene Diagramm für 6 Monate zeigte.

Bei den mit dem roten „X“ gekennzeichneten Feldern wird angenommen, dass es sich nicht um zuverlässige Werte handelt, die von den Verantwortlichen gegeben wurden. Interessanterweise handelt es sich dabei um fast alle optimistischen und die nur sehr gering pessimistischen Schätzungen.

Wie sind diese Diagramme zu interpretieren?

Die Dreizeitenschätzung, die PERT benutzt, bietet eine pessimistischere Schätzung der Zeit im Vergleich zur Schätzung mit einer Dauer M. Der Pessimismus steigt linear zur Gesamtdauer des Vorgangs, wie Abbildung 7 zeigt.Die pessimistischere Schätzung ist allerdings näher an der wirklichen Dauer des Vorgangs, so dass dies ein gewollter Effekt von PERT ist.

Dass Kurven wie in Abbildung 5 und 6 entstehen, hat inzwischen (Stand 1960) auch abgenommen. PERT befindet sich in der Phase der Implementierung und Details müssen noch ausgearbeitet werden, doch kann es sich immer größerer Akzeptanz und Beliebtheit erfreuen, da die Ergebnisse erfolgversprechend wirken.

4.3 Weiterentwicklung von PERT im Verteidungsministerium [HA64]

Das Original-PERT wurde natürlich ständig weiterentwickelt. Schnell bekam es den neuen Namen PERT/TIME, was darauf hinweisen sollte, dass es sich primär um eine Technik handelte, die sich um den zeitlichen Aspekt eines Projekts kümmert.

Nachdem PERT/TIME bei der Navy ein großer Erfolg war, übernahm die Air Force ebenfalls diese Technik und erweiterte sie kontinuierlich. Diese PERT-Versionen wurden PERT I und PERT II genannt.

Die folgende Tabelle gibt einen Überblick, wie oft PERT als Managementsystem im Jahr 1963 in der Air Force genutzt wurde:

Systeme, die PERT nutzen Systeme, die PERT nicht nutzenAeronautical Systems Division 6 20

Ballistic Systems Division 3 3Electronic Systems Division 10 10

Space Systems Division 4 16Total 23 49

Tabelle 3: Einsatz von PERT in der Air Force [HA64]

Das mag auf dem ersten Blick nicht viel aussehen, doch man muss dazu sagen, dass es sich bei fast allen Projekten, die PERT nicht nutzen, um Projekte handelt, die anfingen bevor PERT für die Air Force verfügbar war und es sich einfach nicht rentierte, diese an PERT anzupassen. PERTs rapider Erfolg ist eindeutig.

In der Zwischenzeit arbeitete auch die Navy weiter an PERT und entwickelte aus PERT/TIME eine Technik namens PERT/COST, die den Fokus auf Kosteneingrenzung setzt. Auch die Air Force nahmen die Kosten als wesentlichen Bestandteil in ihre PERT-Modelle hinzu und PERT/COST wurde neuer Standard.

Die erstaunliche Entwickelung von PERT soll dieses Diagramm schließlich noch einmal zusammenfassen:

Abbildung 9: Weiterentwicklung von PERT beim DoD [HA64]

4.4 Der Mythos PERT [REVP]

Leider sah die Realität nicht ganz so schön aus, wie die vielen Informationen, die das Militär der Öffentlichkeit zur Verfügung stellt, es oberflächlich zeigen wollen.

Natürlich war das Polaris-Projekt ein großer Erfolg. Es hat dank seines Managements Ziele erreicht, die zu dieser Zeit noch für unmöglich gehalten wurden.Allerdings war PERT in diesem Managementsystem nur ein Bestandteil von vielen. Und abgesehen von der Öffentlichkeitsarbeit ein relativ unbedeutender.

Nur wenige Teile des Projekts wurden wirklich mit PERT modelliert und so umgesetzt. Der Erfolg von Polaris lag nach Sapolsky unter anderem viel eher in den sehr gut definierten Zielen, die Möglichkeit, die besten Technologien zu benutzen, die es derzeit gab, die staatliche Priorisierung und die SPO-Angestellten, die über gute Management-, politischen und militärwissenschaftlichen Fähigkeiten verfügten.

Zum Schluss dieses Kapitels soll das Fazit von Professor Harvey Sapolsky aus seinem kritischen, aber objektiven Buch „The Polaris System Development“ erwähnt werden:

„PERT was less effective than advertised but more so than rain dancing. As such, it served its purpose.“ [SA72]

5. Kritik und Ausblick

Obwohl der Entwurf von PERT in den ersten Kapiteln so erfolgversprechend aussah und zweifelsfrei einige gute und interessante Ansätze in dieser Technik sind, hat gerade das praktische Beispiel gezeigt, dass PERT weit entfernt von der ultimativen Netzplantechnik ist, auch wenn das DoD es gerne anders darstellen würde.

5.1 Schwächen von PERT [CATS]

Der größte Makel liegt wahrscheinlich in genau der Eigenschaft, die PERT so besonders macht; der Dreizeitenschätzung.

Die Formel E=O4∗M P

6 trifft leider in der Praxis einfach nicht zu.

Grund dafür ist, dass Annahmen für diese Formel getroffen werden, die falsch sind, wie z.B. dass die Dauer eines Vorgangs statistisch unabhängig sei oder dass sich der kritische Pfad nicht ändern würde.

Das führt dazu, dass oft die fast-kritischen Pfade zu kritischen Pfaden werden. Auch fällt es PERT schwer, die Wahrscheinlichkeitsverteilung der Dauer korrekt zu modellieren, da zu viele Faktoren nicht berücksichtigt werden.Eine Monte-Carlo-Simulation würde hier eine viel höhere Genauigkeit bieten, doch darum soll es in dieser Arbeit nicht gehen.

Berücksichtigt man diese Nachteile, wird schnell deutlich, dass sich PERT eigentlich nur für triviale Projekte eignet.

Auch das DoD sieht PERT inzwischen nicht mehr als zwingenden Standard an.

5.2 Abschließender Kommentar

Die vernichtende Kritik soll nicht den Anschein erwecken, dass es sich nicht lohnen würde, sich mit PERT auseinander zu setzen. Der praktische Nutzen ist heutzutage wohl nicht besonders hoch, doch bietet es einen leicht verständlichen Einstieg in die Materie und insbesondere das Polaris-Projekt sollte auch heute noch eine Inspiration für jeden Manager sein, der denkt, von ihm würden unmöglich zu schaffende Aufgaben verlangt werden.

Vizeadmiral Raborn hat sein Projekt legendär erfolgreich abgeschlossen, trotz der immensen Schwierigkeiten, die der Polaris-Entwicklung im Weg standen.

Je höher das Risiko, desto größer der Erfolg?

Das Polaris-Projekt demonstriert eindrucksvoll, wie mächtig der moderne Mensch sich gegen Risiken und Unbekanntes wehren kann.

Quellen

Literaturverzeichnis

[GA04] L. GALWAY, Quantitative Risk Analysis for Project Management, 2004

[HA64] R. L. HAMILTON, Study of Methods for Evaluation of the PERT/COST Management System, 1964

[SA72] H. M. SAPOLSKY, The Polaris System Development, 1972

[TE60] K. M. TEBO, Proceedings of the PERT Coordination Task Group Meeting, 1960

[NETP]http://www.netmba.com/operations/project/pert/

[NETC]http://www.netmba.com/operations/project/cpm/

[VISO]http://www.visionarytools.com/decision-making/3-point-estimating.htm

[CATS]http://herdingcats.typepad.com/my_weblog/2007/06/pert-analysis-r.html

[REVP]http://www.cadmus.ca/bookreviewpolaris.htm

Grafiken

Abbildung 1 und Abbildung 3 wurden mit Microsoft Office Visio erstelltAbbildung 2 wurde mit Paint.NET bearbeitetAbbildung 9 wurde mit OpenOffice.org Draw erstellt

Anhang

Kompletter Netzplan [TE60]