Die Geschichte des Projektmanagements

Erstfassung 24. Oktober 2026, zuletzt geändert am 24. Oktober 2026 · Andreas Stockter

Projektmanagement ist die Kunst, ein Vorhaben zu Ende zu bringen, das es so noch nicht gab: ein Ziel, das einmalig ist, eine Frist, die gesetzt ist, ein Budget, das nicht reicht, und Menschen, die vorher nicht zusammengearbeitet haben. Der Begriff ist siebzig Jahre alt, die Sache ist so alt wie die Pyramiden, und ihr Ergebnis ist bis heute ernüchternd: In der größten Sammlung von Projektdaten, die es gibt, rund 16.000 Vorhaben aus 136 Ländern, blieben 47,9 Prozent im Budget, 8,5 Prozent zugleich im Budget und in der Zeit, und ein halbes Prozent brachte dazu den Nutzen, der versprochen war.¹ Der Berliner Flughafen öffnete neun Jahre nach dem ersten Termin, Stuttgart 21 soll nach dem Stand vom Juni 2026 zwölf Jahre später fertig werden als vereinbart und dreimal so viel kosten, und der Berufsverband der Projektmanager rechnet damit, dass die Welt bis 2030 25 Millionen zusätzliche Menschen braucht, die Projekte führen.^{2, 3, 4} Dieser Text erzählt, wie der Mensch gelernt hat, Vorhaben zu planen, und warum er es noch immer nicht kann.

Wie die Geschichte der KI, die Geschichte der Mathematik hinter der KI, die Geschichte der Softwareentwicklung, die Geschichte des Internets, die Geschichte von Open Source, die Geschichte des Venture Capitals, die Geschichte des Vibe-Coding und die Geschichte des E-Commerce folgt dieser Text einer Kette: Jede Epoche löst einen Engpass, den die vorherige offen gelassen hat, und schafft dabei den nächsten. Hier hat der Engpass seit dem ersten Bauplan dieselbe Form: Zwischen dem Versprechen, das am Anfang steht, und dem Werk, das am Ende steht, liegen Ungewissheit, Abhängigkeit und Menschen, und irgendjemand muss sie beherrschen. Erst fehlte die Methode, dann die Zeit auf dem Papier, dann die Abhängigkeit, dann die Organisation, dann die Norm, dann die Beweglichkeit, dann der Maßstab, zuletzt die Antwort auf die Frage, wer steuert, wenn eine Maschine plant (Abbildung 1). Jeder Fachbegriff wird an der Stelle fett gesetzt, an der er erklärt wird, und erst danach verwendet. Ein Glossar listet alle Begriffe alphabetisch.

Inhalt: 1 Bauherren und Baumeister · 2 Taylor, Gantt, Balkenplan · 3 Der Netzplan · 4 Apollo, Matrix, Beruf · 5 Normen und Zertifikate · 6 Lean, Scrum, Agil · 7 Maßstab und Großprojekte · 8 Wer steuert · Kette · Zeitleiste · Weiterlesen · Quellen

1. Vorgeschichte: Bauherren und Baumeister (bis 1900)

Das Problem. Ein Haus baut man, wie man das letzte gebaut hat. Ein Vorhaben, das es so noch nicht gab, eine Pyramide, eine Kathedrale, ein Kanal, eine Brücke über einen Fluss, den noch niemand überbrückt hat, baut man ohne Vorbild, und alles, was daran unbekannt ist, muss jemand entscheiden, bevor es gebaut werden kann: wie viele Steine, wie viele Leute, in welcher Reihenfolge, was zuerst fertig sein muss, damit das Nächste beginnen kann, und was geschieht, wenn der Winter früher kommt. Ein Projekt, ein Vorhaben mit einem einmaligen Ziel, einem Anfang und einem Ende, unterscheidet sich vom Betrieb, der dasselbe immer wieder tut, dadurch, dass man die Antworten nicht aus der Erfahrung holen kann, sondern aus dem Kopf. Jahrtausendelang war dieser Kopf der des Baumeisters, und das Verfahren, das er anwandte, hatte keinen Namen und kein Papier.

Die Bauten. Die Pyramide des Cheops entstand um 2560 vor Christus in etwa zwanzig Jahren aus gut zwei Millionen Steinblöcken; die Arbeiter wohnten in einer eigenen Stadt, bekamen Brot und Bier als Lohn, und die Verwaltung zählte Rationen, Mannschaften und Steine auf Papyrus. Die Kathedralen des Mittelalters hatten Bauzeiten, die kein Mensch überblickte: In Köln begann der Bau 1248 und endete 1880, und über die Jahrhunderte wechselten Baumeister, Pläne und Geldgeber, während das Werk stand und wartete. In China ließ Kaiser Yang aus der Sui-Dynastie zwischen 605 und 610 den Kaiserkanal vollenden, rund zweitausend Kilometer Wasserweg zwischen Gelbem Fluss und Jangtse, mit Millionen zwangsverpflichteter Bauern und Soldaten; wie viele dabei starben, weiß niemand, und die Dynastie überlebte das Werk nur um wenige Jahre. Alle drei Arten von Bauten gelangen, aber nicht durch Planung, wie wir sie verstehen, sondern durch Dauer, Macht und ein Wissen, das von Meister zu Meister weitergegeben wurde. Sébastien Le Prestre de Vauban, Ludwigs XIV. Festungsbaumeister, plante im 17. Jahrhundert über hundert Festungen mit Zeichnungen, Mengenlisten und Kostenvoranschlägen, die so genau waren, dass der König sie prüfen konnte; aber das Wissen, wie man aus dem Plan den Bau macht, blieb bei ihm.⁵

Das Wort. Das Wort kommt vom lateinischen proiectum, das nach vorn Geworfene, der Entwurf. Im 17. Jahrhundert wurde es zum Schimpfwort: Projektemacher nannte man die Leute, die mit Plänen für Kanäle, Manufakturen und Lotterien von Hof zu Hof zogen und Geld dafür suchten, und Daniel Defoe, selbst ein gescheiterter Projektemacher, schrieb 1697 seinen „Essay upon Projects“, in dem er Banken, Versicherungen, Straßen und Schulen für Frauen vorschlug und zugleich beschrieb, wie die meisten Projekte endeten: in der Überschätzung dessen, der sie erdacht hatte.⁶ Der Satz, dass ein Projekt zuerst ein Versprechen ist und erst dann ein Werk, stand damit lange vor der Methode fest.

Die Ingenieure. Das 19. Jahrhundert gab dem Bauen eine neue Größe und einen neuen Beruf. John Smeaton hatte sich 1768 als Erster „civil engineer“ genannt, Ingenieur für zivile Bauten im Unterschied zu den militärischen, und die Eisenbahnen machten aus dem Beruf einen Stand: Isambard Kingdom Brunel baute von 1835 an die Great Western Railway von London nach Bristol, zweihundert Kilometer mit Brücken, Tunneln und Bahnhöfen, mit Hunderten von Zeichnungen, Verträgen mit Dutzenden Bauunternehmern und einem Budget, das am Ende, wie bei fast allen Ingenieuren seiner Zeit, um mehr als das Eineinhalbfache überschritten war.⁷ Ferdinand de Lesseps, ein Diplomat ohne technische Ausbildung, ließ von 1859 bis 1869 den Suezkanal graben, zehn Jahre statt sechs, für das Doppelte des Voranschlags, und wurde zum berühmtesten Mann Frankreichs. Dann versuchte er es noch einmal. Die Compagnie universelle du canal interocéanique de Panama begann 1881, mit dem Plan eines Kanals auf Meereshöhe wie in Suez, im Gebirge und im Dschungel, ohne die Geologie zu kennen und ohne zu wissen, dass das Gelbfieber von Mücken kommt; 1889 war die Gesellschaft bankrott, 1,3 Milliarden Franc waren ausgegeben, über zwanzigtausend Menschen gestorben und ein Drittel des Kanals gegraben. Die Vereinigten Staaten nahmen das Werk 1904 wieder auf, mit einem Schleusenkanal, einem Arzt, William Gorgas, der die Mücken bekämpfte, bevor gebaut wurde, und einem Offizier, George Goethals, der 1907 die Leitung bekam, mit Vollmacht über alles vom Bagger bis zur Kantine; 1914 war der Kanal offen, zwei Jahre vor dem Termin und unter dem Voranschlag.⁸ Der Unterschied zwischen den beiden Versuchen war nicht das Geld und nicht der Mut, sondern das, was später Projektmanagement heißen sollte: Erst verstehen, dann planen, dann einer, der entscheidet.

Der Turm. Das Gegenbeispiel zum Scheitern stand zur selben Zeit in Paris. Gustave Eiffels Firma begann am 28. Januar 1887 mit den Fundamenten des Turms für die Weltausstellung und war am 31. März 1889 fertig, nach zwei Jahren, zwei Monaten und fünf Tagen, zum Termin und im Budget. Das Geheimnis lag in der Vorbereitung: 18.000 Eisenteile wurden in Eiffels Werkstatt in Levallois nach 5.300 Zeichnungen auf den Zehntelmillimeter vorgefertigt, nummeriert und mit den Löchern für die Nieten geliefert, so dass auf der Baustelle nur noch zusammengesetzt wurde, was anderswo gedacht war; die Montage dauerte je Teil Minuten, und zweihundertfünfzig Arbeiter reichten.⁹ Eiffel hatte verstanden, dass ein Projekt umso schneller gebaut wird, je mehr davon vor dem ersten Spatenstich entschieden ist, und er hatte die Mittel, es zu tun: Zeichnung, Nummer, Liste.

Der Engpass. 1900 konnten Ingenieure Kanäle, Türme und Eisenbahnen bauen, die hundert Jahre zuvor undenkbar gewesen waren, und sie wussten, dass ein Vorhaben an Vorbereitung und Führung hängt. Aber das Wissen, wie viel Zeit ein Werk braucht und was zuerst getan werden muss, war ein Bild im Kopf des Baumeisters. Es ließ sich nicht aufzeichnen, nicht prüfen und nicht übergeben, und wenn der Baumeister fiel wie de Lesseps, fiel das Projekt. Was fehlte, war ein Papier, auf dem die Zeit steht: wer wann was tut, und ob man im Plan ist.

2. Die Zeit auf dem Papier: Taylor, Gantt und der Balkenplan (1896–1936)

Adamiecki. Das Papier, auf dem die Zeit steht, wurde zweimal erfunden, und das erste Mal in einer Sprache, die niemand las. Karol Adamiecki, Ingenieur in einem Walzwerk im russischen Teil Polens, zeichnete 1896 ein Diagramm, das er Harmonogramm nannte: Jeder Arbeitsschritt eine Spalte, die Zeit auf einer Achse, die Dauer als Streifen, und Papierstreifen, die man verschieben konnte, bis die Schritte ineinandergriffen, ohne dass eine Maschine wartete. Er stellte es 1903 der Technischen Gesellschaft in Jekaterinoslaw vor und veröffentlichte es erst 1931, auf Polnisch; die Welt hat es nicht gelesen.¹⁰

Taylor und Fayol. In den Vereinigten Staaten wurde die Arbeit zur Wissenschaft. Frederick Winslow Taylor maß in den Stahlwerken von Pennsylvania mit der Stoppuhr, wie lange ein Handgriff dauert, zerlegte jede Arbeit in Schritte, bestimmte für jeden Schritt den besten Weg und die beste Zeit und schrieb beides vor; sein Buch „The Principles of Scientific Management“ von 1911 machte daraus eine Lehre, die bis heute das Denken über Arbeit prägt, im Guten wie im Schlechten. Henri Fayol, Direktor eines französischen Bergwerkskonzerns, beschrieb 1916 in „Administration industrielle et générale“, was Führung tut: vorausschauen und planen, organisieren, anweisen, koordinieren, kontrollieren. Die fünf Verben sind bis heute das Gerüst jedes Lehrbuchs des Projektmanagements, obwohl Fayol von Unternehmen sprach, nicht von Projekten.¹¹

Gantt. Henry Laurence Gantt, Taylors Mitarbeiter und später sein Kritiker, zeichnete zwischen 1910 und 1915 für die Werkstätten, die er beriet, Tafeln, auf denen jede Maschine und jeder Arbeiter eine Zeile hatte, die Zeit die Spalten bildete und ein Balken zeigte, was geplant war und ein zweiter, was geschafft; wer die Tafel ansah, sah auf einen Blick, wer hinter dem Plan lag. Im Ersten Weltkrieg setzte er die Tafeln für die Rüstung ein, für die Munitionsfabriken des Heeres unter General Crozier und für den Schiffbau der Emergency Fleet Corporation, wo Hunderte von Werften nach einem Plan bauen mussten. Gantt starb 1919; sein Mitarbeiter Wallace Clark gab der Tafel 1922 in dem Buch „The Gantt Chart“ den Namen, verkaufte sie in Europa, und die sowjetischen Planer nahmen sie für die Fünfjahrpläne.¹² Der Balkenplan, ein Diagramm mit den Vorgängen als Zeilen und der Zeit als waagerechter Achse, in dem jeder Vorgang ein Balken von seinem Anfang bis zu seinem Ende ist, war das erste Werkzeug, mit dem ein Plan aufgezeichnet, verglichen und übergeben werden konnte (Abbildung 2). Er ist bis heute das Bild, das die meisten Menschen vor Augen haben, wenn sie „Projektplan“ hören.

Hoover Dam und das Empire State Building. Die 1930er Jahre zeigten, was mit dem Balkenplan und einer Firma, die ihn beherrschte, möglich war. Für den Staudamm im Colorado, den größten, der je gebaut worden war, schlossen sich sechs Baufirmen des Westens zur Six Companies zusammen, bekamen 1931 den Auftrag für 49 Millionen Dollar und setzten Frank Crowe als Bauleiter ein, der Dämme seit zwanzig Jahren baute. Crowe plante die Arbeit vom Ende her: Umleitungstunnel, Kofferdämme, Betonblöcke, die mit Kühlrohren durchzogen wurden, damit der Beton nicht hundert Jahre zum Abbinden brauchte, eine Seilbahn über die Schlucht, eine eigene Stadt für fünftausend Arbeiter. Der Damm war am 1. März 1936 fertig, zwei Jahre vor dem vertraglichen Termin, und die Six Companies verdienten daran.¹³ In New York begann im März 1930 der Bau des Empire State Building, und im Mai 1931, nach 410 Tagen, war das höchste Haus der Welt fertig. Die Baufirma Starrett Brothers and Eken hatte den Bau wie ein Fließband organisiert: Die Stahlträger kamen aus Pittsburgh auf den Tag genau, als sie gebraucht wurden, die Stockwerke wuchsen in manchen Wochen um viereinhalb, und die Pläne wurden fertig, während unten schon gebaut wurde.¹⁴ Das war Fast-Tracking, der Beginn der Ausführung, bevor die Planung abgeschlossen ist, mit dem Risiko, das später viele Projekte zu Fall brachte, und es gelang, weil Bauherr, Architekt und Baufirma dasselbe wollten und der Bau aus bekannten Teilen bestand.

Selbst ausprobieren. Ein Balkenplan braucht keine Software. In einer Tabellenkalkulation die Vorgänge in die erste Spalte, die Wochen in die erste Zeile, und in jede Zelle, in der ein Vorgang läuft, ein X oder eine Farbe; eine zweite Zeile je Vorgang für das, was geschafft ist. Wer damit einen Umzug, eine Küche oder eine Abschlussarbeit plant, merkt nach zehn Minuten, was Gantt gesehen hat: Die Dauer ist leicht, die Reihenfolge ist schwer, und das Papier sagt nicht, warum ein Vorgang erst nach dem anderen beginnen kann.

Der Engpass. 1936 konnte man den Plan eines Vorhabens aufzeichnen, an die Wand hängen, und jeder sah, wer im Rückstand war. Aber der Balkenplan zeigt, wann etwas geschieht, nicht, wovon es abhängt: Dass die Kühlrohre vor dem Beton liegen müssen und der Beton vor der Seilbahnlast, steht in Crowes Kopf, nicht im Diagramm. Verschiebt sich ein Balken, muss ein Mensch wissen, welche anderen mitwandern. Bei einem Damm mit hundert Vorgängen ging das. Bei einem Vorhaben mit zehntausend Vorgängen in zweihundert Firmen, von denen keine das Ganze sah, ging es nicht mehr, und genau solche Vorhaben begann der nächste Krieg.

3. Der Netzplan: Manhattan, Polaris und der Computer (1942–1962)

Manhattan. Das Vorhaben, an dem die alten Mittel endgültig scheiterten, war die Bombe. Das Manhattan-Projekt baute von 1942 bis 1945 unter General Leslie Groves Fabriken in Oak Ridge und Hanford, ein Laboratorium in Los Alamos und eine Waffe, von der niemand wusste, ob sie funktionieren würde; es beschäftigte auf dem Höhepunkt 130.000 Menschen und kostete knapp zwei Milliarden Dollar. Groves tat, was kein Bauherr vorher getan hatte: Weil nicht feststand, welcher der Wege zum spaltbaren Material gangbar war, ließ er alle zugleich bauen, drei Verfahren zur Urananreicherung und die Plutoniumreaktoren, und nahm in Kauf, dass die meisten umsonst sein würden. Das war die Antwort auf Ungewissheit, die sich später jedes Rüstungsprogramm abschaute: Parallelität statt Reihenfolge, Geld statt Zeit.¹⁵ Nach dem Krieg wurde aus dem Ausnahmefall die Regel. Die Luftwaffe entwickelte ab 1954 unter Bernard Schriever die Interkontinentalrakete Atlas nach dem Prinzip der Concurrency, der gleichzeitigen Entwicklung von Rakete, Triebwerk, Sprengkopf und Startanlagen, die eigentlich nacheinander hätten entstehen müssen, und sie brauchte dafür eine Organisation, die hunderte Firmen und tausende Abhängigkeiten im Blick behielt. Der Balkenplan konnte das nicht.¹⁶

CPM. Die Antwort kam aus der Chemie und von der Rechenmaschine. DuPont wollte die Stillstandszeiten seiner Chemieanlagen bei Wartung und Umbau verkürzen und hatte seit 1954 einen UNIVAC, der nichts zu tun hatte. Morgan Walker von DuPont und James Kelley von Remington Rand, dem Hersteller des Rechners, setzten im Mai 1957 ein Projekt auf, das aus dem Plan eine Rechnung machte: Jeder Vorgang bekommt eine Dauer und die Liste seiner Vorgänger, die fertig sein müssen, bevor er beginnen kann; daraus entsteht ein Netz, und im Netz gibt es den längsten Weg vom Anfang zum Ende. Verzögert sich ein Vorgang auf diesem Weg, verzögert sich das Ganze; Vorgänge abseits davon haben Spielraum, den Puffer, die Zeit, um die sich ein Vorgang verschieben darf, ohne den Endtermin zu verschieben. Die Critical Path Method, CPM, berechnete für jeden Vorgang den frühesten und spätesten Anfang und machte sichtbar, welche zehn von tausend Vorgängen den Termin bestimmen. DuPont setzte sie 1958 bei einem Werksumbau in Louisville ein und verkürzte den Stillstand von 125 auf 93 Stunden; Kelley und Walker stellten das Verfahren 1959 auf der Eastern Joint Computer Conference vor.¹⁷ Der Netzplan, die Darstellung eines Projekts als Netz aus Vorgängen und ihren Abhängigkeiten, war damit erfunden; die Kette der Vorgänge ohne Puffer, deren Summe die Projektdauer ist, heißt kritischer Weg und wurde zur wichtigsten Zahl, die ein Projektleiter kennt (Abbildung 3).

PERT. Fast gleichzeitig und unabhängig entstand dasselbe bei der Marine, mit einem Zusatz für das Ungewisse. Das Special Projects Office unter Admiral William Raborn hatte 1956 den Auftrag, die Polaris zu bauen, eine Rakete, die aus einem getauchten U-Boot startet, mit einem Sprengkopf, einem Antrieb, einem Navigationssystem und einem U-Boot, die es alle noch nicht gab, und mit 250 Hauptauftragnehmern und neuntausend Zulieferern. Im Januar 1958 begann ein Team aus dem Büro, der Beratungsfirma Booz Allen Hamilton und Lockheed, das Programm als Netz darzustellen; weil niemand wusste, wie lange die Entwicklung eines Bauteils dauern würde, das noch nie gebaut worden war, bekam jeder Vorgang drei Schätzungen, eine optimistische, eine wahrscheinliche und eine pessimistische, und aus ihnen eine erwartete Dauer und eine Streuung. Die Program Evaluation and Review Technique, PERT, berechnete damit nicht nur den kritischen Weg, sondern die Wahrscheinlichkeit, einen Termin zu halten. Die Marine veröffentlichte das Verfahren noch 1958, die Polaris war 1960 einsatzbereit, zwei Jahre früher als geplant, und PERT bekam das Verdienst dafür, ob zu Recht oder nicht; der Historiker Harvey Sapolsky hat später gezeigt, dass das Büro PERT vor allem als Schutzschild gegen den Kongress und das Pentagon benutzte, das Programm aber durch gute Ingenieure und viel Geld zum Erfolg kam. Ab 1962 verlangte das Verteidigungsministerium PERT von jedem großen Auftragnehmer, und die Berater verkauften es an die Industrie.¹⁸ In Frankreich entwickelte Bernard Roy 1958 für die Beratungsfirma SEMA die Méthode des potentiels Métra, die statt der Vorgänge die Ereignisse verband und sich leichter ändern ließ; sie wurde zum Netzplan der französischen Industrie.¹⁹

Der Projektstrukturplan. Ein Netz mit zehntausend Vorgängen braucht eine Ordnung, bevor man es zeichnen kann. Die Luftfahrtindustrie und das Pentagon gewöhnten sich an, ein Vorhaben zuerst in Teile zu zerlegen wie einen Baum: die Rakete in Stufen, die Stufe in Triebwerk, Tank, Steuerung, das Triebwerk in Pumpen, Brennkammer, Düse, bis jedes Blatt des Baums ein Stück Arbeit ist, das einer verantworten, schätzen und abrechnen kann. Der Projektstrukturplan, englisch Work Breakdown Structure, bekam seine amtliche Form im Juni 1962 im PERT/COST-Leitfaden von Verteidigungsministerium und NASA, der zugleich verlangte, jedem Element des Baums seine Kosten zuzuordnen, so dass Plan und Rechnung dieselbe Gliederung haben.²⁰ Seither beginnt jedes Projekt, das nach den Lehrbüchern geführt wird, mit diesem Baum, und die meisten Streitigkeiten über den Umfang eines Projekts sind Streitigkeiten über seine Äste.

Der Projektleiter. Das Verfahren brauchte einen Menschen, der es verantwortete, und dieser Mensch war neu. In einer Firma hatte jeder einen Chef, den Leiter seiner Abteilung; ein Vorhaben aber lief quer durch alle Abteilungen, und niemand war für das Ganze zuständig. Paul Gaddis, Manager bei Westinghouse, beschrieb 1959 in der Harvard Business Review eine Figur, die in den Rüstungsfirmen gerade entstand, und nannte sie „The Project Manager“: einer, der für Ergebnis, Termin und Kosten eines Vorhabens verantwortlich ist, ohne dass ihm die Leute gehören, die daran arbeiten, und der deshalb mit Überzeugung führen muss statt mit Befehl.²¹ Der Projektleiter, die Person, die ein Projekt über die Grenzen der Abteilungen hinweg plant, steuert und verantwortet, war damit benannt; was ihm an Befugnis fehlte, sollte die nächste Epoche regeln.

Selbst ausprobieren. Den kritischen Weg kann man von Hand finden. Für das Netz in Abbildung 3: Jeden Vorgang mit seiner Dauer aufschreiben, dann von links nach rechts für jeden den frühesten Anfang bestimmen, das ist das späteste Ende aller Vorgänger, und das früheste Ende, Anfang plus Dauer. Von rechts nach links dasselbe für das späteste Ende, das ist der früheste Anfang aller Nachfolger, und den spätesten Anfang. Vorgänge, bei denen frühester und spätester Anfang gleich sind, liegen auf dem kritischen Weg; bei allen anderen ist die Differenz der Puffer. Wer das für zehn Vorgänge gemacht hat, versteht, warum DuPont dafür einen Rechner wollte, und warum jede Projektsoftware seither nichts anderes tut.

Der Engpass. 1962 ließ sich ein Vorhaben aus zehntausend Vorgängen zerlegen, als Netz zeichnen, durchrechnen und mit Wahrscheinlichkeiten versehen, und der Computer hielt den Plan aktuell. Aber das Verfahren gehörte dem Militär und der Luftfahrt, es brauchte Großrechner, und der Mann, der es verantwortete, hatte einen Titel, aber keine Organisation: Er musste sich die Leute von Abteilungsleitern leihen, die andere Ziele hatten. Was fehlte, war eine Form, in der das Projekt Vorrang hat vor der Linie, und ein Beruf, der das Wissen trägt.

4. Apollo, die Matrix und der Beruf (1961–1975)

Das Versprechen. Am 25. Mai 1961 sagte John F. Kennedy dem Kongress, die Vereinigten Staaten sollten noch vor dem Ende des Jahrzehnts einen Menschen auf dem Mond landen und sicher zurückbringen. Es war das größte Projekt, das je mit Termin und Ziel angekündigt worden war, und niemand wusste, wie man es macht: Die größte Rakete, die es gab, hatte ein Zehntel des nötigen Schubs. Apollo beschäftigte auf dem Höhepunkt rund 400.000 Menschen, davon 34.000 bei der NASA und der Rest bei zwanzigtausend Firmen und Universitäten, und kostete bis 1973 25,4 Milliarden Dollar.²² Das Programm ist bis heute das Lehrstück des Projektmanagements, weil es beides zeigte: dass ein Vorhaben dieser Größe zum Termin gelingen kann, und was es dafür braucht.

Mueller. Was es brauchte, kam im September 1963, als George Mueller die Leitung der bemannten Raumfahrt übernahm. Eine Prüfung, die er in Auftrag gab, kam nach zwei Wochen zurück mit dem Befund, dass der Mond bei dem Tempo nicht vor 1971 erreicht werde. Mueller änderte zweierlei. Er ordnete die Organisation neu: Jedes der drei Zentren, Houston, Huntsville, Cape Canaveral, bekam dieselben fünf Funktionen, Programmsteuerung, Systemtechnik, Test, Zuverlässigkeit und Qualität, Flugbetrieb, die an die gleichen fünf Funktionen in Washington berichteten, so dass jede Frage auf jeder Ebene einen Zuständigen hatte, die „GEM boxes“, nach seinen Initialen. Und er verfügte das All-up-Testing: Die Saturn V sollte beim ersten Flug mit allen Stufen zugleich fliegen, statt Stufe für Stufe erprobt zu werden, wie Wernher von Brauns Ingenieure es aus Peenemünde gewohnt waren. Von Braun hielt das für Wahnsinn und schrieb später, ohne diese Entscheidung wäre die Landung 1969 nicht möglich gewesen.²³ Dazu kam das Konfigurationsmanagement, die Vorschrift, dass jede Änderung an einem Bauteil beantragt, geprüft, genehmigt und in allen Zeichnungen nachgeführt wird, so dass zu jedem Zeitpunkt feststand, was gebaut war; die Luftwaffe hatte es für ihre Raketen erfunden, Apollo machte es zur Regel.

Die Matrix. Die Form, in der das Projekt Vorrang vor der Linie bekam, hieß Matrix, und sie entstand in den Luftfahrtfirmen, die für die NASA und das Pentagon mehrere Programme zugleich bauten. In der Matrixorganisation gehört jeder Ingenieur weiter seiner Fachabteilung, die ihn ausbildet, bezahlt und befördert, und zugleich einem Projekt, das ihm sagt, was er diese Woche tut; der Projektleiter hat die Verantwortung für das Ergebnis, der Abteilungsleiter die für die Leute, und beide müssen sich einigen. Die Form löste das Problem von Gaddis und schuf ein neues, den Streit um Vorrang, den jeder kennt, der in einer Matrix gearbeitet hat.²⁴

Earned Value. Das Pentagon, das zehntausende Verträge zugleich überwachte, verlangte ab 1967 von seinen Auftragnehmern ein Verfahren, das Termin und Kosten in einer Zahl verbindet. Die Cost/Schedule Control Systems Criteria, 35 Anforderungen an das Berichtswesen, verlangten für jedes Element des Projektstrukturplans drei Werte: was bis heute geplant war, was es gekostet hat und was davon tatsächlich fertig ist, bewertet mit dem geplanten Preis, der Fertigstellungswert, englisch Earned Value. Aus den drei Zahlen ergibt sich, ob ein Projekt hinter dem Plan liegt und ob es zu teuer wird, und aus dem Verhältnis lässt sich hochrechnen, was es am Ende kosten wird, lange bevor das Geld ausgegeben ist (Abbildung 4). Das Verfahren ist bis heute die Grundlage jeder Fortschrittskontrolle, die mehr sieht als die Rechnungen.²⁵

Die Verbände. Der Beruf fand in diesen Jahren seine Vereine. 1964 lud der Franzose Pierre Koch den Niederländer Dick Vullinghs und den Deutschen Roland Gutsch ein, über die Netzplantechnik zu reden; 1965 gründeten sie in der Schweiz einen Verband, der INTERNET hieß, lange bevor das Wort etwas anderes bedeutete, 1967 hielt er in Wien seinen ersten Kongress mit Teilnehmern aus dreißig Ländern, und seit 1994 heißt er International Project Management Association, IPMA.²⁶ In den Vereinigten Staaten trafen sich am 9. Oktober 1969 in Atlanta Ingenieure aus der Rüstungs- und Bauindustrie, darunter Jim Snyder und Gordon Davis, und gründeten das Project Management Institute, PMI, mit dem Ziel, das Wissen des Berufs zu sammeln und zu lehren.²⁷ In Deutschland entstand 1979 aus der deutschen INTERNET-Sektion die Gesellschaft für Projektmanagement, GPM.

Tokio. Dass die Lehre von Apollo auch anderswo galt und ihr Gegenteil auch, zeigten zwei Bauten derselben Jahre. Die japanische Staatsbahn begann am 20. April 1959 den Bau der Tokaido-Schnellbahn zwischen Tokio und Osaka, der ersten Hochgeschwindigkeitsstrecke der Welt, und eröffnete sie am 1. Oktober 1964, neun Tage vor den Olympischen Spielen in Tokio, zum Termin. Die Kosten waren eine andere Sache: 1958 waren rund 195 Milliarden Yen veranschlagt, am Ende waren es rund 380 Milliarden, und der Präsident der Staatsbahn, Shinji Sogō, der das Vorhaben gegen alle Widerstände durchgesetzt hatte, trat 1963 zurück; nach späteren Darstellungen hatte er die Schätzung bewusst niedrig gehalten, weil weder das Parlament noch die Weltbank den wahren Betrag bewilligt hätten. Der Shinkansen wurde das Muster für die Schnellbahnen Europas und Chinas, und sein Finanzierungsweg das Muster für das, was Flyvbjerg vierzig Jahre später strategische Fehldarstellung nannte.²⁸

Sydney. Das Gegenstück zu Apollo entstand in denselben Jahren am anderen Ende der Welt. Jørn Utzon gewann 1957 den Wettbewerb für das Opernhaus von Sydney mit Skizzen von Segeln aus Beton, von denen niemand wusste, wie man sie baut; die Regierung von New South Wales schätzte die Kosten auf sieben Millionen australische Dollar und ließ 1959 mit dem Bau beginnen, bevor die Pläne fertig waren, weil sie vor der nächsten Wahl Fundamente sehen wollte. Die Schalen mussten umkonstruiert werden, nachdem die Fundamente standen, Utzon trat 1966 im Streit mit dem neuen Minister zurück, und das Haus wurde am 20. Oktober 1973 eröffnet, zehn Jahre nach dem Termin, für 102 Millionen Dollar, fast das Fünfzehnfache. Es ist seit 2007 Welterbe der UNESCO und das Lehrbeispiel dafür, was geschieht, wenn man baut, bevor man weiß, was.²⁹

Software. Ein neuer Typ von Projekt widersetzte sich inzwischen allen Methoden. IBM hatte 1964 das System/360 angekündigt, eine Familie von Rechnern mit einem gemeinsamen Betriebssystem, OS/360, und das Betriebssystem kam Jahre zu spät, kostete mehr als die Hardware und war beim Erscheinen nicht fertig. Fred Brooks, der es geleitet hatte, zog 1975 in „The Mythical Man-Month“ die Lehre, die seither sein Gesetz heißt: Wer zu einem verspäteten Softwareprojekt Leute hinzufügt, verspätet es weiter, weil die neuen eingearbeitet werden müssen und die Zahl der Gespräche mit der Zahl der Leute im Quadrat wächst. Menschen und Monate sind in der Software nicht austauschbar, und der Netzplan, der das annimmt, misst dort etwas, das es nicht gibt.³⁰ Winston Royce von TRW hatte 1970 ein Bild gezeichnet, das zeigte, wie Software nach den Regeln der Hardware entstehen würde: Anforderungen, Entwurf, Programmierung, Test, Betrieb als Stufen, von denen jede fertig sein muss, bevor die nächste beginnt, eine Kaskade. Royce schrieb darunter, dass dieses Vorgehen riskant sei und zum Scheitern einlade, weil die Fehler des Entwurfs erst beim Test sichtbar werden, und schlug Rückschleifen vor. Gelesen wurde nur das Bild; das Wasserfallmodell, die Entwicklung in festen, aufeinanderfolgenden Phasen mit vollständiger Dokumentation an jedem Übergang, wurde zur Vorschrift des Pentagons und zum Standard einer Branche, die zwanzig Jahre brauchte, um Royces Warnung zu verstehen.³¹

Der Engpass. 1975 hatte das Projektmanagement eine Organisation, ein Kontrollverfahren, zwei Verbände und einen Beweis, dass es zum Mond reicht. Aber das Wissen lag in den Köpfen von einigen tausend Leuten in der Luftfahrt und im Pentagon, jede Firma nannte die Dinge anders, und wer außerhalb dieser Welt ein Projekt führen sollte, in einer Bank, einer Behörde, einem Softwarehaus, fand kein Buch, das ihm sagte, was zu tun ist. Was fehlte, war die Norm: eine gemeinsame Sprache, ein Lehrbuch und ein Zertifikat, das sagt, wer sie beherrscht.

5. Normen, Wasserfall und Zertifikate (1975–1997)

Das magische Dreieck. Die Norm begann mit einem Bild. Martin Barnes, ein englischer Bauingenieur, zeichnete 1969 für einen Kurs ein Dreieck mit den Ecken Zeit, Kosten und Qualität und erklärte, dass man keine Ecke bewegen kann, ohne die anderen zu verschieben: Wer schneller will, zahlt mehr oder bekommt weniger. Das Bild heißt seither magisches Dreieck: Zeit, Kosten und Umfang als die drei Größen, die jedes Projekt zugleich begrenzen und gegeneinander ausspielt; es wurde zum ersten Satz jeder Ausbildung, und die meisten Projekte, die scheitern, scheitern daran, dass jemand alle drei Ecken zugleich festgehalten hat (Abbildung 5).³²

Die Normen. Deutschland normte zuerst die Zeichnung, dann das Wort: DIN 69900 regelte 1979 die Netzplantechnik, DIN 69901 definierte im Dezember 1980 die Begriffe des Projektmanagements, darunter den Meilenstein, ein Ereignis von besonderer Bedeutung im Projektablauf, meist das Ende einer Phase, an dem geprüft wird, ob der Plan noch gilt, und wurde 2009 zu einem fünfteiligen Normwerk mit einem Prozessmodell, nach dem seither die deutschen Behörden und viele Konzerne ihre Vorhaben führen.³³ In Großbritannien kaufte die Behörde für die Rechner der Regierung, die CCTA, 1989 ein Verfahren, das die Firma Simpact seit 1975 unter dem Namen PROMPT II verkaufte, und nannte es PRINCE, Projects in Controlled Environments: ein Vorgehen, das jedes Projekt in Phasen mit Entscheidungspunkten teilt, einen Lenkungsausschuss, ein Gremium aus Auftraggeber, Nutzern und Lieferanten, das die Phasen freigibt, über den Projektleiter setzt und für jede Rolle und jedes Dokument eine Vorlage hat. 1996 erschien PRINCE2 für Projekte jeder Art, und es wurde zum Standard der britischen Verwaltung, der Niederlande und vieler europäischer Konzerne.³⁴ Das PMI veröffentlichte im März 1987 ein Dokument mit dem Titel „Project Management Body of Knowledge“, das zusammenfasste, was der Beruf wissen muss, und 1996 den „Guide to the Project Management Body of Knowledge“, den PMBOK Guide, 176 Seiten mit neun Wissensgebieten und 37 Prozessen, von der Initiierung bis zum Abschluss; er ist seither die Bibel der Zunft, in jeder Auflage dicker, und 2012 übernahm die internationale Norm ISO 21500 seinen Aufbau mit fünf Prozessgruppen und zehn Themen, mit 39 statt der damals 42 Prozesse.³⁵ Die Bundesverwaltung bekam 1992 ihr eigenes Vorgehen für Software, das V-Modell, entwickelt von der IABG für die Bundeswehr, das die Phasen des Wasserfalls als V zeichnet, links hinunter die Zerlegung von den Anforderungen zum Code, rechts hinauf die Prüfung von der Einheit bis zur Abnahme, so dass jeder Entwurfsschritt seinen Test hat; 1997 kam das V-Modell 97, 2005 das V-Modell XT.³⁶

Das Zertifikat. Am 6. Oktober 1984 legten in Philadelphia 56 Menschen die erste Prüfung zum Project Management Professional ab, 43 bestanden. Der PMP, das Zertifikat des PMI, das Erfahrung und eine Prüfung über den PMBOK Guide verlangt, wurde zum Ausweis des Berufs, den Arbeitgeber in Stellenanzeigen verlangten und Hunderttausende erwarben; 2020 waren es über eine Million. PRINCE2 und die IPMA bekamen eigene Stufen, und aus dem Beruf wurde ein Markt für Kurse, Bücher und Prüfungen.³⁷

Der Rechner auf dem Tisch. Was 1957 einen UNIVAC gebraucht hatte, lief ab 1984 auf dem Personal Computer: Microsoft Project, zuerst für DOS, zeichnete Balkenpläne, rechnete den kritischen Weg und verteilte Ressourcen, und jeder, der einen PC hatte, konnte ein Projekt planen, ob er es konnte oder nicht. Die Projektsoftware, Programme, die Vorgänge, Abhängigkeiten, Termine, Ressourcen und Kosten eines Projekts verwalten und aus ihnen Pläne und Berichte erzeugen, machte die Methoden von Gantt, Kelley und dem Pentagon zur Büroarbeit; sie machte sie nicht richtiger.³⁸

Die Alternativen. Nicht alle glaubten an den Wasserfall. Barry Boehm, der bei TRW die Kosten von Software erforscht hatte, veröffentlichte 1986 das Spiralmodell: Ein Projekt durchläuft dieselben Schritte, Ziele, Risiken, Entwurf, Prüfung, mehrmals in immer größeren Runden, und in jeder Runde entscheidet das größte Risiko, was als Nächstes getan wird; die Spirale war das erste anerkannte Vorgehen, das Software in Schleifen statt in Phasen baute.³⁹ Robert Cooper beschrieb 1990, was die erfolgreichen Produktentwickler der Industrie taten: Sie teilten den Weg vom Einfall zum Produkt in Stufen und setzten zwischen die Stufen Tore, an denen entschieden wird, ob das Vorhaben weitergeht, umgebaut oder beendet wird; der Stage-Gate-Prozess wurde zum Standard der Produktentwicklung in Chemie, Pharma und Maschinenbau.⁴⁰ Eliyahu Goldratt, ein israelischer Physiker, hatte 1984 in dem Roman „The Goal“ die Theorie der Engpässe für Fabriken erzählt, dass jedes System genau einen Engpass hat und alles andere sich nach ihm richten muss, und wandte sie 1997 in „Critical Chain“ auf Projekte an: Die Leute, nicht die Vorgänge, sind der Engpass, jeder Einzelne polstert seine Schätzung mit Sicherheit, die er dann verbraucht, und deshalb solle man die Puffer aus den Vorgängen nehmen und als einen gemeinsamen Puffer an das Ende des Projekts legen. Die Critical-Chain-Methode hat Anhänger in der Industrie, aber den kritischen Weg nicht verdrängt.⁴¹

Die Zahlen des Scheiterns. 1994 veröffentlichte die Standish Group, eine kleine Beratungsfirma aus Massachusetts, ihren ersten CHAOS Report: Von den Softwareprojekten amerikanischer Firmen seien 16 Prozent zum Termin und im Budget fertig geworden, 53 Prozent verspätet, zu teuer oder gestutzt, und 31 Prozent abgebrochen worden. Die Methode der Studie war fragwürdig, die Befragten waren nach Misserfolgen gefragt worden, und spätere Forscher haben die Zahlen zerpflückt; aber sie waren das Erste, was die Branche über sich selbst gehört hatte, und sie wurden in jeder Präsentation der nächsten zwanzig Jahre zitiert.⁴² Zwei Großprojekte dieser Jahre lieferten die Bilder dazu. Der neue Flughafen von Denver sollte im Oktober 1993 öffnen, mit einer automatischen Gepäckanlage aus Dutzenden Kilometern Schienen und viertausend Wagen, die in der Vorführung Koffer zerriss und Wagen entgleisen ließ; der Flughafen öffnete im Februar 1995, sechzehn Monate später, mit einem herkömmlichen System daneben, und der Rechnungshof bezifferte die Kosten der Verzögerung auf 360 Millionen Dollar.⁴³ Der Eurotunnel öffnete 1994 ein Jahr zu spät und kostete real 80 Prozent mehr als geplant; die Aktionäre verloren ihr Geld, die Züge fahren bis heute.⁴⁴

Selbst ausprobieren. Earned Value ist drei Zahlen und zwei Brüche. Ein Projekt mit 100.000 Euro Budget soll nach sechs Monaten zur Hälfte fertig sein, Planwert 50.000. Tatsächlich sind 40 Prozent fertig, Fertigstellungswert 40.000, und ausgegeben sind 60.000. Terminindex 40.000 geteilt durch 50.000 gleich 0,8, Kostenindex 40.000 geteilt durch 60.000 gleich 0,67. Wenn es so weitergeht, kostet das Projekt 100.000 geteilt durch 0,67, also 150.000 Euro, und dauert zwölf geteilt durch 0,8, also fünfzehn Monate. Wer diese Rechnung im dritten Monat macht, kann noch etwas ändern; wer sie im zwölften macht, hat nur noch die Erklärung.

Der Engpass. 1997 gab es die Norm, das Lehrbuch, das Zertifikat und die Software, und ein Projektleiter in Stuttgart, Leeds und Denver verstand dieselben Worte. Aber die Norm beschrieb ein Projekt, dessen Ziel am Anfang feststeht, und immer mehr Projekte waren nicht so: Software, deren Nutzer erst beim Ausprobieren merkten, was sie wollten, Produkte für Märkte, die sich änderten, während man plante. Der Wasserfall verlangte, dass alles gewusst wird, bevor etwas gebaut wird, und bestrafte jede Änderung mit einem Antrag. Was fehlte, war ein Vorgehen, das das Nichtwissen am Anfang einrechnet, statt es wegzudefinieren.

6. Beweglich: Lean, Scrum und das Agile Manifest (1986–2010)

Rugby statt Staffellauf. Der Aufsatz, mit dem es begann, handelte nicht von Software. Hirotaka Takeuchi und Ikujiro Nonaka beschrieben im Januar 1986 in der Harvard Business Review, wie Fuji-Xerox, Honda und Canon ihre erfolgreichsten Produkte entwickelt hatten: nicht als Staffellauf, bei dem jede Abteilung den Stab an die nächste weitergibt, sondern wie beim Rugby, in dem die ganze Mannschaft den Ball gemeinsam über das Feld trägt. Kleine Teams aus allen Fachrichtungen, ein Ziel, aber keine Vorschrift des Weges, überlappende Phasen, Lernen während der Arbeit, Vorgesetzte, die den Rahmen setzen und sich heraushalten; sie nannten das Bild vom Gedränge Scrum.⁴⁵ Zugleich lernte der Westen von Toyota. James Womack und Daniel Jones beschrieben 1990 in „The Machine That Changed the World“ das Produktionssystem, das Taiichi Ohno seit den 1950er Jahren gebaut hatte: Nichts wird gefertigt, bevor es gebraucht wird, jeder Fehler hält das Band an, jeder Arbeiter verbessert seinen Schritt, und alles, was dem Kunden keinen Wert bringt, ist Verschwendung. Lean, die Lehre, Verschwendung zu vermeiden und den Fluss der Arbeit am Bedarf auszurichten, wanderte von der Fabrik in die Projektarbeit.⁴⁶

Scrum. Jeff Sutherland leitete 1993 bei der Firma Easel in Massachusetts die Entwicklung eines Werkzeugs und baute aus dem Aufsatz ein Vorgehen: ein Team von wenigen Leuten, das sich selbst organisiert, eine nach Wert geordnete Liste aller Wünsche, das Backlog, und feste Abschnitte von dreißig Tagen, in denen das Team den wertvollsten Teil der Liste zu einem Stück fertiger, vorführbarer Software macht, jeden Morgen ein Treffen von fünfzehn Minuten, am Ende eine Vorführung und ein Rückblick. Ken Schwaber, der an derselben Art von Werkzeugen arbeitete, stellte das Verfahren mit Sutherland 1995 auf der Konferenz OOPSLA in Austin vor. Scrum, das Rahmenwerk aus Rollen, Ereignissen und Artefakten, in dem ein Team in kurzen, festen Abschnitten, jeder ein Sprint, jeweils ein nutzbares Stück Produkt fertigstellt und den Plan danach neu ordnet, war das erste Vorgehen, das Royces Rückschleife zur Regel machte und das Nichtwissen am Anfang nicht als Mangel, sondern als Normalfall behandelte (Abbildung 6). Es löst das Problem des Wasserfalls, indem es ihn alle zwei Wochen von vorn durchläuft, im Kleinen.⁴⁷

Extreme Programming. Kent Beck übernahm im März 1996 bei Chrysler ein Gehaltsabrechnungsprojekt, das nicht vorankam, und machte es zum Versuchsfeld für Regeln, die er zusammen mit Ward Cunningham und Ron Jeffries entwickelte: zu zweit programmieren, den Test vor dem Code schreiben, jeden Tag alles zusammenbauen, den Kunden im Raum haben, in Abschnitten von Wochen liefern und nie mehr entwerfen, als die nächste Woche braucht. Das System ging 1997 für zehntausend Angestellte in Betrieb, Beck veröffentlichte 1999 „Extreme Programming Explained“, und Chrysler stellte das Projekt im Februar 2000 ein, bevor es alle Angestellten abrechnete; die Regeln überlebten das Projekt.⁴⁸ In Großbritannien hatte sich 1994 ein Konsortium von Firmen auf DSDM geeinigt, die Dynamic Systems Development Method, die feste Zeit und festes Budget setzt und den Umfang zur Variablen macht, das magische Dreieck auf den Kopf gestellt.⁴⁹

Das Manifest. Vom 11. bis 13. Februar 2001 trafen sich siebzehn Männer, Sutherland, Schwaber, Beck, Cunningham, Jeffries, Martin Fowler, Alistair Cockburn und andere, in einem Skihotel in Snowbird, Utah, um zu klären, was ihre Verfahren gemeinsam hatten. Sie schrieben vier Sätze auf: Individuen und Interaktionen mehr als Prozesse und Werkzeuge, funktionierende Software mehr als umfassende Dokumentation, Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung, Reagieren auf Veränderung mehr als das Befolgen eines Plans, und darunter zwölf Prinzipien, und nannten es das Manifest für agile Softwareentwicklung. Agil heißt seither jedes Vorgehen, das in kurzen Abschnitten liefert, aus dem Gelieferten lernt und den Plan dem Gelernten anpasst, statt das Gelernte dem Plan.⁵⁰ Das Wort machte Karriere, wie kaum eines in der Geschichte des Managements: Schwaber gründete 2002 die Scrum Alliance, die ab 2003 nach einem zweitägigen Kurs das Zertifikat Certified ScrumMaster vergab, Hunderttausende erwarben es, und zehn Jahre nach Snowbird nannte sich fast jede Softwareabteilung der Welt agil, ob sie es war oder nicht.⁵¹

Kanban. David Anderson leitete 2004 bei Microsoft eine kleine Abteilung, die Wartungsaufträge bearbeitete und unter dem Berg der Anfragen begraben war. Statt Sprints führte er ein, was Toyota an seinen Bändern tat: eine Tafel mit Spalten für die Schritte, Karten für die Aufgaben, und eine Zahl über jeder Spalte, die sagt, wie viele Karten dort zugleich sein dürfen. Wer eine Karte weiterschieben will, muss warten, bis Platz ist, und der Stau zeigt, wo das System hakt. Die Durchlaufzeit sank nach Andersons eigener Darstellung in einem Jahr von fünf Monaten auf fünf Wochen. Anderson wiederholte das 2007 bei Corbis und veröffentlichte die Methode 2010; Kanban, die Steuerung der Arbeit über eine Tafel mit begrenzter Zahl gleichzeitiger Aufgaben je Schritt, wurde zur zweiten Säule der agilen Welt, ohne Sprints, ohne Rollen, mit einer einzigen Regel: nicht mehr anfangen, als man zu Ende bringt.⁵²

DevOps und die Werkzeuge. Die letzte Mauer stand zwischen denen, die Software bauten, und denen, die sie betrieben. Am 23. Juni 2009 zeigten John Allspaw und Paul Hammond von Flickr auf der Konferenz Velocity, dass ihre Firma mehr als zehnmal am Tag neue Software in Betrieb nahm, weil Entwickler und Betreiber dieselben Werkzeuge, dieselbe Verantwortung und dasselbe Ziel hatten; Patrick Debois, ein belgischer Berater, der den Vortrag im Netz sah, lud im Oktober nach Gent zu den ersten DevOpsDays, und das Wort war in der Welt. DevOps, die Zusammenarbeit von Entwicklung und Betrieb mit gemeinsamer Verantwortung und automatisierter Auslieferung, machte aus dem Projekt, das endet, wenn die Software übergeben ist, ein Produkt, das nie endet.⁵³ Die Werkzeuge folgten: Jira, 2002 von Atlassian in Sydney als Fehlerverwaltung begonnen, wurde zur Tafel für Sprints und Backlogs, Trello brachte im September 2011 die Kanban-Tafel in den Browser, und wer 2015 ein Projekt führte, tat es in diesen Programmen, nicht mehr in Microsoft Project.⁵⁴

Selbst ausprobieren. Scrum lässt sich an einem Wochenende lernen, mit einem Vorhaben, das einem gehört: ein Garten, ein Buch, ein Umzug. Die Liste aller Wünsche aufschreiben, nach Wert ordnen, den obersten Teil für eine Woche auswählen, jeden Morgen drei Fragen beantworten, was gestern geschafft wurde, was heute ansteht, was im Weg ist, am Ende der Woche ansehen, was fertig ist, und die Liste neu ordnen. Wer das zweimal gemacht hat, weiß, warum der Rückblick der wichtigste Teil ist und warum die Liste am Ende der zweiten Woche anders aussieht als am Anfang der ersten.

Der Engpass. 2010 gab es ein Vorgehen für Vorhaben, deren Ziel sich beim Bauen klärt, und es funktionierte, für ein Team von sieben Leuten in einem Raum. Aber die Projekte, an denen die Welt hing, hatten hundert Teams, Verträge mit Festpreis, Aufsichtsbehörden, die Dokumente verlangten, und Vorstände, die wissen wollten, was es am Ende kostet. Die agile Welt hatte dafür keine Antwort, und die klassische Welt hatte ihre Antwort nicht geändert. Was fehlte, war der Maßstab: ein Weg, Beweglichkeit über ein Team hinaus zu tragen, und ein Verständnis dafür, warum die größten Projekte trotz aller Methoden weiter scheiterten.

7. Maßstab: Skalierung, Hybride und die Großprojekte (2010–2022)

Agil im Großen. Die Antwort der Berater auf die hundert Teams hieß Rahmenwerk. Dean Leffingwell und Drew Jemilo veröffentlichten 2011 das Scaled Agile Framework, SAFe, ein Schaubild, das Teams zu Zügen bündelt, Züge zu Lösungen, Lösungen zu einem Portfolio, mit Planungstreffen alle zehn Wochen, an denen hundert Leute zwei Tage in einer Halle stehen, und mit Rollen für alles, was ein Konzern gewohnt ist. Kritiker aus der agilen Bewegung hielten es für den Wasserfall in neuen Kleidern; die Konzerne führten es ein, weil es sich in ihre Hierarchien und Budgets einfügte.⁵⁵ Henrik Kniberg und Anders Ivarsson beschrieben 2012 in einem Aufsatz, wie Spotify seine Entwicklung in Squads, Tribes, Chapters und Guilds gliederte, und das „Spotify-Modell“ wurde in Banken und Versicherungen kopiert, die kein Spotify waren; 2019 sagte einer der Beteiligten, Spotify selbst habe das Modell nie so benutzt, wie es die Kopien beschrieben.⁵⁶ Die Normen gaben nach. PRINCE2 bekam 2015 eine agile Ausgabe, der PMBOK Guide 2017 einen Leitfaden für agile Praxis, ISO 21502 löste 2020 die ISO 21500 ab, und der Begriff hybrides Projektmanagement, die Verbindung klassischer Phasen, Meilensteine und Budgets mit agiler Arbeit innerhalb der Phasen, wurde zur Beschreibung dessen, was die meisten Firmen ohnehin taten.⁵⁷

Das eiserne Gesetz. Während die Software beweglich wurde, blieben die Bauten, wie sie waren. Bent Flyvbjerg, ein dänischer Planungsforscher in Oxford, hatte seit den 1990er Jahren Daten über Großprojekte gesammelt, Brücken, Tunnel, Bahnen, Kraftwerke, Olympische Spiele, Rechenzentren, und 2003 in „Megaprojects and Risk“ den Befund veröffentlicht, der seither sein eisernes Gesetz heißt: über dem Budget, über der Zeit, unter dem Nutzen, immer wieder. Neun von zehn Großprojekten überschreiten ihre Kosten, die Überschreitungen sind seit siebzig Jahren nicht kleiner geworden, und sie sind in allen Ländern gleich.⁵⁸ Die Ursache fand er nicht in der Technik, sondern bei Daniel Kahneman und Amos Tversky, die 1979 den Planungsfehlschluss beschrieben hatten: Menschen schätzen Dauer und Kosten eines Vorhabens, indem sie sich seinen Ablauf vorstellen, und der vorgestellte Ablauf enthält keine Überraschungen, während der wirkliche aus ihnen besteht. Dazu kommt, was Flyvbjerg strategische Fehldarstellung nennt: Wer ein Projekt genehmigt haben will, rechnet es klein, und das Projekt, das am kleinsten gerechnet wird, bekommt das Geld. Die Abhilfe, die er mit Kahneman entwickelte, heißt Referenzklassenprognose: nicht den eigenen Plan durchrechnen, sondern eine Klasse ähnlicher, abgeschlossener Projekte nehmen und fragen, wie sie ausgegangen sind. Das britische Finanzministerium schrieb das Verfahren 2004 für öffentliche Vorhaben vor, mit Aufschlägen auf jeden Voranschlag je nach Projektart; Dänemark, die Schweiz und die Niederlande folgten.⁵⁹

Deutschland baut. Die deutschen Beispiele dieser Jahre stehen in jedem Lehrbuch der Welt. Der Flughafen Berlin Brandenburg, erster Spatenstich am 5. September 2006, sollte am 30. Oktober 2011 öffnen, bei Baukosten von rund zwei Milliarden Euro. Der Termin wurde im Juni 2010 auf den 3. Juni 2012 verschoben, weil ein Planungsbüro insolvent war, und am 8. Mai 2012, vier Wochen vor der Eröffnung, abgesagt, weil die Brandschutzanlage nicht abgenommen wurde; es folgten weitere Termine, Gutachten über die Entrauchungsanlage und Tausende Kilometer Kabel, von denen viele falsch verlegt waren, und mehrere Flughafenchefs. Der BER öffnete am 31. Oktober 2020, bei Kosten von über sechs Milliarden Euro, mit Finanzierungskosten über sieben. Die Untersuchungsausschüsse in Berlin und Potsdam fanden, was Sydney gefunden hatte: Der Bau begann, bevor die Planung fertig war, die Flughafengesellschaft der drei Eigentümer Berlin, Brandenburg und Bund hatte 2008 nach einer gescheiterten Ausschreibung auf einen Generalunternehmer verzichtet und die Steuerung selbst übernommen, ohne dafür gerüstet zu sein, und der Bau wurde während der Ausführung vergrößert und umgeplant, in einem System, das für Änderungen nicht gebaut war.² Die Elbphilharmonie in Hamburg wurde 2005 mit 186 Millionen Euro Gesamtkosten geplant, davon 77 Millionen für die Stadt; bei der Grundsteinlegung 2007 waren es 241 und 114 Millionen, bei der Eröffnung am 11. Januar 2017 866 und 789 Millionen, und der Untersuchungsausschuss der Bürgerschaft nannte als Ursache eine unfertige Planung beim Baubeginn, fehlende Kontrolle und eine Baustelle, auf der Bauherr, Architekt und Baufirma einander mit Nachträgen und Stillständen bekämpften. Das Haus ist seither ausverkauft.⁶⁰ Stuttgart 21, der Umbau des Kopfbahnhofs in einen Tiefbahnhof, wurde 2009 mit 4,5 Milliarden Euro und einer Eröffnung 2019 vereinbart; nach dem Stand der Bahn vom Juni 2026 kostet es rund 14,5 Milliarden, und der Bahnhof soll im Dezember 2031 in Betrieb gehen, zwölf Jahre später als versprochen. Ein Gericht entschied 2024, dass die Bahn die Mehrkosten allein trägt.³ In London öffnete die Elizabeth Line am 24. Mai 2022, dreieinhalb Jahre nach dem Termin, für 18,9 statt 14,8 Milliarden Pfund, und der Rechnungshof beschrieb, wie die Bahn die Verspätung bis wenige Monate vor dem Termin vor ihren Eigentümern verborgen hatte.⁶¹

Asien baut. Die Gegenbeispiele kamen aus Asien, und sie bestätigten die Regel. E. Sreedharan, ein Eisenbahningenieur, der 1997 die Leitung der Delhi Metro übernahm, eröffnete die erste Strecke am 24. Dezember 2002 und schloss die erste Ausbaustufe 2005 ab, zwei Jahre und neun Monate vor dem Termin und im Budget, mit japanischen Krediten, einer Vollmacht, die ihn von der Politik abschirmte, und einer Baustelle, auf der jeder Vertrag eine Strafe für Verzug enthielt; die Metro wurde zum Vorbild für ein Dutzend indischer Städte.⁶² China baute ab 2008, als die Strecke von Peking nach Tianjin öffnete, in sechzehn Jahren ein Schnellbahnnetz von 48.000 Kilometern, mehr als der Rest der Welt zusammen, mit einem einzigen Streckentyp, einem Bahnhofstyp und Baumannschaften, die von einer Strecke zur nächsten zogen, also mit der Modularität, die Flyvbjerg empfiehlt; seine Untersuchung von 95 chinesischen Verkehrsprojekten fand allerdings dieselben Kostenüberschreitungen wie in den reichen Demokratien, im Mittel 30,6 Prozent, und keine bessere Trefferquote beim Nutzen. Japan hatte 2001 mit P2M einen eigenen Standard veröffentlicht, der nicht beim Projekt, sondern beim Programm ansetzt, der Frage, welchen Wert ein Bündel von Projekten für das Unternehmen schafft, zwanzig Jahre bevor der PMBOK Guide dieselbe Wendung nahm.⁶²

Was anders war. Flyvbjerg hat die Projekte, die gelingen, ebenso untersucht wie die, die scheitern, und ihre Regeln sind die Regeln von Eiffel und Crowe: langsam denken, schnell handeln, also die Planung so lange treiben, bis sie fertig ist, und dann bauen, ohne anzuhalten; das Vorhaben aus Bausteinen zusammensetzen, die man schon einmal gebaut hat, wie die Madrider Metro, die zwischen 1995 und 2003 131 Kilometer Strecke und 76 Bahnhöfe baute, nach Flyvbjergs Rechnung in der halben Zeit und zur Hälfte der Kosten vergleichbarer Netze, weil sie bewährte Tunnelbohrer, einen Bahnhofstyp und erfahrene Bauleiter nahm; und ein Team, das das Werk schon einmal gemacht hat. Windparks, Solarfelder und Stromleitungen stehen in seinen Daten am oberen Ende, weil sie aus Modulen bestehen, Kernkraftwerke, Olympische Spiele und Rechenzentren mit eigener Software am unteren, weil jedes ein Unikat ist.¹ Das Projektmanagement hatte in sechzig Jahren alle Werkzeuge gebaut, die man braucht; die Projekte scheiterten dort, wo sie nicht benutzt wurden, und sie wurden nicht benutzt, weil das Versprechen vor dem Plan kam.

Selbst ausprobieren. Eine Referenzklassenprognose braucht keine Datenbank. Wer ein Vorhaben schätzt, einen Umbau, eine Softwareeinführung, eine Dissertation, sucht zehn ähnliche, die abgeschlossen sind, bei Bekannten, in Berichten, in den eigenen Unterlagen, und schreibt für jedes auf, um wie viel es länger gedauert und mehr gekostet hat als geplant. Der Mittelwert dieser Zahlen ist der Aufschlag auf die eigene Schätzung. Er liegt fast immer über dem, was man sich selbst zugestanden hätte, und das ist der Planungsfehlschluss, gemessen am eigenen Leib.

Der Engpass. 2022 wussten die Forscher, warum Großprojekte scheitern, die Normen hatten die Beweglichkeit aufgenommen, und die Werkzeuge waren auf jedem Rechner. Aber das Wissen änderte die Projekte nicht, weil es gegen die Anreize derer stand, die sie beschließen; Stuttgart 21 wurde 2009 nach allem beschlossen, was Flyvbjerg bis dahin veröffentlicht hatte. Und ein neues Werkzeug begann, Pläne zu schreiben, Berichte zu erzeugen und Risiken zu benennen, schneller als jeder Projektleiter, und niemand wusste, ob es die Projekte besser machte oder nur die Berichte.

8. Wer steuert: KI, Prinzipien und das offene Versprechen (seit 2020)

Die Normen werden weich. Die Pandemie machte 2020 aus den Projektbüros Bildschirme, und die Normen zogen die Folgerung aus zwanzig Jahren agilen Streits. Der PMBOK Guide erschien 2021 in seiner siebten Auflage und war zum ersten Mal kein Prozesshandbuch mehr: Statt 49 Prozessen mit Eingaben und Ausgaben beschrieb er zwölf Prinzipien, Verantwortung, Zusammenarbeit, Wert, Anpassung, und acht Leistungsbereiche, und überließ die Wahl der Methode dem Projekt; die achte Auflage vom November 2025 kürzte auf sechs Prinzipien und sieben Bereiche und nahm Abschnitte über künstliche Intelligenz auf. PRINCE2 bekam im September 2023 seine siebte Ausgabe, die als Erste ein Kapitel über die Menschen enthielt, mit denen das Projekt gemacht wird.⁶³ Vierzig Jahre nach dem ersten Zertifikat hatten die Verbände anerkannt, dass das Verfahren nicht die Methode ist, sondern das Urteil.

Die Maschine plant. Gartner hatte im März 2019 vorhergesagt, dass bis 2030 achtzig Prozent der heutigen Arbeit des Projektmanagements, das Sammeln von Daten, das Verfolgen, das Berichten, von künstlicher Intelligenz erledigt werde.⁶⁴ Ab 2023 kam die Technik, die das möglich machte, in die Werkzeuge: Das PMI stellte im Januar 2024 PMI Infinity vor, einen Assistenten, der auf den Normen des Verbands antwortet, Atlassian baute Sprachmodelle in Jira ein, erst als Assistent Rovo, 2025 als Agenten, denen man Aufgaben zuweist wie einem Teammitglied, und Microsoft legte seinen Copilot über Planner, Project und Teams, so dass ein Statusbericht aus den Daten entsteht, ohne dass ein Mensch ihn schreibt. Ein KI-Agent im Projekt, ein Programm aus Sprachmodell und Werkzeugen, das Aufgaben anlegt, zuordnet, verfolgt, Risiken meldet und Berichte erzeugt, nahm dem Projektleiter die Arbeit ab, die Gantt 1917 mit Bleistift getan hatte.⁶⁵ Die Geschichte des Vibe-Coding erzählt, wie dieselben Agenten die Arbeit in Softwareprojekten selbst übernahmen, mit Folgen, die 2026 Amazon dreizehn Stunden Ausfall und einen Sicherheitsreset kosteten: Der Agent hatte entschieden, eine Umgebung zu löschen und neu zu bauen, und niemand hatte die Entscheidung gelesen.

Was die Zahlen sagen. Die Verbände zählten derweil, was bleibt. Das PMI schätzte 2021, dass die Welt bis 2030 25 Millionen zusätzliche Menschen braucht, die Projekte führen, 2,3 Millionen im Jahr, weil mehr Arbeit als Projekt organisiert wird, die Schwellenländer bauen und die Generation von Apollo in Rente geht.⁴ Seine jährliche Umfrage setzte 2024 eine neue Definition des Erfolgs: nicht mehr Termin, Budget und Umfang, das Dreieck von 1969, sondern der Wert, den das Projekt für die stiftet, die es bezahlt haben; nach dem alten Maß scheitern seit Jahrzehnten dieselben Anteile.⁶⁶ Flyvbjerg und Dan Gardner fassten 2023 in „How Big Things Get Done“ die Datenbank von 16.000 Projekten zusammen: 47,9 Prozent im Budget, 8,5 Prozent im Budget und in der Zeit, 0,5 Prozent im Budget, in der Zeit und mit dem versprochenen Nutzen. Ein Projekt von zweihundert hält, was es versprochen hat.¹

Wer steuert. Die Frage, die der Agent stellt, ist die Frage von Gaddis in neuer Form. 1959 war der Projektleiter der Mensch, der ohne Befehlsgewalt für das Ganze einstand; 2026 schreibt ein Programm den Plan, verfolgt die Aufgaben, meldet die Risiken und schlägt vor, was als Nächstes zu tun ist, und der Mensch, der die Vorschläge annimmt, steht weiter für das Ganze ein. Die Werkzeuge haben den Teil des Berufs übernommen, der sich aufschreiben ließ: den Balkenplan, den Netzplan, den Fertigstellungswert, den Bericht. Übrig bleibt der Teil, der sich nie aufschreiben ließ, und das ist der, an dem die Projekte seit de Lesseps scheitern: das Versprechen am Anfang, die Entscheidung, zu bauen, bevor man weiß, was, und das Gespräch, in dem jemand sagt, dass der Termin nicht zu halten ist, bevor es alle wissen. Stuttgart 21, beschlossen mit allen Werkzeugen dieser Chronik, wird 2031 fertig, wenn es gut geht, und keine Software hätte das verhindert; verhindert hätte es ein Mensch, der 2009 die Referenzklasse gezogen und die Zahl ausgesprochen hätte.

Selbst ausprobieren. Was ein Agent beim Planen kann und was nicht, zeigt ein Versuch von zehn Minuten. Einem Assistenten, ChatGPT, Claude, Gemini, Copilot, ein Vorhaben beschreiben, etwa die Einführung einer neuen Software in einer Firma mit fünfzig Leuten, und um einen Plan mit Vorgängen, Abhängigkeiten, Dauern und Risiken bitten. Der Plan kommt in Sekunden und sieht aus wie aus dem Lehrbuch. Dann prüfen: Welche Abhängigkeit fehlt, die nur kennt, wer die Firma kennt? Welche Dauer ist geraten? Woher stammt die Risikoliste? Der Agent liefert den Plan, den ein Lehrbuch liefern würde, und das ist genau der Plan, den der Planungsfehlschluss beschreibt: vollständig, plausibel und ohne die Überraschungen, aus denen das Projekt bestehen wird.

Der Engpass. Die Kette dieses Textes endet mit einem offenen Glied. Jede Stufe seit 1896 hat ein Stück des Wegs zwischen Versprechen und Werk auf das Papier und dann auf die Maschine verlagert: die Zeit auf den Balkenplan, die Abhängigkeit auf den Netzplan, den Fortschritt auf den Fertigstellungswert, die Methode auf die Norm, das Lernen auf den Sprint, den Bericht auf den Agenten. Die letzte Stufe verlagert das Planen selbst, und mit ihm die Frage, wer für den Plan einsteht. Offen ist, ob ein Programm, das aus allen Projekten der Welt gelernt hat, den Planungsfehlschluss vermeidet oder ihn mit größerer Überzeugung wiederholt. Offen ist, wer die Zahl ausspricht, die niemand hören will, wenn der Bericht sie nicht enthält. Und offen ist, ob ein Projekt, das zweitausend Jahre lang ein Versprechen zwischen Menschen war, eines bleibt, wenn eine Maschine es formuliert. Die Antwort wird nicht in der Software fallen, sondern dort, wo sie immer gefallen ist: am Anfang, bei der Frage, ob man schon weiß, was man baut.

Die Kette in Kurzform

1. Bis 1900 bauen Baumeister und Ingenieure Pyramiden, Kanäle und Türme aus dem Kopf; Panama scheitert mit dem Mann, Eiffel gelingt mit der Vorbereitung; es fehlt das Papier, auf dem die Zeit steht.
2. Adamiecki, Taylor und Gantt (1896–1936) bringen die Zeit auf das Papier; der Balkenplan baut Hoover Dam und Empire State Building, zeigt aber nicht, wovon ein Vorgang abhängt.
3. Manhattan, CPM und PERT (1942–1962) machen aus dem Plan ein Netz mit kritischem Weg, Projektstrukturplan und Wahrscheinlichkeit; der Projektleiter hat einen Namen, aber keine Organisation.
4. Apollo (1961–1975) liefert Matrix, Konfigurationsmanagement und Earned Value, die Verbände entstehen, Sydney und OS/360 zeigen die Grenzen; es fehlt die Norm.
5. PMBOK, PRINCE, DIN 69901 und das Zertifikat (1975–1997) geben dem Beruf Sprache und Ausweis, die Software den Plan auf jeden Tisch; der Wasserfall verlangt Wissen, das am Anfang fehlt.
6. Lean, Scrum und das Agile Manifest (1986–2010) rechnen das Nichtwissen ein und liefern in Sprints; es trägt ein Team, nicht hundert.
7. SAFe, Hybride und Flyvbjergs Gesetz (2010–2022) skalieren die Beweglichkeit und erklären das Scheitern der Großprojekte durch Planungsfehlschluss und Anreiz; BER, Elbphilharmonie und Stuttgart 21 liefern die Belege.
8. Prinzipien statt Prozesse und Agenten statt Berichte (seit 2020) verlagern das Planen auf die Maschine; offen ist, wer für den Plan einsteht.

Zeitleiste

Weiterlesen

• Bent Flyvbjerg, Dan Gardner: How Big Things Get Done. The Surprising Factors Behind Every Successful Project, from Home Renovations to Space Exploration. Crown, New York 2023 (deutsch: How Big Things Get Done. Was man über das Gelingen großer Vorhaben wissen muss, Campus, Frankfurt 2023). Die Daten von 16.000 Projekten und die Regeln, die daraus folgen.
• Peter W. G. Morris: The Management of Projects. Thomas Telford, London 1994. Die Geschichte des Berufs von den Netzplänen bis in die 1990er Jahre, von einem der Gründer der Disziplin.
• Frederick P. Brooks: The Mythical Man-Month. Essays on Software Engineering. Addison-Wesley, Reading, MA 1975, Jubiläumsausgabe 1995 (deutsch: Vom Mythos des Mann-Monats, mitp, Bonn 2003). Warum Software anders ist, aus der Erfahrung von OS/360.
• Stephen B. Johnson: The Secret of Apollo. Systems Management in American and European Space Programs. Johns Hopkins University Press, Baltimore 2002. Wie die NASA und die Luftwaffe lernten, das Unmögliche zu organisieren.
• Harvey M. Sapolsky: The Polaris System Development. Bureaucratic and Programmatic Success in Government. Harvard University Press, Cambridge, MA 1972. Was PERT wirklich war.
• David McCullough: The Path Between the Seas. The Creation of the Panama Canal, 1870–1914. Simon & Schuster, New York 1977. Das Scheitern der Franzosen und das Gelingen der Amerikaner.
• Jeff Sutherland: Scrum. The Art of Doing Twice the Work in Half the Time. Crown Business, New York 2014 (deutsch: Die Scrum-Revolution, Campus, Frankfurt 2015). Die Entstehung von Scrum, von einem seiner Erfinder.
• Tom DeMarco, Timothy Lister: Peopleware. Productive Projects and Teams. Dorset House, New York 1987, 3. Auflage 2013 (deutsch: Wien wartet auf Dich!, Hanser, München 1991). Warum Projekte an Menschen scheitern, nicht an Technik.
• Heinz Schelle, Roland Ottmann, Astrid Pfeiffer: ProjektManager. GPM Deutsche Gesellschaft für Projektmanagement, Nürnberg, laufend neu aufgelegt. Das deutsche Lehrbuch des Verbands.

Quellen

Die Chronik stützt sich auf die Originalarbeiten, Normen, Berichte der Rechnungshöfe und Untersuchungsausschüsse, Pressemitteilungen und zeitgenössischen Berichte, die in den Fußnoten genannt sind.