Projektmanagement der Titanic & Vergleich mit Softwareprojekten

Nur wenige Projekte haben jemals den Ruhm und die Berühmtheit erlangt, die der Titanic und ihren Schwesterschiffen der Olympic-Klasse, der Olympic und der Britannic, zuteilwurden, deren Entwurf vor einhundertzehn Jahren in eben diesem Jahr begann. Aus dem Schicksal der Olympic-Schiffe lassen sich natürlich viele Lektionen in Bezug auf das Projektmanagement ziehen, und tatsächlich gibt es viele Aspekte des Projektmanagements, die es wert sind, behandelt zu werden.

(Wenn ich auf die Schiffe als Gesamtheit Bezug nehme, werde ich sie einfach als die Olympics bezeichnen, da die drei zusammen die Schiffe der Olympic-Klasse der White Star Line waren. Der individuelle und spätere Ruhm der Titanic ist hier irrelevant. Außerdem gehe ich hier davon aus, dass die allgemeinen Informationen über die Olympic-Schiffe, ihre Geschichte und ihr Schicksal dem Leser allgemein bekannt sind, und werde sie nicht erneut behandeln.)

Angesichts der Häufigkeit, mit der das Projektmanagement der Olympics bereits behandelt wurde, halte ich es für sinnvoller, einige moderne Parallelen zu betrachten, anhand derer wir das heutige Projektmanagement durch eine wertvolle historische Linse betrachten können. Es trifft in hohem Maße zu, dass das Projektmanagement eine Disziplin ist, die seit Jahrtausenden Bestand hat, und dass sich viele der Herausforderungen, Fähigkeiten und Techniken nicht so sehr verändert haben und die Fallstricke der Vergangenheit für uns auch heute noch sehr wohl gelten. Die alte Redensart trifft zu: Wenn wir nicht aus der Vergangenheit lernen, sind wir dazu verdammt, sie zu wiederholen.

Mein Ziel ist es daher, die Risikoanalyse, die Wahrnehmung und das Profil des Projekts zu untersuchen und dies auf das moderne Projektmanagement anzuwenden.

Zunächst müssen wir die Stakeholder des Olympics-Projekts identifizieren. Die White Star Line selbst (sponserndes Unternehmen und Hauptinvestor) und ihr Direktor Joseph Bruce Ismay, Harland-Wolff (beauftragte Werft) mit ihren leitenden Konstrukteuren Alexander Carlisle und Thomas Andrews, die Besatzung der Schiffe einschließlich Kapitän Edward John Smith, die britische Regierung, wie wir später sehen werden, und, am wichtigsten, die Passagiere.

Wie bei jeder Gruppe von Stakeholdern werden unterschiedliche Rollen wahrgenommen. White Star ist auf der einen Seite Sponsor und Investor und wäre in einem modernen Softwareprojekt mit einem sponsernden Kunden, einer Führungskraft oder einer Abteilung vergleichbar. Harland-Wolff waren die Konstrukteure und Erbauer und am ehesten mit den “Teammitgliedern” der Softwareentwicklung in einem modernen Softwareteam vergleichbar, also den Entwicklern selbst. Die Besatzung der Schiffe war nach Abschluss des Projekts für den Betrieb zuständig und wäre mit einem IT-Betriebsteam vergleichbar, das nach der Fertigstellung den laufenden Betrieb der fertigen Software übernimmt. Die Passagiere glichen weitgehend den Endnutzern von heute, die hofften, sowohl vom technischen Endprodukt (Schiff oder Software) als auch von der darauf aufbauenden Dienstleistung (Fährbetrieb oder IT-Managed-Services) zu profitieren. (“Olympic”)

Eine weitere Analyseachse des Projekts ist die der “Chicken”- und “Pig”-Stakeholder, wobei “Chickens” beteiligt sind und ein Risiko tragen, während “Pigs” voll eingebunden sind und das letztendliche Risiko tragen. In der gewöhnlichen Software verwenden wir diese Vergleiche, um über Abstufungen von Stakeholdern zu sprechen – jene, die beteiligt sind, gegenüber jenen, die sich verpflichtet haben –, doch im Fall der Olympic-Schiffe nehmen diese Begriffe eine neue und schreckliche Bedeutung an, da Besatzung und Passagiere in der Betriebsphase der Schiffe buchstäblich ihr Leben aufs Spiel setzten, während die Investoren und Erbauer nur finanziell im Risiko standen. (Schwaber)

Zweitens halte ich es für sinnvoll, zwischen den verschiedenen Projekten zu unterscheiden, die im Kontext der Olympics existieren. Da war natürlich der physische Entwurf und Bau der drei Schiffe. Dies ist ein einzelnes Projekt mit zwei klaren Komponenten – einer des Entwurfs und einer des Baus. Und drei diskreten Liefergegenständen, nämlich den drei Olympic-Schiffen. Am Ende der Bauphase gibt es einen äußerst klaren Trennungspunkt, an dem die am Zusammenbau des Schiffes beteiligten Projektmanager und Teams ihre Arbeit einstellen und die Besatzung, die das Schiff betrieb, die Aufgabe übernahm.

Hier können wir bereits eine wichtige Parallele zur modernen Welt der Technologie ziehen, in der Softwareprodukte von Softwareingenieuren entworfen und entwickelt werden und nach ihrer Fertigstellung an das IT-Betriebspersonal übergeben werden, das die eigentlich vorgesehene Nutzung des Endprodukts übernimmt. Diese beiden Teams können intern unter einem einzigen organisatorischen Dach angesiedelt sein oder aus zwei oder mehr sehr getrennten Organisationen stammen. Doch die Trennung zwischen der Entwicklungs- und der Betriebsabteilung ist in den meisten heutigen Unternehmen genauso klar und deutlich geblieben, wie sie es im Schiffbau und Fährbetrieb vor über einem Jahrhundert war.

Wir können noch einen Schritt weiter gehen und den transatlantischen Fährbetrieb von White Star mit vielen modernen Software-as-a-Service-Anbietern wie Microsoft Office 365, Salesforce oder G Suite vergleichen. In diesen Fällen verfügt das betreffende Unternehmen über ein Entwicklungs- oder Produktteam, das das Kernprodukt erstellt, und über ein zweites Team, das dieses hausintern entwickelte Produkt nimmt und als Dienst betreibt. Es wird im Bereich der Softwareentwicklung zunehmend zu einem wichtigen Geschäftsmodell, dass dasselbe Unternehmen, das die Software erstellt, auch der letztendliche Betreiber davon sein wird, allerdings für externe Kunden. In vielerlei Hinsicht nimmt die Relevanz der Olympics für moderne Software und IT eher zu als ab.

Dies bringt ein wichtiges Verständnis über die Schnittstelle zur Sprache, das bei den Olympics versäumt wurde und auch heute oft versäumt wird: Jede Seite der Übergabe glaubte, dass letztlich die andere Seite für die Sicherheit verantwortlich sei. Die Ingenieure rühmten die Sicherheit ihres Entwurfs, waren aber, wenn man sie drängte, zu Kompromissen bereit, in der Annahme, dass betriebliche Verfahren die Risiken mindern würden und dass ihre eigenen Bemühungen weitgehend redundant seien. Ebenso war das Betriebsteam, wenn es gedrängt wurde, die Dinge in Bewegung zu halten und gute Fahrzeiten zu erreichen, bereit, bei den Verfahren Kompromisse einzugehen, weil es glaubte, das Entwicklungsteam sei so weit gegangen, dass ihre eigenen Bemühungen im Grunde überflüssig geworden seien, da das Schiff so sicher sei, dass betriebliche Vorsichtsmaßnahmen schlicht nicht gerechtfertigt wären. Diese Fehlkommunikation brachte das Unterfangen von zwei Arten von Systemen extremer Sicherheit auf praktisch keine herunter. Hätte jede Seite verstanden, wie die andere arbeiten würde oder tatsächlich arbeitete, hätte sie dies berücksichtigen können. Letztlich gingen beide Seiten zumindest in gewissem Maße davon aus, dass die Sicherheit “Aufgabe des anderen Teams” sei. Während das Schiff stark auf Grundlage seiner Sicherheit beworben wurde, bestand die Realität darin, dass es den allgemeinen Trend des vergangenen halben Jahrhunderts und mehr fortsetzte, in dem Schiffe Jahr für Jahr weniger sicher gebaut und betrieben wurden als im Jahr zuvor. (Brander 1995)

Heute sehen wir dasselbe Problem zwischen IT und Softwareentwicklung auftreten – weniger im Hinblick auf Stabilität (auch wenn das gewiss zutreffend bleibt), sondern nun im Hinblick auf Sicherheit, die im Kontext der Olympics ähnlich wie die physische Sicherheit betrachtet werden kann. Sicherheit ist auf beiden Seiten des technologischen Zauns zu einem der wichtigsten Themen des letzten Jahrzehnts geworden, und die Branche steht vor den Herausforderungen, die durch die Notwendigkeit entstehen, dass beide Seiten Sicherheitspraktiken gründlich umsetzen müssen – keine ist allein in der Lage, wirklich sichere Systeme zu realisieren. Die Planung für Sicherheit ist schlicht kein Ersatz für ihre verfahrenstechnische Durchsetzung während des Betriebs.

Ein hervorragender Vergleich von heute sind British Airways und die Art und Weise, wie sie an jeden Flug herangehen, den sie auf seiner Überquerung des Atlantiks beaufsichtigen. Als wichtigster Luftverkehrsträger über dem Nordatlantik – derselben Route, die die Olympics durchqueren sollten – muss British Airways einen Ruf für herausragende Sicherheit aufrechterhalten. Selbst im Jahr 2017 ist ein Flug über den Nordatlantik eine heikle und komplizierte Reise.

Bevor ein Flug von British Airways abhebt, müssen die Piloten und die Besatzung ein dreihundert Seiten umfassendes Missionshandbuch durchgehen, das ihnen alles mitteilt, was vor sich geht, einschließlich Details zum Flugzeug, zur Besatzung, zum Wetter und so weiter. Dieser Prozess ist so intensiv, dass British Airways sich sogar weigert anzuerkennen, dass es sich um einen Flug handelt, sondern jede einzelne Reise über den Atlantik offiziell als “Mission” bezeichnet; und zwar gezielt, um allen Beteiligten die Schwere und das Risiko eines solchen Unterfangens vor Augen zu führen. Sie verstehen eindeutig, wie wichtig es ist, die Art und Weise zu ändern, wie Menschen über eine solche Reise denken, und sind sich bewusst, was geschehen kann, wenn Menschen anfangen anzunehmen, dass alle anderen ihre Arbeit gut erledigt haben werden und dass sie bei ihrer eigenen Arbeit Abstriche machen können. Sie möchten, dass niemand nachlässig wird oder anfängt, das Gefühl zu haben, der Flug sei, auch wenn er mehrmals täglich durchgeführt wird, jemals Routine. (Winchester)

Hätte man bei der Titanic den Ansatz von British Airways angewandt, wäre die Katastrophe sehr wahrscheinlich nicht zu jenem Zeitpunkt eingetreten. Allein die betriebliche Seite hätte die Katastrophe verhindern können. Ebenso wären die Schiffsingenieure, hätte man sie denselben Standards unterworfen wie heute Boeing oder Airbus, wahrscheinlich nicht so leicht vom Management unter Druck gesetzt worden, die Sicherheitsanforderungen während ihrer Arbeit am Projekt zu verändern.

Was die Olympics in vielerlei Hinsicht wirklich beeinträchtigte, war eine Form ungebremsten Scope Creeps. Das Projekt begann als traditioneller Wasserfallansatz mit “Big Design Up Front”, und die anfänglichen Anforderungen waren gut, wobei die Sicherheit eine entscheidende Rolle spielte. Hätte man die ursprünglichen Projektanforderungen und sogar einen Großteil des ursprünglichen Entwurfs verwendet, wären die Schiffe weit sicherer gewesen, als sie es waren. Doch neue Anforderungen nach größeren Speisesälen oder luxuriöserer Ausstattung erhielten Vorrang, und der Umfang und die Parameter des Projekts wurden geändert, um diesen neuen Änderungen Rechnung zu tragen. Wie bei jedem Projekt geschieht keine Änderung im luftleeren Raum, sondern hat Auswirkungen auf andere Faktoren wie Kosten, Sicherheit oder Liefertermin. (Sadur)

Der Scope Creep speziell bei der Titanic war dramatisch, aber verborgen und größtenteils nicht zwangsläufig offensichtlich. Es ist leicht, kleine Änderungen wie eine Verschiebung der Speisesaalgröße zu benennen, doch von weit größerer Bedeutung war die Änderung des Zeitrahmens, in dem das Schiff geliefert werden musste. Was den Umfang in Wirklichkeit veränderte, war tatsächlich, dass die ursprünglichen Fristen und Projekte relativ strikt eingehalten werden mussten. Dies war deshalb besonders problematisch, weil während der Trockendockarbeiten und späteren Arbeiten der Titanic am Liegeplatz das ältere Schwesterschiff Olympic mehrfach für umfangreiche Reparaturen hereingeholt wurde, was sehr große Auswirkungen auf die im ursprünglichen Zeitplan verfügbare Zeit hatte, um die Arbeiten an der Titanic selbst fertigzustellen. Diese Art von Umfangsänderung lässt sich sehr leicht übersehen oder ignorieren, besonders im Nachhinein, da sich die physischen Liefergegenstände und die ursprünglichen Termine nicht in irgendeiner dramatischen Weise änderten. Praktisch in jeder Hinsicht wurde die Titanic jedoch viel schneller durch die Produktion gehetzt, als ursprünglich geplant war.

In der modernen Softwareentwicklung ist allgemein anerkannt, dass niemand die Dauer einer Entwurfsaufgabe so gut einschätzen kann wie der oder die Ingenieure, die die Aufgabe selbst ausführen werden. Es ist auch allgemein anerkannt, dass es kein Mittel gibt, Entwicklungs- und Entwurfsbemühungen durch Druck des Managements wesentlich zu beschleunigen. Sobald ein Projekt mit Höchstgeschwindigkeit läuft, wird es nicht schneller werden. Versuche, schneller zu werden, führen oft zu Fehlern, Versäumnissen oder Auslassungen. Wir wissen, dass dies bei Software zutrifft, und können annehmen, dass es auch beim Schiffsentwurf zutreffen musste, da die Prinzipien dieselben sind. Hätte man der Titanic die angemessene Zeit für diesen Prozess eingeräumt, wäre es möglich, dass Sicherheitsmaßnahmen gründlicher bedacht oder zumindest bei der Übergabe ordnungsgemäß an das Betriebsteam kommuniziert worden wären. Teams, die gehetzt werden, sind gezwungen, Kompromisse einzugehen, und da die Zeit nicht angepasst werden kann, weil sie die Randbedingung ist, müssen die Abstriche an anderer Stelle gemacht werden, und das geht fast immer zu Lasten von Qualität und Gründlichkeit. Dies kann sich als Fehler äußern oder vielleicht als Versäumnis, alle beteiligten Faktoren vollständig zu prüfen, wenn man einen Teil eines Entwurfs ändert.

Dies bringt uns zum ganzheitlichen Entwurfsdenken. Zu Beginn des Projekts wurden die Olympics mit Blick auf Sicherheit entworfen: jene Sicherheit, die sich aus dem sorgfältigen Zusammenspiel vieler getrennter Systeme ergibt, die zusammen ein hochzuverlässiges Schiff ergeben sollen. Wir können die Komponenten eines Schiffes dieser Größenordnung nicht einzeln betrachten, sie ergeben keinen Sinn – der Entwurf des Rumpfes, die Bauweise der Decks, das Gewicht der Ladung, die verwendeten Materialien, die Bauart der Schotts sind alle miteinander verknüpft und müssen zusammen funktionieren.

Als das Projekt gedrängt wurde, schneller fertiggestellt zu werden oder Parameter zu ändern, wurde dieses ganzheitliche Denken und ein klares Wiederaufgreifen früherer Entscheidungen nicht oder nicht angemessen vorgenommen. Stattdessen wurden einzelne Komponenten verändert, ungeachtet dessen, wie sich dies auf ihre Rolle innerhalb des gesamten Schiffes und auf die daraus resultierenden Auswirkungen auf die Gesamtsicherheit auswirken würde. Was wie eine geringfügige Änderung erscheinen mochte, hatte unbeabsichtigte Folgen, die nicht vorhergesehen wurden, weil ganzheitliches Projektmanagement aufgegeben worden war. (Kozak-Holland)

Diese Änderung an der Technik spiegelte sich natürlich im Betrieb wider. Jede Änderung, etwa das Nichtverwenden von Ferngläsern oder das Nichtdurchführen von Eiseimer-Messungen, war für sich genommen einigermaßen geringfügig, doch zusammengenommen waren sie unglaublich folgenreich. Wahrscheinlich – aber sicher sein können wir nicht – wurde kein zusammenhängendes Projektmanagement oder zumindest kein System zur Prozessverbesserung eingesetzt. Wer beaufsichtigte, dass Ferngläser verwendet wurden, dass die Wassertests korrekt waren und so weiter? Jede noch so kleine Überprüfung hätte ergeben, dass die für diese Aufgaben benötigten Werkzeuge schlichtweg überhaupt nicht existierten. Es ist ausgeschlossen, dass auch nur ein einfacher Probedurchlauf der Verfahren hätte durchgeführt werden können, geschweige denn eine regelmäßige Überprüfung und Prozessverbesserung. Die Prozessverbesserung wird besonders durch die Tatsache hervorgehoben, dass Kapitän Smith bereits Übung auf der RMS Olympic gehabt, auf ihrer fünften Reise eine Kollision auf See verursacht und dann beinahe denselben Fehler bei der ersten Indienststellung der Titanic wiederholt hatte. Was eine wichtige, von allen Kapitänen und Lotsen der Olympic-Schiffe gelernte Lektion hätte sein sollen, wurde stattdessen ignoriert und fast unmittelbar wiederholt. (“Olympic”)

Schiffbau und Software sind natürlich sehr unterschiedliche Dinge, doch viele Lektionen lassen sich teilen. Eine der wichtigsten Lektionen besteht darin, die Einschränkungen zu erkennen, mit denen der Schiffbau konfrontiert war, und zu erkennen, wann wir nicht gezwungen sind, dieselben Einschränkungen beizubehalten, wenn wir mit Software arbeiten. Die Olympic und die Titanic wurden nahezu zur selben Zeit gebaut, ganz ohne Zeit dafür, das aus dem Bau der Olympic gewonnene technische Wissen, geschweige denn aus ihrem Betrieb, auf den Bau der Titanic anzuwenden. In moderner Software würden wir eine solche Randbedingung niemals erwarten und wären in der Lage, Software zumindest in geringem Maße zu testen, bevor wir zu weiterer Software übergehen, die darauf aufbaut, sei es im tatsächlichen Code oder auch nur konzeptionell. Das Projektmanagement von heute muss die Unterschiede, die sowohl in der heutigen Zeit als auch in unserer anderen Branche bestehen, bestmöglich zu seinem Vorteil nutzen. Einige Softwareprojekte erfordern noch immer solche Prozesse, doch diese sind im Laufe der Zeit immer seltener geworden und sind heute dramatisch weniger verbreitet, als sie es noch vor zwanzig Jahren waren.

Es lohnt sich sehr, die von Harland-Wolff mit den Olympics geleistete Arbeit zu bewerten, da sie ganz offensichtlich bestrebt waren, alle Feedbackschleifen einzubeziehen, die in ihrem damaligen Wirkungsbereich möglich waren. Sie versuchten nicht nur, den Bau früherer Schiffe zu nutzen, um für die späteren mehr zu lernen – was allerdings sehr begrenzt war, da sich die Schiffe größtenteils gleichzeitig im Bau befanden und die meisten Lektionen keine Zeit gehabt hätten, angewandt zu werden –, sondern, was weit wichtiger war, sie unternahmen den außergewöhnlichen Schritt, eine “Garantiegruppe” mit den Schiffen fahren zu lassen. Diese Garantiegruppe bestand aus Lehrlingen und Meister-Schiffbauern aller Art aus allen möglichen unterstützenden Gewerken. (“Guarantee Group”)

Der Einsatz der Garantiegruppe für direktes Feedback war und bleibt wahrhaft beispiellos und stellte für die Schiffbauer eine enorme Investition an harten Kosten und Zeit dar, so viele wertvolle Arbeiter dafür zu opfern, in Luxus über den Atlantik hin und her zu fahren. Die Gruppe konnte ihre Arbeit aus erster Hand inspizieren, sie in Aktion sehen, ein Verständnis für ihre Anwendung im Kontext des in Betrieb befindlichen Schiffes gewinnen, an Teambildung, Wissenstransfer und mehr zusammenarbeiten. Dies war weit wertvoller als das Feedback von den Werften, auf denen sich die Schiffe im Bau überschnitten; dies war eine starke Investition in die Zukunft ihres Schiffbauunternehmens: ein Bekenntnis zur industriellen Ausbildung, das ihnen wahrscheinlich über Jahrzehnte hinweg von Nutzen gewesen wäre.

Moderne Bereitstellungsstile, Werkzeuge und Ausbildung haben dazu geführt, dass die überwiegende Mehrheit der Software, die früher nach einer Wasserfallmethodik erstellt wurde, die sich nicht so sehr von der im Schiffbau zur Wende des [letzten] Jahrhunderts verwendeten unterschied, heute größtenteils ein gewisses Maß an agilen Methoden nutzt, die rasches Testen, Bewerten, Ändern und Bereitstellen ermöglichen. Scope Creep hat sich von etwas, das gemindert oder stark gemanagt werden muss, zu etwas gewandelt, das innerhalb des Entwicklungsprozesses als erwartet und vorausgesetzt behandelt werden kann, bis hin zu dem Punkt, dass es nahezu nutzbar gemacht wird. Eines der grundlegenden Probleme von Big Design Up Front besteht darin, dass es stets vom Kunden oder vom Stakeholder in der Kundenrolle verlangt, “große Entscheidungen im Vorfeld” zu treffen, die für ihn oft weitaus schwerer zu treffen sind, als es der Entwurf für die Ingenieure ist. Diese frühen Entscheidungen sind oft ein wesentlicher Beitrag zu Scope Creep oder zu späteren Änderungsanträgen und können durch agile Prozesse, die kontinuierliche Änderungen an den Anforderungen erwarten und diese in den Prozess einbauen, oft reduziert oder vermieden werden.

Die Schiffbauer Harland und Wolff bauten zwar ein fünfzehn Fuß langes Modell der Olympic für Tests, was in gewissem Maße nützlich ist, doch dieses konnte natürlich die hydrologischen Effekte nicht nachbilden, die das Schiff in voller Größe später erzeugen würde, und konnte einige der gefährlicheren Nebenwirkungen der Größe des neuen Schiffes in der Nähe anderer Schiffe nicht vorhersagen, was zum ersten Unfall der Gruppe und zu einem beinahe zweiten führte. Die Erbauer scheinen tatsächlich jede Anstrengung unternommen zu haben, in jeder ihnen während des Entwurfs- und Bauprozesses zur Verfügung stehenden Phase zu testen und zu lernen. (Kozak-Holland)

Im Vergleich zum modernen Projektmanagement wäre dies vergleichbar mit der Erstellung eines schnellen Mock-ups oder Wireframes, mit dem Entwickler oder sogar Kunden praktische Erfahrungen sammeln können, bevor weiterer Aufwand in einen Weg investiert wird, der sich aus unvorhergesehenen Gründen als Sackgasse erweisen könnte. Dies ist besonders wichtig beim Entwurf von Benutzeroberflächen, wo es oft kaum möglich ist, Benutzerfreundlichkeit oder Zufriedenheitswerte angemessen vorherzusagen, ohne tatsächlichen Nutzern die Gelegenheit zu geben, das System physisch zu bedienen und selbst zu beurteilen, ob es das gewünschte Erlebnis bietet. (Esposito)

Wir müssen natürlich das Risiko betrachten, das die Olympics im Kontext ihrer historischen Einordnung in Bezug auf finanzielle Trends und Kräfte eingingen. Zur damaligen Zeit, ausgehend von der Mitte des vorangegangenen Jahrhunderts, lautete das vorherrschende finanzielle Denken, dass es am besten sei, eher zum Riskanten als zum Sicheren zu neigen – in Bezug auf den Verlust von Menschenleben, Ladung oder Schiffen – und die Differenz über Versicherungsinstrumente auszugleichen. Es war für die Schiffe schlicht zu finanziell vorteilhaft, auf riskante Weise zu operieren, anstatt übermäßig vorsichtig mit Menschenleben umzugehen. Dieser Trend hatte sich bis zur Zeit der Olympics seit fast sechzig Jahren fest etabliert und begann sich erst mit der starken öffentlichen Aufmerksamkeit für den Untergang der Titanic zu ändern. Die Marktwirkung auf die Öffentlichkeit existierte nicht, bis das “unsinkbare” Schiff mit so vielen Seelen an Bord auf so spektakuläre Weise verloren ging.

Dieser Umgang mit Risiko und seinen finanziellen Abwägungen ist einer, den Projektmanager heute genauso verstehen müssen wie vor über einhundert Jahren. Es ist leicht, in den Glauben zu verfallen, dass Risiko so wichtig sei, dass es jeden Preis wert sei, es zu eliminieren, doch Projekte dürfen nicht so denken. Es ist möglich, unbegrenzte Ressourcen in das Streben nach Risikoreduzierung zu stecken. In der realen Welt ist es notwendig, dass wir Risiken gegen die Kosten der Risikominderung abwägen. Ein hervorragendes Beispiel hierfür in der heutigen Zeit, allerdings außerhalb der Softwareentwicklung im engeren Sinne, ist der Umgang mit Kreditkartenbetrug in den Vereinigten Staaten. Bis vor wenigen Jahren war es allgemein die Auffassung der US-Kreditkartenbranche, dass die Kosten höherer Sicherheitsmaßnahmen bei Kreditkarten zur Verhinderung von Diebstahl im Vergleich zu den Risiken, sie nicht zu haben, zu hoch seien; im Grunde war es kosteneffizienter, Geld für die Erstattung gefälschter Transaktionen auszugeben, als diese gefälschten Transaktionen zu verhindern. Dieses Verhältnis von Kosten zu Risiko kann manchmal kontraintuitiv und sogar frustrierend sein, ist aber eines, das Projektentscheidungen in einer logischen, kalkulierten Weise leiten muss.

In ähnlicher Weise ist es in der IT verbreitet, Systeme in dem Glauben zu entwerfen, dass Ausfallzeiten im Grunde unbegrenzte Kosten verursachen, und weitaus mehr für den Versuch auszugeben, ein Ausfallrisiko zu mindern, als die Kosten des tatsächlichen Ausfallereignisses selbst wahrscheinlich betragen würden, sollte es eintreten. Das ist offensichtlich töricht, doch da Kostenanalysen dieser Art so selten durchgeführt oder so selten korrekt durchgeführt werden, wird es allzu leicht, dieser Denkweise zum Opfer zu fallen. Bei Softwareentwicklungsprojekten müssen wir an Risiken auf ähnliche Weise herangehen. Zu akzeptieren, dass es ein Risiko jeglicher Art gibt, das tatsächliche Risiko zu bestimmen, das Ausmaß der Auswirkung dieses Risikos zu bestimmen und dies gegen die Kosten von Minderungsstrategien abzuwägen, ist entscheidend, um eine angemessene Projektmanagemententscheidung in Bezug auf das Risiko zu treffen. (Brander 1995)

Von besonderem Interesse für extrem große Projekte, zu denen die Olympics gewiss zählten, ist außerdem das zusätzliche Konzept des “Too Big to Fail”. Dies ist natürlich eine moderne Wendung, die während der Finanzkrise des vergangenen Jahrzehnts aufkam, doch das Konzept und die Realität dahinter sind weit älter und eine wertvolle Erwägung für jedes Projekt, das auf eine Größenordnung fällt, die als “nationale Finanzkatastrophe” gelten würde, sollte das Projekt vollständig scheitern. Im Fall der Olympics schützte die britische Regierung die Investoren letztlich vor dem totalen Ruin, da der Zusammenbruch einer der größten Passagierlinien für das Land zur damaligen Zeit verheerend gewesen wäre.

Die White Star Line war schlicht “too big to fail” und wurde sozusagen von der Regierung über Wasser gehalten, bevor sie einige Jahre später zwangsweise mit Cunard fusioniert wurde. Dieses Konzept – das Wissen, dass die Regierung die Risiken eines Scheiterns des Unternehmens nicht akzeptieren wollen würde – wurde zur damaligen Zeit möglicherweise kalkuliert oder berücksichtigt, das wissen wir nicht. Wir wissen jedoch, dass dies heute bei sehr großen Projekten berücksichtigt wird. Ein Beispiel dafür, das sich gegenwärtig ereignet, ist der F-35-Kampfjet von Lockheed Martin, der das Budget dramatisch überschreitet, seinen Liefertermin überschritten hat und nicht einmal mehr als wahrscheinlich nützlich gilt, aber seit Jahren von verschiedenen staatlichen Geldgebern gestützt wird, die das Projekt – selbst in einem Zustand des Lieferversagens – als zu wichtig für die Volkswirtschaft erachten, um es vollständig kollabieren zu lassen. Da dieses Phänomen immer bekannter wird, ist es wahrscheinlich, dass wir mehr Projekte erleben werden, die dies in ihren Risikoanalysephasen berücksichtigen. (Ellis)

Wenn wir zur betrieblichen Seite der Gleichung springen, könnten wir eine beliebige Anzahl von Aspekten untersuchen, die schiefgingen und zum Untergang der Titanic führten, doch im Kern glaube ich, dass am offensichtlichsten ein Mangel an Standardarbeitsanweisungen während des gesamten Prozesses war. Dies ist bis zu einem gewissen Grad verständlich, da sich das Schiff auf seiner Jungfernfahrt befand und kaum Zeit für Prozessdokumentation und -verbesserung blieb. Dies war jedoch das Flaggschiff einer seit Langem bestehenden Schifffahrtslinie, die einen Ruf zu wahren hatte und über umfangreiche Erfahrung in diesen Angelegenheiten verfügte. Es würde außerdem übersehen, dass die Olympic zu der Zeit, als die Titanic ihre erste Reise unternehmen wollte, bereits weit länger als ausreichend in Dienst gewesen war, um einen zufriedenstellenden Satz von Standardarbeitsanweisungen entwickelt zu haben.

Eine grundlegende Dokumentation wäre selbst auf einer Jungfernfahrt zu erwarten gewesen; es ist unangemessen zu erwarten, dass ein Schiff dieser Größenordnung überhaupt funktioniert, sofern es keine Koordination und Kommunikation unter der Besatzung gibt. Es war reichlich Zeit, tatsächlich Jahre, um grundlegende betriebliche Verfahren für die Besatzung zu erstellen und vorzubereiten, bevor das erste Schiff in See stach, und dies hätte natürlich für alle Schiffe dieser Art geschehen müssen, doch es war offensichtlich, dass solche Arbeitsanweisungen im Fall der Titanic mangelhaft waren, fehlten und ungetestet blieben.

Die für die Arbeitsanweisungen verantwortliche Partei wäre wahrscheinlich auf der Betriebsseite der Projektgleichung zu verorten, doch ein gewisses Maß solcher Dokumentation hätte auch von den Entwicklungs- und Bauteams bereitgestellt oder mit ihnen abgestimmt werden müssen. Zu den vielen Verfahren, die auf der Titanic zusammenbrachen, gehörten ein Versagen der Befehlskette unter Druck, als der Direktor des Unternehmens das Kommando auf der Brücke übernahm und der Kapitän es zuließ, die Anweisung an die Funker, Passagiernachrichten mit Vorrang vor Eisbergwarnungen weiterzuleiten, das Zulassen, dass die Funker anderen Schiffen, die sie zu warnen versuchten, sagten, sie sollten die Übertragung einstellen, kritische Nachrichten, die nicht auf die Brücke gebracht wurden, für kritische Aufgaben benötigte Werkzeuge, die nicht bereitgestellt wurden, und so weiter. (Kuntz)

Ähnlich wie es bei der Konstruktion und dem Entwurf der Schiffe erforderlich war, benötigte der Betrieb der Schiffe eine starke und ganzheitliche Steuerung, die sicherstellte, dass das Schiff und seine Besatzung als Ganzes funktionierten, anstatt Abteilungen wie die Marconi-Funker als einzelne Einheit zu betrachten. In jenem Beispiel waren sie offiziell nicht Teil der Schiffsbesatzung, sondern Angestellte von Marconi, die an Bord waren, um die bezahlten Mitteilungen der Passagiere abzuwickeln, und Notfallverkehr des Schiffes nur dann zu bearbeiten, wenn es die Zeit erlaubte. Wären sie als Teil eines ganzheitlichen betrieblichen Managementsystems beaufsichtigt worden, selbst als externe Auftragnehmer, ist es wahrscheinlich, dass ihre Verfahren weitaus stärker auf Sicherheit ausgerichtet gewesen wären oder dass zumindest Service-Level-Vereinbarungen über die Übermittlung von Nachrichten an die Brücke klar definiert gewesen wären statt ad hoc und nach eigenem Ermessen.

In jedem Projekt und jeder Projektkomponente ist eine gute Dokumentation – sei es von Projektzielen, Liefergegenständen, Verfahren und so weiter – entscheidend, und das Projektmanagement hat wenig Aussicht auf Erfolg, wenn nicht gute Kommunikation und Dokumentation im Mittelpunkt all dessen stehen, was wir tun, sowohl intern innerhalb des Projekts als auch extern gegenüber den Stakeholdern.

Was wir heute feststellen, ist, dass die Projektmanagement-Lektionen der Olympic, Titanic und Britannic für uns auch heute noch wertvoll sind und dass der Kontext jener Ära nach wie vor relevant ist – sei es das Drängen auf iterativen Projektentwurf, wo möglich, das Investieren in Erfahrungswissen, das Kalkulieren von Risiken, das Verstehen der Rollen von Systementwicklung und Systembetrieb oder das Zusammenwirken schützender externer Kräfte auf die Produktkosten. Die Faktoren, die Projekte beeinflussen, kommen und gehen in Zyklen; heute sehen wir Trends, die eher zu Modellen wie den Olympics tendieren als von ihnen weg. In der Zukunft wird das Pendel wahrscheinlich wieder zurückschwingen. Die zugrunde liegenden Lektionen sind sehr relevant und werden es auch weiterhin sein. Wir können viel lernen, indem wir sowohl bewerten, wie unsere eigenen Projekte denen von White Star ähneln, als auch, worin sie sich von ihnen unterscheiden.

Literaturverzeichnis und zitierte Quellen:

Miller, Scott Alan. Project Management of the RMS Titanic and the Olympic Ships, 2008.

Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.

Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Audio-Ausgabe über Audible.

Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.

Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry, Februar 2007.

Esposito, Dino. “Cutting Edge – Don’t Gamble with UX—Use Wireframes.” MSDN Magazine, Januar 2016.

Sadur, James E. Homepage. “Jim’s Titanic Website: Titanic History Timeline.” (2005): 13. Februar 2017.

Winchester, Simon. “Atlantic.” Harper Perennial, 2011.

Titanic-Titanic. “Olympic.” (Datum unbekannt): 15. Februar 2017.

Titanic-Titanic. “Guarantee Group.” (Datum unbekannt): 15. Februar 2017.

Brander, Roy. P. Eng. “The RMS Titanic and its Times: When Accountants Ruled the Waves – 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture”. (1998): 16. Februar 2017.

Brander, Roy. P. Eng. “The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management.” (1995): 16. Februar 2017.

Ellis, Sam. “This jet fighter is a disaster, but Congress keeps buying it.”. Vox, 30. Januar 2017.

Zusätzliche Anmerkungen:

Mark Kozak-Holland veröffentlichte sein Buch ursprünglich 2003 als eine Reihe von Gantthead-Artikeln über die Titanic:

Kozak-Holland, Mark. “IT Project Lessons from Titanic.” Gantthead.com, die Online-Community für IT-Projektmanager, und später ProjectManagement.com (2003): 8. Februar 2017.

Weiterführende Lektüre:

Kozak-Holland, Mark. Avoiding Project Disaster: Titanic Lessons for IT Executives. Toronto: Multi-Media Publications, 2006.

Kozak-Holland, Mark. On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive. IBM Press, 2002.

Offizielle Anhörungs- und Untersuchungsprotokolle des US-Senats und der britischen Behörden aus dem Jahr 1912 beim Titanic Inquiry Project.