Vor Komplexität nicht kapitulieren Ursachen und Wirkungen in komplexen Projekten visualisieren und analysieren

Komplexität dient häufig als Entschuldigung dafür, dass bestimmte negative Entwicklungen in einem Projekt nicht vorhersehbar waren. Mit der Explorativen, Qualitativen Ursache-Wirkungsmodellierung präsentiert Kai Neumann eine Methode, die diese Entschuldigung nicht mehr gelten lässt. Anhand eines einfachen Beispiels zeigt er auf, wie man Wirkungszusammenhänge visualisiert, modelliert und in ihren Auswirkungen analysiert. Wer frühzeitig einen Teufelskreis erkennt, hat die Chance, ihn in einen Engelskreis zu verwandeln.

 

Vor Komplexität nicht kapitulieren Ursachen und Wirkungen in komplexen Projekten visualisieren und analysieren

Komplexität dient häufig als Entschuldigung dafür, dass bestimmte negative Entwicklungen in einem Projekt nicht vorhersehbar waren. Mit der Explorativen, Qualitativen Ursache-Wirkungsmodellierung präsentiert Kai Neumann eine Methode, die diese Entschuldigung nicht mehr gelten lässt. Anhand eines einfachen Beispiels zeigt er auf, wie man Wirkungszusammenhänge visualisiert, modelliert und in ihren Auswirkungen analysiert. Wer frühzeitig einen Teufelskreis erkennt, hat die Chance, ihn in einen Engelskreis zu verwandeln.

 

Projekte scheitern, wenn entscheidende Zusammenhänge gar nicht gesehen oder ihre Dynamiken unterschätzt wurden, wenn also die Projektverantwortlichen ihre Wahrnehmung eines komplexen Projekts zu stark vereinfacht haben. Sobald etwas aus dem Ruder läuft, sind sie dadurch zum einen nicht in der Lage, adäquat darauf zu reagieren, und zum anderen der festen Überzeugung, dass keiner die dafür ursächlichen Zusammenhänge sehen und dementsprechend auch nicht richtig einschätzen konnte.

Elbphilharmonie und BER: "Augen zu und durch" führt direkt ins Projekt-Desaster

Die in der Presse vielfach dokumentierte Ignoranz der Verantwortlichen gegenüber der komplexen Aufgabenstellung eines ehrgeizigen Prestigeprojekts beim Bau der Elbphilharmonie ist hierfür ein typisches Beispiel. Beim Bau des Berliner Großflughafens BER ließen sich die Verantwortlichen u.a. vom Nichtfunktionieren der Brandschutzanlage "überraschen", die ein zentrales Sicherheitssystem eines jeden Flughafens ist.

Das Ashbysche Gesetz

Projekte sind komplexe Systeme. Wer ein komplexes System steuern will, kommt um das Ashbysche Varietätsgesetz nicht herum. Dieses grundlegende Gesetz der Kybernetik besagt vereinfacht, dass ein steuerndes System (also das Projektmanagementteam) umso besser ein anderes System (das Projekt) steuern kann, je mehr Varietät (Handlungsmöglichkeiten) es selbst hat.

Mögliche Entwicklungen frühzeitig erkennen, um handlungsfähig zu bleiben

Projektverantwortliche sollten deshalb versuchen, die Anzahl der möglichen Entwicklungen eines Projekts durch eine Vorab-Reflexion möglichst vieler dieser Entwicklungen in den Griff zu bekommen. Dadurch sind sie in der Lage, gemäß Ashbyschem Varietätsgesetz die eigene Varietät – d.h. die Zahl der zur Verfügung stehenden Handlungsmöglichkeiten – dem Umfeld anzupassen.

Ich möchte Ihnen im Folgenden die "Explorative, Qualitative Ursache-Wirkungsmodellierung" vorstellen. Anhand eines einfachen, konkreten Beispiels demonstriere ich Ihnen, wie Sie mit Hilfe dieses Modells die Wahrscheinlichkeit maximieren können, dass Sie die entscheidenden Zusammenhänge sehen und richtig bewerten. Dabei geht es in diesem Beitrag um Projekte mit grundsätzlich bekannten Projektschritten, d.h. in traditionellem Verständnis "planbaren" Projekten. Die Projektmodellierung ist selbstverständlich auch bei neuartigen Projekten möglich und ganz besonders sinnvoll – dies wird Gegenstand eines eigenen Beitrags sein.

Modellieren ist besser als Entscheidung nach Bauchgefühl!

Die möglichen Entwicklungen eines Projekts vorherzusehen halten viele für unmöglich – und zwar zu Recht! Auch für den hier vorgestellten Ansatz gilt: "Alle Modelle sind falsch, nur manche sind nützlich" oder wie der britische Mathematiker George E. P. Box es ausdrückte: "Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful" (dt.: "Denke daran, dass alle Modelle falsch sind; für die Praxis kommt es darauf an, wie falsch sie sein müssen, damit sie nicht nützlich sind").

"Nützlich" bedeutet in diesem Zusammenhang, dass sie uns besser auf die Realität vorbereiten. Auch gilt, dass selbst das schlechteste Modell vermutlich besser ist, als kein Modell zu verwenden, denn die Alternativen sind:

  • die Entwicklungen des Systems dem Zufall überlassen
  • aus dem Bauch zu entscheiden
  • auf "Best Practices" zu vertrauen

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
11 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 7
Kommentare 11

Alle Kommentare (11)

Rüdiger
Geist

Hallo Herr Neumann, schöner Artikel. Kompliment. Zunehmend gewinne ich aber den Eindruck, dass die Artikel im Projektmagazin mit einer Art von "reisserischer" Kurzbeschreibung begonnen wird, welcher der Artikel später nicht ganz gerecht wird. So ging es mir auch hier. Z.B. der Satz "Komplexität dient häufig als Entschuldigung dafür, dass bestimmte negative Entwicklungen in einem Projekt nicht vorhersehbar waren." machte mich neugierig. Ich hääte gerne gewusst woher diese Erkenntnis kommt, dass Komplexität als Entschuldigung benutzt wird und hätte mir gewünscht hierzu mehr zu erfahren. Letztendlich bleibt es aber nur eine Behauptung, da nicht durch Quellen belegt. Auch wenn ich die von ihnen vorgestellte Vorgehensweise durchaus als sinnvoll erachte, so fehlt mir doch ein wenig das Aufzeigen deren Grenzen. Ohne tief in diesen Themen zu sein, scheint mir doch offensichtlich, dass es weniger um das Auffinden von Wirkungszusammenhängen geht, als um die Darstellung und Analyse. Wenn mir Wirkungszusammenhänge nicht bekannt sind, hilft mir auch die Darstellung nur wenig. Auch gegenseitige Beeinflussung (z.B. durch Interaktion) konnte ich in den Grafiken nicht finden (vielleicht habe ich es übersehen). Vermutlich kann die von ihnen erwähnte SW das sogar abbilden, aber das muss sie aus meiner Sicht gar nicht. Und ich denke Sie haben völlig Recht zu sagen, lieber ein Modell als gar keins, sofern es hilft und die Kommunikation darüber in Gang bringt. Was mir allerdings ein wenig zu vereinfachend daher kommt, sind Ihre Beispiel Elbphilharmonie und BER. Abgesehen davon, dass wir vermutlich nur einen Bruchteil der tatsächlichen Vorgänge kennen, scheint mir die Annahme, dass wären sich alle über Ursache-Wirkungszusammenhänge im Klaren gewesen, das Ergebnis deutlich positiver wäre doch ein wenig banalisiert. Dies würde voraussetzen, dass unsere Entscheidungen wesentlich durch "für die Sache (das Projekt) sinnvoll und richtig" geprägt würden. Das dem nicht so ist, wissen wir schon sehr lange und für modernere Organisationsformen spätestens seit den 90-igern (Niklas Luhmann, Kahnemann, ...). Umso mehr schätze ich Ihren Artikel als Beitrag zum Thema "Komplexe Projekte", denn aus meiner Sicht ist die Kommunikation über die Komplexität wichtiger, als die Genauigkeit in der Erfassung dieser Komplexität. Und das finde ich zeigen Sie toll auf. Lieben Gruss

 

Kai
Neumann

Hallo Herr Geist Vielen Dank für Ihr Feedback. In der Tat kenne ich keine Untersuchung zum Verweis auf Komplexität als Entschuldigung für nicht bedachte Entwicklungen. Außer vielleicht der geradezu täglichen Erfahrung, wenn Menschen sagen "das kann man eh nicht vorhersagen" etc.. Die Psychologie nennt vergleichbar die Selbsterlernte Hilflosigkeit. Gestern in den Nachrichten hat der Chef von HochTief zur Elbphilarmonie sinngemäß gesagt, dass Komplikationen bei so vielen Faktoren und Ingenieuren kein Wunder sind. In einem anderen Interview hat jemand anderes festgestellt, es wurde schon gebaut ehe fertig spezifiziert war. Bekannte Zusammenhänge visualisieren und analysieren macht die deskriptive Modellierung. In dem Artikel sollte die explorative Modellierung vorgestellt worden sein, für die Kommunikation, Kreativität, das Einbeziehen von Experten und Stakeholdern, und die dort vorgestellte KNOW-WHY-Fragetechnik entscheidend sind. Dass bei öffentlichen Bauprojekten Probleme gewollt sein können, steht außer Frage. Dass es einen emotionalen Bias bei der Wahrnehmung von Zusammenhängen gibt, auch. Allerdings dient genau dort die Modellierung, wenn das mentale Modell einzelner anderen vorgelegt wird. Wenn immer also ein einzelner Wirkungspfeil subjektiv und Deutungshoheit scheint, sollten die Faktoren, die hinter der Annahme stehen, dem Modell hinzugefügt werden. Tatsächlich entscheidend scheint mir, dass, um überhaupt erst zu denken und dann zu handeln, und für das Denken auch noch eine Software zu nutzen, ein Kulturwandel notwendig ist. Denn wir sind es gewohnt, aus dem Bauch und ohne zu viel Aufwand zu entscheiden und wir fühlen uns sicherer zu meinen, wir könnten etwas nicht vorhersehen, als es zu versuchen und dafür verantwortlich gemacht werden zu können. Nochmals besten Dank wie Gruß von der Küste

 

Wolfgang
Merten
Dipl.-Ing.

Hallo Her Neumann, ich halte Ihre Gedankenansätze für grundsätzlich richtig - jedoch erscheint mir bei der Umsetzung in der Praxis sehr schnell eine Grenze des Überschauens erreicht. Normalerweise plant der Architekt ein Haus und muss genau diese Fragen - wo kommt die PV-Anlage hin, in Bezug zu den Sparren - im Vorfeld geklärt haben. Der Grundsatz: Erst Denken dann Handeln bzw. erst Planen dann Ausführen scheint mir von Ihnen gleich übersprungen. Eine Diskussion vor Ort zwischen dem Architekten und den Handwerkern, was nun zu tun sei, um doch noch eine vernünftige Lösung zu generieren und die Auswirkungen - Kabelverzug durch Dämmung - ist bestimmt machbar. Ich möchte jedoch den Fokus eigentlich auf die vollständige Spezifikation der Projektziele legen. Hierzu kann die vorgestellte Methode zu berücksichtigende Anhaltspunkte liefern. Ob dies bei einem Mammutprojekt wie dem BER überhaupt noch darstell- und bewertbar wäre, wage ich jedoch zu bezweifeln. Beste Grüße aus Berlin

 

Hallo Herr Merten Auch Ihnen vielen Dank für das Feedback. Sie laden mich damit ein, auf die Bedeutung des verwendeten Tools hinzuweisen. Vorweg der Hinweis, dass genau das "Erst Denken dann Handeln...." mit diesem Ansatz passieren soll. Da ist der Artikel vielleicht missverständlich. Dass es schnell unübersichtlich werden kann, ist natürlich Aufgabe des Werkzeugs. Dieses erlaubt auch Modelle mit etlichen Tausend Faktoren abzubilden und auszuwerten. Es wird immer nur (gehirngerecht) aus der Perspektive eines bestimmte Faktors auf das Modell geblickt, es werden Ebenen ausgeblendet, Faktoren erhalten Kategorien hernach gefiltert und geclustert werden kann, usw.. In der Praxis können dann in kurzen Meetings Beteiligte jeweils ihren Ausschnitt eines riesigen Modells bearbeiten und dabei unmittelbar die Argumente visualisieren, die verbal eh ausgetauscht werden. Im Hintergrund entsteht ein Gesamtmodell, bei dem das Management aber auch jeder Bereich für sich in Matrizen und Wirkungspfaden anzeigen kann, wo die Risiken sind, was getan werden muss, womit im Gesamtkontext das eigene Wirken zusammenhängt. Der Artikel sollte nicht so sehr auf das Tool abheben, aber gerade bei Großprojekten geht es ohne Tool nicht mehr. Unabhängig vom Tool ist der Mehrwert, dass mit Blick auf die visualisierten Zusammenhänge und mit der systematische Frageweise das "Erst Denken" gefördert wird. Wenngleich das Beispiel mit der PV-Anlage tatsächlich real ist und eine Kabeldurchführung durch die Dämmung eine lästige Wärmebrücke darstellt, ist das Beispiel natürlich sehr einfach gehalten und nur für die Anleitung im Artikel konstruiert. Viele Grüße nach Berlin

 

Gerhard
Friedrich
Dr.

Interessanter Beitrag. Ganz banal schon einmal das Tool, trifft einen Bedarf, für den ich bisher kein Angebot kannte. Allerdings sehe ich Mindmapping als einfache Methode zum Einstieg in so ein Thema immer noch als sinnvoll an. Modelle als Instrument zu thematisieren finde ich gut, schreibe gerade an einem Artikel, wo ich das an einem anderen Beispiel zu demonstrieren versuche. Sie zitieren Ashby (Requisite Variety). Ich halte diese Regel für sehr problematisch. Im Original heißt es (habe extra das Buch herausgesucht): "Nur Vielfalt kann Vielfalt zerstören". Das ist offenbar falsch, denn mit der Dampfwalze (sehr einfältig) kann ich einen botanischen Garten (der sehr vielfältig ist) ganz schnell und nachhaltig zerstören. Der Gärtner wird allerdings ein etwas komplexeres Modell brauchen, der Botaniker auch, wenn auch ein anderes. Es kommt also immer auf das Ziel an, wieviel Komplexität man braucht. Konkreter: Ein Projekt zu stoppen ist oft die sinnvollste Maßnahme überhaupt und erfordert keinerlei Eingehen auf die innere Komplexität der Ursache-Wirkungs-Zusammenhänge im Projekt. Und auch sonst arbeiten wir doch immer mit stark vereinfachten Darstellungen sehr erfolgreich. Wenn ich den richtigen Ansatzpunkt (den Engpass) finde und richtig adressiere, erspare ich mir die Detailanalyse, das System schwingt sich "von selbst" wieder ein (weil die mir durchaus nicht im Detail bekannten Mechanismen wirken). Das ist nun kein Argument gegen Ihren Artikel, ich muss das nur einmal loswerden, denn Ashbys "Gesetz der erforderlichen Vielfalt" ist nicht so vielen bekannt, wird aber, wenn überhaupt, immer als selbstverständlich richtig zitiert.

 

Kai
Neumann

Äh, meine recht umfangreichen Antworten scheinen zeitverzögert gelöscht zu werden bzw. technisch zu verschwinden - kläre das erst einmal......

 

Kai
Neumann

Hallo Herr Dr. Friedrich Vielen Dank für Ihren Hinweis - habe es bei Ashby nun auch gefunden. Er nennt es eine bildhaftere Beschreibung des "Only variety in R's moves can force down the variety in the outcomes". Er benutzt den Allquantor "immer" und das ist natürlich falsch. Sie nennen denn zwei Beispiele, wobei Ihre Alternative bei beiden vom Ziel abhängt, was Sie glaube ich auch meinen. Umgekehrt würde ich nicht allein sagen, dass Komplexität grundsätzlich auch mit einfachen Mitteln begegnet werden kann, sondern nur dann, wenn das zufällig noch mit der Zielsetzung (bei Projektaufgabe der übergeordneten) konform geht. Lieber würde ich doch für eine Reflexion werben. Ein Projekt abzubrechen kann richtig sein, wenn der schlechte Ausgang sicher ist. Das nicht zu reflektieren, sondern einfach zu tun, führt dann dazu qua Deutungshoheit zu sagen, eine Fortführung wäre falsch gewesen. Zu einer Reflexion gehört dann auch die Berücksichtigung übergeordneter Ziele und natürlich auch die emotionaler Aspekte (Wunschdenken, Dissonanzabbau, ....). Spannend finde ich auch Ihren Hinweis "Wenn ich den richtigen Ansatzpunkt (Engpass) finde und richtig adressiere, erspare ich mir die Detailanalyse....". Das mag ohne Reflexion gelingen, aber ich meine es gibt weniger Fälle, in denen eine Reflexion das gute Bauchgefühl für ein Finden solcher Ansatzpunkte verhindert, als es Reflexionen gibt, die auch wirklich die richtigen Ansatzpunkte zu finden erlauben. Die ToC Community um Goldratt herum geht ja mittlerweile auch in Richtung systemischer Constraint - Suche. Ich hoffe schon bald dazu auch im ProjektMagazin einen Artikel zu verfassen. Zusammengefasst können Sie also in vielen Fällen Recht haben, dass doch auch eine einfache Lösung ohne Reflexion funktioniert, nur würde ich sagen, dass eine Reflexion zumal mit mehr und mehr Übung besser ist.

 

Gerhard
Friedrich
Dr.

Antwort auf von Kai Neumann

Einfache Lösungen mit Verzicht auf Reflexion gleichzusetzen scheint mir doch ungewollt polemisch. Der Abbruch eines Projektes erfolgt aus der Perspektive des Umsystems mit guten Gründen und das Finden des Engpasses ist auch kein Lucky shot. Bin schon gespannt auf ihren Artikel.

 

Kai
Neumann

Hmm, ungewollt auf jeden Fall und vielleicht auch nur ein Missverständnis? Sie schrieben "Ein Projekt zu stoppen ist oft die sinnvollste Maßnahme überhaupt und erfordert keinerlei Eingehen auf die innere Komplexität der Ursache-Wirkungs-Zusammenhänge im Projekt."

 

Gerhard
Friedrich
Dr.

Die innere Komplexität, also was im Projekt schief gelaufen ist, kann und soll für lessons learned analysiert werden, jedoch nicht in der Tiefe, die man für einen Turnaround brauchen würde. Und generell gilt: Das Missverständnis ist der Normalfall ;-)

 

Kai
Neumann

Entscheidend scheint mir den (vermeintlichen) Mehraufwand für eine Reflexion auf sich zu nehmen. Dazu eine Anekdote: am Ende eines Newsletters gab es den Link auf das "Einstein-Rätsel", das angeblich nur 2% der Menschen lösen können. Also trotz der knappen Zeit schnell ran das Projekt. Zuerst ging ich natürlich davon aus, dass ich mit Blick auf die Fragestellung schon sehen würde, was die Lösung ist. Als sich schnell merkte, dass es so einfach nicht ist, war der Reflex die Aufgabe anzuzweifeln - ich vermutete die Lösung müsse sein, dass es keine Lösung gibt oder so ähnlich. Das wurde aber nicht der Ankündigung der Aufgabe gerecht. Also einfach einen Kugelschreiber genommen und auf der Rückseite eines Briefumschlages angefangen, das Projekt abzuarbeiten. Ich bemerkte schnell, dass eine Visualisierung der vielen Faktoren der Aufgabe vermutlich helfen würde, hatte aber keine Lust Handy oder Tablet zum Modeln an den Frühstückstisch zu holen. Weiter hinten merkte ich, dass eine Matrix-Visualisierung sogar noch besser gewesen wäre, aber die passte nicht auf den Briefumschlag. Also mühsam weiter probiert und nach irren 2 Stunden dann endlich die Lösung gefunden. Und tatsächlich wäre es mit einem Tool viel einfacher gewesen. Die Moral von der Geschicht: selbst einem Tool-Anbieter kann es passieren, dass er den Aufwand eines Tools scheut und es so probiert. Und gäbe es die Eitelkeit nicht, wäre der nächst-vernünftige Schritt gewesen, das Projekt abzubrechen und auf die fertige Lösung zu blicken. Ich bin also froh es geschafft zu haben, ärgere mich über die Zeit, die es gekostet hat, und meine Faulheit, kein Werkzeug eingesetzt zu haben. Die Kenntnis von Tools, das Vorhandensein der Tools, und selbst die positiven Erfahrungen aus der Vergangenheit allein reichen nicht, diese auch lieber einmal zu viel als zu wenig einzusetzen. Sie helfen aber! Letztlich bedarf es einer Kultur der Reflexion für den einzelnen wie für eine Organisation: https://www.know-why.net/model/AjuKM1aY9TMTxRV9iJs8TBw