Multi-Stakeholder Design: 5 Protokolle für echte Stakeholder-Konflikte

Eine Versicherung entwickelt ein neues Schadenmanagement-Portal. Der Einkauf will die Kosten pro Schadenfall senken. Die Schadensachbearbeiter wollen schnellere Bearbeitungszeiten. Die IT will standardisierte Schnittstellen. Die Rechtsabteilung will lückenlose Dokumentation. Die Geschäftsführung will die Kundenzufriedenheit steigern. Fünf Stakeholder, fünf verschiedene Definitionen von “Erfolg” — und das sind nur die sichtbaren fünf. Dahinter stehen Vertriebspartner, Regulierer, Endkunden, Datenschutzbeauftragte und weitere, die nie im Workshop sitzen, aber über Erfolg oder Scheitern entscheiden.

Das ist kein Kommunikationsproblem. Das ist ein Designproblem.

Forrester befragte 2024 über 16.000 B2B-Einkäufer und fand: An einem durchschnittlichen B2B-Kauf sind 13 Stakeholder beteiligt, und 86 % aller Kaufprozesse geraten ins Stocken — nicht wegen des Anbieters, sondern wegen interner Komplexität beim Kunden [1]. Gartner bestätigt mit einer Studie unter 632 Einkäufern: 74 % der Einkaufsgruppen zeigen “ungesunden Konflikt” während der Entscheidungsfindung [2].

Die meisten Stakeholder-Ansätze behandeln diesen Konflikt als Moderationsproblem — als ob bessere Post-its und ein erfahrenerer Facilitator die Lösung wären. Dieser Artikel vertritt eine andere These: Multi-Stakeholder Design scheitert, wenn es Konflikte als Kommunikationsproblem behandelt. Die eigentliche Herausforderung ist strukturell. Stakeholder haben gegensätzliche Erfolgskennzahlen, und die Aufgabe des Designers ist es, den Entscheidungsprozess selbst zu gestalten — nicht einen Kompromiss zu finden, der niemanden zufriedenstellt.

Was ist Multi-Stakeholder Design — und warum reicht Stakeholder Mapping nicht?

Definition: Multi-Stakeholder Design vs. Stakeholder Mapping vs. Stakeholder Management

Die drei Begriffe werden oft synonym verwendet. In der Praxis bezeichnen sie fundamental unterschiedliche Aktivitäten:

Kriterium	Stakeholder Mapping	Stakeholder Management	Multi-Stakeholder Design
Kernfrage	Wer ist beteiligt?	Wie halten wir alle informiert?	Wie gestalten wir Entscheidungen, wenn Stakeholder gegensätzliche Ziele haben?
Output	Influence/Interest-Matrix, Stakeholder-Map	Kommunikationsplan, RACI-Matrix	Entscheidungsarchitektur, Engagement-Journey, Facilitation-Protokolle
Annahme	Stakeholder lassen sich kategorisieren	Stakeholder lassen sich steuern	Stakeholder haben strukturell widersprüchliche Bedürfnisse, die gestaltet werden müssen
Zeitpunkt	Einmalig zu Projektbeginn	Laufend im Projektmanagement	Laufend als Design-Aufgabe über alle Projektphasen
Typischer Fehler	Wird erstellt und nie aktualisiert	Verwechselt Information mit Beteiligung	Wird gar nicht erst als eigenständige Aufgabe erkannt

R. Edward Freeman definierte 1984 einen Stakeholder als “a group or individual who can affect or is affected by the organization’s success” [3]. Diese Definition hat das Management-Denken revolutioniert — aber im Service Design reicht sie nicht aus. Service Design nach Birgit Mager (TH Köln, weltweit erste Professorin für Service Design) “choreographiert Prozesse, Technologien und Interaktionen in komplexen Systemen, um gemeinsam mit relevanten Stakeholdern Wert zu schaffen” [4]. Das Verb “choreographiert” ist präziser als “managt” oder “facilitiert” — es impliziert eine gestaltete, sequenzierte Koordination mehrerer Akteure.

Multi-Stakeholder Design ist die Disziplin, die diese Choreografie entwirft, wenn die Akteure unterschiedliche — manchmal widersprüchliche — Vorstellungen vom Ergebnis haben.

Warum “den Nutzer verstehen” im B2B nicht reicht

Sanders und Stappers (2008) beschreiben den Wandel vom nutzerzentrierten zum co-kreativen Design: Die Rolle des Designers verändert sich vom Übersetzer zum Facilitator, die des Forschers vom Spezialisten zum Verbinder, und “the person formerly known as the ‘user’” wandelt sich vom Subjekt zum Partner [5]. Aber was passiert, wenn es nicht “den Nutzer” gibt, sondern fünf, zehn oder dreizehn — mit widersprüchlichen Definitionen von Erfolg?

Im B2B-Kontext ist die Person, die einen Service nutzt, fast nie die Person, die ihn bezahlt. Und die Person, die ihn bezahlt, ist selten die Person, die ihn auswählt. Wenn du ein neues Kundenportal für eine Bank gestaltest, optimierst du für den Endkunden (will Einfachheit), den Relationship Manager (will Kundenbindung), die Compliance-Abteilung (will Nachvollziehbarkeit), die IT (will Wartbarkeit) oder den Vorstand (will Differenzierung)? “Für alle gleichzeitig” ist keine Antwort — es ist das Rezept für Design by Committee.

Stickdorn et al. (2018) formulieren das co-kreative Prinzip: “Service design cannot be done for users — it always needs to be done with users, customers, and employees” [6]. Das stimmt als Aspiration — aber es wird operativ naiv, wenn Stakeholder sich weigern, im selben Raum zu arbeiten. Oder wenn ihre Erfolgskennzahlen sich gegenseitig ausschließen.

Für die verschiedenen Nutzertypen im Service Design und ihre Anforderungen an Personas und Prototypen haben wir separate Artikel geschrieben. Dieser Artikel geht einen Schritt weiter: Was tust du, wenn du die Nutzertypen verstehst — aber ihre Bedürfnisse einander widersprechen?

Das Buying Committee als Design-Herausforderung

5 Rollen im B2B-Einkauf — und warum jede eine andere “gute” Dienstleistung will

Webster und Wind entwickelten 1972 das Buying-Center-Modell mit fünf Rollen [7]. Im Service Design ist jede dieser Rollen ein eigenständiges Designziel:

Rolle	Funktion	Was diese Rolle unter “gutem Service” versteht	Typische Vertretung
Users (Nutzer)	Verwenden den Service täglich	Einfache Bedienung, schnelle Erledigung, wenig Reibung	Sachbearbeiter, Fachkraft
Buyers (Einkäufer)	Formale Vertragsverantwortung	Beste Konditionen, standardisierte Prozesse, Vergleichbarkeit	Einkaufsabteilung, Procurement
Influencers (Einflussnehmer)	Liefern Informationen und Kriterien	Technische Überlegenheit, Innovationspotenzial, Compliance	IT-Architekten, Fachberater
Deciders (Entscheider)	Wählen unter Alternativen	Strategische Passung, Risikoabsicherung, ROI	Geschäftsführung, Bereichsleitung
Gatekeepers (Türsteher)	Kontrollieren den Informationsfluss	Standardkonformität, Sicherheit, Integrationsfähigkeit	IT-Security, Compliance, Rechtsabteilung

Der entscheidende Punkt: Diese fünf Rollen bewerten denselben Service nach unterschiedlichen Kriterien. Ein Schadenmanagement-Portal, das für den Nutzer (schnelle Bearbeitung) optimiert ist, kann für den Gatekeeper (Compliance-Dokumentation) inakzeptabel sein — und umgekehrt. Multi-Stakeholder Design erkennt an, dass keine Optimierung für eine einzelne Rolle ausreicht. Die Aufgabe ist, ein Design zu finden, das für jede Rolle funktional akzeptabel ist — nicht für eine Rolle maximal optimiert.

Die Zahlen: 13 Stakeholder, 86 % Stagnation, 74 % ungesunder Konflikt

Research Insight: Forrester (2024, n=16.000+ Einkäufer): An einem durchschnittlichen B2B-Kauf sind 13 Stakeholder beteiligt. 89 % der Kaufentscheidungen involvieren zwei oder mehr Abteilungen. 86 % aller B2B-Käufe geraten während des Prozesses ins Stocken. 81 % der Einkäufer sind mit dem gewählten Anbieter unzufrieden [1].

Diese Zahlen machen Multi-Stakeholder Design von einer methodischen Option zu einer geschäftlichen Notwendigkeit.

Research Insight: Gartner (2025, n=632 Einkäufer): 74 % der Einkaufsgruppen zeigen “ungesunden Konflikt” während der Entscheidungsfindung. Gruppen, die Konsens erreichen, berichten 2,5-mal häufiger von einem qualitativ hochwertigen Abschluss [2].

Diese Zahlen stammen aus der Vertriebsforschung — aber sie beschreiben ein Design-Problem. Wenn 86 % der B2B-Käufe ins Stocken geraten, ist das kein Vertriebsproblem. Es ist ein Zeichen dafür, dass der Service (oder das Angebot) nicht so gestaltet ist, dass 13 Stakeholder gleichzeitig Ja sagen können.

Drei Strukturprobleme, die Workshops zum Scheitern bringen

Rollenmyopie: Jeder sieht nur seine eigene Funktion

Flaig, Guyader und Ottosson (2025) identifizierten in ihrer Längsschnittstudie eines Mobilitäts-Service-Ökosystems zwei spezifische Barrieren: Rollenmyopie — Stakeholder sehen nur ihre eigene Funktion — und Rollenunsicherheit — Stakeholder sind sich über ihre systemische Position unklar [9]. Ihr DOSE-Framework (Design-Oriented Stakeholder Engagement) zeigt, dass Stakeholder drei Grade reflexiver Fähigkeiten zeigen: fokussiert auf die selbst wahrgenommene Rolle, auf die aktuelle systemische Rolle, und auf die zukünftige systemische Rolle.

Konkret: Ein Telko-Unternehmen gestaltet eine neue Self-Service-Plattform. Der Kundenservice-Leiter optimiert für Anrufvermeidung (seine KPI). Die Marketing-Abteilung optimiert für Upselling-Möglichkeiten (ihre KPI). Die IT optimiert für Wartbarkeit (ihre KPI). Jeder hat recht — innerhalb seiner Rolle. Aber niemand gestaltet für das Kundenerlebnis als Ganzes, weil jeder nur seine eigene Funktion sieht. Das ist Rollenmyopie, und sie lässt sich nicht durch bessere Kommunikation lösen — sie ist eine Funktion der Organisationsstruktur.

Das HiPPO-Problem: Wenn die ranghöchste Person den Raum dominiert

Farr (2018) untersuchte in zwei longitudinalen Fallstudien (Krankenhaus-Service-Design und kommunale Innovation), ob Co-Design-Prozesse bestehende Machtdynamiken verändern können. Das Ergebnis war ernüchternd: Während persönliche Erfahrungen sich verbesserten (Teilnehmer fühlten sich gehört), blieb “genuine equality of power difficult to achieve within uneven hierarchical structures” [10]. Strukturelle Veränderungen blieben kleinräumig, obwohl die persönlichen Auswirkungen positiv waren.

Wie das aussieht: Wenn der Bereichsleiter im Workshop eine Meinung äußert, stimmen die Teamleiter zu — nicht weil sie überzeugt sind, sondern weil die Hierarchie den Raum dominiert. Spark Market Research empfiehlt als Gegenmaßnahme: “Bring in a 3rd-party facilitator who won’t pay much heed to interpersonal conflicts between departments, and whose outside viewpoint brings much-needed objectivity — not siding with any part of the business” [11]. Aber externe Moderation ist ein Workaround, keine strukturelle Lösung. Die strukturelle Lösung liegt in Entscheidungsformaten, die hierarchische Dominanz ausschließen — wie das consent-basierte Entscheidungsverfahren der Holakratie (dazu mehr in Abschnitt 6).

Design by Committee: Warum “alle mitreden” Innovation tötet

Riddle und Treder (UXPin) formulieren es ungeschönt: “Committee design is not collaborative. It’s a dictatorship of many, and you’ll be reduced to implementer rather than facilitator” [12]. Design by Committee entsteht, wenn Multi-Stakeholder-Beteiligung ohne Entscheidungsarchitektur organisiert wird: Innovation wird verwässert, Scope Creep ersetzt Designentscheidungen, und interne Stakeholder verdrängen die Kundenperspektive [13][14].

Von Busch und Palmas (2022) gehen noch weiter: “Designers tend to overemphasize the place of ideals in design, leaving them ill-equipped to deal with a social world of power-wielding and zero-sum games.” Ihr Konzept “Realdesign” argumentiert, dass Co-Design-Prozesse “rife with betrayals, decay, and corruption” sind und dass “designerly empathy has morphed into a new form of cunning statecraft” [15]. Das Problem ist nicht mangelnde Empathie — es ist mangelnder Realismus über Macht.

Stakeholder-Bedürfnisse kartieren — jenseits der 2x2-Matrix

Power/Legitimacy/Urgency: Das Mitchell-Agle-Wood-Modell

Die klassische Influence/Interest-Matrix (2x2-Quadrant) ist das am weitesten verbreitete Stakeholder-Tool. Sie kategorisiert Stakeholder nach zwei Achsen: Einfluss (hoch/niedrig) und Interesse (hoch/niedrig). Für eine erste Orientierung ist sie nützlich. Für Multi-Stakeholder Design ist sie unzureichend, weil sie zwei Dimensionen auf eine komplexe Realität reduziert.

Mitchell, Agle und Wood (1997) entwickelten ein differenzierteres Modell mit drei Dimensionen [16]:

• Power (Macht): Kann der Stakeholder Ressourcen einsetzen, um seinen Willen durchzusetzen?
• Legitimacy (Legitimität): Wird der Anspruch des Stakeholders als berechtigt anerkannt?
• Urgency (Dringlichkeit): Wie zeitkritisch ist die Forderung des Stakeholders?

Die Kombination dieser drei Dimensionen erzeugt sieben Stakeholder-Typen [16]:

• Dormant (schlafend): Nur Macht, keine Legitimität, keine Dringlichkeit — z. B. ein Vorstand, der das Projekt nicht kennt, aber jederzeit stoppen könnte
• Discretionary (freiwillig): Nur Legitimität — z. B. Endnutzer, die berechtigt sind, aber weder Macht noch Dringlichkeit haben
• Demanding (fordernd): Nur Dringlichkeit — z. B. ein Beschwerdeführer, der laut, aber weder mächtig noch legitimiert ist
• Dominant (dominierend): Macht + Legitimität — z. B. die IT-Abteilung, die implementieren muss und berechtigt ist
• Dangerous (gefährlich): Macht + Dringlichkeit, aber keine Legitimität — z. B. ein Wettbewerber, der Druck ausübt
• Dependent (abhängig): Legitimität + Dringlichkeit, aber keine Macht — z. B. Kunden mit dringendem Bedarf, aber ohne Einfluss auf die Entscheidung
• Definitive (definitiv): Alle drei Dimensionen — diese Stakeholder MÜSSEN einbezogen werden

Für Service Design ist der entscheidende Vorteil: Das Modell erklärt, warum bestimmte Stakeholder dominieren und andere ignoriert werden, obwohl ihre Ansprüche berechtigt sind. Besonders die “Dependent”-Stakeholder (Legitimität + Dringlichkeit, aber keine Macht) werden in Buying Committees systematisch übergangen — obwohl sie oft die eigentlichen Nutzer des Service sind.

Am Beispiel eines neuen Kunden-Onboardings für einen Industrieversicherer:

Abteilung	Macht	Legitimität	Dringlichkeit	Konsequenz
Compliance	Hoch (kann stoppen)	Hoch (Regulierung)	Niedrig (ändert sich langsam)	Dominant — wird gehört, blockiert aber selten aktiv
Vertrieb	Mittel	Hoch (Kundennähe)	Hoch (verlorene Kunden)	Dependent — legitimiert und dringend, aber ohne Vetorecht. Wird systematisch übergangen
IT	Hoch (muss implementieren)	Niedrig (aus Kundensicht)	Hoch (Release-Plan)	Dangerous — kann Fakten schaffen, ohne die Kundenperspektive zu vertreten

Das Mitchell-Agle-Wood-Modell macht sichtbar, warum der Vertrieb in der Praxis ignoriert wird, obwohl er Legitimität UND Dringlichkeit hat: Ihm fehlt die Macht, das Projekt zu stoppen.

Dynamische Salienz: Warum sich Stakeholder-Gewicht über Projektphasen verschiebt

Lievens und Blazevic (2021) schlagen das Konzept der “Stakeholder Engagement Journey” vor: eine Verbindung von Service-Design-Phasen und Innovationsprozess-Stufen, die explizit macht, wann welche Stakeholder einbezogen — und wann bewusst nicht einbezogen — werden sollten [17]. Stakeholder-Salienz ist nicht statisch. Sie verschiebt sich über den Projektverlauf.

Am Beispiel eines Versicherungsprodukts: In der Discover-Phase dominiert die Kundenperspektive (Nutzerforschung). In der Define-Phase gewinnen Aktuare und Compliance an Salienz (Machbarkeit, Regulierung). In der Develop-Phase treten IT-Architekten und Prozessverantwortliche in den Vordergrund (Umsetzbarkeit). Und in der Deliver-Phase bestimmt der Vertrieb die Prioritäten (Marktfähigkeit). Wer die Stakeholder-Map einmal erstellt und nie aktualisiert, arbeitet in jeder Phase mit der falschen Priorisierung.

Das BMW i3/i8-Projekt illustriert die Bandbreite: BMW kollaborierte mit Stadtplanern, Regulierungsbehörden, Energieversorgern, Universitäten und Forschungsinstituten — jede Gruppe war zu unterschiedlichen Zeitpunkten und mit unterschiedlicher Intensität relevant [17]. Eine Customer Journey Map für jeden einzelnen Stakeholder wäre unverhältnismäßig — aber eine “Engagement Journey” über alle Stakeholder hinweg ist die notwendige Ergänzung zur klassischen Stakeholder-Map.

Fünf Methoden für echte Stakeholder-Konflikte

Die folgenden fünf Methoden sind keine generischen Workshop-Techniken. Jede adressiert ein spezifisches Strukturproblem bei widersprüchlichen Stakeholder-Bedürfnissen.

Methoden-Navigator: Welche Methode für welches Problem?

Methode	Strukturproblem	Gruppengröße	Zeitrahmen	Facilitator-Kompetenz
Consent-Entscheidung	Entscheidungsblockade durch Konsenssuche	5—15	60—90 Min. pro Runde	Hoch (Einwand vs. Präferenz unterscheiden)
Integrierte Co-Design-Workshops	Gruppen zu unterschiedlich für gemeinsame Sessions	20—200+ (in Untergruppen)	Mehrere Workshops à 2—4 Std.	Mittel (Gruppenmoderation)
Dual-Threshold-Voting	Dominanz großer Gruppen über kleine	20—50+ (in Gruppen)	30—60 Min. pro Abstimmungsrunde	Niedrig (Voting-Mechanik)
Conflict Sensitive Design	Stakeholder verweigern gemeinsame Teilnahme	10—30 (in separaten Sessions)	2—3 Std. pro Partei + Synthese	Hoch (Mediationskompetenz)
Engagement-Journey	Stakeholder-Relevanz verschiebt sich über Phasen	Beliebig	Projektbegleitend (quartalsweise Review)	Mittel (Projektsteuerung)

Nutze diese Übersicht als Ausgangspunkt — in der Praxis kombinierst du oft mehrere Methoden im selben Projekt.

Consent-basierte Entscheidungsfindung statt Konsens

Wann einsetzen: Wenn Entscheidungen an Konsenssuche scheitern — jeder hat ein Veto, niemand bewegt sich.

Was es ist: Consent (aus Soziokratie und Holakratie) verschiebt die Frage von “Sind alle einverstanden?” zu “Hat jemand einen schwerwiegenden Einwand — einen Grund, warum dieser Vorschlag Schaden verursachen würde?” [18][19]. Der Bereich zwischen persönlicher Präferenz und aktivem Einwand — die sogenannte Toleranzzone — ist der Raum, in dem die meisten Entscheidungen leben.

Protokoll:

1. Ein konkreter Vorschlag wird formuliert (nicht “Was wollen wir?”, sondern “Ich schlage vor, dass…”)
2. Klärungsfragen — nur Verständnisfragen, keine Meinungen
3. Reaktionsrunde — jeder Stakeholder äußert seine Reaktion, ohne Diskussion
4. Einwandrunde — “Hast du einen schwerwiegenden Einwand?” (Einwände müssen begründet sein: Was genau würde Schaden verursachen?)
5. Integration — jeder valide Einwand wird in den Vorschlag integriert, nicht weggestimmt

Warum es funktioniert: Consent eliminiert die Filibuster-Dynamik, in der ein einzelner Stakeholder den Fortschritt unbegrenzt blockieren kann. Einwände müssen auf der Organisationsrolle basieren, nicht auf persönlicher Präferenz [20]. (Ausführlichere Erklärung in Abschnitt 6.)

Das passiert in der Praxis oft: Ein hierarchisch hochstehender Stakeholder nutzt “Einwand” als Vetorecht und begründet jeden Einwand mit abstraktem “strategischem Risiko”. Gegenmaßnahme: Bestehe darauf, dass Einwände einen konkreten Schaden benennen müssen — “Das widerspricht unserer Strategie” ist kein Einwand, “Das würde unsere bestehenden Kunden im Segment X verlieren” ist einer.

Aus unserer Governance-Praxis: Die größte Hürde beim Consent-Prozess ist Schritt 4 — die Unterscheidung zwischen Präferenz und Einwand. In unserer täglichen Governance-Praxis beobachten wir, dass etwa 80 % der anfänglichen “Einwände” tatsächlich Präferenzen sind. Was hilft: Hänge vor dem Workshop ein Plakat auf mit der Frage “Würde dieser Vorschlag konkreten Schaden verursachen — oder hätte ich es einfach lieber anders?” Diese visuelle Erinnerung reduziert Pseudo-Einwände sofort.

Integrierte Co-Design-Workshops: Gruppen reagieren auf die Ergebnisse anderer Gruppen

Wann einsetzen: Wenn Stakeholder-Gruppen zu unterschiedlich sind, um produktiv im selben Raum zu arbeiten, aber ihre Perspektiven dennoch integriert werden müssen.

Was es ist: Kerr et al. (2022) entwickelten das “Integrated Co-Design”-Modell im inclusionED-Projekt (Australien), bei dem Lehrer, Sonderpädagogen, Schüler auf dem Autismus-Spektrum, Eltern und Bildungspolitiker gemeinsam eine Lernplattform gestalteten — über 200 Stakeholder in neun initialen Co-Design-Workshops mit vier verschiedenen Gruppen [21].

Protokoll:

1. Jede Stakeholder-Gruppe arbeitet separat in eigenen Workshops
2. Die Ergebnisse einer Gruppe werden den anderen Gruppen vorgestellt
3. Jede Gruppe reagiert kreativ auf die Ergebnisse der anderen (z. B. Bildungspolitiker reagieren auf Workshop-Ergebnisse der Schüler)
4. Die Synthese erfolgt durch das Design-Team, nicht durch einen gemeinsamen Kompromiss-Workshop
5. Blended-Formate (vor Ort + online) ermöglichen Teilnahme von Gruppen, die nicht physisch anwesend sein können

Warum es funktioniert: Die Methode bewahrt die authentische Stimme jeder Gruppe, während sie einen strukturierten Dialog zwischen Gruppen schafft — ohne die Machtdynamiken eines gemeinsamen Raums. Das Ergebnis: Die inclusionED-Plattform kombiniert Ergebnisse aus über 25 Forschungsprojekten an 300+ australischen Schulen [21].

Das passiert in der Praxis oft: Gruppe A lehnt die Ergebnisse von Gruppe B komplett ab, weil der Kontext fehlt. Gegenmaßnahme: Stelle die Ergebnisse nie als fertige Vorschläge vor, sondern als “Perspektiven, auf die eure Gruppe reagieren soll”. Das Framing als Reaktionsaufforderung statt als Bewertungsaufgabe verhindert reflexhafte Ablehnung.

Dual-Threshold-Voting: >50 % der Personen UND >50 % der Gruppen

Wann einsetzen: Wenn Entscheidungen demokratisch legitimiert sein müssen, ohne dass eine zahlenmäßig große Stakeholder-Gruppe die kleineren dominiert.

Was es ist: Daly-Smith et al. (2020) dokumentierten den ersten Fall, in dem Praktiker, Politiker und Forscher gemeinsam ein Framework von der Konzeption an co-designten. 50 Stakeholder in 9 Gruppen (britische Forscher, Spezialisten für öffentliche Gesundheit, Schulleitungen, Lehrer, Sport-England-Vertreter u. a.) [22].

Protokoll:

1. Vorschläge werden ausgearbeitet und allen Stakeholder-Gruppen vorgelegt
2. Jede Änderung wird nur akzeptiert, wenn >50 % aller Personen UND >50 % aller Stakeholder-Gruppen (mindestens fünf von neun) dafür stimmen
3. Wenn ein Vorschlag den Dual-Threshold nicht erreicht, muss das Design-Team eine alternative Lösung entwickeln
4. Abgelehnte Vorschläge werden nicht einfach gestrichen — sie erzwingen kreative Neuformulierung

Warum es funktioniert: Das doppelte Schwellenprinzip verhindert zwei Probleme gleichzeitig: Es stoppt die Dominanz einer zahlenmäßig großen Gruppe (Forscher können nicht Praktiker überstimmen), und es fordert gleichzeitig breite Unterstützung über alle Gruppen hinweg. Von 8 vorgeschlagenen Änderungen im CAS-Framework wurden 6 angenommen und 2 abgelehnt — bei den abgelehnten wurde eine Alternativdarstellung entwickelt, die den Dual-Threshold bestand [22].

Das passiert in der Praxis oft: Eine zahlenmäßig kleine Stakeholder-Gruppe (z. B. 3 Personen) fühlt sich von der Gruppen-Schwelle strukturell benachteiligt gegenüber einer großen Gruppe (z. B. 15 Personen). Gegenmaßnahme: Kommuniziere vorab, dass die Gruppen-Schwelle genau dieses Problem löst — jede Gruppe zählt gleich, unabhängig von ihrer Größe.

Conflict Sensitive Design: Getrennte Sitzungen mit Synthese

Wann einsetzen: Wenn Stakeholder sich weigern, gemeinsam an einem Tisch zu sitzen — oder wenn gemeinsame Sitzungen durch Machtgefälle so verzerrt sind, dass ehrlicher Input unmöglich wird.

Was es ist: Ogunyemi et al. (2025) entwickelten Conflict Sensitive Design (CSD) für die Gestaltung von Community-Policing-Technologie in Nigeria, wo Bürger und Polizei die Teilnahme an gemeinsamen Sessions ablehnten — aus Angst und Misstrauen [23]. Die Methode adaptiert Mediationstechniken für den Designprozess.

Protokoll:

1. Spannungsreduktion: Separate Vorgespräche mit jeder Partei
2. Leveling: Sicherstellen, dass jede Gruppe gleichwertige Ressourcen und Aufmerksamkeit erhält
3. Common Ground Reminder: Explizites Benennen gemeinsamer Interessen als Ausgangspunkt
4. Getrennte Sitzungen: Jede Gruppe erarbeitet ihre Designanforderungen separat
5. Formalisierte Vereinbarungen: Das Design-Team synthetisiert die Ergebnisse und formalisiert Kompromisse

Warum es für B2B relevant ist: Der Extremfall Nigeria-Polizei beleuchtet ein alltägliches Enterprise-Problem: Wenn Vertrieb und Operations adversarische Dynamiken haben, wenn Management und Frontline sich gegenseitig misstrauen, wenn IT und Fachabteilung verschiedene Welten bewohnen — dann sind getrennte Sitzungen mit professioneller Synthese nicht die zweitbeste Lösung. Sie sind die einzige, die ehrlichen Input ermöglicht.

Das passiert in der Praxis oft: Eine Partei verweigert die Teilnahme an separaten Sitzungen, weil sie befürchtet, dass die andere Partei “hinter ihrem Rücken” das Ergebnis beeinflusst. Gegenmaßnahme: Transparenz über den Syntheseprozess — beide Parteien erhalten vorab eine Beschreibung, wie die Ergebnisse zusammengeführt werden, und haben die Möglichkeit, die Synthese zu kommentieren, bevor sie finalisiert wird.

Stakeholder-Engagement-Journey: Wann einbeziehen — und wann bewusst nicht

Wann einsetzen: Bei Projekten, die sich über mehrere Monate erstrecken und in denen die relevanten Stakeholder sich über die Phasen verändern.

Was es ist: Lievens und Blazevic (2021) schlagen vor, Service Design als “Trigger” zu nutzen, um Aktivitäten zu entwickeln, die Stakeholder gezielt ein- und ausschalten — “(dis)engage” — über den gesamten B2B-Innovationsprozess [17].

Protokoll:

1. Identifiziere alle Stakeholder über den gesamten Projektzyklus (nicht nur die aktuellen)
2. Ordne jeden Stakeholder den Phasen zu, in denen seine Salienz am höchsten ist
3. Definiere für jede Phase: Wer wird aktiv einbezogen? Wer wird informiert? Wer wird bewusst nicht einbezogen?
4. Plane die Übergänge: Wie bringst du einen Stakeholder ins Projekt, der in Phase 1 irrelevant war, aber in Phase 3 entscheidend wird?
5. Dokumentiere die Entscheidung: Warum wird ein Stakeholder in einer bestimmten Phase nicht einbezogen?

Der Service Blueprint ist das natürliche Werkzeug, um die Backstage-Orchestration dieser Engagement-Journey sichtbar zu machen: Welche internen Prozesse und Übergaben stehen hinter den Stakeholder-Wechseln?

Das passiert in der Praxis oft: Stakeholder, die in Phase 1 bewusst nicht einbezogen wurden, fühlen sich in Phase 3 übergangen und blockieren das Projekt. Gegenmaßnahme: Dokumentiere und kommuniziere die Engagement-Journey explizit an alle Stakeholder — auch an diejenigen, die erst in späteren Phasen aktiv werden. Die Botschaft: “Du bist eingeplant für Phase 3, weil dort deine Expertise am meisten zählt” ist etwas völlig anderes als “Du wurdest nicht eingeladen”.

Jonas, Roth und Möslein (2016) fanden in ihrer Untersuchung deutscher Mittelstandsunternehmen heraus, dass es 35+ Methoden zur Stakeholder-Integration gibt — aber fast alle nur für interne Stakeholder eingesetzt werden. Externe Stakeholder, vor allem Kunden, werden nur am Anfang befragt (Interviews) und am Ende getestet (Pilotprojekt). Der gesamte Mittelteil — wo die eigentlichen Designentscheidungen fallen — bleibt intern [24]. Die Engagement-Journey schließt diese Lücke, indem sie explizit macht, wann externe Stakeholder aktiv mitgestalten müssen — nicht nur informiert werden.

Integrative Entscheidungsfindung aus der Holakratie

Die folgenden Formate stammen aus der Holakratie — einer Organisationsform, die wir bei SI Labs täglich praktizieren. Was als interne Governance funktioniert, lässt sich direkt auf Multi-Stakeholder Design-Workshops übertragen. In den folgenden Abschnitten teilen wir, was wir dabei gelernt haben — einschließlich der Stellen, an denen die Übertragung schwieriger ist als erwartet.

Vom Konsens zum Consent: “Hast du einen schwerwiegenden Einwand?”

Die Grundmechanik von Consent vs. Konsens haben wir in Abschnitt 5 vorgestellt. Hier geht es um die holakratische Rahmung — und warum sie einen entscheidenden Unterschied macht:

Kriterium	Konsens	Consent
Leitfrage	”Stimmen alle zu?"	"Hat jemand einen schwerwiegenden Einwand?”
Schwelle	Alle müssen zustimmen	Kein Einwand darf unintegriert bleiben
Was blockiert	Jede Nicht-Zustimmung	Nur begründete Einwände, die Schaden nachweisen
Typisches Ergebnis	Kleinster gemeinsamer Nenner	”Good enough for now, safe enough to try”
Risiko	Ambitionslose Kompromisse	Erfordert Facilitator-Kompetenz, um Einwände von Präferenzen zu unterscheiden

In der Holakratie ist Consent nicht nur eine Abstimmungsmethode — es ist ein Governanceprinzip [18][19][20]. Der entscheidende Unterschied zum bloßen Workshop-Tool: Einwände müssen auf der Organisationsrolle basieren, nicht auf persönlicher Präferenz. Für Multi-Stakeholder Design-Workshops bedeutet das: Jeder Einwand muss die Frage beantworten “Welcher konkrete Schaden würde für meine Rolle im System entstehen?” — nicht “Ich hätte es lieber anders.”

Taktische Meetings als Design-Review-Format

Das taktische Meeting der Holakratie ist ein schlankes Format für operative Abstimmung: Check-in, Checklisten, Metriken, Projektfortschritt, Triage offener Punkte, Check-out. Es dauert typischerweise 30-60 Minuten und folgt einem strikten Ablauf, der verhindert, dass einzelne Themen die gesamte Zeit dominieren.

Für Multi-Stakeholder Design-Reviews ist dieses Format direkt übertragbar — eine Übertragung, die wir aus unserer internen Governance-Praxis ableiten:

1. Check-in: Jeder Stakeholder beschreibt in einem Satz seinen aktuellen Stand zum Projekt
2. Checkliste: Wiederkehrende Fragen werden mit Ja/Nein beantwortet, nicht diskutiert
3. Metriken: Relevante Kennzahlen werden berichtet, nicht interpretiert
4. Triage: Offene Design-Fragen werden priorisiert, nicht gelöst — jede Frage bekommt einen nächsten Schritt und einen Verantwortlichen
5. Check-out: Ein Satz zur Reflexion über das Meeting selbst

Aus unserer Governance-Praxis: Der Transfer vom internen Governance-Meeting zum externen Design-Review erfordert drei Anpassungen: (1) Die Checkliste muss vorher mit den Stakeholdern vereinbart werden — intern kennt jeder die wiederkehrenden Fragen, extern nicht. (2) Die Triage funktioniert nur, wenn der Facilitator konsequent bei “nächster Schritt + Verantwortlicher” bleibt — externe Stakeholder tendieren dazu, Triage-Punkte sofort lösen zu wollen. (3) Der Check-out ist das unterschätzte Element: Eine Reflexionsfrage wie “Was hat dich in diesem Meeting überrascht?” liefert oft die wertvollsten Hinweise auf blinde Flecken.

IBM’s Enterprise Design Thinking nutzt ein verwandtes Prinzip: “Playbacks” sind strukturierte Alignment-Meetings am Ende jeder Design-Phase. Draft-Playbacks (“Playback -2”, “Playback -1”) werden vor dem eigentlichen Milestone-Playback gehalten, um iterativ auf Alignment hinzuarbeiten, bevor Commitments gemacht werden [25]. Das Prinzip ist dasselbe: Strukturierte, zeitlich begrenzte Formate verhindern die Endlos-Diskussionen, die Multi-Stakeholder-Meetings unproduktiv machen.

Rollenbasierte statt personenbasierte Stakeholder-Identifikation

Ein häufiger Fehler im Multi-Stakeholder Design: Stakeholder werden als Personen identifiziert (“Herr Müller aus der IT”, “Frau Schmidt aus dem Einkauf”). Das Problem: Wenn Herr Müller krank wird oder die Rolle wechselt, bricht die Stakeholder-Map zusammen.

Die Holakratie löst dieses Problem, indem sie konsequent zwischen Rollen und Personen unterscheidet. Eine Rolle ist ein Bündel aus Purpose (Zweck), Domains (Zuständigkeiten) und Accountabilities (Verantwortlichkeiten). Eine Person kann mehrere Rollen ausfüllen; eine Rolle kann von mehreren Personen getragen werden.

Für Multi-Stakeholder Design bedeutet das: Identifiziere nicht “die 13 Personen im Buying Committee”, sondern die 5-7 Rollen, die im Entscheidungsprozess vertreten sein müssen. Wenn eine Person ausfällt, bleibt die Rolle besetzt — und die Stakeholder-Map intakt.

Aus unserer Governance-Praxis: Rollenbasierte Identifikation kollidiert häufig mit der deutschen Unternehmenskultur, in der “Herr Müller aus der IT” eine Person ist, nicht eine Rolle. Der Wechsel zum Rollen-Denken erfordert explizites Framing am Workshop-Beginn: “Wir sprechen heute über die Rolle IT-Sicherheit, nicht über Herrn Müller. Welche Verantwortlichkeiten hat diese Rolle — unabhängig davon, wer sie gerade ausfüllt?” Dieser einfache Satz verändert die Dynamik des gesamten Workshops.

Reypens, Lievens und Blazevic (2021) beobachteten im European Medical Information Framework (EMIF) — einem Pharma-Innovationsnetzwerk mit 57 Partnern aus 14 Ländern — dass effektive Orchestratoren hybride Orchestration praktizieren: Sie wechseln dynamisch zwischen dominierenden Modi (wenn Geschwindigkeit oder IP-Schutz nötig sind) und konsensbasierten Modi (wenn Buy-in und Legitimität gebraucht werden) [26]. Die Fähigkeit, den Moderationsmodus situativ zu wechseln, erfordert rollenbasiertes Denken: Was braucht die Rolle des Orchestrators in diesem Moment?

Wann du NICHT alle Stakeholder einbeziehen solltest

Tokenistische Beteiligung schadet mehr als keine Beteiligung

Nicht jeder Stakeholder sollte an jedem Punkt des Prozesses beteiligt sein. Die Forschung identifiziert mindestens drei Szenarien, in denen Stakeholder-Beteiligung aktiv schadet:

1. Tokenistische Partizipation: Stakeholder einzuladen, deren Input nie wirklich berücksichtigt wird, “may be worse than not involving stakeholders at all, as it creates false expectations and erodes trust” [27].

2. Entscheidungen fallen trotzdem woanders: “Decision-making always reverted to the design teams or proxies. Even though designers prioritized users’ ideas, it was the designers who determined project outcomes” [28]. Wenn Stakeholder merken, dass ihre Beteiligung keine Auswirkung hat, sinkt nicht nur ihr Engagement — ihr Vertrauen in den gesamten Prozess erodiert.

3. Verfügbarkeit statt Relevanz privilegieren: “Confining participation only to a select few who can participate intensively runs the danger of over-privileging those social groups” [29]. Wer kann an einem ganztägigen Workshop teilnehmen? Nicht der Monteur auf der Baustelle, nicht die Sachbearbeiterin im Schichtdienst — sondern Management und Stabsfunktionen. Die Stimmen, die am leichtesten zu integrieren sind, sind nicht immer die relevantesten.

collaboratio helvetica, eine Schweizer Multi-Stakeholder-Facilitation-Organisation, empfiehlt als Mindeststandard: zwei geschulte Facilitatoren für Multi-Stakeholder-Workshops, die explizit darauf achten, welche Stimmen fehlen — nicht nur welche anwesend sind [30].

Gruppe schlägt Individuum: Warum individuelle Relevanz den Gruppenkonsens um 59 % senkt

Research Insight: Gartner (2025): Inhalte, die auf individuelle Relevanz zugeschnitten sind, senken den Gruppenkonsens um 59 %. Inhalte, die auf Gruppen-Relevanz zugeschnitten sind, erhöhen den Konsens um 20 %. Einkäufer, die Gruppen-Relevanz erleben, berichten 3-mal häufiger von einem qualitativ hochwertigen Abschluss [2].

Diese Erkenntnis invertiert den Standard-UX-Instinkt: In Multi-Stakeholder-Kontexten schadet die Optimierung für individuelle Zufriedenheit der Gruppeneinigung. Wenn du jedem Stakeholder individuell das gibst, was er will, erzeugst du 13 personalisierte Perspektiven, die keinen gemeinsamen Nenner mehr haben.

Die Konsequenz für Multi-Stakeholder Design: Die Einheit des Designs ist nicht der einzelne Stakeholder — es ist die Gruppendynamik. Teams, die versuchen, jeden Stakeholder individuell glücklich zu machen, erzeugen Lösungen, für die sich kein Stakeholder kollektiv verantwortlich fühlt. Die Gartner-Daten bestätigen diesen Befund empirisch (siehe Research Insight oben).

Häufige Fehler im Multi-Stakeholder Design

Fehler 1: Stakeholder Map einmal erstellen und nie aktualisieren

Warum es passiert: Die Stakeholder-Analyse wird als Projektstart-Ritual behandelt — ein Pflichtdokument, das im Projektordner verschwindet.

Was schiefgeht: Gartners Daten zeigen, dass Buying Committees ihre Zusammensetzung über Beschaffungsphasen hinweg verändern [2]. Der CFO ist in der strategischen Entscheidung präsent, aber nicht in der Detailverhandlung. Neue Stakeholder treten auf, wenn das Projekt ihre Abteilung betrifft. Wer mit der Stakeholder-Map von Monat 1 in Monat 6 arbeitet, optimiert für die falschen Personen.

Was stattdessen tun: Stakeholder-Maps quartalsweise überprüfen. Bei jedem Phasenübergang (Discover -> Define -> Develop -> Deliver) explizit fragen: Welche Stakeholder haben an Salienz gewonnen? Welche haben an Salienz verloren? Wer ist neu hinzugekommen?

Fehler 2: Konflikte als Kommunikationsproblem behandeln

Warum es passiert: Die Facilitation-Literatur betont “aktives Zuhören”, “Empathie” und “gemeinsame Sprache finden” — Techniken, die bei Missverständnissen helfen. Aber viele Stakeholder-Konflikte sind keine Missverständnisse.

Was schiefgeht: Wenn der Einkauf Kostenreduktion will und die Fachabteilung Qualitätserhöhung, verstehen sich beide perfekt. Sie haben einen strukturellen Interessenkonflikt, keinen kommunikativen. Mehr Empathie ändert daran nichts.

Was stattdessen tun: Den Konflikt als Designaufgabe begreifen. Die Frage ist nicht “Wie bringen wir Einkauf und Fachabteilung dazu, sich zu verstehen?” sondern “Wie gestalten wir eine Entscheidungsarchitektur, die beide Interessen transparent abwägt — und explizit macht, welche Trade-offs akzeptiert werden?”

Fehler 3: Externe Stakeholder nur passiv einbinden

Warum es passiert: Jonas, Roth und Möslein (2016) dokumentierten das Muster empirisch: Deutsche Mittelstandsunternehmen konzeptualisieren Stakeholder-Integration auf einem Kontinuum von passiv (informieren), reaktiv (Feedback einholen), mutual (gemeinsam gestalten) bis pro-aktiv (Stakeholder initiiert). Höhere Integrationsmodi (mutual, pro-aktiv) treten fast ausschließlich bei internen Stakeholdern auf [24].

Was schiefgeht: Externe Stakeholder — vor allem Kunden — werden am Anfang befragt (Interviews) und am Ende getestet (Pilot). Der gesamte Mittelteil des Designprozesses, in dem die eigentlichen Entscheidungen fallen, bleibt ein interner Prozess. Das Ergebnis: Der Service wird für die interne Logik optimiert, nicht für den Kunden.

Was stattdessen tun: Mindestens einen externen Stakeholder in der Develop-Phase als aktiven Mitgestalter einbinden — nicht als Testperson, sondern als Co-Designer. IBMs “Sponsor Users” sind ein bewährtes Format: echte Nutzer, die dauerhaft in die Design-Teams eingebettet sind und kontinuierlich Feedback geben [25].

Fehler 4: Den Facilitator als neutral betrachten

Warum es passiert: Die Facilitation-Orthodoxie betrachtet den Moderator als neutrale Instanz, die den Prozess steuert, ohne das Ergebnis zu beeinflussen.

Was schiefgeht: Goodwin (2009) beschreibt den Designer als “translator, arbitrator, and negotiator of consensus among the many stakeholders” [31]. Arbitrator und Negotiator sind keine neutralen Rollen. Farr (2018) fand, dass selbst bei dedizierten Co-Design-Prozessen die Entscheidungsmacht letztlich bei den Designern lag [10]. Der Facilitator trifft ständig Mikroentscheidungen: Wer darf wie lange sprechen? Welche Ideen werden auf das Whiteboard geschrieben? Welche werden “geparkt”? Diese Entscheidungen sind nicht neutral — sie formen das Ergebnis.

Was stattdessen tun: Den Facilitator nicht als neutral deklarieren, sondern seine Gestaltungsmacht transparent machen. Explizit benennen: “Meine Rolle ist es, sicherzustellen, dass die Perspektive der Endnutzer nicht von der der Entscheider überrollt wird. Das ist keine neutrale Position — es ist eine bewusste Designentscheidung.”

FAQ — Häufig gestellte Fragen

Wie viele Stakeholder sollte ich maximal in einen Workshop einladen?

Es gibt keine feste Obergrenze, aber die Forschung gibt Hinweise: Daly-Smith et al. arbeiteten erfolgreich mit 50 Stakeholdern in 9 Gruppen [22], Kerr et al. mit über 200 Stakeholdern in 4 Gruppen [21]. Der Schlüssel ist nicht die absolute Zahl, sondern die Strukturierung: Arbeite in homogenen Stakeholder-Gruppen und synthetisiere die Ergebnisse, statt alle in einen Raum zu setzen. collaboratio helvetica empfiehlt zwei Facilitatoren als Minimum [30].

Wie gehe ich mit einem Stakeholder um, der den Prozess dominiert?

Das HiPPO-Problem (Highest Paid Person’s Opinion) ist strukturell, nicht persönlich. Drei Gegenmaßnahmen: (1) Schriftliche Einzelbeiträge vor der Gruppendiskussion einsammeln — das verhindert Ankereffekte [11]. (2) Consent-basierte Entscheidungsfindung statt Konsens — Einwände müssen begründet werden, Meinungen nicht [18][19]. (3) Externe Facilitation, die hierarchische Dynamiken bewusst adressiert [11].

Funktioniert Multi-Stakeholder Design auch bei internen Dienstleistungen (nicht B2B)?

Ja. Das Buying Committee ist der B2B-spezifische Auslöser, aber die Strukturprobleme (Rollenmyopie, HiPPO, Design by Committee) treten bei jeder Dienstleistung auf, die mehrere Abteilungen betrifft. Wenn du ein internes HR-Portal gestaltest, hast du dieselben Konflikte: HR will Self-Service, IT will Standardisierung, Betriebsrat will Datenschutz, Management will Kostensenkung.

Wann sollte ich Stakeholder bewusst ausschließen?

Drei Kriterien: (1) Wenn ihre Beteiligung tokenistisch wäre — du kannst oder willst ihren Input nicht berücksichtigen [27]. (2) Wenn ihre Anwesenheit andere Stakeholder daran hindert, ehrlich zu sprechen (Machtgefälle) — dann nutze Conflict Sensitive Design mit getrennten Sitzungen [23]. (3) Wenn ihre Salienz in der aktuellen Phase niedrig ist — plane sie für eine spätere Phase ein [17].

Methodik & Quellenangabe

Dieser Artikel basiert auf einer systematischen Auswertung von 30 direkt zitierten Quellen: 10 akademische Studien (peer-reviewed), 7 Bücher, 2 Industrieberichte (Forrester n=16.000+, Gartner n=632), und 11 Praxis- und Kontextquellen. Alle DOIs und URLs wurden vor Aufnahme verifiziert. Die SERP-Analyse umfasste 10 Wettbewerberartikel in Deutsch und Englisch.

Praxis-Einschätzungen, die über die zitierten Quellen hinausgehen, basieren auf der operativen Erfahrung mit holakratischen Governance-Formaten, die wir in der Einleitung zu Abschnitt 6 offenlegen.

Limitationen: Die Forrester- und Gartner-Statistiken beziehen sich auf globale B2B-Einkäufe; DACH-spezifische Abweichungen sind möglich. Wir verwenden holakratische Facilitation-Formate intern seit 2017; ihre systematische Anwendung in externen Service-Design-Workshops ist bisher weder in peer-reviewed Studien dokumentiert noch haben wir eigene Wirksamkeitsdaten publiziert. Jonas et al. (2016) untersuchten drei Mittelstandsunternehmen — die Generalisierbarkeit auf den gesamten Mittelstand ist begrenzt.

Offenlegung

SI Labs berät Unternehmen bei der Gestaltung von Dienstleistungen. Wir haben ein kommerzielles Interesse an den in diesem Artikel beschriebenen Methoden. In Abschnitt 6 haben wir unsere Erfahrungen mit holakratischen Governance-Formaten offengelegt und markiert. Darüber hinaus haben wir uns bemüht, alle Empfehlungen auf publizierte Quellen zu stützen und die Grenzen der Ansätze ehrlich zu benennen (siehe “Wann du NICHT alle Stakeholder einbeziehen solltest” und “Häufige Fehler”).

Quellenverzeichnis

[1] Forrester. The State of Business Buying, 2024. Forrester Research, 2024. n=16.000+ globale B2B-Einkäufer. URL: https://www.forrester.com/press-newsroom/forrester-the-state-of-business-buying-2024/ [Industry Report | n=16.000+ | Quality: High]

[2] Gartner. “74% of B2B Buyer Teams Demonstrate ‘Unhealthy Conflict’ During the Decision Process.” Gartner Press Release, 7. Mai 2025. n=632 B2B-Einkäufer (Aug-Sep 2024). URL: https://www.gartner.com/en/newsroom/press-releases/2025-05-07-gartner-sales-survey-finds-74-percent-of-b2b-buyer-teams-demonstrate-unhealthy-conflict-during-the-decision-process [Industry Report | n=632 | Quality: High]

[3] Freeman, R. Edward. Strategic Management: A Stakeholder Approach. Boston, MA: Pitman, 1984. [Book | Foundational — coined “stakeholder” concept | Quality: High]

[4] Mager, Birgit. “Service Design.” Service Design Network, 2012. URL: https://www.service-design-network.org/about-service-design [Expert Source | First SD Professor worldwide (1995), TH Köln (KISD) | Quality: High]

[5] Sanders, Elizabeth B.-N. und Pieter Jan Stappers. “Co-creation and the New Landscapes of Design.” CoDesign: International Journal of CoCreation in Design and the Arts 4, Nr. 1 (2008): 5—18. DOI: 10.1080/15710880701875068 [Academic Article | Citations: 24.500+ | Quality: High]

[6] Stickdorn, Marc, Markus Edgar Hormess, Adam Lawrence und Jakob Schneider. This Is Service Design Doing: Applying Service Design Thinking in the Real World. O’Reilly Media, 2018. ISBN: 978-1491927182. [Practitioner Book | 54 Methods | Quality: High]

[7] Webster, Frederick E. und Yoram Wind. “A General Model for Understanding Organizational Buying Behavior.” Journal of Marketing 36, Nr. 2 (1972): 12—19. DOI: 10.1177/002224297203600204 [Academic Article | Foundational — Buying Center model | Quality: High]

[9] Flaig, Alexander, Hugo Guyader und Mikael Ottosson. “Design-Oriented Stakeholder Engagement in Service Ecosystems.” Journal of Business Research 191 (2025): Article 115255. DOI: 10.1016/j.jbusres.2025.115255 [Academic Article | Open Access (CC BY 4.0) | Quality: High]

[10] Farr, Michelle. “Power Dynamics and Collaborative Mechanisms in Co-production and Co-design Processes.” Critical Social Policy 38, Nr. 4 (2018): 623—644. DOI: 10.1177/0261018317747444 [Academic Article | Longitudinal qualitative study | Quality: High]

[11] Spark Market Research. “Raising the Bar in Stakeholder Workshops.” Spark MR Blog. URL: https://sparkmr.com/raising-the-bar-in-stakeholder-workshops/ [Practitioner Source | Quality: Medium]

[12] Riddle, Ryan Thomas und Marcin Treder. “Design by Committee.” UXPin, zitiert via ProductPlan. URL: https://www.productplan.com/learn/how-to-avoid-design-by-committee/ [Practitioner Source | Quality: Medium]

[13] InnerView. “Design by Committee: Why It Fails and How to Avoid It.” URL: https://innerview.co/blog/design-by-committee-why-it-fails-and-how-to-avoid-it [Practitioner Source | Quality: Medium]

[14] LogRocket UX Blog. “Design by Committee Failure.” URL: https://blog.logrocket.com/ux-design/design-by-committee-failure/ [Practitioner Source | Quality: Medium]

[15] Von Busch, Otto und Karl Palmas. The Corruption of Co-Design: Political and Social Conflicts in Participatory Design Thinking. London: Routledge, 2022. ISBN: 978-1032250014. [Academic Book | Contrarian/Critical source | Quality: High]

[16] Mitchell, Ronald K., Bradley R. Agle und Donna J. Wood. “Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What Really Counts.” Academy of Management Review 22, Nr. 4 (1997): 853—886. DOI: 10.5465/amr.1997.9711022105 [Academic Article | Foundational — Stakeholder salience theory | Quality: High]

[17] Lievens, Annouk und Vera Blazevic. “A Service Design Perspective on the Stakeholder Engagement Journey during B2B Innovation: Challenges and Future Research Agenda.” Industrial Marketing Management 95 (2021): 128—141. DOI: 10.1016/j.indmarman.2021.04.007 [Academic Article | B2B-specific | Quality: High]

[18] Sociocracy For All. “Consent Decision Making.” URL: https://www.sociocracyforall.org/consent-decision-making/ [Practitioner Source | Quality: Medium]

[19] Sociocracy 3.0. “Consent Decision-Making Pattern.” URL: https://patterns.sociocracy30.org/consent-decision-making.html [Practitioner Source | Quality: Medium]

[20] Holacracy.org. “Values Integration via the Integrative Decision-Making Process.” URL: https://www.holacracy.org/blog/values-integration-via-the-integrative-decision-making-process/ [Practitioner Source | Quality: Medium]

[21] Kerr, Jemma, Megan Whelan, Oksana Zelenko, Karen Harper-Hill und Catherine Villalba. “Integrated Co-design: A Model for Co-designing with Multiple Stakeholder Groups from the ‘Fuzzy’ Front-End to beyond Project Delivery.” International Journal of Design 16, Nr. 2 (2022): 75—90. DOI: 10.57698/v16i2.06 [Academic Article | Open Access | Quality: High]

[22] Daly-Smith, Andy, Thomas Quarmby, Victoria S. J. Archbold et al. “Using a Multi-stakeholder Experience-based Design Process to Co-develop the Creating Active Schools Framework.” International Journal of Behavioral Nutrition and Physical Activity 17 (2020): 13. DOI: 10.1186/s12966-020-0917-z [Academic Article | Open Access | n=50 Stakeholder, 9 Gruppen | Quality: High]

[23] Ogunyemi, Abiodun et al. “How Should We Design Technology with Diverse Stakeholders Who Wish Not to Attend Design Activities Together?” In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems. ACM, 2025. DOI: 10.1145/3706598.3714168 [Academic Article | CHI 2025 | Quality: High]

[24] Jonas, Julia M., Angela Roth und Kathrin M. Möslein. “Stakeholder Integration for Service Innovation in German Medium-Sized Enterprises.” Service Science 8, Nr. 3 (2016): 320—332. DOI: 10.1287/serv.2016.0152 [Academic Article | DACH-specific | Quality: High]

[25] IBM. “Enterprise Design Thinking Framework.” URL: https://www.ibm.com/design/approach/design-thinking/ [Practitioner Source | Enterprise-scale | Quality: High]

[26] Reypens, Charlotte, Annouk Lievens und Vera Blazevic. “Hybrid Orchestration in Multi-stakeholder Innovation Networks: Practices of Mobilizing Multiple, Diverse Stakeholders across Organizational Boundaries.” Organization Studies 42, Nr. 1 (2021): 61—83. DOI: 10.1177/0170840619868268 [Academic Article | EMIF case study, 57 partners, 14 countries | Quality: High]

[27] Johansson, Stefan, Per-Olof Hedvall, Mia Larsdotter, Thomas P. Larsson und Catharina Gustavsson. “Co-Designing with Extreme Users: A Framework for User Participation in Design Processes.” Scandinavian Journal of Disability Research 25, Nr. 1 (2023): 418—430. DOI: 10.16993/sjdr.952 [Academic Article | Open Access | Quality: High]

[28] Hodson, Elise, Annukka Svanda und Nastaran Dadashi. “Whom Do We Include and When? Participatory Design with Vulnerable Groups.” CoDesign 19, Nr. 4 (2023): 269—286. DOI: 10.1080/15710882.2022.2160464 [Academic Article | Quality: High]

[29] Hyysalo, Sampsa und Tomás Dorta. “Design Participation and Codesign: New Forms, Application Domains, and Representational Systems.” Designing 1, Nr. 1 (2025): 24—31. DOI: 10.1177/30497671251392167 [Academic Article | Quality: High]

[30] collaboratio helvetica. “Multi-Stakeholder Workshops.” Blog, 27. Juli 2021. URL: https://collaboratiohelvetica.ch/en/blog/27/07/2021/multi-stakeholder-workshops-bxxrz [Practitioner Source | DACH | Quality: Medium]

[31] Goodwin, Kim. Designing for the Digital Age: How to Create Human-Centered Products and Services. Wiley, 2009. ISBN: 978-0470229101. 740 Seiten. [Practitioner Book | Enterprise design | Quality: High]