1. Zusammenfassung: Die Stacey-Matrix – Die Renaissance der Differenzierung

In der zeitgenössischen Praxis des Business Developments und der Organisationsentwicklung stehen Entscheidungsträger vor einer fundamentalen Herausforderung, die weit über die bloße Ressourcenallokation oder Marktpositionierung hinausgeht. Es ist die Herausforderung der korrekten epistemologischen Einordnung von Problemen. In einer Wirtschaftswelt, die zunehmend durch Volatilität, Unsicherheit, Komplexität und Ambiguität (VUCA) geprägt ist, versagen traditionelle, linear-kausale Managementmethoden immer häufiger. Das Scheitern ambitionierter Großprojekte, die Stagnation bei der digitalen Transformation etablierter Konzerne oder die Unfähigkeit, auf disruptive Markteintritte adäquat zu reagieren, lassen sich oft auf einen zentralen Diagnosefehler zurückführen: Die Anwendung von Methoden, die für stabile, vorhersehbare Umgebungen konzipiert wurden, auf Situationen, die durch dynamische Instabilität und Nicht-Linearität gekennzeichnet sind.¹

Das vorliegende Dossier widmet sich einer erschöpfenden Analyse der Stacey-Matrix, eines der prominentesten Sense-Making-Frameworks zur Bewältigung dieses Dilemmas. Ursprünglich entwickelt von Ralph Douglas Stacey, hat sich dieses Modell von einem akademischen Konstrukt zu einem unverzichtbaren Werkzeug für agile Transformationen und strategisches Management entwickelt.³ Die Matrix bietet eine scheinbar einfache Heuristik – die Korrelation von Anforderungsklarheit (Agreement) und Lösungsklarheit (Certainty) –, um Projekte und Initiativen in unterschiedliche Komplexitätsdomänen zu klassifizieren.⁴ Doch hinter dieser visuellen Simplizität verbirgt sich eine tiefgreifende Auseinandersetzung mit der Natur menschlicher Organisationen, der Grenzen der Vorhersagbarkeit und der Rolle von Macht und Politik in Entscheidungsprozessen.⁵

Dieses Dossier wird nicht nur die mechanische Anwendung der Matrix erläutern, sondern tief in ihre historische Genese eintauchen, die paradoxe intellektuelle Reise ihres Schöpfers vom Befürworter systemischer Modelle zum Kritiker derselben nachzeichnen und die Matrix im Kontext konkurrierender Frameworks wie Cynefin verorten. Es wird aufgezeigt, wie Business Developer die Matrix nutzen können, um nicht nur Projekte zu retten, sondern die fundamentale Architektur ihrer Organisationen anpassungsfähiger zu gestalten.

---

2. Historische Genese und Intellektuelle Biographie

2.1 Ralph Douglas Stacey: Der Praktiker als Theoretiker

Um die Stacey-Matrix in ihrer vollen Tiefe zu begreifen, muss man sie als Resultat der spezifischen Lebenserfahrung ihres Schöpfers verstehen. Ralph Douglas Stacey (1948–2021) war kein reiner Elfenbeinturm-Akademiker, dessen Theorien im luftleeren Raum entstanden. Seine intellektuelle Reise begann in Südafrika und führte ihn über die London School of Economics (LSE), wo er 1967 in Ökonomie promovierte, tief in die Realwirtschaft.⁶

Vor seiner akademischen Karriere an der Hertfordshire Business School arbeitete Stacey in der strategischen Unternehmensplanung der British Steel Corporation. Diese Phase in den 1970er und 80er Jahren war prägend. Die Stahlindustrie, ein Koloss der “Old Economy”, war massiven Marktschwankungen, Arbeitskämpfen und technologischen Umbrüchen ausgesetzt. Stacey erlebte aus erster Hand, wie die damals vorherrschenden Modelle der langfristigen strategischen Planung – basierend auf der Annahme, man könne die Zukunft durch genügend Datenanalyse vorhersagen und steuern – an der Realität zerschellten.⁷ Er beobachtete, dass detaillierte Fünfjahrespläne oft schon kurz nach ihrer Verabschiedung durch unvorhergesehene Ereignisse obsolet wurden. Diese Diskrepanz zwischen der Illusion der Kontrolle, die Management-Bücher versprachen, und der chaotischen Realität des Unternehmensalltags wurde zum Motor seiner späteren Forschung.⁷

2.2 Der Einfluss der Komplexitätswissenschaften

Nach seinem Wechsel in die Akademie in den 1990er Jahren begann Stacey, nach Erklärungsmodellen zu suchen, die diese Unvorhersehbarkeit nicht als “Fehler” oder “Rauschen” abtaten, sondern als inhärente Eigenschaft von Systemen akzeptierten. Er fand Inspiration in den Naturwissenschaften, insbesondere in der Chaos-Theorie und der Lehre von den Komplexen Adaptiven Systemen (CAS), die am Santa Fe Institute populär gemacht wurden.⁸

Die ursprüngliche Intention der Matrix war es, Managern zu visualisieren, warum ihre Standardwerkzeuge versagten. Stacey wollte zeigen, dass Organisationen sich oft am “Rand des Chaos” (Edge of Chaos) befinden – einem Zustand zwischen starrer Stabilität und völliger Anarchie. In diesem Zustand ist das System am kreativsten und anpassungsfähigsten, aber auch am schwersten zu steuern.⁴ Die Matrix war also initial weniger ein Tool zur Auswahl von Projektmanagement-Methoden (wie sie heute oft genutzt wird), sondern ein Instrument zur Diagnose organisatorischer Dynamiken und zur Legitimation von Unsicherheit im Management-Diskurs.

2.3 Die Ironie der Popularität

Es entbehrt nicht einer gewissen Ironie, dass Ralph Stacey selbst später zu einem der schärfsten Kritiker seiner eigenen Matrix wurde. Während die Agile-Community das Modell in den 2000er Jahren begeistert aufnahm, um Methoden wie Scrum zu rechtfertigen, bewegte sich Stacey intellektuell weiter. Er sah in der Matrix zunehmend eine unzulässige Vereinfachung, die suggerierte, ein Manager könne von “außen” auf das System blicken und objektiv entscheiden, in welchem Quadranten man sich befinde. Stacey wandte sich der Theorie der Complex Responsive Processes (CRP) zu, die den Fokus auf lokale Interaktionen und Gespräche legte, statt auf abstrakte Systemmodelle.⁶ Dennoch – oder gerade deshalb – bleibt die Matrix als “Brückentechnologie” für das Verständnis von Komplexität von unschätzbarem Wert für Business Developer.

---

3. Methodische Dekonstruktion: Die Anatomie der Matrix

Die Stacey-Matrix spannt einen zweidimensionalen Raum auf, der Entscheidungssituationen anhand zweier kritischer Unsicherheitsfaktoren kartografiert. Diese Dimensionen sind nicht zufällig gewählt; sie repräsentieren die zwei fundamentalen Säulen organisationalen Handelns: Die soziale Dimension (Menschen und Ziele) und die technische Dimension (Kausalität und Umsetzung).¹¹

3.1 Die vertikale Achse: Das “Was” (Agreement / Übereinstimmung)

Die Y-Achse, oft als “Agreement” bezeichnet, misst den Grad der Übereinstimmung zwischen den beteiligten Stakeholdern bezüglich der Ziele, Anforderungen oder des Problems selbst.

• Close to Agreement (Hohe Übereinstimmung): In diesem Bereich herrscht Konsens. Das Team, das Management und die Kunden teilen eine gemeinsame Vision. Die Anforderungen sind klar definiert, stabil und widerspruchsfrei. Es gibt keine versteckten Agenden.
• Far from Agreement (Geringe Übereinstimmung): Hier herrschen Konflikte, divergierende Interessen oder unterschiedliche Wertvorstellungen. Das “Was” ist umstritten. Ein typisches Beispiel wäre eine strategische Neuausrichtung, bei der verschiedene Abteilungsleiter um Budgets konkurrieren, oder ein Produkt, dessen Marktakzeptanz intern kontrovers diskutiert wird.

Implikation für Business Developer: Diese Achse repräsentiert die politische und soziologische Komponente der Arbeit. Wenn man sich weit entfernt von Übereinstimmung befindet, ist das Problem nicht technischer Natur. Keine noch so detaillierte Projektplanung oder technische Expertise wird helfen. Die Lösung liegt in Verhandlung, Diplomatie, Stakeholder-Management und Konsensbildung.³

3.2 Die horizontale Achse: Das “Wie” (Certainty / Sicherheit)

Die X-Achse, oft als “Certainty”, “Technology” oder “Know-how” bezeichnet, repräsentiert den Grad der Sicherheit darüber, wie das Ziel erreicht werden kann. Sie befasst sich mit Ursache-Wirkungs-Zusammenhängen.

• Close to Certainty (Hohe Sicherheit): Die Kausalitäten sind bekannt und deterministisch. Wenn Aktion A ausgeführt wird, folgt garantiert Ergebnis B. Es existieren Erfahrungswerte aus der Vergangenheit, Best Practices oder bewährte Technologien. Man kann extrapolieren.⁴
• Far from Certainty (Geringe Sicherheit): Man betritt Neuland. Es ist unklar, ob eine Technologie funktioniert oder wie der Markt auf eine Innovation reagieren wird. Ursache und Wirkung sind nur retrospektiv oder gar nicht erkennbar. Prognosen basierend auf historischen Daten sind hier nutzlos oder irreführend.³

Implikation für Business Developer: Diese Achse repräsentiert die epistemologische und technische Komponente. Unsicherheit hier erfordert Experimente, Prototyping und empirische Forschung, nicht politische Überzeugungsarbeit.

3.3 Die Interdependenz der Achsen

Die wahre Stärke der Matrix liegt in der Korrelation dieser beiden Achsen. Sie zeigt auf, dass mit abnehmender Sicherheit oft auch die Übereinstimmung sinkt (wenn niemand weiß, wie es geht, streiten die Leute oft auch über das Ziel) und umgekehrt. Dennoch erlaubt die Matrix die Differenzierung von asymmetrischen Zuständen:

• Wir sind uns einig über das Ziel, wissen aber nicht, wie wir hinkommen (Technisches Problem).
• Wir wissen genau, wie wir etwas bauen können, sind uns aber uneinig, ob wir es tun sollen (Politisches Problem).⁵

---

4. Die Domänen der Matrix: Strategien und Handlungsfelder

Aus der Überlagerung der Achsen ergeben sich fünf distinkte Zonen, die jeweils radikal unterschiedliche Management-Paradigmen erfordern. Ein Business Developer muss in der Lage sein, diese Zonen zu identifizieren und den Führungsstil entsprechend anzupassen.

Domäne	Charakteristika (Was & Wie)	Primäre Strategie	Führungsstil	Methodik
Einfach (Simple)	Klarheit über Was und Wie. Hohe Vorhersagbarkeit.	Wiederholen, Optimieren.	Anweisend / Kontrollierend	Wasserfall, SOPs, Checklisten
Kompliziert (Complicated)	Klarheit über Was, Unsicherheit über Wie (oder umgekehrt). Expertenwissen nötig.	Analysieren, Planen.	Koordinierend / Delegierend	PMBOK, Prince2, Kanban
Komplex (Complex)	Unsicherheit über Was und Wie. Emergenz, Nicht-Linearität.	Probieren, Lernen, Anpassen.	Ermöglichend (Servant Leadership)	Scrum, Design Thinking, Lean Startup
Chaotisch (Chaotic)	Völlige Unklarheit. Zusammenbruch von Ordnung.	Handeln, Stabilisieren.	Autoritär (Krisenmanagement)	“Act-Sense-Respond”, Triage
Anarchie / Edge of Chaos	Übergangszone. Hohes kreatives Potential, hohe Gefahr.	Diversität fördern, Muster stören.	Visionär	Open Space, Hackathons

4.1 Die Einfache Zone (Simple / Rational)

In dieser Zone, nahe dem Ursprung der Achsen, ist die Welt deterministisch. Probleme sind bekannt, Lösungen sind bewährt.

• Wesen: Hier regiert die Effizienz. Man muss das Rad nicht neu erfinden. Daten aus der Vergangenheit sind perfekte Prädiktoren für die Zukunft.
• Gefahr: Die größte Gefahr ist die Selbstgefälligkeit (Complacency). Da alles stabil scheint, übersieht man, wenn sich der Kontext ändert und das System in den chaotischen Bereich abrutscht. Zudem besteht die Gefahr des Mikromanagements, wenn Führungskräfte einfache Aufgaben zu stark überwachen.¹⁴
• Beispiel: Lohnbuchhaltung, Serienfertigung am Fließband.

4.2 Die Komplizierte Zone (Complicated / Political & Judgmental)

Stacey und spätere Interpreten differenzieren diesen Bereich oft in zwei Sub-Sektoren, was für Business Developer essentiell ist ⁵:

4.2.1 Technisch Kompliziert (Judgmental Decision Making)

Hier herrscht Einigkeit über das Ziel (hohes Agreement), aber der Weg ist unklar (niedrige Certainty).

• Strategie: Man benötigt Experten. Es ist kein Experimentieren nötig, sondern Analyse. Ein Ingenieur kann berechnen, wie eine Brücke zu bauen ist. Es gibt “die richtige” Lösung, man muss sie nur finden.
• Methodik: Klassisches Projektmanagement (Plan-Build-Run).

4.2.2 Politisch Kompliziert (Political Decision Making)

Hier ist der Weg klar (hohe Certainty), aber das Ziel ist strittig (niedriges Agreement).

• Strategie: Analyse hilft hier nicht, da das Problem nicht im “Wissen”, sondern im “Wollen” liegt. Die Lösung liegt in Verhandlung, Kompromissbildung und Koalitionsbildung.
• Methodik: Stakeholder-Management, Workshops, Mediation. Der Versuch, politische Probleme mit technischen Plänen zu lösen, ist ein klassischer Fehler im Change Management.

4.3 Die Komplexe Zone (Complex)

Dies ist die Zone der Emergenz. Hier interagieren viele Variablen so miteinander, dass das Ergebnis mehr ist als die Summe seiner Teile. Ursache-Wirkungs-Ketten sind im Vorhinein nicht erkennbar.¹⁴

• Wesen: Vorhersagen sind unmöglich. Ein Plan, der weiter als ein paar Wochen in die Zukunft reicht, ist reine Fiktion.
• Strategie: Empirische Prozesskontrolle. Man muss Hypothesen bilden, kleine Experimente durchführen (“Probes”), das Ergebnis messen und den Kurs anpassen. Fehler sind hier keine Defekte, sondern notwendige Lernschritte.
• Führung: Manager müssen von “Command and Control” zu “Context Setting” wechseln. Sie definieren die Rahmenbedingungen (Boundaries), innerhalb derer sich das Team selbst organisiert.¹

4.4 Die Chaotische Zone (Chaotic)

Hier existieren keine Muster. Alles ist im Fluss, oft ausgelöst durch externe Schocks.

• Wesen: Hohe Dringlichkeit, hoher Druck.
• Strategie: Act-Sense-Respond. Es ist keine Zeit für Analyse oder Experimente. Man muss sofort handeln, um die Blutung zu stoppen (Stabilisierung), dann die Situation bewerten und versuchen, das System in den komplexen oder komplizierten Bereich zu überführen.¹⁴
• Beispiel: Ein Cyberangriff, ein PR-Desaster, der Ausbruch einer Pandemie.

---

5. Methodische Anwendung: Der Kompass für Agilität

Für Business Developer ist die Stacey-Matrix oft das primäre Argumentationswerkzeug, um agile Methoden in konservativen Unternehmen einzuführen. Sie liefert die theoretische Rechtfertigung, warum der “Wasserfall” nicht universell einsetzbar ist.¹⁸

5.1 Scrum vs. Kanban vs. Wasserfall

Die Matrix ermöglicht eine präzise Allokation von Methoden (Method Mapping):

1. Wasserfall (Simple/Complicated): Wenn Anforderungen stabil sind und die Technologie bekannt ist (z.B. Bau eines Rechenzentrums nach Standardblaupause), ist der Wasserfall effizienter, da er weniger Kommunikationsaufwand erfordert als Agile. Die Matrix schützt davor, “Agile um des Agilen willen” zu betreiben.²⁰
2. Kanban (Complicated/Complex Border): Kanban wird oft im Übergangsbereich oder im komplizierten Bereich der Prozessoptimierung verortet. Da es auf Flussoptimierung (Flow) setzt, eignet es sich gut für Umgebungen, in denen der Arbeitsinhalt variiert, aber der Prozess definiert werden kann (z.B. Wartung, Support, operative HR-Prozesse).¹⁷
3. Scrum (Complex): Scrum ist explizit für die komplexe Zone designed. Die Iterationen (Sprints) sind Feedback-Loops, um die Unvorhersehbarkeit zu navigieren. Das “Product Backlog” ist kein statischer Plan, sondern ein lebendes Dokument, das sich an die emergente Realität anpasst. In der komplexen Zone ist Scrum dem Wasserfall überlegen, weil es das Risiko des Scheiterns (“Fail fast”) minimiert und den ROI beschleunigt.¹⁸
4. Lean Startup (Complex/Startup): Für Business Development neuer Geschäftsmodelle. Hier ist die Unsicherheit maximal. Die Matrix diktiert: Baue kein fertiges Produkt (Wasserfall), sondern ein MVP (Complex Strategy), um Annahmen zu validieren.¹⁴

5.2 Hybrid-Modelle und Bimodale IT

Die Matrix legitimiert auch hybride Ansätze. Ein Großprojekt kann in Teilprojekte zerlegt werden, die in unterschiedlichen Quadranten liegen.

• Beispiel: Der Bau einer neuen Fabrik.

• Das Gebäude (Beton, Stahl) ist Kompliziert -> Wasserfall.
• Die Steuerungssoftware für die neuen Roboter ist Komplex -> Scrum.
• Die Akzeptanz der Belegschaft für neue Schichtmodelle ist Politisch Kompliziert -> Change Management.
  Ein erfahrener Business Developer nutzt die Matrix, um diese Differenzierung vorzunehmen, anstatt das gesamte Projekt über einen Kamm zu scheren.13

---

6. Die Evolution und die Kehrtwende: Ralph Staceys Selbstkritik

Kein Dossier über die Stacey-Matrix wäre intellektuell redlich ohne die Diskussion der theoretischen Evolution ihres Schöpfers. Ralph Stacey vollzog um die Jahrtausendwende eine bemerkenswerte Wende, die seine frühere Arbeit in ein neues Licht rückte.⁷

6.1 Kritik am “Systemischen Denken”

Stacey begann, die ontologischen Prämissen seiner eigenen Matrix und des gesamten “Systems Thinking” zu hinterfragen. Seine Kritik lautete: Modelle wie die Matrix suggerieren, dass eine Organisation ein “System” ist (wie eine Maschine oder ein Organismus) und dass der Manager außerhalb dieses Systems steht. Von dieser externen Position aus, so die Illusion, könne der Manager den Hebel betätigen (“Wir wechseln jetzt von Wasserfall zu Agile”), um das System zu steuern.10

Stacey argumentierte, dies sei ein Trugschluss (“Dominant Discourse of Management”). Manager sind immer Teil des Systems. Sie können nicht objektiv auf die Matrix schauen, da ihre eigene Wahrnehmung durch Machtstrukturen, Angst und Politik verzerrt ist.

6.2 Complex Responsive Processes (CRP)

Als Alternative entwickelte Stacey die Theorie der Complex Responsive Processes of Relating.

• Kernidee: Organisationen existieren nicht als abstrakte Entitäten. Sie sind nichts anderes als die Summe der Interaktionen (Gespräche, Gesten, E-Mails) zwischen Menschen.
• Strategie: Strategie ist kein Dokument, sondern ein Muster, das aus diesen täglichen Interaktionen emergiert.
• Implikation für die Matrix: Stacey riet später davon ab, die Matrix als Diagnose-Tool zu nutzen, um Methoden auszuwählen. Er sah sie eher als Metapher, um Gespräche anzuregen. Für Business Developer bedeutet das: Die Matrix ist keine “Wahrheit”, sondern eine “Brille”. Sie hilft, eine Diskussion darüber zu starten, wie unsicher man sich fühlt, aber sie liefert keine objektive Messung der Realität.⁶

---

7. Vergleichende Analyse: Stacey-Matrix vs. Cynefin-Framework

In der Welt der Komplexitätsmodelle wird die Stacey-Matrix oft mit dem Cynefin-Framework von Dave Snowden verglichen. Beide sind essentiell, aber unterschiedlich in ihrer Philosophie.²⁴

7.1 Ontologie vs. Epistemologie

• Cynefin (Dave Snowden): Cynefin ist ein ontologisches Framework. Es klassifiziert die Realität selbst. Es sagt: “Dieses System ist komplex.” In Cynefin gehen die Daten der Kategorisierung voraus. Es hilft, die Natur der Dinge zu verstehen.²⁸
• Stacey-Matrix: Ist primär ein epistemologisches oder phänomenologisches Werkzeug. Es fragt: “Was wissen wir über die Situation?” (Sicherheit/Übereinstimmung). Es klassifiziert basierend auf der Wahrnehmung der Akteure. Ein Problem kann ontologisch einfach sein, aber wenn das Team keine Ahnung hat (geringe Certainty), landet es in der Stacey-Matrix im Chaos oder Komplexen Bereich.²⁸

7.2 Strukturunterschiede: Disorder und Grenzen

Ein wesentlicher Unterschied ist die fünfte Domäne in Cynefin: Disorder (Unordnung).

• In Cynefin ist Disorder der Zustand, in dem man nicht weiß, in welcher Domäne man ist. Dies ist der gefährlichste Zustand, da man dazu neigt, Probleme gemäß der eigenen Präferenz zu interpretieren (der Bürokrat sieht einfache Prozesse, der Experte sieht komplizierte Probleme).¹
• Die Stacey-Matrix hat keine explizite “Disorder”-Zone, obwohl die Mitte der Matrix oft so interpretiert wird.
• Die Klippe: In Cynefin gibt es eine “katastrophale Klippe” zwischen “Simple” (heute Clear) und “Chaotic”. Wer komplexe Probleme vereinfacht (Complacency), stürzt direkt ins Chaos ab. In der Stacey-Matrix wirken die Übergänge oft fließender als Kontinuum.²⁹

7.3 Wann welches Modell?

• Nutzen Sie die Stacey-Matrix für Workshops zur Methodenauswahl und zur Visualisierung von Stakeholder-Konflikten (“Wir sind uns nicht einig”). Sie ist intuitiver und politisch leichter zu vermitteln.
• Nutzen Sie Cynefin für tiefgehende strategische Analysen, Sense-making in Krisen und um kognitive Verzerrungen (Biases) im Führungsteam aufzudecken.³⁰

8. Infografik: Die Stacey-Matrix

9. Praxisbeispiele: Die Matrix im realen Business Development

Um die theoretische Tiefe in operative Exzellenz zu übersetzen, analysieren wir zehn detaillierte Szenarien aus der Praxis.

Beispiel 1: Die Lohnbuchhaltung (Payroll)

• Klassifikation: Einfach (Simple)
• Szenario: Ein Unternehmen muss monatlich 5000 Gehälter überweisen.
• Analyse: Die steuerlichen Regeln sind fix (Hohe Certainty). Das Ziel (pünktliche Zahlung) ist unstrittig (Hohes Agreement).
• Strategie: Automatisierung und Standardisierung. Es gibt keinen Raum für “Kreativität” oder “Agilität”. Fehler sind inakzeptabel.
• Business Dev Implikation: Outsourcing an spezialisierte Dienstleister oder Einsatz von Standard-SaaS-Lösungen. Hier Geld in individuelle Softwareentwicklung zu stecken, wäre Verschwendung.¹⁴

Beispiel 2: Bau einer neuen Produktionshalle

• Klassifikation: Technisch Kompliziert
• Szenario: Erweiterung der Kapazität durch einen Neubau.
• Analyse: Das Ziel ist klar definiert und genehmigt (Agreement). Der Weg (Architektur, Statik, Material) ist anspruchsvoll, aber für Experten berechenbar (Certainty ist durch Analyse herstellbar).
• Strategie: Wasserfall-Projektmanagement. Detaillierte Gantt-Charts, Critical Path Method. Änderungen in späten Phasen sind extrem teuer, daher ist ausführliche Planung (“Plan first”) notwendig.
• Business Dev Implikation: Auswahl von Partnern mit nachgewiesener Expertise. Verträge sollten auf Lastenheften basieren (Fixed Price möglich).³

Beispiel 3: Post-Merger Integration (Kulturell)

• Klassifikation: Politisch Kompliziert
• Szenario: Zwei Firmen fusionieren. Die IT-Integration ist planbar, aber die Teams hassen sich.
• Analyse: Technisch weiß man, wie man E-Mail-Server zusammenlegt (Certainty). Aber es gibt massive Widerstände, Angst um Jobs und Machtkämpfe (Niedriges Agreement).
• Strategie: Change Management. Hier hilft kein technischer Projektplan. Es braucht Workshops, “Townhall Meetings”, Mediation und Visionsarbeit, um das Agreement zu erhöhen.
• Business Dev Implikation: Das Scheitern droht hier nicht durch Technik, sondern durch Menschen. Budgets müssen massiv in Kommunikation und “Soft Factors” investiert werden, nicht nur in IT-Migration.⁵

Beispiel 4: Entwicklung einer KI-basierten Innovation

• Klassifikation: Komplex
• Szenario: Ein Startup will eine KI entwickeln, die Kundenemotionen am Telefon erkennt.
• Analyse: Niemand weiß, ob die Technologie zuverlässig funktionieren wird (Niedrige Certainty). Kundenanforderungen sind unklar, da es noch keinen Markt gibt (Mäßiges Agreement).
• Strategie: Agile (Scrum). Bauen eines MVP (Minimum Viable Product). Kurze Sprints. Hypothesen testen.
• Business Dev Implikation: Verträge dürfen nicht auf fixen Liefergegenständen basieren (Time & Material). Investoren müssen eine “Venture Capital”-Mentalität haben (hohes Risiko, hohe Chance), keine “Bankkredit”-Mentalität.¹⁴

Beispiel 5: Reaktion auf die COVID-19-Pandemie (März 2020)

• Klassifikation: Chaotisch
• Szenario: Plötzlicher Lockdown, Lieferketten brechen zusammen.
• Analyse: Keine Daten über das Virus, keine Erfahrungswerte (Null Certainty). Panik und Unsicherheit bei Mitarbeitern (Niedriges Agreement).
• Strategie: Krisenstab. Autoritärer Führungsstil (“Alle ins Homeoffice, jetzt!”). Handeln (Act), um das System zu stabilisieren, dann Daten sammeln (Sense).
• Business Dev Implikation: Liquidität sichern (Cash is King). Alle strategischen Langzeitprojekte stoppen (Freeze). Fokus auf das bloße Überleben der Organisation.³¹

Beispiel 6: ERP-Einführung (SAP S/4HANA) – Die Falle

• Klassifikation: Wahrgenommen als Kompliziert, Realität ist Komplex/Politisch
• Szenario: Einführung eines neuen ERP-Systems.
• Analyse: Oft wird dies als reines IT-Projekt behandelt (Kompliziert -> Wasserfall). In Wahrheit greift es tief in Prozesse ein, verändert Machtstrukturen (Wer hat Datenhoheit?) und löst Widerstand aus (Politisch). Zudem sind die technischen Anpassungen oft unvorhersehbar (Komplex).
• Strategie: Hybrid. Technische Migration mag kompliziert sein, aber Prozessanpassung muss iterativ und unter starker Einbindung der Stakeholder erfolgen.
• Insight: ERP-Projekte scheitern oft, weil sie fälschlicherweise in der “Komplizierten” Zone der Matrix verortet werden.¹⁴

Beispiel 7: Marketing für die “Gen Z”

• Klassifikation: Komplex
• Szenario: Eine etablierte Marke will 18-Jährige ansprechen.
• Analyse: Das Verhalten dieser Zielgruppe ist volatil und nicht linear aus dem Verhalten der “Boomer” ableitbar (Niedrige Certainty). Interne Marketing-Gurus sind sich uneinig über die Botschaft (Niedriges Agreement).
• Strategie: Experimentelle Kampagnen auf TikTok. A/B-Testing. Social Listening.
• Business Dev Implikation: Keine großen Jahreskampagnen im Voraus buchen. Budgets flexibel halten (“Rolling Budget”), um auf Trends reagieren zu können.¹²

Beispiel 8: Skalierung eines Startups (Scale-up Phase)

• Klassifikation: Transition von Komplex zu Kompliziert
• Szenario: Ein Startup hat Product-Market-Fit gefunden und wächst explosiv.
• Analyse: Die Phase des reinen Experimentierens (Komplex) ist vorbei. Jetzt müssen Prozesse (Sales Funnel, HR Onboarding) stabilisiert werden, um Effizienz zu gewinnen (Kompliziert/Einfach).
• Herausforderung: Der Gründer muss seinen Führungsstil ändern oder COO einstellen.
• Business Dev Implikation: Einführung von Management-Strukturen, ohne die agile Seele zu töten. Ein Balanceakt auf der Matrix.³⁴

Beispiel 9: Politische Lobbyarbeit / Public Affairs

• Klassifikation: Politisch Komplex
• Szenario: Einflussnahme auf neue Gesetzesvorhaben (z.B. ESG-Regulierung).
• Analyse: Das Ziel der Firma ist klar (Regulierung abmildern), aber die politischen Akteure haben diverse Agenden (Niedriges Agreement). Der Weg der Gesetzgebung ist volatil (Mäßige Certainty).
• Strategie: Netzwerken, Allianzen schmieden, Szenario-Planung.
• Business Dev Implikation: Aufbau von langfristigen Beziehungen (“Stakeholder Capital”), da Kausalitäten (“Wenn wir spenden, passiert X”) nicht funktionieren.¹⁶

Beispiel 10: Routine-Wartung von IT-Infrastruktur

• Klassifikation: Einfach / Trivial
• Szenario: Server-Patching, User-Support.
• Analyse: Probleme sind bekannt, Lösungen dokumentiert.
• Strategie: Service Level Agreements (SLAs), Ticketsysteme.
• Gefahr: Wenn hier “Agile” eingeführt wird (z.B. Daily Standups für Support-Mitarbeiter), sinkt die Effizienz. Hier gilt: “Don’t fix what isn’t broken”.³⁵

---

10. Strategische Implikationen für Business Development

Aus der Anwendung der Stacey-Matrix ergeben sich konkrete Handlungsanweisungen für die strategische Unternehmensentwicklung:

1. Kontextuelle Ambidextrie: Organisationen müssen beidhändig (ambidextrous) werden. Sie müssen gleichzeitig in der “Einfachen Zone” effizient exekutieren (Exploitation) und in der “Komplexen Zone” innovieren (Exploration). Ein Business Developer muss Strukturen schaffen, die beides erlauben (z.B. Innovation Labs getrennt vom Kerngeschäft).²⁴
2. Vertragsgestaltung:

• Für Projekte im Bereich Einfach/Kompliziert: Festpreisverträge (Fixed Price) sind möglich und sinnvoll, da der Lieferumfang definierbar ist.
• Für Projekte im Bereich Komplex: Festpreisverträge sind toxisch, da sie Änderungen bestrafen. Hier sind “Time & Material” oder agile Festpreise (Fixed Price per Sprint) notwendig. Business Developer müssen Kunden erziehen, Unsicherheit vertraglich abzubilden.

3. Fehlerkultur:

• In der Einfachen Zone sind Fehler Abweichungen vom Standard und müssen vermieden werden (Six Sigma).
• In der Komplexen Zone sind Fehler (wenn sie klein und früh passieren) wertvolle Datenpunkte. Eine “Null-Fehler-Kultur” tötet hier jede Innovation.

4. Kommunikation: Die Matrix dient als Objektivierungstool. Wenn ein Stakeholder einen detaillierten Plan für ein komplexes Projekt fordert, kann der Business Developer anhand der Matrix zeigen: “Wir befinden uns hier (Komplex). Ein Plan würde uns eine Scheinsicherheit geben. Lassen Sie uns stattdessen in Iterationen arbeiten.” Dies verschiebt die Diskussion von “Unfähigkeit zu planen” hin zu “professionellem Umgang mit Unsicherheit”.⁴

---

11. Fazit und Ausblick

Die Stacey-Matrix ist weit mehr als ein 2×2-Diagramm zur Auswahl von Projektmethoden. Sie ist eine Landkarte für das kognitive Verständnis von Organisationen. Trotz der berechtigten Kritik ihres Schöpfers an der systemischen Vereinfachung bleibt sie für den Praktiker das vielleicht mächtigste Tool, um die Kluft zwischen der Sehnsucht nach Ordnung und der Realität des Chaos zu überbrücken.

In einer Zukunft, die durch KI-Disruption noch undurchsichtiger wird, verschieben sich wertschöpfende Tätigkeiten massiv vom einfachen/komplizierten Bereich (der automatisiert wird) in den komplexen/politischen Bereich. Die Fähigkeit, in diesem Bereich zu navigieren – Unsicherheit auszuhalten, Emergenz zu nutzen und Konsens in Konflikten zu finden – wird zur entscheidenden Kernkompetenz des Business Developers. Die Stacey-Matrix mahnt uns: Wir können die Komplexität nicht wegplanen, aber wir können lernen, in ihr zu tanzen.

Referenzen

1. Understanding Cynefin, Stacey Matrix & Complexity Theory – AgileLAB GmbH, Zugriff am November 26, 2025, https://agilelab.de/blog/cynefin-stacey-matrix-complexity-theory
2. Stacey Matrix & Takeaways – why does your IT project suck? – Blog – Visuality, Zugriff am November 26, 2025, https://www.visuality.pl/posts/stacey-matrix-takeaways-why-does-your-project-suck
3. Stacey matrix – Praxis Framework, Zugriff am November 26, 2025, https://www.praxisframework.org/en/library/stacey-matrix
4. Ralph Stacey’s Agreement & Certainty Matrix Brenda Zimmerman, Schulich School of Business, York University, Toronto, Canada, Zugriff am November 26, 2025, https://www.nccmt.ca/uploads/media/media/0001/03/219b71c0f7ff72221e90bd4b6b7c537466c18301.pdf
5. The Stacey Matrix – Adapt Knowledge, Zugriff am November 26, 2025, https://adaptknowledge.com/wp-content/uploads/rapidintake/PI_CL/media/Stacey_Matrix.pdf
6. Ralph D. Stacey – Wikipedia, Zugriff am November 26, 2025, https://en.wikipedia.org/wiki/Ralph_D._Stacey
7. Ralph Stacey 10/9/1942 – 4/9/2021 – The Cynefin Co, Zugriff am November 26, 2025, https://thecynefin.co/ralph-stacey-10-9-1942-4-9-2021/
8. (PDF) Complexity and the Group Matrix – ResearchGate, Zugriff am November 26, 2025, https://www.researchgate.net/publication/30383245_Complexity_and_the_Group_Matrix
9. Unpacking Stacey Matrix – Humantific, Zugriff am November 26, 2025, https://www.humantific.com/post/unpacking-stacey-matrix
10. Reflections in Conversation – NextD Journal, Zugriff am November 26, 2025, https://www.nextd.org/post/nextd-journal-2
11. Stacey Matrix: the Basics and Diagram – Toolshero, Zugriff am November 26, 2025, https://www.toolshero.com/decision-making/stacey-matrix/
12. Understanding The Stacey Matrix & How It Helps Manage Complexities – Insight Blog, Zugriff am November 26, 2025, https://agilityportal.io/blog/stacey-matrix
13. What is the Stacey Matrix? Simple, Complicated, Complex, & Chaotic – OnlinePMCourses, Zugriff am November 26, 2025, https://onlinepmcourses.com/what-is-the-stacey-matrix-simple-complicated-complex-chaotic/
14. How to use the Stacey Matrix in Consulting – PrepLounge, Zugriff am November 26, 2025, https://www.preplounge.com/en/case-interview-basics/the-stacey-matrix
15. When Is It Time to Stop Using Scrum? – Age-of-Product.com, Zugriff am November 26, 2025, https://age-of-product.com/stop-using-scrum/
16. Stacey Matrix. (1) Technical rational decision-making. (2) Political… – ResearchGate, Zugriff am November 26, 2025, https://www.researchgate.net/figure/Stacey-Matrix-1-Technical-rational-decision-making-2-Political-decision-making_fig1_285525881
17. Agile vs Waterfall ? Risks By Using the Wrong One — Stacey Matrix, Zugriff am November 26, 2025, https://mgrush.com/blog/agile-vs-waterfall/
18. Choosing Agile or Waterfall? Optimal Agile Application – YouTube, Zugriff am November 26, 2025, https://www.youtube.com/watch?v=Re_3fIymbK0
19. The Stacey Matrix: Agility or waterfall in the project? – InLoox, Zugriff am November 26, 2025, https://www.inloox.com/company/blog/articles/the-stacey-matrix-agility-or-waterfall-in-the-project/
20. Agile vs Waterfall — What is the Best Delivery Method? | Jibility, Zugriff am November 26, 2025, https://www.jibility.com/blog/agile-vs-waterfall
21. Agile, Waterfall, or Kanban? Let the Stacey Matrix Guide Your Project Management Choice, Zugriff am November 26, 2025, https://azularc.com/latest-in-tech-news/agile-waterfall-or-kanban-let-the-stacey-matrix-guide-your-project-management-choice/
22. Kanban vs. Scrum – how to find the right project framework, Zugriff am November 26, 2025, https://omr.com/en/reviews/contenthub/kanban-vs-scrum
23. Scrum X Kanban – Reddit, Zugriff am November 26, 2025, https://www.reddit.com/r/scrum/comments/164ppq9/scrum_x_kanban/
24. How to choose the right project management approach | IAPM, Zugriff am November 26, 2025, https://www.iapm.net/en/blog/choosing-the-right-project-management-approach/
25. Stacey Matrix Mis-used Again!, Zugriff am November 26, 2025, http://bkekst.weebly.com/bk-blog/stacey-matrix-mis-used-again
26. It’s Just Not That Simple: A complex adaptive systems approach to understanding changing dynamics in leadership teams – OPUS at UTS, Zugriff am November 26, 2025, https://opus.lib.uts.edu.au/bitstream/10453/162584/2/02%20whole.pdf
27. Remembering Ralph Stacey | Complexity & Management Centre, Zugriff am November 26, 2025, https://complexityandmanagement.com/2021/12/03/remembering-ralph-stacey/
28. Separated by a common language? – The Cynefin Co, Zugriff am November 26, 2025, https://thecynefin.co/separated-by-a-common-language/
29. Complexity sub-domain framework – The Cynefin Co, Zugriff am November 26, 2025, https://thecynefin.co/complexity-sub-domain-cynefin-framework/
30. Cynefin Framework versus Stacey Matrix versus network perspectives – Rick On the Road, Zugriff am November 26, 2025, http://mandenews.blogspot.com/2010/08/test3.html
31. Leadership in a crisis: Responding to the coronavirus outbreak and future challenges – McKinsey, Zugriff am November 26, 2025, https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/leadership-in-a-crisis-responding-to-the-coronavirus-outbreak-and-future-challenges
32. Organisational learning during the coronavirus pandemic: A case study on models for extended learning and complexity management – PubMed Central, Zugriff am November 26, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC9207589/
33. SAFe for Agile Marketing Guidance Article – AgileSparks, Zugriff am November 26, 2025, https://agilesparks.com/safe-for-agile-marketing-guidance-article/
34. 5 Things that established firms can learn from startups – DMEXCO, Zugriff am November 26, 2025, https://dmexco.com/stories/5-things-that-established-firms-can-learn-from-startups/
35. Navigating the Maze: Mastering the Stacey Matrix for Project Success, Zugriff am November 26, 2025, https://juanfernandopacheco.medium.com/navigating-the-maze-mastering-the-stacey-matrix-for-project-success-313d27764987