Читать книгу Agiler Kapitalismus - Timo Daum - Страница 12

Am 2. April 1917 forderte Woodrow Wilson, damals Präsident der Vereinigten Staaten von Amerika, den Kongress auf, der deutschen Reichsregierung den Krieg zu erklären; vier Tage später traten die USA in den Ersten Weltkrieg ein. Die Achsenmächte ließen sich durch diese Nachricht zunächst nicht aus der Ruhe bringen – lagen die USA doch geografisch weit entfernt vom europäischen Kriegsschauplatz, auch ihre militärische Stärke schätzte der Generalstab gering ein. Die erste große Herausforderung für die US-Armee war denn auch eine logistische: Es galt, innerhalb kurzer Zeit Millionen Soldaten und Seeleute zu mobilisieren und mitsamt ihrer Ausrüstung auf eine lange Reise zu schicken; auf dem beschwerlichen Weg von Newport News in Virginia bis nach Frankreich mussten knapp 7.000 Kilometer mit Bahn und Schiff zurückgelegt werden. Mit der gigantischen Aufgabe, für die es keinerlei Blaupausen gab – Erfahrungen aus dem über ein halbes Jahrhundert zurückliegenden Amerikanischen Bürgerkrieg waren angesichts der seither veränderten Kriegstechnik unbrauchbar –, wurde das United States Army Ordinance Corps betraut, die Versorgungsabteilung der US-Armee unter General William Crozier.

Der oberste Nachschuboffizier der USA beauftragte einen jungen Maschinenbauingenieur namens Henry Gantt, auf den er bei Inspektionen von Rüstungsbetrieben aufmerksam geworden war, mit der Planung des gigantischen Projekts. Gantt hatte in diesen Unternehmen erfolgreich eine neue Organisationsmethode implementiert, die für umfangreiche Bereitstellungsprojekte wie geschaffen war. Sie beruhte wesentlich auf einem Diagramm zur Visualisierung von Projektabläufen, das er wenige Jahre zuvor erfunden hatte. Diese zweidimensionalen Ablaufschemata für unterschiedliche Teilprozesse erwiesen sich als ungemein effektiv, etwa um Abhängigkeiten von Projektphasen voneinander abbilden zu können, z. B. wenn eine Aktivität erst begonnen werden kann, sobald eine andere beendet ist.

Bereits drei Monate nach Kriegseintritt betraten die ersten amerikanischen Truppen französischen Boden. Im weiteren Verlauf des Krieges organisierte Crozier den Transport von über einer Million Soldaten, die Pioniere der US-Armee bauten im Laufe des Krieges 82 neue Schiffsanlegestellen und verlegten über 100.000 Kilometer Telefon- und Telegrafenkabel auf dem alten Kontinent.¹ Der Kriegseintritt der USA war schließlich doch kriegsentscheidend geworden – nicht zuletzt aufgrund der beeindruckenden logistischen Leistungen der Nachschubabteilung der US-Armee und der erfolgreichen Planungsmethoden Gantts. Nach der Kapitulation der Achsenmächte eroberten Henry Gantts Diagramme auch die zivile Welt. Eines der berühmtesten Projekte, das mit Gantts Diagrammen realisiert wurde, war der 221 Meter hohe Hoover-Staudamm, der nach nur vier Jahren Bauzeit 1935 eingeweiht werden konnte.² Die charakteristischen Ablaufpläne Gantts finden bis heute Verwendung und wurden immer wieder aktualisiert und verfeinert. Die Vordenker der Wirtschaftsinformatik Kenneth und Jane Laudon definieren ein Projekt als »geplante Abfolge miteinander verbundener Aktivitäten zur Erreichung eines bestimmten Unternehmensziels«. Im klassischen Projektmanagement werden Projekte als lineare Abfolge von Projektschritten abgearbeitet, die allesamt auf detaillierten Vorgaben beruhen – das zugrunde liegende Modell heißt Wasserfall, und Gantts Diagramme sind seine allgemein verbreitete Visualisierung. Diese Vorgehensweise erfordert allerdings detaillierte Planung, was oft zu einem hohen Aufwand bei der Festlegung der Erfordernisse führt. Es setzt weiterhin klar getrennte Aufgabenbereiche voraus; Zuständigkeiten, Rollen und Projektphasen sind im Vorhinein klar definiert. Das hohe Maß an Arbeitsteilung produziert eine Vielzahl kritischer Abhängigkeiten und erhöht den Steuerungsaufwand zusätzlich. Zur Steuerung des Projektablaufs ist daher intensives kleinteiliges Management nötig, was wiederum mit streng hierarchischen Organisationsstrukturen am besten funktioniert – die Entstehungsgeschichte im militärischen Kontext lässt grüßen.

Gantt-Chart im klassischen Projektmanagement

Nicht nur das moderne Projektmanagement, auch die Entwicklung von Computern und der für diese geschriebenen Software haben starke Wurzeln im militärischen Bereich – die ersten Computeranwendungen, allen voran das Internet, fanden in diesem Kontext statt, oft auch finanziell gefördert durch das Militär. In der Sowjetunion war die Computerindustrie insgesamt Geheimsache und militärischen Erfordernissen untergeordnet, mit ein Grund für die letztlich immer mehr ins Hintertreffen geratende IT-Industrie jenseits des Eisernen Vorhangs.

Mit »einem für die Nutzung von Computern entscheidenden Problem, der sogenannten Software, die zu ihrer Steuerung entwickelt wurde«, befasste sich im November 1968 eine von der NATO finanzierte Tagung; neben der Hardware gelangte Ende der 1960er zunehmend auch diese in den Fokus militärischer Planung. Zu der Tagung kamen Expertinnen aus nahezu allen NATO-Ländern nach Garmisch-Partenkirchen, um darüber zu debattieren, wie Softwareprojekte vernünftig zu managen seien – seit Gantts Erfolgen beim militärischen Logistikmanagement waren gut 50 Jahre vergangen. Den Vorsitz führte Friedrich Bauer, Mathematikprofessor an der TU München. Der Abschlussbericht legt beredtes Zeugnis ab über den Stand der jungen Disziplin Softwareentwicklung und wartet mit einer Checklist für gutes IT-Projektmanagement auf.³

Gleich zu Beginn heißt es darin: »Das neue System wird seinem Vorgänger und Lösungen der Konkurrenz deutlich überlegen sein.« Daraufhin wird betont, alle Spezifikationen und Anforderungen müssten im Vorhinein absolut verbindlich festgelegt und in einem detaillierten Anforderungskatalog niedergelegt sein. »Der neue Computer ist eine großartige Maschine; die Programmierer werden ihn lieben, sobald sie ihre Handbücher bekommen«, wird erklärt, gefolgt von der Versicherung: »Die Integration des neuen Systems in bestehende Software ist trivial, darum kann man sich später immer noch kümmern.« Im Anschluss geht es auch noch um Geld: »Der Projektmanager hat möglicherweise das Budget für sein letztes Projekt überzogen, aber er hat seine Lektion gelernt und wird es diesmal nicht tun.« Quantitative Überlegungen schließen das Dokument ab: »Addieren Sie für jeden Budgetposten zehn Prozent zu den geschätzten Kosten und einen Monat zur geschätzten Zeit.«

Nachdem zunächst grenzenlose Zuversicht verbreitet wird, offenbart sich im zweiten Punkt die Achillesferse des klassischen Projektmanagements: In der realen Welt ist die absolut verbindliche Spezifikation eben nichts weiter als Wunschdenken – es ist schlicht unmöglich, im Voraus alle Eventualitäten abzusehen, planerisch zu erfassen und in einer fixen Spezifikation niederzulegen. Auch das quasireligiöse Einschwören auf die Segnungen der Technologie, bei der die Leserschaft so richtig »mitgenommen« wird, kann den groben Leichtsinn nicht verdecken: Wer sich nur ein wenig mit der Entwicklung von Software befasst hat, weiß, wie schwierig und unwägbar die Integration von Neuentwicklungen in bestehende Systeme sein kann. Auch der Umgang mit Zeit- und Budgetplanung kommt eher hemdsärmelig daher. Dieser frühe Versuch, das klassische Projektmanagement auf die Produktion von Software zu übertragen, kann daher gut und gerne als naiv und blauäugig bezeichnet werden.

Deutlich besser machte es dann einige Jahre später der Informatiker Winston Royce. In einem Artikel für das Magazin von IEEE, dem amerikanischen Verband der Elektroingenieure, schlug er eine Adaption des Wasserfallmodells für Softwareentwicklungsprojekte vor, in dem erstmals alle wichtigen Stufen sequentieller Entwicklung von Softwareprojekten benannt waren, die bis heute Standard sind – von Anforderungen bis Wartung.⁴ In der Folgezeit etablierte sich das Wasserfallmodell auch in der Softwareentwicklung. »Bis die verbesserten Ansätze, die auf agilen Techniken basierten, sie um 2008 übertrafen, war die Wasserfallmethode der gebräuchlichste Projektmanagementansatz in der Softwareentwicklung«, schreibt Mark C. Layton, der Autor eines Standardwerks zur Einführung in Agilität.⁵ »Eins nach dem anderen« lautete das Credo des alten Wasserfallmodells. Oft waren daher unflexible Projekte, ein erheblicher Steuerungsaufwand und ausufernde Dokumentationen die Folge. Ein weiterer Nachteil wasserfallartig gemanagter Projekte ist das Fehlen von Zwischenetappen: Das Ergebnis von Projektschritten bzw. der Erfolg eines Projekts ist erst ganz zum Schluss erkennbar, bei Misserfolg ist es für Gegenmaßnahmen oft zu spät. Etwaige Änderungen der Projektziele sind nach dem Projektstart nicht vorgesehen, im Extremfall muss das Ende abgewartet werden, bevor Korrekturen implementiert werden können, die wiederum die gesamte Kaskade durchlaufen müssen. Einer, der dem Wasserfallmodell zusammen mit anderen bald den Garaus machen würde, Jeff Sutherland, benennt die Probleme seiner Übertragung auf Softwareprojekte: »Der Prozess war langsam, unvorhersehbar und führte oft zu einem Produkt, das die Leute gar nicht haben oder kaufen wollten.«⁶

Das Wasserfallmodell in der Softwareentwicklung

Insbesondere in der Softwarebranche sind gescheiterte oder aus dem Ruder gelaufene Projekte an der Tagesordnung, eine Umfrage aus dem Jahr 2016 unter IT-Firmen ergab, dass mehr als die Hälfte der IT-Projekte fehlschlägt. Gesprengte Budgets, gerissene Deadlines oder gar das komplette Verfehlen der Projektziele werden am häufigsten als Ursachen genannt. Im öffentlichen Sektor sieht die Bilanz noch schlechter aus: Zwischen 2003 und 2013 waren sage und schreibe 94 Prozent aller großen öffentlichen IT-Entwicklungsprojekte vollständig oder teilweise erfolglos – mehr als die Hälfte war verspätet, lag über dem Budget oder erfüllte nicht die Erwartungen der Benutzer. Den vielleicht kostspieligsten Fehlschlag in der Geschichte der Branche stellt wohl der Versuch dar, den britischen Gesundheitsdienst NHS zu digitalisieren: Nach zehn Jahren Projektlaufzeit wurde er 2013 abgebrochen, und fast 10 Milliarden Britische Pfund waren verschwendet worden.⁷