Cynefin — warum Projekte scheitern
Zu diesem Blogartikel gibt es ein passendes Youtube-Video, in welchem ich das Cynefin-Framework erkläre: Klick!
Es ist, wie es ist: Die eine perfekte Projektmethode, das eine perfekte Vorgehen gibt es nicht. Die Auswahl der Vorgehensweise hängt vom Lebensraum eines Projekts ab.
Für die Analyse des Lebensraums nutzen wir in unserer täglichen Arbeit das Cynefin-Framework von Dave Snowden (sprich: Kinnäwi-en). Der Begriff Cynefin ist ein walisisches Wort und steht für so etwas wie Lebensraum (Habitat).
Die vier (fünf) Habitate
Die vier (erwünschten) Lebensräume des Cynefin Frameworks heißen: Obvious, Complicated, Complex und Chaotic. Je nach Quelle heißt der Obvious-Lebensraum auch clear oder simple.
Der Lebensraum Obvious: Die Checklisten
Offensichtliche Aufgabenstellungen haben genau eine richtige Lösung — es gibt genau ein Ziel. Die einzelnen Schritte sind einfach zu erkennen, zu kategorisieren und es ist entsprechend einfach, auf sie zu reagieren. Das heißt: Es sind Aufgabenstellungen, die sehr gut mittels einer Checkliste abgearbeitet werden können. Sie haben (nahezu) keine wechselseitigen Abhängigkeiten und können von einer Person bearbeitet oder aber auch auf unterschiedliche Schultern verteilt werden. Klassische Beispiele hierfür sind Aufgaben wie Kaffeekochen oder Zähneputzen.
Aber es gibt sie auch im Businesskontext: z. B. wenn wir immer gleichbleibende Berichte oder regelmäßige Newsletter erstellen, in denen nur Bilder, Texte und Links ausgetauscht werden müssen. Wir können bei Aufgaben aus dem Lebensraum “Obvious” mit Best Practices arbeiten: Das haben wir schon immer so gemacht und das ist auch gut so.
Der Lebensraum Complicated: Die Projektpläne
Im komplizierten Habitat oder Cynefin “Complicated” zeichnen sich die Aufgaben dadurch aus, dass wir am Anfang ein klares Ziel definieren müssen. Dieses ist zwar erkennbar, vor der Umsetzung müssen wir allerdings einige Parameter entscheiden. Denn auf den ersten Blick sind mehrere Variationen des Ziels denkbar: Unsere Entscheidung ist notwendig und beeinflusst den darauffolgenden Plan.
Wenn wir ein Haus bauen möchten, treffen wir im Vorfeld zahlreiche Entscheidungen: Anzahl der Stockwerke, Keller, Dachform, Raumaufteilung — wo befinden sich Türen und Fenster? Diese Festlegungen ermöglichen es uns, in die Umsetzung zu starten: Die gesamte Kette ist für uns sichtbar: Dadurch wissen wir, was wir wann tun müssen, damit wir unser Ziel erreichen. Ein Projektplan entsteht. Die einzelnen Umsetzungsschritte sind teils voneinander abhängig, manche können parallelisiert werden und/oder werden in unterschiedlichen Gewerken umgesetzt. Auch enthalten sie ggf. Fristen: Eine Verspätung der einen Aufgabe hat Einfluss auf unseren Plan. Entscheidend im Lebensraum Complicated: Wir können dies im Vorfeld analysieren, eine entsprechende Risikoanalyse durchführen und einen Umgang bei Risikoeintritt planen. Typisch für das Cynefin “Complicated” sind also diejenigen Aufgaben, die sich hervorragend mit Projektplänen abarbeiten lassen. Ebenso sinnvoll ist hier ein Kanban-Prozess, da wir einen Fluss erstellen und entsprechend steuern können. Die Nutzung von Gantt-Diagrammen oder Kanban beantwortet also nur noch die Frage, wie Menschen zusammenarbeiten sollen.
So können auch “kleinere Projekte”, die wenige Tage dauern, in diese Kategorie eingeordnet werden — sofern die einzelnen Schritte dem Habitat entsprechend analysierbar und planbar sind. Complicated Aufgaben werden mit sog. Good Practices bearbeitet. Wir wissen, dass wir einen Plan brauchen und die Kette analysieren müssen. Der detaillierte Plan aber weist entsprechende Unterschiede abhängig vom definierten Ziel aus.
Der Lebensraum “Complex”: Die Zielräume
Wechseln wir die Seite des Frameworks, vollzieht sich auch ein Paradigmenwechsel. Bisher haben wir uns mit Aufgabenstellungen beschäftigt, die ein klares Ziel haben. Komplexe Aufgabenstellungen zeichnen sich durch ein irgendwie nicht richtig greifbares Ziel aus. Wir versuchen es zu analysieren und merken: Es bleiben immer Fragen offen, so richtig klar kriegen wir es nicht formuliert. Es ist gut zu umschreiben, aber es bleiben offene Punkte — es ist wolkig, irgendwie fluffig.
Wir sind es gewohnt, klare Ziele benennen zu müssen. Deswegen merken wir es in der täglichen Arbeit häufig gar nicht unbedingt, dass wir es eigentlich mit einem Zielraum zu tun haben. Erst im Laufe der Projektumsetzung fallen uns diese Unklarheiten auf. Dazu später mehr.
Entscheidend ist folgendes, wenn wir den komplexen Lebensraum verstehen möchten: Es gibt Projekte, da können wir nur einen Zielraum benennen. Wenn wir versuchen, dieses Ziel genauer zu definieren, geraten wir häufig ins Stocken. Wir nutzen sehr viel Zeit für Analyse und die letzten 20%, die uns vermeintlich fehlen. Schnell ist ein halbes Jahr vergangen und es wurde noch nichts vom Projekt umgesetzt. Wenn ihr euch in einer solchen Situation befindet, habt ihr es vermutlich mit einer komplexen Aufgabenstellung zu tun.
Das Cynefin-Framework empfiehlt in solchen Fällen die Arbeit in Iteration. Wir leben mit dem etwas unklaren Zielraum und starten unsere Arbeit mit dem, was wir wissen. Wir planen eine kleine, aber genaue Iteration oder Schleife — danach halten wir inne und fragen uns: Ist das gut, was wir gemacht haben? Ist es das was wir wollten? Was machen wir als nächstes? Was passen wir an? Und dann starten wir in die nächste Iteration: Wir robben uns also gewissermaßen an unseren Zielraum heran — und mit jedem Schritt werden wir diesen klarer sehen.
Fertigwerden ist eine Entscheidung
In komplexen Aufgabenstellungen war unser Ziel am Anfang nicht klar zu benennen, erst durch die Umsetzung in Iterationen können wir Antworten auf unsere offenen Fragen finden. Das heißt häufig auch: Fertigwerden ist eine Entscheidung. Komplexe Aufgabenstellungen bergen die Gefahr, niemals beendet zu werden — durch die Wolkigkeit des Zielraums entdecken wir immer weitere Themen und Einzelaufgaben, die umgesetzt werden könnten. Hier ist es ganz entscheidend, in regelmäßigen Abständen den Status des Projekts zu überprüfen und jede Anforderung auf ihre echte Notwendigkeit zu überprüfen. Denn sonst verlieren wir uns in einem endlosen Projekt. Und: Projekte haben immer einen Startpunkt und einen Endpunkt. Sie gehen häufig ins Tagesgeschäft über — aber sie verlieren ihren Projektstatus.
Komplexe Projekte finden sich häufig in der Softwareentwicklung. Aber auch in der Organisations- und Teamentwicklung, weil wir nicht voraussagen können, wie Menschen auf solche Maßnahmen reagieren. Wir können zwar davon ausgehen, dass Feedback-Trainings oder Retrospektiven eine gute Idee sind, welche Wirkung sie aber tatsächlich entfalten, werden wir erst nach ihrer Durchführung erkennen.
Auch können viele Stakeholder*innen oder viele Beteiligte zur Komplexität beitragen, weil es dann schwieriger wird, vor der Umsetzung Einigkeit über ein Ziel herzustellen. Wir können z. B. aufgrund der Digitalisierung davon ausgehen, dass uns heute und auch in der Zukunft immer mehr Projekte begegnen werden, die als komplex einzuordnen sind. Die Schwierigkeit hierbei ist der oben benannte Paradigmenwechsel: Wir sind es gewohnt mit klaren Zielen zu arbeiten und die Planbarkeit von Projekten wird von uns erwartet — denn dies hat jahrzehntelang hervorragend funktioniert. Komplexe Projekte können wir im Vorfeld nicht detailliert planen. Es ist schlicht nicht möglich. Dies kann sich gerade zu Beginn eher wie Unfähigkeit oder Inkompetenz anfühlen. “Einen Plan haben” ist als Ausspruch tief in unserer Gesellschaft verankert und wird mit Kompetenz gleichgesetzt. Die Kunst ist anzuerkennen, dass es Aufgabenstellungen gibt, die sich in einem anderen Lebensraum befinden. Wir verlieren extrem viel Zeit und Energie damit, solche Projekte zu planen: Zu Anfang, weil die Analysephase zäh wie Kaugummi ist, und währenddessen, weil der ausgefeilte Plan immer wieder auf die Realität angepasst werden und durch neue Erkenntnisse erweitert werden muss.
Stattdessen hilft ein fester Prozess: Die Arbeit in Iterationen und mit Inkrementen. Eine Methode, die genau dies versucht abzubilden, ist das agile Methoden-Framework Scrum. Es nutzt gleichlange Sprints, die mit einem Planning für den Sprint starten, dann in die Umsetzungsphase von ein bis vier Wochen gehen, und mit einer Review und Retrospektive abschließen, bevor es in den nächsten Sprint geht. Scrum versucht so, mit der Unsicherheit und Komplexität umzugehen und Projekte mit Sprints / Iterationen zum Erfolg zu bringen.
Im komplexen Habitat gilt die Emergent Practice. Wir leben mit einer Ungewissheit und schließen dieses Unwissen durch Erfahrungslernen. Wir gehen einen Schritt, analysieren diesen und passen unseren nächsten Schritt auf den vorherigen an.
Der Lebensraum Chaotic: Die Innovationen
Direkt zu Beginn: Der Lebensraum chaotisch heißt nicht so, weil Projekte dort chaotisch laufen. Das Projekt an sich hat chaotische Eigenschaften. Es gibt zwei Wege, um das chaotische Habitat zu betreten. Der erste Weg ist derjenige, den wir in der Regel lieber mögen. Wir wollen Produktinnovationen erschaffen. Wenn wir eine Idee haben, dann wissen wir nämlich nicht genau, wie das Ergebnis aussehen wird. Produktinnovationen entstehen aus einem Funken und auf diesen Funken wollen wir hinarbeiten: Es muss doch etwas drinstecken in der Idee. Angenommen, es soll etwas Neues entstehen, das Haare reinigt. Kein Shampoo mit einem neuen Geruch — das ist nur eine Weiterentwicklung. Sondern etwas gänzlich Neues. Ich habe da so einen Funken. Ich habe hier etwas, das könnte sich doch zur Haarreinigung eignen, denke ich. Also nutze ich Methoden für ein chaotisches Projektumfeld.
Ich arbeite, wie im Komplexen, mit Iterationen. Der entscheidende Unterschied: Ich überlege erst, was ein sinnvoller Zwischenschritt sein könnte — ein Prototyp. Dann überlege ich, wie lange ich für die Entwicklung dieses Prototyps brauchen werde, und lege die Länge meiner Iteration anhanddessen fest. Auch entscheidend: Wenn ich den ersten Prototyp habe (und sei er noch so einfach), dann stelle ich genau diesen einer geeigneten Testgruppe vor, um direkt Feedback von den potenziellen Kund*innen/ Anwender*innen zu erhalten. Die Erkenntnisse aus dem Feedback fließen in den nächsten Prototyp. Es ist also: erst handeln, dann analysieren und reagieren. Während wir im Komplexen auf einen Zielraum hinarbeiten und deshalb in der Regel immer einen Mehrwert in einer Iteration generieren, kann es im chaotischen Lebensraum durchaus passieren, dass wir das Ergebnis einer gesamten Iteration wegwerfen, weil es keinen Mehrwert liefert.
Der zweite Weg, das chaotische Habitat zu betreten, sind Umwelteinflüsse: Es passiert etwas und wir kommen in die Situation, dass wir sofort handeln müssen. Wir haben keine Zeit zu analysieren oder ausgiebig Erkenntnisse zu sammeln. Ein sehr konkretes Beispiel ist die Corona-Pandemie. Es erfolgte die Meldung eines Virus mit hoher Ansteckungsgefahr. In einem ersten Schritt kam es direkt zum Lockdown. Dieser hat Zeit gegeben, zu analysieren und zu erkennen, um dann erneut zu reagieren. Zu Beginn wurde sich gegen Masken ausgesprochen, dann wurden Stoffmasken empfohlen — und schließlich doch medizinische und FFP2-Masken. All dies wurde häufig erst beschlossen, um anschließend und währenddessen die Wirkung analysieren zu können und entsprechend neu zu reagieren.
Im chaotischen Lebensraum müssen wir erst handeln, dann analysieren und reagieren. Es bleibt uns nicht anderes übrig, weil wir nicht genug Wissen haben. Solche ungewissen Gewässer sind nicht immer beliebt, lassen sich aber häufig nicht vermeiden. Umso besser ist es, wenn wir wissen, wie wir mit ihnen umgehen können. Auch im Arbeitsumfeld kann eine Marktsituation entstehen, in der wir erst einmal handeln müssen, weil keine Analysezeit bleibt. Wir brauchen im chaotischen Lebensraum Innovative Practices — wir müssen etwas Neues tun. Erst einmal machen.
Selbstorganisierte Teams
In den Lebensräumen Komplex und Chaotisch gibt es noch eine entscheidende Sache: Wir sollten auf selbstorganisierte Teams setzen, die all diejenigen Kompetenzen und Fähigkeiten vereinen, die es braucht, um ein Problem zu lösen. Während im Komplexen typische Teamgrößen zwischen sechs und zehn Personen sehr gut funktionieren, setzt man im Chaotischen eher auf kleinere Expert*innen-Teams. Denn: Kleine Teams sind mutiger. Je mehr Leute wir an einen Tisch setzen, desto höher ist die Wahrscheinlichkeit, dass jemand sagt: “Das wird aber nicht gehen” und Ideen entsprechend ausbremst. Auch verlieren wir schlicht und ergreifend mehr Zeit, wenn ein Team aufgrund seiner Größe länger für Entscheidungen braucht. Nicht immer wissen wir im Vorfeld genau, welche Kompetenzen es braucht, um eine Aufgabe zu bewältigen: Natürlich passen wir das Team an, wenn wir neue Erkenntnisse gewonnen haben, bis wir genau die richtigen Expert*innen dabei haben.
Der Lebensraum Disorder: Wenn’s nicht läuft
Disorder bzw. Unordnung ist im eigentlichen Sinne kein Lebensraum einer Aufgabenstellung. In Disorder landen wir immer dann, wenn der Lebensraum des Projekts und die gewählte Methode nicht zusammenpassen. Versucht ihr, eine komplexe Aufgabenstellung in einen Projektplan zu gießen, werdet ihr merken, dass es zäh wird. Ihr werdet viel Zeit damit verbringen, den Projektplan auf neue Erkenntnisse und Geschehnisse anzupassen. Dasselbe geschieht, wenn ihr eine Aufgabe aus dem Bereich Obvious mit einer iterativen Methode wie Scrum umzusetzen versucht: Es wird zäh. Ihr habt Meetings, die euch keinen Mehrwert bringen. Ihr trefft euch regelmäßig zum Planning, obwohl alle genau wissen, was zu tun ist. Genau dann seid ihr in Disorder.
Disorder ist der Bereich, in dem Projekte scheitern. Scheitern muss dabei nicht die große Katastrophe bedeuten. Scheitern kann auch heißen: Wir schaffen das Projekt nicht in der geplanten Zeit oder nicht im geplanten Budget. Oder unsere Stakeholder*innen, Teams und/oder Kund*innen sind unzufrieden.
Projekte, die vor sich hindümpeln und “eigentlich” fertig sind — sie sind in Disorder, weil sie nie richtig abgeschlossen werden.
Schaut auch eure Projekte an: Welches Vorgehen meint ihr, passt dazu? Was glaubt ihr, welchem Lebensraum sie zugehören könnten? Entscheidet und fangt an. Wenn ihr nach ein paar wenigen Wochen merkt, dass das gewählte Vorgehen nicht passt: Verändert es. Gerade am Anfang ist die Entscheidung für einen Lebensraum eher ein Best Guess. Aber je häufiger wir das Framework nutzen, desto gewohnter wird es, und desto mehr haben wir über unsere eigene Projektlandschaft gelernt.
Ihr könnt euch zwischen zwei Habitaten nicht entscheiden? Dann wählt das “Ungewissere”. Eure Aufgabe könnte Complicated oder Complex sein? Meine Empfehlung: Startet mit einem Vorgehen, das zu komplexen Aufgaben passt. Der Wechsel hin zur Planung ist leicht gemacht und vor allem: Ihr habt nicht so viel Zeit verloren, sondern diese äußerst sinnvoll genutzt.
Wir planen einen Onlinekurs mit mehr zu Cynefin und dem Umgang vor allem mit komplexen Aufgaben. Interessiert? Hier kannst du dich eintragen und bekommst alle Infos, wenn es soweit ist.
Außerdem bieten wir in unserem Programm den Team-Workshop “Agiles Arbeiten” an, in dem ihr euch ebenfalls näher mit Cynefin auseinandersetzen könnt!