Abstract
This chapter will focus on complexity, starting with a short introduction to the subject by defining it and differentiating between real complexity and the feeling of something being complex. An overview of common pitfalls and known fields of complexity will lead to the discussion of the need for complexity and the ways to deal with it providing analogies and corresponding examples helping to simplify in order to find adequate solution approaches to situations. This chapter will aim to help readers open up to understand, handle, and solve situations applying appropriate tools and techniques. Moreover the chapter will recognize the intensified existence of complexity - whether genuine or felt - which entails the demand for new competencies and approaches and therefore will help identify forces, structures, order parameters, and opportunities within
Outline (Entwurf)
1.) Intro
- Thematische Annäherung an Komplexität
- Die andere Seite der Komplexität
- Ashbys und Luhmanns Komplexitätsdilemmna
2.) Agiles Management von Komplexität
3.) Tools & Techniken
4.) Zusammenfassung
Text (Entwurf)
1.) Intro
Die Komplexität - Eine allgemeine Einführung
Der Begriff der Komplexität (v. lat.: complectere = umarmen, umfassen) ist in jedermanns Munde und wurde von jedem sicherlich schon einmal verwendet. Die eigene subjektive Einschätzung über die Bedeutung muss dabei nicht falsch sein, sie bietet aber keinen Ansatz für eine einheitliche Betrachtungsweise, insbesondere im professionellen Kontext. Die subjektive Einschätzung und damit die zusammenhängende Begriffsdefinition hängt von vielen persönlichen Faktoren wie Herkunft, Bildung, Beruf, Umfeld, Einstellung etc. ab. Daher soll an dieser Stelle eine Einführung in die verschiedenen verbreiteten und teilweise anerkannten Definitionen zur Komplexität erfolgen.
Einfachheit bzw. Trivialität ist das Gegenteil zur Komplexität, so viel kann einmal festgehalten werden. Einfachheit ist bestimmbar, d.h. deterministisch, überschaubar und linear. Komplexität ist im Gegenzug zur Trivialität nicht linear, d.h. der allgemein bekannte Flügelschlag eines Schmetterlings irgendwo in Europa kann theoretisch einen Orkan in Asien auslösen. Des Weiteren ist die Komplexität nicht überschaubar und lässt sich nicht abschließend formal beschreiben oder nur unter Zuhilfenahme von starken Vereinfachungen des wahren Systemverhaltens definieren.
Die Systemtheorie erklärt die Komplexität eines Systems über die Anzahl der Elemente, die Anzahl der Verknüpfungen bzw. Wechselbeziehungen sowie über die Funktionalität bzw. das Verhalten dieser Elemente über die Verknüpfungen zueinander. Komplexität beschreibt also die Vielfalt der Beziehungen von Elementen und deren dazugehöriges nicht lineares, bzw. nicht deterministisches, d.h. nicht vorhersehbares Verhalten. Als wichtiges Merkmal komplexer Systeme, für den Entscheider wird die damit zusammenhängende Intransparenz des komplexen Systems angesehen.
Die allgemeinen Ausführungen zur Komplexität lassen sich mit folgender Eselsbrücke zusammenfassen:
„EBV(t)“, was für E: Elemente – B: Beziehungen – V: Verhalten – (t): Zeit steht.
Das bedeutet, dass Komplexität vereinfacht ausgedrückt wird durch die Vielzahl der Elemente, die Anzahl der Wechselbeziehungen und das Verhalten der Elemente bzw. deren Wechselbeziehungen zueinander. Und das zeitlich veränderbar!
Grafik: Michael Frahm/ Simone Fass - Komplexität
Die andere Seite der Komplexität
Doch immer wieder gibt es auch Situationen, die uns aufgrund ihrer Komplexität vor Herausforderungen stellen, von anderen jedoch sofort durchdrungen oder gar gelöst werden. Ebenso erleben wir selbst auch, dass andere sich die Zähne ausbeißen, während wir eine Lösung direkt parat haben. Woran liegt das? Neben der faktischen, objektiven Komplexität gibt es auch gefühlte, subjektive Komplexität. Diese erhöht den Schwierigkeitsgrad einer Aufgabe, eines Projektes oder einer Beziehung ebenfalls, aber dies ganz spezifisch für den Einzelnen.
So durchschlug Alexander der Große den Gordischen Knoten mit seinem Schwert, wenngleich das Aufbinden die eigentliche Aufgabe war. Dennoch hatte er das gewünschte Ergebnis – die Loslösung des Streitwagens – ohne Zweifel erreicht.[1] Eine ähnliche Herangehensweise demonstrierte Christopher Columbus mit dem berühmten Ei, das er beherzt und somit standfest auf den Tisch setzte.[2] Beide Lösungsfindungen haben gemein, dass sie bekannte bzw. angenommene Voraussetzungen ignorierten und dadurch einen Lösungsweg außerhalb des erwarteten Schemas fanden. Lösungen, die kein anderer fand. Mittlerweile ist dieses Vorgehen weitbekannt und wird oft als „Thinking outside the box“ bezeichnet.
Situationen, in denen wir „den Wald vor lauter Bäumen nicht sehen“, sind jedem bekannt. Verschiedenste Gründe sorgen immer wieder dafür, dass wir wider besseres Wissen hineingeraten – und nicht nur solche, an die wir vielleicht zuerst denken. So kann ein Experte durchaus an einer Aufgabe scheitern, da sein bisheriges Wissen ihm die Sicht auf die einfachste Lösung verwehrt. Hingegen kann ein Anfänger im selben Bereich ganz unbefangen schlussfolgern, da ihn keine Erfahrungswerte oder Grundannahmen beeinträchtigen. Auch Motivation und Ehrgeiz können zuweilen hinderlich sein, wenn der innere Drang den Blick auf die zu meisternde Aufgabe trübt. Ebenso können Verzweiflung und Kapitulation die Lösung vereiteln, da der Verstand schon auf das Versagen programmiert ist. Manchmal sogar suchen wir die Komplexität, weil uns unser Tun sonst zu banal erscheint. Die Beispiele für Verzerrer sind vielfältig und allgegenwärtig. Doch wie begegnet man diesen Hindernissen auf dem Weg zur Lösung? Wie hilft uns diese Erkenntnis im Projekt? Perspektivwechsel und Kollaboration sind hierbei Schlüsselkomponenten. Das aktive Suchen nach neuen Perspektiven verhilft bei der Findung zusätzlicher Einblicke und damit bei der Erlangung eines umfassenderen, möglichst besseren Verständnisses. Dieses wiederum soll zu besseren Lösungen führen.
[1] vgl. Robin Lane Fox: „Alexander der Große: Eroberer der Welt“, Klett-Cotta, Vierte Auflage, 2005, S. 183
[2] vgl. William D. Phillips, Jr. & Carla Rahn Phillips: „The Worlds of Christopher Columbus“, Cambridge University Press, 1999, digitalisiert 2002, S. 190
Ashbys und Luhmanns Komplexitätsdilemma
Ashbys Law ist nicht nur in Kybernetiker Kreisen hinlänglich bekannt, " Nur Komplexität kann Komplexität beherrschen" (Beherrschen im Sinne von Kompetenz haben in einer Sache, bevor dies zu Missverständnissen führt). Soziale Gebilde bleiben demnach lenkbar, sofern das Lenkungssystem (z.B. Management) über die gleiche Varietät d.h. die gleiche Handlungsvielfalt verfügt wie das zu lenkende System (z.B. Produktionseinheit mit zugehöriger Umwelt (z.B. Kunden)) selbst.
Aber nicht nur Ashby hat sich mit diesem Thema beschäftigt. Ein Gegenentwurf bietet Luhmanns Selektivitätsstrategie. Ein System ist nur durch Selektion beherrschbar, d.h. Komplexität führt zum Selektionszwang. Gemäß Luhmann sind Lenkungssysteme nicht genau so Komplex auszubilden wie Ihre Umwelt, im Gegenteil. Diese sind einfach auszubilden, so reduziert sich dann auch die Komplexität der Umwelt. Dafür sind Selektionsstrategien notwendig, welche potentielle Systemzustände auszuwählen können.
Die beiden Ansätze stehen aber nur scheinbar im Widerspruch, den Ashby wurde sehr oft falsch verstanden. Es soll nicht so sein, das ein Management so viel Eigenvarietät besitzen soll, dass es nicht mehr handhabbar ist. Es ist vielmehr wichtig, sich eine Umwelt auszusuchen bzw. zu selektieren, welche verkraftbar ist. In dieser Umwelt ist dann ausreichend Verhaltensrepertoire aufzubauen, um die vorhandene Umweltkomplexität zu bewältigen.
2.) Agiles Management von Komplexität (Entwurf)
Stichworte: Empirisch, Inkrementell, Iterativ, Flexibilität und Anpassung - Statt ausführlicher und umfangreicher Planung zu Beginn eines Projekts, adaptive Planen, schnelle Abstimmung im Team.
Textelement: Anforderungen an ein Produkt, an Pläne oder eine Vorgehensweise werden nicht ein für alle Mal festgelegt, sondern kontinuierlich detailliert und angepasst. Damit wird nicht die Komplexität einer Aufgabe reduziert. Ziel soll es sein kleinere beherrschbare "komplexe" Aufgaben zu schaffen. Getreu dem Spruch "Wie ist man einen großen Elefanten? - Häppchen für Häppchen"
3.) Tools & Techniques (Entwurf)
- Root Cause Analysis - Vermeidung der reinen Behandlung von Symptomen
- SMART & KISS
- Kooperation & Perspektivwechsel (siehe auch Vinh Giangs Video zur Fokussierung)
- Low Context-Kommunikation (Erin Meyer's Cultur Map)
- Ashbys Law
- Viable System Model
- System Dynamics (Qualitative und Quantitative Modellierung)
4.) Zusammenfassung (Das wichtigste auf einen Blick)
Ideenspeicher:
- alltägliche Bereiche und Fallstricke
- Komplexitätsfalle (siehe auch z.B. HBR Toyota Crisis )
- organisationsbezogene, strukturelle Komplexität (Projekt- und Linienorganisation, Entscheidungsinstanzen, Kompetenzverteilung, Hierarchien, ...)
- sachliche (Ziele und Inhalt, Business Case, Fachgebiete, Technologien, ...)
- soziale Komplexität (Stakeholder, Allianzen/Oppositionen, Erlebtes, Kultur, ...)
- spezielle Ausprägungen, z.B. Bias for Action & Paralysis by Analysis & Groupthink
- spezielle Ausprägungen, z.B. Bias for Action & Paralysis by Analysis & Groupthink
- mögliche Ursachen für das Zulassen von Komplexität
- Expertise ("den Wald vor lauter Bäumen nicht sehen")
- Heldentum (das kann nicht jeder lösen / bewältigen)
- Entlastung (deswegen konnte das ja nichts werden)
- Drang zur Vereinfachung (siehe auch Occam's Razor)
- Reduktion auf Wesentliches (wie z.B. in der Bruchrechnung)
- Hauptziele und die "eierlegende Wollmilchsau"
- Kompetenzträger und "viele Köche verderben den Brei"
- Vereinheitlichung (wie z.B. bei Linearen Gleichungssystemen)
- Auflösung einzelner "Variablen" nacheinander
- Zusammenführung
Attachments:
Comments:
Ich persönlich würde die gefühlte Komplexität von der tatsächlich vorhandenen trennen. Das ist mir ein zu weites Feld und sollte für sich ausführlicherer abgehandelt werden. ![]() |
michael frahm, willst Du vielleicht direkt ein Kapitel zu echter Komplexität schreiben? ![]() |
Klaro kann ich machen - diese ist aber dann stark Management seitig geprägt ![]() |
also wenn das allgemein bejaht wird - dann brauche ich nur eine leere Seite - der Inhalt mit Grafik ist dann schnell vorhanden. ![]() |
Hallo Michael und Christina, bevor ich eine Seite anlege (was immer ein trennendes Element ist) würde ich noch folgendes bitten/vorschlagen ... a) Der Aspekt, dass es "gefühlte" und "reale" Komplexität gibt ist sehr wichtig. Es gibt z.B. auch wertschöpfende und wertvernichtende Komplexität. b) Das könnte aber auch in diesem Kapitel integriert behandelt werden und zwar recht weit am Anfang. Das Handbuch ist ja für Leute die sich für das Thema interessieren und noch recht neu sind - daher stolperns sie genau über diese Fragen. Daher denke ich sollten sie recht weit forne so als Übersicht beantwortet sein - muss ja nicht lang sein. ... wäre das für euch auch eine Idee - also im Artikel integriert am Anfang? ![]() |
Hallo zusammen, wir haben im Rahmen der Vorarbeiten einen Artikel "Projektmanagement am Rande des Chaos" geschrieben, der viele der oben angeführten Aspekte behandelt. Ich lasse euch den Artikel per eMail zukommen. Bitte prüft, was ihr verwenden wollt.
![]() |
Werde mal ein aus meiner Sicht einführenden Vorschlag machen, zu dem Thema Komplexität allgemein.
![]() |
meine Vorschlag: Die Einführung zur Komplexität habe ich verfasst. Die Komplexität im IT Projekt (m.E. die größte Relevanz bei Agil PM) sollte in ähnlichem Umfang ergänzt werden (Wer mach das?) Darunter würde ich dann Methoden und Haltungen um mit K im PM umzugehen darstellen.
![]() |
Hallo Michael, lass uns einen gemeinsamen roten Faden finden, so dass wir noch diese Woche einen Abstract bereitstellen können. Erreiche ich DIch morgen dazu? Wann passt es Dir am besten?
![]() |
Hallo Christina, bin die restliche Woche off. Du kannst gerne einen Vorschlag machen. Ich habe mit der allgemeinen Formulierung und der Grafik vorgelegt. Vielleicht kannst du den IT Part übernehmen? Am besten erreichst du mich über info@k-bpm.de Viele Grüße Michel
![]() |
Bitte überprüft eure Inhalte darauf, ob wir "Allgemeine Aussagen zum Thema Kompelxität, die man in nahezu jedem Buch nachlesen kann" übernehmen bzw. wiederholen wollen. Davon gibt es schon sehr viele und sehr oft werden sie unreflektiert weitergegeben. Bitte legt das Thema auch so an, dass IT keine Hauptrolle spielt. Wir wollen gemäss unserer Vision explizit keine Aussagen treffen, die nachher vom Leser so verstanden werde "Das gilt ja nur für IT". ![]() |
Ich habe den Abstract ergänzt und die Inhalte zusammengeführt. Ich sehe keine Notwendigkeit für eine Abgrenzung oder Hervorhebung von IT-Projekten in diesem Themenfeld. Die Outline ist insoweit ergänzt, als dass sie beiden Zweigen - echte und gefühlte Komplexität - Platz einräumt. Das Intro kann sicher verkürzt werden. michael frahm: Ich mail Dich an; wir sollten uns morgen kurz abstimmen. ![]() |
Zwischenbericht: Michael und ich haben uns abgestimmt und schon mehrfach unseren roten Faden überarbeitet. Wir sind zudem weiterhin in der Ideenfindung und -Koordination. Der Abstract steht schon eine Weile zum Review bereit; weitere Textteile folgen, wenn uns die Richtung klarer ist. Wir bleiben am Ball. ![]() |
Bin bei der Arbeit an den Methoden am Thema "Komplexität" hängen geblieben
2) Mit einem System konfrontiert versuchen wir das System zu verstehen, d.h.
dabei bemühen sich einzelne Personen in unterschiedlichem Maße darum, ein System zu verstehen, die detaillierte Analyse lässt ein System komplexer erscheinen => Komplexität entsteht beim Betrachter! 3) Haben wir ein inneres Abbild eines Systems erzeugt, können wir das Systemverhalten antizipieren/prognostizieren und zielgerichtet im System agieren. Es geht also darum, eine System in angemessener Tiefe zu durchdringen um bei beschränkten Ressourcen und beschränkter Zeit das Systemverhalten bestmöglich zu prognostizieren. Der Anspruch einer vollständigen Analyse führt zu Handlungsfähigkeit.
Als vernetzte Elemente des Systems können wir uns auf die direkten, eigenen Wirk-Zusammenhänge beschränken, indem wir Aktionsimpulse von anderen Elementen erhalten und verarbeiten (Schwarm)
Jetzt zu meinem Methoden-Thema - 1. Methode Scrum
![]() |