Klare Verantwortlichkeiten dank RACI-Matrix

Geteilte Verantwortlichkeit ist ein häufiges Problem in Projekten. Dabei vertrete ich die Meinung, dass, wenn zwei Personen verantwortlich ist, keiner verantwortlich ist. Die RACI-Matrix, auch Verantwortlichkeitsmatrix genannt, ist ein Werkzeug im Projektmanagement, das die Rollen und Verantwortlichkeiten der Beteiligten für die einzelnen Projektaufgaben oder -entscheidungen klärt. Sie stellt sicher, dass für jede Aufgabe klar ist, wer was zu tun hat, und hilft so, Missverständnisse, Doppelarbeit und Kommunikationsprobleme zu vermeiden.

RACI-Matrix leicht gemacht

Die RACI-Matrix ermöglicht eine schnelle und visuelle Übersicht über die Verantwortlichkeiten. Sie sollte zu Beginn eines Projekts erstellt und bei Bedarf aktualisiert werden. Jeder Buchstabe des Akronyms RACI steht für eine spezifische Rolle:

R – Responsible (Verantwortlich): Die Person, die die Aufgabe ausführt. Es können auch mehrere Stakeholder bzw. Personen für eine Aufgabe verantwortlich sein. Wobei ich empfehle, pro Stakeholder immer nur eine Person zu nominieren, die dann die Inputs von anderen einholt.

A – Accountable (Rechenschaftspflichtig): Die Person, die die Gesamtverantwortung für die Fertigstellung und Qualität der Aufgabe trägt. Diese Person nimmt die Aufgabe ab, ohne ihre Zustimmung kann die Aufgabe nicht abgeschlossen werden. Es kann nur eine Person pro Aufgabe rechenschaftspflichtig sein.

C – Consulted (Konsultiert): Personen, deren Input oder fachliche Meinung vor der Fertigstellung der Aufgabe eingeholt werden muss. Die Kommunikation erfolgt in der Regel in zwei Richtungen.

I – Informed (Informiert): Personen, die über den Fortschritt oder die Fertigstellung der Aufgabe auf dem Laufenden gehalten werden müssen. Die Kommunikation erfolgt nur in eine Richtung. Diese Personen geben keinen Input.

Beispiel Vertrag

Die RACI-Matrix funktioniert bei der Vertragsverhandlung genauso gut wie im Projekt selbst. Bei der Erstellung des Vertrages hilft die RACI-Matrix dabei, die Verantwortlichkeiten der beiden Parteien zu klären.

Produkt	Lieferobjekte	Kunde	Lieferant
PM / PMO	Definition von Roadmap und Liefermodell für Berichts- und Planungsanforderungen	A, R	C
	Risiko- und Problemmanagement, rechtzeitige Identifizierung von Risiken und Definition von Minderungsmaßnahmen	A, R	C
	Stakeholdermanagement, regelmäßige Kommunikation und Abstimmung bei Projektentscheidungen	A, R	C
	Ressourcenplanung zur Gewährleistung der Verfügbarkeit von Kernteammitgliedern und Fachexperten vom Kunden	A, R	I
	Ressourcenplanung zur Gewährleistung der Verfügbarkeit von Kernteammitgliedern und Fachexperten vom Lieferanten	I	A, R
	Governance zur Gewährleistung der Abstimmung hinsichtlich der End-to-End-Zeitlinie, der Meilensteine und Abhängigkeiten	A, R	C
	Regelmäßige, transparente Statusberichte, einschließlich Fortschritt, aufgewendeter Aufwand und Risiko/Minderungsmaßnahmen	A	R
Functional Design	Funktionales Design-Dokument zur Spezifizierung der Geschäftsanforderungen	A	R
	Berichtskatalog – Liste der benötigten analytischen SAP Analytics Cloud Stories und Excel-Arbeitsmappen	A	R
	Planungskatalog – Liste der benötigten Planungs-SAP Analytics Cloud Stories und Excel-Arbeitsmappen	A	R
Technical Design and Documentation	Reporting-Mock-ups mit dem Design-Layout und den Schlüsselmerkmalen der zukünftigen Berichte	A	R
	Planungs-Mock-ups mit dem Design-Layout und den Schlüsselmerkmalen der Planungsformulare	A	R
	Technisches Design-Dokument für die Reporting-Lösung	A	R
	Technisches Design-Dokument für die Planungs-Lösung	A	R
Implementation	Bereitstellung einer Reportinglösung mit SAP Datasphere und SAP Analytics Cloud, SAP Analytics Cloud Add-in für Microsoft Excel-Tools, gemäß den vom Kunden vorgegebenen Anforderungen und innerhalb der von beiden Parteien vereinbarten Frist als realisierbar bestätigt.	A, R	R
	Bereitstellung einer Berichtslösung mit SAP Datasphere und SAP Analytics Cloud, SAP Analytics Cloud Add-in für Microsoft Excel-Tools, gemäß den vom Kunden vorgegebenen Anforderungen und innerhalb der von beiden Parteien vereinbarten Frist als realisierbar bestätigt.	A, R	R
	Durchführung von Unit-Tests für die Reporting-Lösung	A, R	R
	Durchführung von Unit-Tests für die Planungslösung	A, R	R
System Integration Test (SIT)	Definition von System-Integrationstest (SIT) Testplan und Testfällen	A, R	R
	Reporting – SIT-Durchführung für jedes vom Kunden spezifizierte Liefer-Element	A, R	R
	Planung – SIT-Durchführung für jedes vom Kunden spezifizierte Liefer-Element	A, R	R
	Definition von Schulungsplan und Schulungsansatz für Reporting und Planung	A	R
User Acceptance Test (UAT)	Definition von UAT (User Acceptance Test) Testplan und Testfällen	A, R	C
	Durchführung der Endanwenderschulung für die Analyselösung	A	R
	Durchführung der Endanwenderschulung für die Planungslösung	A	R
	Reporting – UAT-Durchführung durch den Fachbereich des Kunden	A, R	C
	Planung – UAT-Durchführung durch den Fachbereich des Kunden	A, R	C
	Erzielung einer Freigabe des Fachbereichs für die Reportinglösung	A, R	I
	Erzielung einer Freigabe des Fachbereichs für die Planungslösung	A, R	I
Cutover	Vorbereitung der produktiven Systemumgebung	A, R	C
	Produktivesetzung der Analyselösung	A, R	C
	Produktivesetzung der Planungslösung	A, R	C
Go-Live	Go-Live-Unterstützung des Kundengeschäfts durch die Ausführung der Analyselösung	A, R	C
	Go-Live-Unterstützung des Kundengeschäfts durch die Ausführung der Planungslösung	A, R	C
	Durchführung zusätzlicher / erweiterter Endanwenderschulungen für die Analyselösung	A, R	C
	Durchführung zusätzlicher / erweiterter Endanwenderschulungen für die Planungslösung	A, R	C
Hypercare	Unterstützung des Tagesgeschäfts (BAU)	A, R	R

Beispiel Projekt

Im Projekt werden die Aufgabenbereiche den jeweiligen Personen zugeordnet. Nehmen wir an, wir haben folgende Stakeholder: Sponsor, Supplier, Support, Customer (3S+C) sowie Projekt Manager.

Sponsoren – Das sind diejenigen, die das Projekt finanzieren und sicherstellen möchten, dass es einen Mehrwert im Verhältnis zu den investierten Mitteln liefert.

Supplier – Das sind die Personen, die die Teams repräsentieren, welche die Produkte entwerfen und erstellen werden.

Support – Das sind die Personen, die die Teams repräsentieren, welche die Produkte nach Abschluss des Projekts warten werden.

Customer – Das sind die Personen, die diejenigen repräsentieren, die entweder vom Projekt profitieren oder dessen Produkte nutzen werden.

Supplier können auch Implementation Partner genannt werden, Customer als Business oder Fachbereicht bezeichnet werden. Support wird auch oft Maintenance, BAU (Business As Usual) oder Operations genannt. Am Ende läuft es jedoch immer auf 3S+C aus.

In diesem Fall könnte die RACI-Matrix wie folgt aussehen.

Aktivitäten	Projektmanager [Name einfügen]	Supplier [Name einfügen]	Support [Name einfügen]	Customer [Name einfügen]	Sponsor [Name einfügen]
System Setup	A	C	R	I	I
Spezifikation der Anforderungen	C	R	C	A	I
Technisches Design	C	R	A	C	I
Implementierung (Entwicklung)	A	R	C	C	I
System Integration Testing (SIT)	A	R	C	I	I
Training und Schulung	C	R	I	A	I
User Acceptance Testing (UAT)	C	R	I	A	I
Cut-Over und Go-Live	A	C	R	C	C
Hypercare und Handover	C	R	A	C	I
Change Requests	A	C	C	R	C
Risk Management	A	R	R	R	C

Die jeweiligen Phasen können bei Bedarf noch weiter unterteilt werden, z.B. Implementierung in Data Modelling (Dimensions, Models), Master Data Provisioning, Transactional Data Provisioning, Front-End (Stories und Data Actions).

Bedeutung im Projektalltag

In Projekten wirst du das Wort „accountable“ oft hören. Letztendlich bedeutet es, dass der eigene Ruf auf dem Spiel steht, falls etwas schiefgeht. So könntest du z.B. für eine Aufgabe im Projekt verantwortlich sein, aber der Projektmanager ist rechenschaftspflichtig für dessen Erfolg. Wenn du also einen Fehler machst, trägt der Projektmanager eine Teilschuld, da er deine Arbeit besser kontrollieren sollte.

Das Erwartungsmanagement gegenüber jeder Person in der RACI-Matrix ist entscheidend für die Zusammenarbeit im Projekt. Vor Projektbeginn gilt es genau zu klären, was jeder Buchstabe im Kontext des jeweiligen Projekts bedeutet. Um die Verantwortlichkeit (Responsible) zu klären, könntet ihr fragen: „Mit wem sollte ich daran zusammennarbeiten?“ oder „Wer ist für welchen Teil der Aufgabe zuständig?“. Um die Rechenschaftspflicht (Accountable) zu klären, eignet sich die Frage: „Wer muss diese Arbeit final absegnen?“. Um herauszufinden, wer konsultiert (Consulted) werden muss, frage am besten: „Wessen Meinung oder Perspektive sollte ich einholen?“. Und um die Personen zu identifizieren, die informiert (Informed) werden müssen, kannst du fragen: „Wen sollte ich über den aktuellen Stand auf dem Laufenden halten?“

Wie bereits erwähnt, kann nur eine einzige Person die Rechenschaftspflicht (Accountable) für eine bestimmte Aufgabe tragen. Im Gegensatz dazu können mehrere Beteiligte für die Ausführung (Responsible), die Konsultation (Consulted) oder die Information (Informed) zu derselben Aktivität verantwortlich sein. Es ist auch möglich, dass eine Person sowohl die Rechenschaftspflicht (Accountable) als auch die Ausführung (Responsible) einer Aufgabe übernimmt.

Vorteile des Konzepts

Die RACI-Matrix bietet eine Reihe von Vorteilen für das Projektmanagement. Sie verbessert die Kommunikation maßgeblich, da sie für jede Aufgabe und Entscheidung klar festlegt, welche Rolle die einzelnen Beteiligten spielen. Dadurch werden Missverständnisse reduziert, denn jede Aufgabe hat eine eindeutig definierte rechenschaftspflichtige Person (Accountable), was das Risiko von Verwirrung minimiert. Dies führt zu einer deutlichen Effizienzsteigerung, da Doppelarbeit vermieden und nur die relevanten Personen in Prozesse eingebunden werden. Nicht zuletzt wird die Entscheidungsfindung optimiert, weil die klare Zuweisung der Rechenschaftspflichten den Prozess beschleunigt.