Was ist eine RACI-Matrix? Definition, Vorlage & Beispiele (2026)
Der vollständige Leitfaden zur Rollenklärung, Vermeidung von Missverständnissen und zum erfolgreichen Projektabschluss ohne unerwartete Hindernisse
Was ist eine RACI-Matrix?
Eine RACI-Matrix ist eine Verantwortlichkeitsmatrix, die jede Aufgabe in einem Projekt den Personen zuordnet, die diese Arbeit ausführen, abnehmen, beratend unterstützen oder darüber informiert werden. Das Akronym steht für Responsible (Durchführungsverantwortung), Accountable (Rechenschaftspflicht), Consulted (Beratung) und Informed (Information) – vier verschiedene Ebenen der Beteiligung, die bei korrekter Zuweisung die häufigste Ursache für das Scheitern von Projekten eliminieren: Unklarheit darüber, wer was tut.
RACI-Matrizen werden typischerweise als Raster dargestellt. Aufgaben oder Ergebnisse werden in den Zeilen auf der linken Seite aufgelistet, Rollen oder namentlich genannte Personen in den Spalten am oberen Rand. An jedem Schnittpunkt zeigt ein einzelner Buchstabe – R, A, C oder I – die Beteiligung dieser Person an der Aufgabe an. Das Ergebnis ist eine einseitige Visualisierung, die für jeden Arbeitsschritt die vier Fragen beantwortet, die ein Projektmanager am häufigsten hört: Wer macht das, wer genehmigt es, wer muss einbezogen werden und wer muss informiert werden?
Das Framework entstand in den 1950er Jahren im industriellen Prozessmanagement und wurde in den 1980er Jahren vom Project Management Institute als Projektmanagement-Tool formalisiert. Heute wird es in der Softwareentwicklung, im Bauwesen, im Gesundheitswesen, im Marketing, in der Fertigung, in der Verwaltung und in der Beratung eingesetzt. Moderne Varianten sind RACIO (zusätzlich „Out of the loop“), RASCI (zusätzlich „Support“) und DACI (Driver, Approver, Contributor, Informed für entscheidungsorientierte Arbeit) – doch die ursprüngliche RACI-Matrix bleibt die am weitesten verbreitete und gelehrte Form.
Eine gut aufgebaute RACI-Matrix verwandelt implizite Annahmen über Zuständigkeiten in explizite, dokumentierte Verpflichtungen. Wenn ein Stakeholder fragt, warum etwas schiefgelaufen ist, können Sie auf die Matrix verweisen und ein präzises Gespräch darüber führen, wer welche Rolle innehatte und wo der Fehler lag. Ohne eine RACI-Matrix artet dasselbe Gespräch oft in gegenseitige Schuldzuweisungen und widersprüchliche Erinnerungen aus.
Was R, A, C und I bedeuten – mit Beispielen
Responsible (R) – Durchführungsverantwortung: Dies ist die Person, die die Arbeit tatsächlich erledigt. Sie schreiben den Code, entwerfen das Dokument, führen die Tests durch oder bauen das Feature. Bei einer einzelnen Aufgabe kann es mehr als eine verantwortliche Person (Responsible) geben – zum Beispiel könnten ein Frontend-Entwickler und ein Backend-Entwickler beide für die Bereitstellung eines Features verantwortlich sein, das beide Ebenen umfasst. In der „Responsible“-Rolle geht es um die Ausführung: Hände an die Tastatur, Hände an die Werkzeuge.
Accountable (A) – Rechenschaftspflicht: Dies ist die einzige Person, die das Endergebnis verantwortet und die Fertigstellung abzeichnet. Dies ist die wichtigste Regel in RACI: Es darf genau eine rechenschaftspflichtige Person pro Aufgabe geben. Wenn zwei Personen „Accountable“ sind, ist es niemand – wenn etwas schiefläuft, wird jeder annehmen, dass der andere sich darum kümmert. Die rechenschaftspflichtige Person kann die Arbeit selbst erledigen oder auch nicht, aber sie ist diejenige, deren Name bei der Auslieferung neben dem Projektergebnis steht und deren Review den nächsten Schritt freigibt. Bei einem Feature-Launch liegt die „Accountable“-Rolle in der Regel beim Produktmanager oder dem technischen Leiter.
Consulted (C) – Konsultation: Dies ist eine Person, deren Input erforderlich ist, bevor die Arbeit finalisiert wird. Consulted-Beziehungen sind zweiseitig – die verantwortliche Person (Responsible) sucht aktiv nach deren Feedback, und diese geben es aktiv zurück. Typische „Consulted“-Rollen sind Fachexperten, Security-Reviewer, Rechtsberater, Designer, die technische Arbeiten prüfen, und Customer-Success-Teams, die bei kundennahen Änderungen beraten. Die Konsultation findet statt, bevor das Ergebnis feststeht, nicht danach.
Informed (I) – Information: Dies ist eine Person, die wissen muss, dass die Arbeit erfolgt ist, aber im Vorfeld keinen Input geben muss. Informed-Beziehungen sind einseitig – sie erhalten Benachrichtigungen oder Zusammenfassungen nach Erreichen wichtiger Meilensteine. Typische „Informed“-Rollen sind Führungskräfte, die den Fortschritt auf Roadmap-Ebene verfolgen, angrenzende Teams, deren Planung von Ihrer abhängt, und Kunden, die Release-Notes erhalten. Die Verwechslung von „Consulted“ mit „Informed“ ist der zweithäufigste RACI-Fehler (nach mehreren Accountable-Verantwortlichen) – dies zieht Personen in Review-Zyklen, an denen sie nicht beteiligt sein sollten.
Ein Beispiel verdeutlicht diese Unterschiede. Betrachten wir die Aufgabe „Authentifizierungsdienst in Produktion bereitstellen“. Der Senior-Backend-Entwickler ist Responsible, da er das Deployment tatsächlich durchführt. Der Engineering Manager ist Accountable, da er den Launch abzeichnet und für etwaige Produktionsvorfälle verantwortlich ist. Der Security-Architekt wird Consulted, da seine Überprüfung des Authentifizierungs-Flows vor dem Deployment erforderlich ist. Das Customer-Support-Team wird Informed, da es über das Deployment informiert werden muss, um Kundenfragen beantworten zu können, den Prozess aber nicht blockiert. Vier Rollen, vier Beteiligungsebenen, null Unklarheit.
Wann man eine RACI-Matrix einsetzt (und wann nicht)
RACI-Matrizen sind am wertvollsten bei fachübergreifenden Projekten, bei denen mehrere Teams oder Rollen koordiniert werden müssen, um ein Projektergebnis zu liefern. Der klassische Auslöser ist die Frage „Wer ist dafür zuständig?“, wenn diese in einem einzigen Meeting mehr als einmal gestellt wird. Wenn Ihr Team in Echtzeit über Zuständigkeiten diskutiert, wird sich eine RACI-Matrix innerhalb einer Woche amortisieren.
Verwenden Sie eine RACI-Matrix für neue Projektstarts, größere Feature-Releases, organisatorische Umstrukturierungen, Compliance- und Audit-Programme, das Onboarding von Anbietern und alle Initiativen, an denen fünf oder mehr Personen aus zwei oder mehr Teams beteiligt sind. Die Matrix ist auch beim Onboarding neuer Teammitglieder von unschätzbarem Wert – sie bietet ihnen eine einseitige Übersicht, mit wem sie über was sprechen müssen.
Verzichten Sie auf die RACI-Matrix bei kleinen, klaren Aufgaben innerhalb eines einzelnen Teams. Eine Aufgabe für zwei Personen, bei der beide offensichtlich ihre Rollen kennen, profitiert nicht von einem Vier-Buchstaben-Framework. Der Aufwand für die Erstellung und Pflege der Matrix übersteigt ihren Nutzen, wenn das implizite Verständnis bereits klar ist. Nutzen Sie Ihr Urteilsvermögen: Wenn das Team die Matrix erst erfinden müsste, um sie auszufüllen, ist sie wahrscheinlich das falsche Werkzeug für diese Ebene der Arbeit.
Vermeide RACI-Matrizen bei hochgradig experimentellen Arbeiten, bei denen sich die Rollen berechtigterweise von Woche zu Woche ändern. Forschung und Discovery in frühen Phasen profitieren oft von lockeren Zuständigkeiten, bei denen derjenige, der eine Aufgabe übernimmt, auch die Verantwortung trägt. Eine zu frühe Festlegung von Rollen kann die Art der opportunistischen Ausführung unterdrücken, von der explorative Arbeit abhängt. Nutzen Sie RACI erst, wenn sich die Arbeit in einem strukturierten Projektplan mit Ergebnissen und Terminen stabilisiert hat.
Wie Sie eine RACI-Matrix in 7 Schritten erstellen
Schritt 1: Listen Sie jedes Projektergebnis, jede Aufgabe oder Entscheidung im Projekt auf. Gehen Sie so detailliert vor, dass jede Zeile eine Arbeitseinheit darstellt, die einer bestimmten Person zugewiesen werden kann – in der Regel ein Aufwand von ein bis zwei Wochen. Vermeiden Sie vage Zeilen wie „Projektmanagement“ oder „Kommunikation“; verwenden Sie stattdessen spezifische Punkte wie „Endgültiges Budget genehmigen“ oder „Lieferantenvertrag unterzeichnen“. Ein typisches mittelgroßes Projekt umfasst 15 bis 40 Zeilen.
Schritt 2: Listen Sie alle Rollen oder Namen oben in der Tabelle auf. Verwenden Sie Rollen, wenn das Team groß ist und Personen wechseln können (Projektmanager, technischer Leiter, Designer, QA-Leiter). Verwenden Sie Namen bei kleinen, stabilen Teams. Beziehen Sie relevante externe Rollen ein – Kunde, Lieferant, Rechtsberatung, externer Prüfer –, damit organisationsübergreifende Übergaben explizit dargestellt werden.
Schritt 3: Identifizieren Sie für jede Zeile die einzelne rechenschaftspflichtige Person (Accountable). Dies ist der schwierigste Schritt bei der RACI-Erstellung und dort, wo die meisten Fehler passieren. Zwingen Sie sich dazu, genau eine Person auszuwählen. Wenn zwei Personen beide rechenschaftspflichtig erscheinen, fragen Sie: Wer erhält die Kalendererinnerung zur Abnahme der endgültigen Version, wenn dieses Ergebnis fertiggestellt ist? Wessen Name steht neben dem Kontrollkästchen für „Abgeschlossen“? Die Antwort ist Ihre rechenschaftspflichtige Person.
Schritt 4: Identifizieren Sie die durchführungsverantwortlichen Personen (Responsible). Es kann mehr als eine geben. Fragen Sie für jede Aufgabe: Wer erledigt die eigentliche Arbeit? Führen Sie alle auf, die die Aufgabe ausführen, nicht nur diejenigen, die die Ausführung leiten. Bei einer UI-Neugestaltung sind sowohl der Designer, der die Mockups erstellt, als auch der Ingenieur, der sie implementiert, durchführungsverantwortlich.
Schritt 5: Identifizieren Sie die zu konsultierenden Parteien (Consulted). Fragen Sie: Wessen Input zwingend erforderlich ist, bevor das Ergebnis finalisiert wird? Seien Sie hier radikal minimalistisch. Jede konsultierte Rolle verlängert die Durchlaufzeit, da die durchführungsverantwortliche Person auf deren Prüfung warten muss. Wenn ein Ergebnis veröffentlicht werden kann, indem eine Person nur informiert statt konsultiert wird, markieren Sie sie als „Informiert“. Der Standard sollte „Informiert“ sein; „Konsultiert“ ist die Ausnahme, die einer Begründung bedarf.
Schritt 6: Identifizieren Sie die zu informierenden Parteien (Informed). Fragen Sie: Wer muss über den Abschluss informiert werden, auch wenn kein Feedback erforderlich ist? Diese Liste ist normalerweise länger als die der zu Konsultierenden. Beziehen Sie Führungskräfte, benachbarte Teamleiter, kundennahe Teams und alle ein, deren Pläne sich mit dem Ergebnis überschneiden.
Schritt 7: Validieren Sie das Diagramm mit dem Team. Gehen Sie es in einer Arbeitssitzung Zeile für Zeile durch. Häufige Fehler, die Sie finden werden: Zeilen ohne rechenschaftspflichtige Person (eine zuweisen), Zeilen mit zwei rechenschaftspflichtigen Personen (verhandeln, wer der tatsächliche Eigentümer ist), Zeilen mit zu vielen konsultierten Personen (einige auf „Informiert“ herabstufen) und Rollen in Spalten, die in keiner Zeile vorkommen (entfernen oder die entsprechende Arbeit hinzufügen). Speichern Sie das Diagramm nach der Validierung an einem für alle zugänglichen Ort und aktualisieren Sie es bei jeder Änderung des Projektumfangs.
Beispiel RACI-Matrix: Software-Produktlaunch
Betrachten wir einen sechswöchigen Software-Produktlaunch mit folgenden Rollen: Produktmanager, technischer Leiter, Designer, QA-Leiter, Marketingmanager, Customer Success Lead und CEO. Die Ergebnisse umfassen die Freigabe des Funktionsumfangs, die Überprüfung des technischen Designs, die Genehmigung des UI-Designs, die Ausführung von Build und Test, die Sicherheitsüberprüfung, den Start des Betaprogramms, den Start der Marketingkampagne und das finale Go-Live.
Bei der Freigabe des Funktionsumfangs ist der Produktmanager rechenschaftspflichtig (Accountable), der technische Leiter und der Designer sind durchführungsverantwortlich (Responsible – sie liefern Input zur Umfangsfestlegung), der CEO wird konsultiert (Consulted – der Launch ist strategisch genug, um Input der Geschäftsführung zum Umfang zu erfordern), und der Marketingmanager sowie der Customer Success Lead werden informiert (Informed).
Bei der Überprüfung des technischen Designs ist der technische Leiter sowohl rechenschaftspflichtig als auch durchführungsverantwortlich (er ist Eigentümer des Designs und erstellt es), der Produktmanager und der QA-Leiter werden konsultiert, und andere Rollen werden informiert. Bei der UI-Design-Genehmigung kehren sich die Verantwortlichkeiten um: Der Designer ist rechenschaftspflichtig, der Produktmanager wird konsultiert und der technische Leiter wird informiert (da er umsetzt, was der Designer spezifiziert, aber das Design nicht freigibt).
Für die Build- und Testphase werden mehrere durchführungsverantwortliche Personen aufgeführt – jeder Ingenieur, der an der Implementierung arbeitet –, während der technische Leiter rechenschaftspflichtig bleibt. Der QA-Leiter ist für den Testanteil durchführungsverantwortlich. Bei der Sicherheitsüberprüfung fungiert ein Sicherheitsarchitekt (als reine Consulted-Spalte zur Rollenliste hinzugefügt) als Gatekeeper, wobei der technische Leiter für die Behebung aller Befunde rechenschaftspflichtig ist.
Die Zeile für das finale Go-Live ist die funktionsübergreifendste im Diagramm: Der Produktmanager ist rechenschaftspflichtig, alle Engineering- und QA-Rollen sind durchführungsverantwortlich, der Marketingmanager und der Customer Success Lead werden konsultiert (ihre Bereitschaft beeinflusst die Go-Live-Entscheidung), und der CEO ist informiert. Hier beweist die Matrix ihren Wert: Wenn der Tag des Launches kommt, weiß jeder genau, welche Freigabe er erteilen muss und wer sein grünes Licht benötigt.
Häufige Fehler bei RACI-Matrizen vermeiden
Mehrere rechenschaftspflichtige Personen sind der häufigste und schädlichste Fehler. Wenn zwei Personen rechenschaftspflichtig sind, wird sich niemand für das Ergebnis verantwortlich fühlen und jeder wird annehmen, dass der andere die Leitung übernimmt. Zwingen Sie sich, genau eine Person zu wählen. Wenn die Arbeit tatsächlich gemeinsam verantwortet wird, teilen Sie sie in zwei Zeilen auf, in denen jede Person für ihre Hälfte rechenschaftspflichtig ist.
Zu viele konsultierte Personen sind der zweithäufigste Fehler. Jede konsultierte Rolle führt zu Tagen oder Wochen des Wartens auf Rückmeldungen. Eine Zeile mit fünf konsultierten Rollen dauert fünfmal länger als eine Zeile mit einer. Überprüfen Sie Ihre Zuweisungen vierteljährlich und stufen Sie alle herab, deren Konsultation das Ergebnis nicht aktiv verändert.
Die Verwechslung von Rollen mit Personen führt zu Instabilität. Wenn in der Matrix steht, dass der technische Leiter für die Sicherheitsüberprüfung rechenschaftspflichtig ist, funktioniert die Matrix auch dann noch, wenn die Person in dieser Rolle wechselt – Sie aktualisieren einfach die Zuordnung von Rolle zu Person. Wenn in der Matrix steht, dass „Sarah“ rechenschaftspflichtig ist, bricht das System zusammen, sobald Sarah das Team wechselt. Verwenden Sie Rollen, wenn das Projekt länger dauert als die Besetzung durch spezifische Personen, und Einzelpersonen, wenn das Projekt kurz und das Team stabil ist.
Veraltete Matrizen führen zu einem schleichenden Scheitern. RACI-Matrizen sind am nützlichsten, wenn sie die aktuelle Realität widerspiegeln, werden aber oft ignoriert, sobald das Projekt Fahrt aufnimmt. Machen Sie es sich zur Gewohnheit, die Matrix bei jedem wichtigen Projektmeilenstein zu überprüfen und zu aktualisieren – bei Phasenübergängen, Umfangsänderungen, Teamzugängen oder -abgängen. Eine zwei Monate alte Matrix, die niemand angefasst hat, ist schlimmer als gar keine Matrix, da sie aktiv in die Irre führt.
Das Überspringen des Validierungsschritts führt dazu, dass sich frühe Fehler fortsetzen. Die erste Version einer RACI-Matrix ist fast immer in Details fehlerhaft. Die Spalte für die Rechenschaftspflicht, die Sie alleine zugewiesen haben, entspricht oft nicht der tatsächlichen Auffassung des Teams über Verantwortlichkeiten. Besprechen Sie die Matrix immer in einer gemeinsamen Arbeitssitzung mit dem Team, bevor Sie sie für final erklären. Die Diskussion selbst macht die Hälfte des Wertes aus – selbst wenn sich keine Zeilen ändern, verlässt das Team das Meeting mit einem gemeinsamen Verständnis darüber, wer was verantwortet.
Kombination von RACI-Matrizen mit Gantt-Diagrammen in Instagantt
RACI-Matrizen beantworten die Frage nach dem „Wer“, während Gantt-Diagramme das „Wann“ klären. Die beiden Tools ergänzen einander und sind keine Alternativen. Ein hervorragender Projektplan umfasst beides: eine RACI-Matrix, die die Zuständigkeiten für jedes Projektergebnis definiert, und ein Gantt-Diagramm, das diese Ergebnisse mit Abhängigkeiten und Meilensteinen in einen Zeitplan einordnet.
In Instagantt können Sie Ihre RACI-Struktur widerspiegeln, indem Sie für jede Aufgabe eine verantwortliche Person als Hauptverantwortlichen (Accountable) festlegen, zusätzliche Beteiligte für „Responsible“ hinzufügen und Kommentare oder Aufgabenbeschreibungen nutzen, um „Consulted“ (Konsultiert) und „Informed“ (Informiert) zu erfassen. Die Gantt-Zeitachse macht die RACI-Zuständigkeiten zeitlich sichtbar: Wenn ein Accountable mehrere Projektergebnisse in derselben Woche hat, markiert die Auslastungsansicht diese, bevor ein Engpass entsteht.
Mit der Snapshot-Funktion von Instagantt können Sie beide Ansichten mit Stakeholdern teilen, ohne ihnen Bearbeitungszugriff zu gewähren. Senden Sie den „Consulted“-Beteiligten einige Tage vor der benötigten Zuarbeit einen Snapshot-Link; senden Sie den „Informed“-Personen eine reine Meilenstein-Ansicht, die sie in Sekunden erfassen können. Die Kombination der RACI-Zuständigkeitsmatrix mit einer Live-Gantt-Zeitachse verwandelt die Projektkommunikation von einem wiederkehrenden Meeting in einen Self-Service-Link.
Für größere Programme ermöglichen es Ihnen die Instagantt-Workbooks, mehrere Projekte in einem einzigen Arbeitsbereich zu gruppieren. Die für jedes Projekt definierten RACI-Rollen werden in einer Portfolio-Ansicht zusammengefasst. Dort sehen Sie beispielsweise, dass dieselbe rechenschaftspflichtige Person (Accountable) in drei gleichzeitigen Projekten auf dem kritischen Pfad liegt. Eine solche projektübergreifende Sichtbarkeit von Zuständigkeiten ist in einer statischen Tabellenkalkulation unmöglich und eines der stärksten Argumente dafür, RACI direkt in einem Projekttool zu verwalten statt parallel dazu.
Nutzen Sie den kostenlosen Tarif von Instagantt, um Ihr erstes RACI-basiertes Gantt-Diagramm zu erstellen. Importieren Sie Ihre Aufgabenliste aus einer Tabelle, weisen Sie Verantwortliche anhand der obigen RACI-Definitionen zu, fügen Sie Abhängigkeiten zwischen den Ergebnissen hinzu und teilen Sie einen öffentlichen Snapshot mit Ihrem Team. Die Kombination aus klarer Zuständigkeit und sichtbarem Zeitplan macht das Diagramm von einem Dokumentationsartefakt zu einem täglichen Planungstool.