Guten Tag, ich habe zu diesem Thema eine Frage: Soll ich als Projektleiter die RASCI-Matrix dem Projekt-Team überhaupt vorstellen? Wenn ja, wann wäre der richtige Zeitpunkt? Währen dem Kick-Off Meeting eines Projektes scheint mir ein bisschen zu früh zu sein, aber in diesem Meeting wird auch über die Kommunikationsart und die Aufgabenverteilung diskutiert. Oder soll ich sie als Projektleiter einfach für mich ganz brav kontinuierlich pflegen und nicht dem Projekt-Team zustellen? Danke im Voraus für Ihre Antwort. PS: Ihre Beiträge sind immer sehr interessant und inspirierend. Bravo und weiter so :-)
@Florindo FALONE Guten Morgen! Ob die Matrix durch den Projektleiter/das Führungsteam "von oben" vorgegeben wird, oder ob Sie gemeinsam mit dem Team oder einer größeren Gruppe von Projektbeteiligten erarbeitet wird, das hängt nicht zuletzt von der Art des Projektes und von der jeweiligen Projekt- und Führungskultur ab. Generell ist es nie schlecht, die Betroffenen zumindest auch zu hören, auch wenn man selbst das letzte Wort hat. Und wie richtig erkannt, kann es in den ersten Meetings noch zu früh sein, um eine hochdetaillierte Matrix zu erstellen, man kann aber auch schon im Kick-Off eine grobe Version erstellen, sofern es für das Projekt voraussichtlich sehr wichtig ist. Diese kann dann im Weiteren verfeinert werden. Vieles in der RACI-Matrix leitet sich dann ja auch aus den anderen Planungsdokumenten zwingend ab, Arbeitspaketverantwortilche z.B.. Anderes ergibt sich erst durch die späteren Entscheidungen, die nicht alle beim Projektleiter liegen. Ich gebe zum Beispiel gern früh eine Matrix vor, in der zumindest alle A vergeben sind, ggf. auch schon einige R, und die sich aus dem Stakeholdermanagement ergebenden C und I. Diese stelle ich dann im Team zur Diskussion und daraus ergeben sich in der Regel Ergänzungen und auch Ungereimtheiten werden aufgedeckt - niemand ist schließlich unfehlbar. Die Matrix ist dann immer für alle einsehbar (sofern nicht Geheimhaltungsgründe dagegen sprechen) und wird im Laufe des Projektes weiterentwickelt und angepasst. Vielen Dank für das Lob :-)
@@projekteleichtgemacht Vielen Dank für Ihre Antwort. Ich habe nun meine Matrix mit "S" für Support ergänzt. Neu RASCI. Nun meine Frage: Wie muss man "S" genau interpretieren? Ich meine ich habe recherchiert und Support bedeutet = "Support, also Personen, die die responsible Person bei der Durchführung einer Aufgabe unterstützen". Nun als Beispiel, wenn ich eine Softwarefunktion durch Keyusers testen lassen muss, sind die Keyusers als "S" in der Matrix zu bezeichnen? Ist das richtig? Oder wie ist es mit dem "S" genau gemeint? Für die beratende Rolle habe ich schon "C" als Consulted definiert. Welche Rolle übernehmen die Keyusers? Danke im Voraus für Ihre Antwort.
@Florindo FALONE Wie ja auch im Video erklärt, kann man die Matrix und die Kategorien auf seine Bedürfnisse hin anpassen. So ist auch das S für Support hinzugekommen. Da also niemand vorschreibt, was eine korrekte Belegung des Begriffes Support ist, ist das die richtige, die im besagten Falle am besten funktioniert/Sinn macht. Wenn die Keyuser aktiv im Projekt mit eingebunden sind und wenn es vor allem auch ein Mapping zwischen der jeweiligen Softwarefunktion und den genau dafür zuständigen spezifischen Keyusern gibt, dann ist es durchaus sinnvoll, diese als "S" in der Matrix zu führen. Funktion F1 hat als "S" dann z.B. die Keyuser K1 und K3, bei F2 sind es die Keyuser K2 und K3 usw. Als Consulted würde ich persönlich dann eher Schlüsselpersonen führen, die nicht aktiv und ständig an der Softwarefunktion mitarbeiten, aber die z.B. spezielle Fachexpertise oder Erfahrung mit ähnlichen Funktionalitäten oder Programmiertechniken haben, oder die im Unternehmen oder beim Kunden für die Einhaltung bestimmter spezifischer Standards zuständig sind. Ebenso könnte bei der Programmierung einer Schnittstelle zwischen zwei Softwarefunktionalitäten die beiden Verantwortlichen für diese Funktionalitäten bei der Schnittstelle als "C" gelistet werden.
![What is a RACI Matrix? [CLEAR BREAKDOWN]](http://i.ytimg.com/vi/dyoOIIaACcE/mqdefault.jpg)
Gutes Verständliches Video!
Pragmatische Erläuterung - fehlt in einem aktuellen Projekt - werde ich mal ausprobieren!
Super. Nur durch Ausprobieren findet man seinen idealen Weg. Vielleicht zeigen sich ja Vorteile, die man ab da nicht mehr missen möchte :-)
Guten Tag, ich habe zu diesem Thema eine Frage: Soll ich als Projektleiter die RASCI-Matrix dem Projekt-Team überhaupt vorstellen? Wenn ja, wann wäre der richtige Zeitpunkt? Währen dem Kick-Off Meeting eines Projektes scheint mir ein bisschen zu früh zu sein, aber in diesem Meeting wird auch über die Kommunikationsart und die Aufgabenverteilung diskutiert. Oder soll ich sie als Projektleiter einfach für mich ganz brav kontinuierlich pflegen und nicht dem Projekt-Team zustellen? Danke im Voraus für Ihre Antwort. PS: Ihre Beiträge sind immer sehr interessant und inspirierend. Bravo und weiter so :-)
@Florindo FALONE Guten Morgen! Ob die Matrix durch den Projektleiter/das Führungsteam "von oben" vorgegeben wird, oder ob Sie gemeinsam mit dem Team oder einer größeren Gruppe von Projektbeteiligten erarbeitet wird, das hängt nicht zuletzt von der Art des Projektes und von der jeweiligen Projekt- und Führungskultur ab.
Generell ist es nie schlecht, die Betroffenen zumindest auch zu hören, auch wenn man selbst das letzte Wort hat. Und wie richtig erkannt, kann es in den ersten Meetings noch zu früh sein, um eine hochdetaillierte Matrix zu erstellen, man kann aber auch schon im Kick-Off eine grobe Version erstellen, sofern es für das Projekt voraussichtlich sehr wichtig ist. Diese kann dann im Weiteren verfeinert werden. Vieles in der RACI-Matrix leitet sich dann ja auch aus den anderen Planungsdokumenten zwingend ab, Arbeitspaketverantwortilche z.B.. Anderes ergibt sich erst durch die späteren Entscheidungen, die nicht alle beim Projektleiter liegen.
Ich gebe zum Beispiel gern früh eine Matrix vor, in der zumindest alle A vergeben sind, ggf. auch schon einige R, und die sich aus dem Stakeholdermanagement ergebenden C und I. Diese stelle ich dann im Team zur Diskussion und daraus ergeben sich in der Regel Ergänzungen und auch Ungereimtheiten werden aufgedeckt - niemand ist schließlich unfehlbar.
Die Matrix ist dann immer für alle einsehbar (sofern nicht Geheimhaltungsgründe dagegen sprechen) und wird im Laufe des Projektes weiterentwickelt und angepasst.
Vielen Dank für das Lob :-)
@@projekteleichtgemacht Vielen Dank für Ihre Antwort. Ich habe nun meine Matrix mit "S" für Support ergänzt. Neu RASCI. Nun meine Frage: Wie muss man "S" genau interpretieren? Ich meine ich habe recherchiert und Support bedeutet = "Support, also Personen, die die responsible Person bei der Durchführung einer Aufgabe unterstützen". Nun als Beispiel, wenn ich eine Softwarefunktion durch Keyusers testen lassen muss, sind die Keyusers als "S" in der Matrix zu bezeichnen? Ist das richtig? Oder wie ist es mit dem "S" genau gemeint? Für die beratende Rolle habe ich schon "C" als Consulted definiert. Welche Rolle übernehmen die Keyusers? Danke im Voraus für Ihre Antwort.
@Florindo FALONE Wie ja auch im Video erklärt, kann man die Matrix und die Kategorien auf seine Bedürfnisse hin anpassen. So ist auch das S für Support hinzugekommen. Da also niemand vorschreibt, was eine korrekte Belegung des Begriffes Support ist, ist das die richtige, die im besagten Falle am besten funktioniert/Sinn macht.
Wenn die Keyuser aktiv im Projekt mit eingebunden sind und wenn es vor allem auch ein Mapping zwischen der jeweiligen Softwarefunktion und den genau dafür zuständigen spezifischen Keyusern gibt, dann ist es durchaus sinnvoll, diese als "S" in der Matrix zu führen. Funktion F1 hat als "S" dann z.B. die Keyuser K1 und K3, bei F2 sind es die Keyuser K2 und K3 usw.
Als Consulted würde ich persönlich dann eher Schlüsselpersonen führen, die nicht aktiv und ständig an der Softwarefunktion mitarbeiten, aber die z.B. spezielle Fachexpertise oder Erfahrung mit ähnlichen Funktionalitäten oder Programmiertechniken haben, oder die im Unternehmen oder beim Kunden für die Einhaltung bestimmter spezifischer Standards zuständig sind. Ebenso könnte bei der Programmierung einer Schnittstelle zwischen zwei Softwarefunktionalitäten die beiden Verantwortlichen für diese Funktionalitäten bei der Schnittstelle als "C" gelistet werden.
@@projekteleichtgemacht Vielen Dank für Ihre Antwort. Werde ich so implementieren und ausprobieren. Gruss.
@@falonef Gern geschehen! Wenn wir auch auch diesmal etwas spät geantwortet haben!