I sin artikel "Hur man förvandlar ett misslyckat projekt till ett framgångsrikt program", Shay Shargal noterade att en av anledningarna till att projekt misslyckas är att "Dålig kommunikation och samordning mellan projektets olika intressenter: Kunder, leverantörer, leverantörer, chefer, resurser och andra."
När kommunikationen bryts ner och uppfattningarna om roller och ansvar är felanpassade blir arbetssättet ofta ett "skuldspel" där upptrappningar är "business as usual". I den här artikeln vill jag dela med mig av användningen av RACIVS-matrisen (även känd som RACIVS-matrisen). Matris för ansvarsfördelning). Många projektledare har hört talas om denna projektledningsteknik, men dess värde underskattas i allmänhet. Att använda RACIVS är ett utmärkt sätt att beskriva roller och ansvarsområden för intressenter i samband med specifika leveranser (eller aktiviteter) och det kommer att hjälpa dig att förebygga dålig kommunikation och samordning.
Så här gör du för att använda den. Lista de leverabler som finns i projektplanens avsnitt om leverabler i en matris. RACIVS-elementen ska fyllas i för varje leveransobjekt. Detta är vad RACIVS står för:
- Ransvarig: den person eller part som är ansvarig för att skapa leveransen, dvs. utföra det faktiska arbetet.
- Accountable: den person eller part som är ansvarig för att skapa leveransen, dvs. den person/part som du kan vända dig till om arbetet inte blir gjort. Observera: det kan bara finnas en ansvarig per leveransobjekt!
- Consulted: den person eller part som aktivt kommer att konsulteras i samband med skapandet av detta resultat.
- Informed: den person eller part som kommer att informeras om (slut)resultaten.
- Verifies: den person eller part som granskar resultatet och som råder undertecknaren att acceptera/förkasta resultatet.
- Signs-Off: den person eller part som kommer att godkänna leveransen.
Låt oss tänka på en användarhandbok. Vi skulle kunna ange följande i projektplanen: Eftersom användarhandboken måste levereras inom projektet är projektledaren ansvarig för att handboken blir klar. Den ledande konstruktören i projektgruppen kommer att skriva handboken, med aktiv medverkan av nyckelanvändarna. Helpdesk informeras (eftersom de måste vara medvetna om att manualen finns) och i slutet kommer nyckelanvändarna att granska manualen och ge ett godkännande till den äldre användaren, som sedan kan godkänna användarhandboken.
Det är många meningar! Vi kan mer effektivt ange samma information i en RACIVS-matris, där intressenterna anges i lämplig RACIVS-kolumn för varje leveransobjekt:
Resultat | R | A | C | I | V | S |
| Användarhandbok | Senior designer | Projektledare | Nyckelanvändare | Helpdesk | Nyckelanvändare | Högre användare |
Ser du hur kraftfull en RACIVS-matris kan vara? Om du har ett begränsat antal intressenter (eller om du arbetar med team) kan det också vara bättre att lista intressenterna i kolumnerna och bara ange R, A, C, I, V eller S (eller en kombination av dessa) i intressentcellerna för varje leveransobjekt:
Resultat | Utvecklingsteam | Kund | Viktiga användare |
| Användarhandbok | RA | IS | CV |
Experimentera med vad som fungerar bäst för dig. Observera att RACIVS-element inte alltid behöver tilldelas. Du kan till exempel använda detta för att klargöra att vissa leveranser inte behöver godkännas formellt.
Att använda RACIVS-tekniken kan tyckas vara lite omständligt, men det kommer faktiskt att bespara dig en hel del diskussioner om "vem som borde ha gjort arbetet från början". Jag bjuder in dig att använda den här tekniken i din nästa projektplan och är nyfiken på att höra om dina erfarenheter.
