Das Große Ganze – Komplexität

Organisationen sind komplexe Systeme. Man kann sie nicht aufschrauben und einfach umbauen, wie Maschinen. Wenn man es doch versucht, scheitert man in der Regel. Deswegen sollte man verstehen was die Unterschiede zwischen komplizierten, komplexen und anderen Systemen sind und welche Herangehensweise jeweils angemessen ist.

Dave Snowden hat mit dem Cynefin Framework ein Modell erarbeitet, anhand dessen man vier Arten von Systemen unterscheiden kann.

 

Offensichtlich: Die Milch kocht über? Ich schalte den Herd aus und nehme den Topf von der heißen Platte. Über offensichtliche Systeme muss man nicht lange nachdenken. Man erkennt es, beurteilt es und reagiert. Es gibt in der Regel nur eine beste Lösung, die sogenannte Best Practice.

Kompliziert: Befindet man sich in einem komplizierten System, braucht man einen Experten. Sein Auto lässt man vom Kfz-Mechaniker reparieren, mit Zahnschmerzen geht man zum Zahnarzt. Diese analysieren das Problem, wählen die passendste Lösung aus und setzen sie um. Schon hier gibt es keine Best Practice mehr, sondern nur noch Good Practices, Optionen die jeweils Vor- und Nachteile haben.

Chaotisch: Die Cynefin-Beispiele für den chaotischen Bereich sind bürgerkriegsähnliche Zustände oder Natur-Katastrophen. Erfolgreiches Vorgehen besteht in diesen Situationen im Stillen der Blutung durch klare Führung, also z.B. Ausgangssperren oder großflächige Evakuationen.

Komplex: Bei organisatorischen Veränderungen hat man es in der Regel wie gesagt mit einem komplexen System zu tun. In diesen Systemen gibt es kein einfaches Erkennen von Ursache und Wirkung mehr. Sie sind unvorhersehbar und instabil. Hier hilft nur, Dinge auszuprobieren, Experimente zu machen und dann zu schauen, wie das System reagiert.

Ich möchte dies an einem Beispiel illustrieren: Ein Team kommt nach Empfinden des Management nicht schnell genug voran. Es stellt die Vermutung auf, dass es an Expertenwissen fehlt und ein Experte aus einer anderen Abteilung wird in das Team versetzt. Nach einigen Wochen stellt man fest, dass das Team noch langsamer geworden ist. Daraufhin beschließt das Management den Experten wieder zu entfernen, weil es ja vorher zumindest etwas besser war. Das Team wird nun noch langsamer als es mit dem Experten war. Zudem kündigt ein Mitarbeiter und einer wird über mehrere Wochen krank geschrieben.

Was war passiert? Die Einarbeitung des vermeintlichen Experten hatte so viel Zeit gekostet, dass wichtige Dinge liegen geblieben waren, wodurch das Team langsamer wurde. Dennoch war die Motivation im Team gut, weil man durch die zusätzliche Person Licht am Ende des Tunnels sah. Gerade als der Experte eingearbeitet war, riss dem Management der Geduldsfaden und es entfernte den Experten wieder. Nun musste das restliche Team allein die liegengebliebenen Dinge aufholen und war zudem frustriert, weil die gegebene Unterstützung wieder zurückgezogen worden war. Frustration und Überlastung führten zu Kündigung und Krankheit.

Im Nachhinein findet man für solche komplexen Vorgänge oft plausible Erklärungen. Die Situation könnte sich aber auch ganz anders entwickeln. Vielleicht ist fehlende Expertise gar nicht das Problem, sondern Konflikte im Team, ein schlechter Prozess oder fehlende Mitbestimmung. Vielleicht passt der Experte persönlich nicht gut ins Team und würde dieses auch langfristig bremsen.

Bei Experimenten im Umgang mit komplexen Systemen sollte man stets darauf achten, dass die Experimente safe-to-fail sind, also die Firma am Leben bleibt, selbst wenn es fehlschlägt.

Bei größeren Veränderungen in Unternehmen gibt es viele Fallen in die man tappen kann. John P. Kotter hat schon 1995 die acht größten herausgearbeitet:

1. Die Dringlichkeit der Veränderung wird nicht genügend motiviert
2. Eine zu schwache Koalition der Willigen, die die Veränderung antreiben
3. Die Vision für die Veränderung fehlt
4. Die Kommunikation der Vision wird massiv versäumt
5. Hindernisse, die der Vision entgegenstehen, werden nicht beseitigt
6. Kurzfristige Erfolge werden nicht systematisch geplant und erreicht
7. Der Abschluss der Veränderung wird zu früh gefeiert
8. Die Veränderung wird nicht in der Organisationskultur verankert

Dies war der dritte und letzte Abschnitt zum Thema “das Große Ganze”. Die Beiträge zum Thema Interessen und Organisationsstrukturen finden Sie hier:

• Interessen
• Organisationsstrukturen

Literatur:

(1) Kotter, John P. 2012: Leading Change*: Harvard Business Review Press

(*) Affiliate-Links.

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Komplexität von Projekten beurteilen

Ist Ihr Projekt zu spät dran? Dann haben Sie wohl ein Versprechen gemacht, dass Sie nicht halten konnten.

Fixe Kosten bei fixer Qualität, fixem Umfang und fixem Termin kann funktionieren, wenn das Projekt oder Produkt einfach genug ist. Leider machen wir es uns oft zu einfach: Wir scheren Projekte unterschiedlicher Komplexität über einen Kamm. Nach Schema F machen wir eine Analyse, wägen Optionen ab, entscheiden uns für die passendste Lösung und setzen sie dann um.

Dave Snowden liefert mit dem Cynefin Framework ein Modell, mit dem man über die Einordnung von Projekten differenziert nachdenken kann. Es kennt folgende Bereiche:

Einfach: Die Milch kocht über? Ich schalte den Herd aus und nehme den Topf von der heißen Platte. Über einfache Probleme muss man nicht lange nachdenken. Man erkennt das Problem, beurteilt es und reagiert. Es gibt in der Regel nur eine beste Lösung, die sogenannte Best Practice.

Kompliziert: Befindet man sich in einem komplizierten System, braucht man einen Experten. Springt mein Auto nicht an, lasse ich den Kfz-Mechaniker anrollen. Der gelangt mit oben genanntem Schema zum Erfolg: Er analysiert das Problem, wählt die passendste Lösung aus und setzt sie um. Schon hier gibt es keine Best Practice mehr, sondern nur noch Good Practices, Optionen die jeweils Vor- und Nachteile haben.

Komplex: Leider starten gerade viele große und innovative Softwareneuentwicklungs-Projekte in einem komplexen System. Es ist unvorhersehbar und instabil. Es gibt keinen Experten, der mit einer einfachen Analyse zum Erfolg kommt. Bewegt man sich in komplexer Umgebung, muss man Dinge ausprobieren, Experimente machen.

Chaotisch: Die Cynefin-Beispiele für den chaotischen Bereich sind bürgerkriegsähnliche Zustände oder Natur-Katastrophen. Erfolgreiches Vorgehen besteht in diesen Situationen im Stillen der Blutung durch klare Führung, also z.B. Ausgangssperren oder großflächige Evakuationen.

Selbstzufriedenheit: Manchmal wägt man sich im einfachen Bereich, in dem man alles unter Kontrolle hat und dann fliegt einem das System um die Ohren. Die Fukushima-Katastrophe wird hier als Beispiel genannt.

Unklarheit: Wenn man nicht weiß in welchem der Bereiche man ist, läuft man Gefahr die falsche Vorgehensweise zu wählen.

Die folgende Übung hilft, die Diskussion zu eröffnen, in welchen Systemen man sich bewegt. Ich führe sie mit meinen Kunden z.B. bei der Vorstellung von agilen Frameworks durch.

Als Basis für die Übung dient die Stacey Landscape Matrix, welche die vier Bereiche einfach, kompliziert, komplex und chaotisch anhand von zwei Achsen aufteilt, wie in der Abbildung gezeigt.

Die X-Achse beschreibt den Grad der Unsicherheit bei der Lösung, also z.B. inwieweit technische Herausforderungen bestehen, die so noch nie gelöst wurden. Die Y-Achse beschreibt den Grad der Uneinigkeit im Projekt darüber was umgesetzt werden soll. Je mehr Stakeholder und je größer die Meinungsverschiedenheiten, umso weiter verschiebt sich das Projekt nach oben.

Nun versucht man (z.B. in Kleingruppenarbeit) die laufenden und anstehenden Projekte oder Produkt-Entwicklungsvorhaben auf der Matrix zu verorten. Anschließend diskutiert man das Ergebnis. Im Bild habe ich vier Beispiele aufgezeigt.

Projekt IO könnte z.B. der Bau einer Elb-Philharmonie sein: Was am Ende herauskommen soll ist relativ klar, aber die bautechnischen Herausforderungen sind völlig neu. Landet das Projekt wie abgebildet im komplexen (roten) Bereich sind also keine genauen Voraussagen möglich, solange bis die Herausforderungen durch safe-to-fail Experimente gemeistert sind und der Rest des Projekts dann nur noch kompliziert ist.

Projekt Babylon ist von der Umsetzung und Technologie-Seite keine große Herausforderung, aber es gibt so viele Meinungsverschiedenheiten, dass diese soziale Komponente das ganze Projekt in den komplexen Bereich verschiebt. Auch hier sollte man nicht einfach durch-implementieren, sondern durch Prototypen Konsens über die gewünschte Art der Lösung herstellen.

Projekt OPUS (“Ohne Plan und Sachverstand”) ist ein gigantisches Projekt mit immensen sozialen und technischen Herausforderungen. Es ist so unüberschaubar, dass es ans chaotische grenzt. Ehe man Millionen hinein versenkt, ist es wahrscheinlich besser das ganze in mehrere kleine Projekte zu zerschneiden bzw. sich auf einen kleinen Bestandteil zu fokussieren.

Manche Projekte sind gar nicht so kompliziert. Projekt 08-15 wurde schon tausendmal durchgeführt und birgt keine Überraschungen. Führt man hier aufwändig eine agile Vorgehensweise ein, schießt man wahrscheinlich mit Raketen auf Spatzen.

Die Diskussion ergibt oft, dass die Teilnehmer je nach Sichtweise die Projekte unterschiedlich einordnen. Das ist oft sehr lehrreich. Business Analysten unter- oder überschätzen technische Herausforderungen, Techniker unterschätzen Uneinigkeit und Unklarheit auf Anforderungsseite.

Wenn man regelmäßig vorab seine Projekte klassifiziert kann man nicht nur die richtige Vorgehensweise wählen, sondern auch versuchen die Projekte bewusst in bestimmte Bereiche zu verschieben. Z.B. könnte man im 08-15-Projekt eine neue Technologie ausprobieren, um das System zu erneuern oder auch um es für die gelangweilten Entwickler interessanter zu machen. Umgekehrt könnte man bei Projekten mit großen Herausforderungen auf Anforderungsseite darauf verzichten auch noch eine völlig unerprobte Technologie zu benutzen.

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de