RACI, DACI oder RAPID: was dein Team wirklich braucht

Es gibt eine bestimmte Art von Meeting, an der man erkennt, dass ein Team ein Problem mit Entscheidungsrechten hat. Eine Wahl wurde vor sechs Wochen getroffen. Jemand, der nicht im Raum war, hat seither einen Einwand erhoben, und nun wird die Wahl erneut getroffen, mit einer anderen Gruppe, von vorn. Niemand verhält sich unvernünftig. Es gab einfach nie eine Vereinbarung darüber, wer entscheiden darf.

Drei Frameworks existieren, um dieses Meeting zu verhindern: RACI, DACI und RAPID. Sie sehen austauschbar aus (vier oder fünf Buchstaben, Personen auf Rollen abgebildet) und Teams wählen mehr oder weniger zufällig, meist nach dem, was ein früherer Arbeitgeber benutzt hat. Sie sind nicht austauschbar. Jedes wurde gegen ein anderes Versagen gebaut, und das falsche zu benutzen erzeugt ein Dokument, das bestenfalls Beschäftigung ist.

Die drei Versagensarten

Es hilft, das Versagen zu benennen, gegen das jedes Framework entworfen wurde, denn das ist, was sie tatsächlich unterscheidet.

RACI ist für laufende, verteilte Arbeit. Sein Versagensmodus ist diffuse Eigentümerschaft über viele Aufgaben, das Projekt, in dem zwanzig Dinge laufen und mehrere sich spät als niemandes Sache erweisen.

DACI ist für eine einzelne Entscheidung. Sein Versagensmodus ist die Entscheidung, die nie geschlossen wird, die Wahl, die offen bleibt, weil vorher niemand vereinbart hat, wer sie trifft.

RAPID ist für eine wesentliche, bereichsübergreifende Entscheidung in einer großen Organisation. Sein Versagensmodus ist die Entscheidung, die getroffen und dann rückgängig gemacht wurde, jene, bei der jemand mit echtem Vetorecht wie ein Berater behandelt wurde, das Ergebnis hinterher erfuhr und es wieder aufmachte.

Wenn du benennen kannst, welche dieser drei in deinem Team passiert, hast du dein Framework schon gewählt.

RACI: eine Landkarte laufender Arbeit

RACI weist jeder Aufgabe vier Rollen zu: Responsible (macht die Arbeit), Accountable (steht dafür ein, genau eine Person), Consulted (wird gefragt, bevor es fertig ist) und Informed (erfährt es danach). Das Project Management Institute behandelt das RACI-Diagramm als ein Beispiel einer Responsibility Assignment Matrix, der allgemeinen Familie von Rastern, die Personen auf Arbeitspakete abbilden.

Die Form sagt, wofür es gedacht ist: ein Raster, viele Zeilen, viele Spalten. Es beschreibt einen Arbeitskörper über Zeit, nicht einen Moment. Ein Software-Release, eine Migration, eine Bauphase, ein Audit.

Wo es funktioniert. Immer wenn die Frage lautet: „Wer macht in all dem was?“ Die Matrixform macht zwei Dinge sichtbar, die Prosa nicht kann: die Zeile ohne rechenschaftspflichtige Eigentümerschaft und die Spalte mit Rechenschaftspflicht in jeder Zeile, den Engpass, über den sich alle beschweren und auf den niemand zeigen kann.

Wo es scheitert. RACI hat kein Konzept von wann. Es sagt, der QA-Lead ist für Tests responsible; es sagt nichts darüber, ob getestet wird, bevor oder nachdem freigegeben wird. Es verträgt auch Detailtiefe schlecht: Bei vierzig Zeilen einzelner Aktivitäten wird es ein Dokument, das niemand pflegt, und eine ungepflegte Matrix ist schlimmer als keine, weil Leute ihr vertrauen.

Und bei Einzelentscheidungen ist es wirklich schwach. Man kann eine hineinzwingen (eine Zeile, Buchstaben darüber) aber das Vokabular ist falsch. „Consulted“ unterscheidet nicht zwischen jemandem, dessen Meinung willkommen ist, und jemandem, der dich blockieren kann.

DACI: eine Entscheidung, geschlossen

DACI ersetzt die Buchstaben durch vier Rollen, die auf eine Wahl zielen: Driver (koordiniert den Entscheidungsprozess und hält ihn in Bewegung), Approver (entscheidet, eine Person), Contributors (liefern Fachwissen und Analyse) und Informed (erfahren das Ergebnis). Atlassian veröffentlicht das als Play im Team Playbook und nutzt es intern.

Der wichtige Schritt ist, Driver von Approver zu trennen. In RACI wird oft angenommen, die rechenschaftspflichtige Person sei auch die, die den Prozess treibt. DACI sagt, das sind verschiedene Aufgaben, und bei einer echten Entscheidung sind sie das meistens: Eine Produktmanagerin führt den Prozess, eine Bereichsleitung entscheidet.

Wo es funktioniert. Jede Entscheidung mit Frist und mehr als drei Personen mit Meinung. Einen Anbieter wählen. Zwischen zwei Architekturen entscheiden. Ein Startdatum festlegen. Das Artefakt ist ein einseitiges Dokument, kein Raster, und es endet mit einer aufgeschriebenen Entscheidung und einem Datum.

Wo es scheitert. DACI hat kein Vokabular für Veto. Alle, die nicht Approver sind, sind Contributor, ob hilfsbereiter Entwickler oder Rechtsabteilungsleitung, die das Ganze stoppen kann. In einer kleinen Organisation kann diese Unterscheidung informell bleiben. In einer großen ist sie genau das, was später hochgeht.

Für laufende Arbeit ist es ebenfalls unpassend. Ein DACI pro Entscheidung ist in Ordnung; vierzig DACIs, die ein Projekt beschreiben, sind kein Plan.

RAPID: Entscheidungsrechte in einer großen Organisation

RAPID®, entwickelt von Bain and Company und bekannt geworden durch den Harvard Business Review-Artikel „Who Has the D?“ von Paul Rogers und Marcia Blenko aus 2006, weist fünf Rollen zu: Recommend (analysiert und schlägt vor), Agree (muss zustimmen, ein echtes Veto), Perform (führt die Entscheidung aus), Input (wird konsultiert, ohne Veto) und Decide (die einzige Person, die die Organisation bindet).

Zwei Dinge machen es anders, und beide kommen von den Organisationen, für die es gebaut wurde.

Erstens: Agree ist von Input getrennt. Das ist der ganze Punkt. Die meisten Frameworks haben einen Topf für „Leute, die wir fragen“. RAPID teilt ihn in Leute, deren Zustimmung erforderlich ist, und Leute, deren Meinung erwünscht ist, und zwingt dich, das vorher zu sagen. Das ist die Kontrolle, die verhindert, dass Entscheidungen rückgängig gemacht werden.

Zweitens: Perform ist eine benannte Rolle in der Entscheidung selbst. Die Personen, die mit der Wahl leben müssen, werden benannt, während sie getroffen wird, was die Wahl tendenziell verbessert.

Wo es funktioniert. Wesentliche, bereichsübergreifende Entscheidungen in Organisationen, die groß genug sind, um echtes funktionales Vetorecht zu haben, Preisgestaltung, Markteintritt, eine Plattformfestlegung. Es ist das präziseste der drei.

Wo es scheitert. Es ist schwer. Ein RAPID für eine Entscheidung zu fahren, die eine Person in zehn Minuten hätte treffen können, ist eine Steuer, und Teams, die es überall einführen, hören schnell ganz damit auf. In einer Firma mit zwölf Leuten fällt die Agree-Rolle meist mit der Decide-Rolle zusammen, und dann pflegt man ein Fünf-Buchstaben-Framework für eine Zwei-Buchstaben-Situation.

Direkter Vergleich

Wählen, in drei Fragen

1. Ist das ein Arbeitskörper oder eine Wahl? Ein Arbeitskörper heißt RACI. Eine Wahl heißt DACI oder RAPID. Diese eine Frage klärt die meisten Fälle, und Teams liegen überraschend oft falsch, meist, indem sie eine RACI für etwas bauen, das eine Entscheidung im Projektkostüm war.

2. Kann jemand außerhalb des Raums das stoppen? Wenn ja, und du kannst diese Person nicht einfach entscheiden lassen, brauchst du RAPID, weil du die Agree-Rolle brauchst. Wenn nein, ist DACI leichter und wird tatsächlich benutzt.

3. Liest das in drei Monaten noch jemand? Wenn nein, baue keines davon. Schreibe in einem Satz auf, wer entscheidet, in dem Dokument, in dem die Arbeit lebt. Die Frameworks sind für den Fall, dass die Antwort den Kontakt mit Leuten überleben muss, die nicht dabei waren.

Was keines davon löst

Dazu lohnt Klartext, denn diese Frameworks werden als Heilmittel für Probleme verkauft, die sie nicht berühren.

Sie schaffen keine Befugnis. Jemandes Namen unter Accountable, Approver oder Decide zu schreiben, gibt dieser Person nicht die Macht zu entscheiden. Wenn sie nicht nein sagen und es durchsetzen kann, beschreibt das Dokument eine Organisation, die nicht existiert. Die richtige Reaktion ist, den Namen der Person ins Feld zu schreiben, die nein sagen kann, auch wenn das politisch unbequem ist, diese Unbequemlichkeit ist die Information.

Sie ersetzen keine Entscheidung. Eine fertige Matrix ist keine Entscheidung; sie ist eine Vereinbarung darüber, wer eine trifft. Gelegentlich beenden Teams das Framework, empfinden Fortschritt und treffen die Wahl nie.

Und sie überleben Vernachlässigung nicht. Alle drei sind Momentaufnahmen. Häng sie an das Dokument, das sie regeln, und prüfe sie, wenn du dieses Dokument prüfst. Das Versagen ist nie dramatisch, niemand kündigt an, dass die Matrix jetzt falsch ist. Sie passt einfach still nicht mehr zur Realität, und dann verlässt sich jemand darauf.

Sie benutzen

Alle vier Varianten (RACI, RASCI, DACI und RAPID) sind Modi desselben Dokuments im RACI-Builder. Ein Moduswechsel behält deine Zeilen und benennt die Buchstaben um, es kostet also nichts, eine Entscheidung erst als DACI und dann als RAPID anzusehen, um zu sehen, welches Vokabular zu dem passt, was tatsächlich geschieht.

Wenn du deine erste baust, steht die Methode in eine RACI-Matrix aufbauen, einschließlich des Reihenfolge-Tricks, der die Konflikte früh statt am Ende hochbringt.