Leben und Überleben im Komplexitätszeitalter

„Komplexität – reduzieren oder erhöhen?“, so lautet das Motto des dritten Berliner PM-Camps (#pmcampber), welches vom 10. bis zum 12. September 2015 in der Berliner Humboldt Universität stattfinden wird. Im Vorfeld zu diesem Event hat Heiko Bartlog eine Blogparade mit dem Thema „Komplexität – in Projekten und darüber hinaus …“ initiiert, zu der ich gerne einen Beitrag beisteuere, auch wenn ich selbst leider nicht am PM-Camp teilnehmen kann. Ich möchte aber mal meine Gedanken zu dem Thema aus der Perspektive eines Systems Engineers beitragen.

Modewort Komplexität?

Der Begriff Komplex ist derzeit omnipräsent. Er wird ständig, ja, man hat fast den Eindruck, er wird geradezu inflationär gebraucht. Alles ist komplex, nichts scheint mehr einfach zu sein. Die Natur war ja schon immer komplex. Die technischen Systeme und die Märkte, mit denen wir es zu tun haben, sind es erst recht. Die gesamtpolitische Lage ist komplex, oder mal Hand aufs Herz: Gelingt es Ihnen noch, die globalen politischen Zusammenhänge zu durchdringen und zu verstehen? Die Ukraine-Krise? Die griechische Schuldenkrise? Die NSA-Abhöraffäre?

Warum sprechen wir heute aber sehr schnell davon, das etwas komplex ist, und sagen eigentlich kaum noch: Es ist kompliziert.

Schaut man mal bei Wikipedia hinein, so findet man dort folgende Definition für Komplexität:

Komplexität bezeichnet allgemein die Eigenschaft eines Systems oder Modells, dessen Gesamtverhalten man selbst dann nicht eindeutig beschreiben kann, wenn man vollständige Informationen über seine Einzelkomponenten und ihre Wechselwirkungen besitzt.

Anders ausgedrückt könnte man auch sagen: komplexe Systeme sind Systeme, die sich gegen Vereinfachung und Kontrolle wehren. Vor allem auf den Begriff der Kontrolle komme ich später noch einmal zurück.

Herausforderungen im Komplexitätszeitalter

Vielleicht erinnern Sie sich noch an die Probleme mit der Entwicklung, Produktion und Auslieferung der neuen ICE 3 Züge vom Typ Velaro D (DB-Baureihe 407). Nachdem es bereits Verschiebungen auf Grund von Problemen mit einem Lieferanten gegeben hat, gab die Siemens AG im Herbst 2012 bekannt, das sich die Auslieferung der ersten Exemplare der neuen Triebzüge erneut verschieben wird. Als Grund wurden, neben diverser anderer Mängel, vor allem sicherheitsrelevante Software-Probleme in der Zugsteuerung genannt, die zu einem kritischen Bremsverhalten des Zuges führen können. Es wurden “viele, teils gravierende, Mängel … im Zusammenhang mit der Bremse” aufgezeigt, darunter “verzögertes Einsetzen der Bremswirkung”.

Der damalige Bundesverkehrsminister Peter Ramsauer (CSU) reagierte medienwirksam empört und wies auf feste Lieferzusagen “von allerhöchster Ebene” seitens Siemens hin. Und DB-Fernverkehrschef Berthold Huber hatte sich anscheinend sofort ein repräsentatives Stimmungsbild bei der Kundschaft abgeholt bevor er feststellte, das die Bahn-Kunden sich von Siemens “im Stich gelassen” fühlten.

Was man von den optimistischen Aussagen “von allerhöchster Ebene” – also: von Top-Managern – halten kann, darüber hat sich Jutta Eckstein in ihrem Heise-Developer-Blog schon so ihre Gedanken gemacht. Man hätte vielleicht auch mal diejenigen fragen sollen, die sich mit der Materie auskennen, statt auf großspurige und zumeist geschönte Aussagen von der Konzernspitze zu vertrauen.

Sogleich meldeten sich damals in den Diskussionsforen und auf den Kommentarseiten diverser Online-Zeitungen die ganzen “Bahntechnik-Experten” unserer Republik zu Wort. Bar jeglicher Detailkenntnisse über die genauen Ursachen für das ICE-Problem, echauffierte man sich über die verloren gegangene, deutsche Ingenieurskunst, über die “lächerliche 1 Sekunde Verzögerung beim Bremsen”, was selbst ein C64-Heimcomputer aus den 1980er Jahren besser hinbekommen hätte. Ein Kommentator fragte, wieso die Bahn nicht japanische Hochgeschwindigkeitszüge kaufen würde, denn “die Asiaten können das besser”. “Die Europäer”, so der Schreiber weiter, “seien ja schon fast überall auf griechischem Niveau angekommen”.

Dabei kann die enorme Komplexität von solchen High-Tech-Großprojekten, bei denen viele Ingenieure und Entwickler unterschiedlichster Fachdisziplinen zusammenarbeiten müssen, von der Allgemeinheit kaum erahnt werden. Moderne Züge vom Kaliber eines ICE 3 sind aus technologischer Sicht eher vergleichbar mit aktuellen Flugzeugtypen, wie beispielsweise dem Airbus A380 oder der Boeing 787 Dreamliner. Schon alleine diese enorme technische Systemkomplexität macht es praktisch unmöglich, das ein einzelner Entwickler, ein Projektleiter, und erst Recht nicht ein Manager oder gar der Kunde, den Überblick behalten kann. Darüber hinaus kommen in Systems Engineering Projekten viele der folgenden Herausforderungen hinzu:

• Berücksichtigung des gesamten Systemlebenszyklus – von der Entwicklung, über den Betrieb, bis zur Entsorgung des Produkts
• Viele verschiedene Subsystem- und Komponenten-Hersteller und Zulieferer
• Komplexe Organisationsstrukturen mit weltweit verteilten, interkulturellen Teams
• Steigende Qualitätsanforderungen bei gleichzeitig sinkenden Budgets
• Dynamisches Umfeld: unvorhersehbare Ereignisse und enttäuschte Erwartungen sind an der Tagesordnung
• Strikte Einhaltung von Normen und Standards, beispielsweise der funktionalen Sicherheit (regulatorisches Umfeld/behördliche Zulassung)
• Immer kürzere Time-To-Market-Zyklen
• Großer Konkurrenzdruck, vor allem aus Schwellenländern, verursacht durch die Globalisierung
• Demografischer Wandel: die Veränderung der Bevölkerungsstruktur wirkt sich zunehmend auf die Beschäftigtenstruktur aus.
• Ein steigendes Umweltbewusstsein fordert immer nachhaltigere Produkte

Der neue Flughafen Berlin-Brandenburg, die Hamburger Elbphilharmonie, der Airbus A400 M, … alle diese Projekte wurden bereits durch die Überlagerung von einigen oder vielen der vorgenannten Faktoren massiv beeinträchtigt. Die Folgen sind hinreichend bekannt.

Komplexität – reduzieren oder erhöhen?

Ich denke es wird jedem sehr schnell klar, dass vor diesem Hintergrund eine Erhöhung der Komplexität töricht wäre. Schon die sog. systeminhärente (inhärent = einer Sache innewohnend) Komplexität solcher Systeme und Projekte ist derart hoch, dass jedes Quäntchen zusätzliche, quasi hausgemachte Komplexität schädlich wäre. Doch leider ist es in vielen Projekten immer noch Standard, das man sich weitere Last aufbürdet, ohne das es dafür einen hieb- und stichfesten Grund gibt.

Von daher liegt es Nahe, das man Komplexität eher reduzieren sollte. Doch das ist bei der systeminhärenten Komplexität in der Regel auch nicht möglich, außer man schafft es als Hersteller die Stakeholder zu überzeugen, das man beispielsweise bestimmte Anforderungen an das System bzw. Produkt nicht erfüllen muss. Das ist sicherlich manchmal möglich, aber bei dem o.g. Beispiel des Bremswegs für die ICE 3 Züge aussichtslos, denn die strengen Zulassungsvoraussetzungen im regulierten Bahnbetrieb können nicht einfach wegdiskutiert werden.

Dann lasst uns doch das Projektmanagement verbessern!

Im Juni diesen Jahres hat der Generalinspekteur der Bundeswehr, Volker Wieker, entschieden, dass das Luftverteidigungssystem MEADS (Medium Extended Air Defense System) vom deutsch-italienischen Rüstungshersteller MBDA und dem US-Unternehmen Lockheed Martin beschafft wird. MEADS soll die in die Jahre gekommenen Flugabwehrsysteme Roland, Hawk und teilweise auch Patriot der Bundeswehr ablösen. Auf die Frage hin, wie man denn sicherstellen will, das auch dieses Rüstungsprojekt nicht wieder mit einer immensen Kostenexplosion, Lieferverzögerungen und diverser technischer Probleme enden wird, sagte Bundesverteidigungsministerin Ursula von der Leyen (CDU) am 10. Juni 2015 in einem Interview beim Nachrichtensender N24 (Hervorhebungen von mir):

„[…] Nämlich, mit dem Blick nach vorne, ein sehr modernes Projektmanagement aufsetzen, das heißt: Ganz am Anfang die Strecke durchplanen, die Risiken früh benennen (…) Zweiter Punkt: Ganz enge Verbindung zwischen denen, die sozusagen im Maschinenraum das Projekt bearbeiten und der Leitung, und wir übernehmen im Ministerium sozusagen eine Parallelkontrolle zur Produktion des Unternehmens, das heißt, das was ich Ihnen schildere, sind sehr moderne Managementansätze, die man nimmt, um Großprojekte zu machen. (…) Diese klare Ansage auch an die Entwickler macht deutlich, wie die Erwartungshaltungen auf beiden Seiten sind (…) und das macht einen hohen Druck auf die Anbieterfirma.“

Planung – Kontrolle – Druck. Das, was die Verteidigungsministerin der Öffentlichkeit hier als “sehr moderne Managementansätze” verkauft, sind Methoden aus dem Zeitalter der Industrialisierung, die ganz sicher noch für die industrielle Massenproduktion für den trägen Markt bis etwa gegen Ende des 20. Jahrhunderts adäquat gewesen sind. Damals waren Planung, Kontrolle und Steuerung noch möglich und durchaus ein probates Mittel, damit eine Organisation wirtschaftlich erfolgreich ist.

Wie bereits weiter oben gesagt, sind komplexe Systementwicklungsprojekte allerdings genau solche, die sich unter anderen gegen eine Kontrolle/Steuerung zur Wehr setzen. Überraschungen (unvorhersehbare Ereignisse und enttäuschte Erwartungen) sind in einem solchen Umfeld an der Tagesordnung. Die Planung (d.h. die Vorwegnahme der Zukunft) wird dabei schwierig bis unmöglich, vor allem vor so einem sehr langen Zeithorizont wie bei MEADS mit einer Projektlaufzeit von rund 10 Jahren.

Um mit solchen High-Tech-Großprojekten, und der damit einhergehenden Komplexität, angemessen umgehen zu können, genügt es eben nicht einfach nur irgendein besseres Projektmanagement zu praktizieren, bzw. das, was bei früheren Projekten schon nicht funktioniert hat, noch mehr und noch intensiver zu praktizieren. Das Management (d.h. der Versuch, ein System unter Kontrolle zu bringen und es zu beherrschen) ist vor diesem Hintergrund ein ausgesprochen schwieriges unterfangen, und ist mit den klassischen Werkzeugen der Kontrolle und Steuerung, die vor vielen Jahrzehnten noch ganz gut funktioniert haben, nicht mehr möglich.

Wie mit Komplexität umgehen?

Da man die inhärente Komplexität eines Systems ohne Verzicht auf die Erfüllung von Anforderungen nicht reduzieren kann, sind Strategien, Methoden und Techniken notwendig, um mit dieser Komplexität angemessen umgehen zu können.

Strategie statt Planung: Ein Plan ist die (gedankliche) Vorwegnahme der Zukunft. Das macht manchmal Sinn und kann durchaus nützlich sein, nämlich dann, wenn stabile Verhältnisse zu erwarten sind. In einem komplexen Umfeld mit hoher Dynamik ist allerdings die Halbwertszeit eines Plans ausgesprochen gering. Alleine nur während des Zulassungsprozesses des ICE 3 mussten 230 technische Anpassungen an den Zügen aufgrund veränderter technischer Vorschriften vorgenommen werden. Hier versagt Planung; irgendwelche verbindlichen Zusagen bezüglich Projektmeilensteine u.ä. werden in einem solchen Umfeld schnell zur Makulatur.

Was man stattdessen benötigt, ist eine Strategie. Eine Strategie stellt den Projektmitarbeitern einen Handlungsraum zur Verfügung, damit diese den Weg zum Ziel beim Gehen aufdecken können. Innerhalb dieses Handlungsraums können Projektmitarbeiter selbstständig die richtigen Entscheidungen treffen, was vor allem dann nützlich ist, wenn man mit unvorhersehbaren Ereignissen konfrontiert wird, die eine Planung sofort zunichte machen würden.

Gut geeignete Strategiewerkzeug für diesen Zweck sind beispielsweise die agilen Methoden im Projektmanagement. Diese akzeptieren das dynamische Umfeld als Normalfall. Das agile Manifest ist ja nichts anderes als ein Leadership Mindset, welches Prinzipien aufstellt, damit Teams selbstorganisiert die richtigen Entscheidungen treffen können, anstatt sie stur einem Plan folgen zu lassen. Die kurzen (iterativ-inkrementellen) Entwicklungszyklen von beispielsweise Scrum als ein Vertreter agiler Frameworks können unter anderem ziemlich gut mit Überraschungen umgehen. Scrum stellt ein dynamikrobustes Framework für die erfolgreiche Entwicklung komplexer Produkte zur Verfügung.

Systems Engineering: Das Systems Engineering ist die große Klammer, die eine angemessene, interdisziplinäre Sicht auf das Gesamtproblem einnimmt. Diese interdisziplinäre und ganzheitliche Sicht auf das zu entwickelnde System fehlt leider noch in vielen Entwicklungsorganisationen – es mangelt am sogenannten Systems Thinking. Das heißt, es fehlen oftmals Denkweisen, Methoden und Prozesse für eine fachdisziplinen-übergreifende Verknüpfung und Koordination aller Aktivitäten und Einzelergebnisse in einem Projekt. Das Systems Engineering adressiert den gesamten Lebenszyklus eines Produkts: von den ersten, vagen Ideen und Visionen, über die Entwicklung, die Integration und den Test, bis hin zum Betrieb inkl. Wartung und die Entsorgung des Produkts (Disposal).

Organisationsentwicklung: Viele Entwicklungsorganisationen besitzen auch heute noch hierarchische Strukturen, die im Industriezeitalter noch gut funktioniert haben. Im Komplexitätszeitalter hingegen sind diese klassischen Command-and-Control-Gebilde eher hinderlich, mitunter sogar sehr problematisch. Die, die eigentlich eng zusammenarbeiten müssen, werden voneinander abgeteilt; daher der entlarvende Name Abteilung für die dadurch entstehenden, funktionalen Organisationseinheiten. Die Maschinenbauer, Konstrukteure, Elektroingenieure, Hardwareentwickler, Softwareentwickler, die Qualitätssicherung, etc. werden voneinander separiert, sollen doch aber gemeinsam ein Produkt entwickeln – wie passt das zusammen? Dadurch wird die notwendige Kommunikation zwischen diesen Mitarbeitern erheblich erschwert, wichtige Entscheidungen werden häufig erst sehr spät auf den darüber liegenden Managementebenen getroffen, es gibt Konflikte und Kompetenzrangeleien um Verantwortlichkeiten und Zuständigkeiten, etc. Zudem existieren zahlreiche schwerfällige Prozesse und Vorschriften, die zu der ohnehin schon hohen Komplexität des zu entwickelnden Produkts auch noch jede Menge hausgemachte Komplexität hinzufügen. Statt sich also um die Dinge zu kümmern, die für das Unternehmen wertschöpfend sind, verschwenden in solchen Organisationen viele Mitarbeiter einen signifikanten Anteil ihrer Zeit mit unnützem Zeug.

Daher müssen auch die Organisationen sich verändern und sich neu aufstellen, um im Komplexitätszeitalter weiterhin bestehen zu können. Die romantische Vorstellung, dass es nur einen visionären “Kapitän” an der Spitze des Unternehmens braucht, der seinen Tanker – die Organisation – mit Hilfe seines Wissensvorsprungs souverän durch unruhiges Gewässer steuert, gehört der Geschichte an.