Blog

Grundlagen

Das Cynefin-Modell: Warum die Situation die Methode bestimmt

Das Cynefin-Modell: Warum die Situation die Methode bestimmt

16. Juli 2026

Was ist Cynefin?

Cynefin (ausgesprochen: ku-NEV-in, walisisch für „Lebensraum“ oder „Umgebung“) wurde Ende der 1990er Jahre von Dave Snowden entwickelt. Es ist weder ein Prozessmodell noch eine Projektmethode.

Cynefin ist ein Sensemaking-Framework.

Also ein Werkzeug, das hilft, Situationen besser zu verstehen, bevor man entscheidet, wie man handelt.

Der Grundgedanke ist einfach:

Nicht jedes Problem ist gleich.

Manche Situationen haben offensichtliche Lösungen. Andere erfordern Expertenwissen. Wieder andere lassen sich erst verstehen, indem man ausprobiert und lernt. Und manchmal herrscht schlicht Chaos.

Cynefin unterscheidet vier grundlegende Domänen sowie einen Zustand der Unklarheit.

Das Cynefin-Framework auf einen Blick

Quelle: Snowden, D. J. (Cynefin Framework / Cognitive Edge Materialien)

Das Cynefin-Framework nach Dave Snowden. Unterschiedliche Situationen verlangen unterschiedliche Vorgehensweisen.

PDF zum Download

Sie möchten das Modell später noch einmal nachschlagen?

Cynefin-Spickzettel als PDF herunterladen

Vorlage „Cynefin — Kurzreferenz“: Welche Art von Problem liegt vor, und welches Vorgehen passt dazu? Die vier Bereiche mit den typischen Fehlgriffen je Bereich. Ohne Konto abrufbar.

Direkt öffnen, ohne Konto

1. Clear (Eindeutig)

Ursache und Wirkung sind offensichtlich. Jeder erkennt den Zusammenhang. Es gibt bewährte Lösungen, die zuverlässig funktionieren.

Beispiele:

  • Standardprozess durchführen
  • Bekannten Fehler beheben
  • Formular bearbeiten

Passende Reaktion:

Wahrnehmen → Kategorisieren → Reagieren

Was hilft hier?

Standards, Checklisten und etablierte Prozesse.

Brauchen wir hier agile Methoden?

Meist nicht. Wenn die Lösung bereits bekannt ist, erzeugen zusätzliche Meetings häufig mehr Aufwand als Nutzen.

2. Complicated (Kompliziert)

Die Zusammenhänge sind vorhanden, aber nicht sofort offensichtlich. Es braucht Analyse, Fachwissen oder mehrere Experten, um die beste Lösung zu finden.

Es gibt mehrere mögliche Antworten – mit unterschiedlichen Vor- und Nachteilen.

Beispiele:

  • Architektur für ein neues System entwerfen
  • Einen Businessplan erstellen
  • Eine Brücke planen

Passende Reaktion:

Einschätzen → Analysieren → Reagieren

Was hilft hier?

Expertise, Analyse und strukturierte Planung.

Brauchen wir hier agile Methoden?

Möglich – aber nicht zwingend notwendig. Häufig reichen klassische Projektplanung oder andere strukturierte Vorgehensweisen aus.

3. Complex (Komplex)

Hier wird es spannend.

In komplexen Situationen lassen sich Ursache und Wirkung erst im Nachhinein erkennen. Die Lösung ist zu Beginn nicht bekannt.

Das bedeutet: Man kann die richtige Antwort nicht vollständig analysieren.

Man muss sie entdecken.

Beispiele:

  • Eine neue Produktidee entwickeln
  • KI in ein Team integrieren
  • Ein innovatives Geschäftsmodell aufbauen

Passende Reaktion:

Sondieren → Beobachten → Reagieren

Was hilft hier?

Experimente, kurze Feedback-Schleifen und kontinuierliches Lernen.

Brauchen wir hier agile Methoden?

Genau für solche Situationen wurden iterative und adaptive Vorgehensweisen entwickelt.

Wenn die Lösung nicht vorab bekannt ist, entsteht sie häufig erst während der Umsetzung.

4. Chaotic (Chaotisch)

In chaotischen Situationen gibt es keine erkennbaren Zusammenhänge.

Es zählt nicht Analyse. Es zählt Handeln.

Beispiele:

  • Produktionsausfall
  • Cyberangriff
  • Akute Projektkrise

Passende Reaktion:

Handeln → Beobachten → Reagieren

Erst Stabilität herstellen. Danach analysieren.

Brauchen wir hier agile Methoden?

Nein. In echten Krisen braucht es schnelle Entscheidungen und klare Verantwortlichkeiten.

5. Confused (Unklar)

In der Mitte des Modells befindet sich kein eigener Problemtyp, sondern ein Warnsignal.

Wir wissen noch nicht, welche Art von Situation vorliegt. Und genau hier entstehen viele Fehlentscheidungen.

Denn wenn wir die Situation falsch einschätzen, wählen wir häufig auch die falsche Vorgehensweise.

SpaceX und Boeing – diesmal mit der Cynefin-Brille

Im letzten Artikel habe ich die Geschichte von SpaceX und Boeing erzählt.

Betrachtet man sie durch die Cynefin-Brille, ergibt sich zumindest eine interessante Hypothese. Vielleicht bestand ein Teil der Herausforderung nicht darin, dass eine Seite bessere Ingenieure hatte.

Sondern darin, wie mit Unsicherheit umgegangen wurde.

In komplizierten Situationen helfen Planung, Spezifikationen und Expertenwissen.

In komplexen Situationen reichen sie allein häufig nicht aus.

Dann werden Experimente, Feedback und Lernen zu einem zusätzlichen Erfolgsfaktor.

Ob genau das den Unterschied zwischen SpaceX und Boeing erklärt, lässt sich von außen nicht sicher beantworten.

Aber der Vergleich zeigt eindrucksvoll, warum die Einordnung einer Situation so wichtig ist.

Drei Fragen, die ich mir vor jedem Projekt stelle

Cynefin ist kein Fragebogen, den man einmal zu Projektbeginn ausfüllt. Es ist eher eine Denkhaltung.

Diese drei Fragen helfen mir bei der Einordnung:

Kennen wir die Lösung bereits?

  • Ja, und sie ist offensichtlich → Clear
  • Ja, aber wir brauchen Expertenwissen → Complicated
  • Nein, wir müssen sie erst entdecken → Complex

Was passiert, wenn wir falsch liegen?

Je höher die Unsicherheit, desto wichtiger werden kleine Schritte und schnelles Feedback.

Verändert sich die Situation durch unser Handeln?

Wenn sich das Umfeld durch unsere Entscheidungen ständig mit verändert, bewegen wir uns häufig im komplexen Bereich.

Was das für Methoden-Entscheidungen bedeutet

Die praktische Konsequenz ist überraschend einfach:

Erst die Situation verstehen. Dann die Methode auswählen.

Scrum ist kein universeller Standard. Ein klassischer Projektplan ist ebenfalls nicht veraltet.

Beides sind Werkzeuge.

Und wie bei jedem Werkzeug hängt der Nutzen davon ab, ob es zur Aufgabe passt.

Die Fähigkeit, das zu unterscheiden, ist aus meiner Sicht eine der wertvollsten Kompetenzen für Projektverantwortliche.

Cynefin im Kurs: Agiles Projektmanagement meistern

Das Cynefin-Framework ist eines der Werkzeuge, die ich in meinem Kurs „Agiles Projektmanagement meistern“ behandle.

Dort geht es nicht nur um Scrum, Kanban oder AgilePM.

Es geht vor allem um eine Frage:

Warum funktioniert eine Methode in einer bestimmten Situation – und in einer anderen nicht?

Genau dieser Unterschied macht aus Methodenwissen echte Methodenkompetenz.

→ Mehr zum Kurs: Agiles Projektmanagement

Das Wichtigste in Kürze

Cynefin beschreibt vier grundlegende Situationstypen sowie einen Zustand der Unklarheit.

Der entscheidende Gedanke dahinter ist einfach:

Unterschiedliche Situationen verlangen unterschiedliche Vorgehensweisen.

Viele Probleme entstehen nicht, weil Teams Scrum oder klassische Projektplanung schlecht anwenden.

Sondern weil ein grundsätzlich gutes Vorgehen nicht zur Situation passt.

Cynefin hilft dabei, vor der Methoden-Diskussion zunächst die eigentliche Frage zu stellen:

Mit welcher Art von Problem haben wir es überhaupt zu tun?

Denn erst danach ergibt die Frage nach der passenden Methode wirklich Sinn.

Häufige Fragen

Was ist das Cynefin-Framework?

Ein Rahmen, um die Art einer Situation zu bestimmen, bevor man eine Methode wählt. Dave Snowden entwickelte ihn ab 1999 bei IBM. Cynefin sortiert nicht Probleme in Schubladen, sondern fragt, in welchem Verhältnis Ursache und Wirkung stehen — ob dieser Zusammenhang bekannt, analysierbar, erst im Nachhinein erkennbar oder gar nicht vorhanden ist. Aus dieser Antwort folgt das Vorgehen, nicht umgekehrt.

Welche fünf Domänen hat Cynefin?

Clear (eindeutig), Complicated (kompliziert), Complex (komplex), Chaotic (chaotisch) und Confused (unklar). Die fünfte ist keine Restkategorie, sondern der gefährlichste Zustand: Man weiß nicht, in welcher der anderen vier man sich befindet, und handelt trotzdem nach der Methode, die man ohnehin gewohnt ist. Die Domäne Clear hieß bis zu einer Überarbeitung 2020 „Obvious“ und davor „Simple“.

Cynefin-Matrix oder Cynefin-Modell — was ist richtig?

Beides wird gesucht, „Matrix“ trifft es aber nicht. Eine Matrix ordnet Fälle nach zwei festen Achsen ein; Cynefin hat keine Achsen und ordnet nichts dauerhaft zu. Es ist ein Rahmen zur Einordnung im Moment der Entscheidung — dieselbe Aufgabe kann morgen in einer anderen Domäne liegen, weil sich die Situation geändert hat. Snowden selbst spricht von einem Sensemaking-Framework. Wer es als Matrix benutzt, verliert genau den Teil, der nützlich ist.

Wann ist ein Projekt komplex und wann nur kompliziert?

Kompliziert heißt: Es gibt eine richtige Antwort, aber man braucht Fachwissen, um sie zu finden. Ein Motorschaden ist kompliziert — ein Fachmensch analysiert und behebt ihn. Komplex heißt: Der Zusammenhang zwischen Ursache und Wirkung zeigt sich erst hinterher. Die Probe aufs Exempel ist die Wiederholbarkeit: Führt dieselbe Maßnahme unter denselben Bedingungen wieder zum selben Ergebnis, ist es kompliziert. Wenn nicht, ist es komplex.

Welche Methode passt zu welcher Domäne?

Im Eindeutigen tragen feste Abläufe und Checklisten. Im Komplizierten trägt Expertise mit Planung — klassisches Projektmanagement ist hier zu Hause. Im Komplexen tragen kurze Zyklen mit echter Rückmeldung, weil man den Weg nur durch Ausprobieren findet; das ist die Domäne, für die agile Verfahren gebaut wurden. Im Chaotischen zählt zuerst Handeln, um überhaupt Stabilität herzustellen. Agil ist damit kein besseres Vorgehen, sondern das passende für eine bestimmte Art von Problem.

Wie spricht man „Cynefin“ aus?

Etwa „ku-NEV-in“. Das Wort ist walisisch und lässt sich nicht in einem Begriff übersetzen: Es meint den Ort, an den man aus vielen Zugehörigkeiten heraus gehört — Herkunft, Beruf, Umfeld. Snowden wählte es, weil genau diese Vieldeutigkeit gemeint ist: Wie wir eine Situation einordnen, hängt davon ab, was wir mitbringen.

Passender Kurs

Agiles Projektmanagement meistern

Cynefin ist im Kurs die Entscheidungsgrundlage für die Methodenwahl — geübt an durchgängigen Szenarien, geprüft von Kai.

Zum Kurs
Philip Müller

Philip Müller

Trainer und Berater für Projektmanagement, agile Methoden und KI im Projektalltag.

Über den Autor →

Newsletter

Was im Projektalltag wirklich funktioniert — alle zwei Wochen.

Neue Beiträge, Werkzeuge und was sich beim Einsatz von KI in Projekten bewährt hat. Kein Verkaufsgerede, keine Zusammenfassung von Nachrichten, die du schon kennst.

Ich möchte gelegentlich E-Mails von Agile Forge zu Kursen, neuen Inhalten und Angeboten erhalten. Du kannst dich jederzeit mit einem Klick wieder abmelden. Deine Adresse gebe ich nicht weiter. Zur Datenschutzerklärung

Cynefin-Framework: welche Methode wann trägt