Matrice RACI: Cos'è, Come Crearla con Esempi Pratici

Cos'è la matrice RACI

La matrice RACI è uno strumento di project management che definisce in modo chiaro e univoco chi fa cosa all'interno di un progetto. RACI è un acronimo che sta per Responsible, Accountable, Consulted e Informed, e ciascuna lettera rappresenta un livello diverso di coinvolgimento rispetto a un'attività o una decisione.

In pratica, si tratta di una tabella dove le righe rappresentano le attività (o i deliverable) del progetto e le colonne le persone o i ruoli coinvolti. All'incrocio tra riga e colonna trovi una delle quattro lettere (R, A, C, I), che indica il tipo di responsabilità di quella persona su quella specifica attività.

---

I quattro ruoli della matrice RACI spiegati

Capire la differenza precisa tra i quattro ruoli è la chiave per usare la RACI in modo efficace. Vediamoli uno per uno.

R - Responsible (Responsabile dell'esecuzione)

È la persona (o il team) che esegue materialmente il lavoro. Il Responsible è chi mette le mani in pasta: scrive il codice, prepara il documento, costruisce il prototipo. Per ogni attività ci possono essere più Responsible, ma l'ideale è che il numero sia contenuto per evitare confusione.

Esempio: in un progetto software, il developer è Responsible della scrittura del codice. Il graphic designer è Responsible della creazione delle interfacce.

A - Accountable (Responsabile ultimo)

È la persona che ha la responsabilità finale sull'attività e ne risponde in caso di problemi. L'Accountable approva o rifiuta il lavoro del Responsible. La regola d'oro della RACI è che per ogni attività ci deve essere uno e un solo Accountable. Mai zero, mai più di uno.

Esempio: il project manager è Accountable della consegna del progetto. Il team lead è Accountable della qualità del codice prodotto dal team.

C - Consulted (Consultato)

Sono le persone il cui parere viene richiesto prima o durante l'esecuzione dell'attività. La comunicazione con i Consulted è bidirezionale: chiedi il loro input e ne tieni conto. Tipicamente sono esperti di dominio, stakeholder tecnici o figure con esperienza rilevante.

Esempio: prima di definire l'architettura di un sistema, consulti l'architetto software senior e il team di sicurezza. Il loro feedback influenza le decisioni, anche se non sono loro a implementare.

I - Informed (Informato)

Sono le persone che vengono aggiornate sull'avanzamento o sul completamento dell'attività. La comunicazione è unidirezionale: li informi, ma non ti aspetti feedback operativo. Tipicamente sono stakeholder, management o team dipendenti dal risultato dell'attività.

Esempio: il CEO viene informato del completamento di una release. Il team di supporto clienti viene informato di un aggiornamento del prodotto per prepararsi alle domande degli utenti.

---

Perché la matrice RACI è fondamentale nel project management

In teoria, tutti sanno cosa devono fare. In pratica, l'ambiguità sui ruoli è una delle cause più frequenti di problemi nei progetti. La matrice RACI risolve problemi concreti che ogni project manager incontra quotidianamente.

Problemi che la RACI risolve

• L'attività orfana: nessuno se ne occupa perché tutti pensano che lo faccia qualcun altro
• La duplicazione: due persone fanno lo stesso lavoro senza saperlo, sprecando tempo
• Il collo di bottiglia decisionale: troppi approvatori bloccano l'avanzamento
• L'over-communication: tutti vengono coinvolti in tutto, le riunioni durano ore e nessuno legge più le email
• Lo scaricabarile: quando qualcosa va storto, nessuno si assume la responsabilità
• Il micromanagement: senza ruoli chiari, i manager tendono a controllare tutto

I benefici concreti

• Decisioni più veloci: sapendo chi approva cosa, i tempi di attesa si riducono drasticamente
• Comunicazione mirata: informi solo chi deve essere informato, consulti solo chi deve essere consultato
• Onboarding più rapido: un nuovo membro del team capisce immediatamente il suo ruolo guardando la matrice
• Scalabilità: quando il progetto cresce, la RACI mantiene l'ordine che altrimenti si perderebbe
• Gestione dei conflitti: le discussioni su "chi doveva fare cosa" si risolvono consultando la matrice, non discutendo

---

Come creare una matrice RACI passo dopo passo

Passo 1: Elenca le attività

Inizia dalla lista delle attività principali del progetto. Non serve scendere al livello di dettaglio estremo: lavora con le macro-attività o i deliverable. Se hai una WBS (Work Breakdown Structure), usa il secondo livello di scomposizione. Tipicamente una RACI efficace ha tra 10 e 30 righe.

Passo 2: Identifica i ruoli

Elenca tutti i ruoli (non le persone) coinvolti nel progetto. Usa ruoli funzionali come "Tech Lead", "Designer", "Product Owner", "Sponsor" piuttosto che nomi propri. Questo rende la matrice riutilizzabile e meno soggetta a cambiamenti quando le persone cambiano.

Passo 3: Compila la matrice

Per ogni incrocio attività-ruolo, assegna una delle quattro lettere (R, A, C, I) o lascia vuoto se quel ruolo non è coinvolto in quell'attività. Segui queste regole:

• Ogni riga deve avere esattamente un A (mai zero, mai più di uno)
• Ogni riga deve avere almeno un R (qualcuno deve fare il lavoro)
• Limita i C a 1-3 per attività (troppi consulted rallentano tutto)
• Gli I possono essere molteplici, ma chiediti se servono davvero tutti

Passo 4: Verifica la matrice

Dopo aver compilato la matrice, fai queste verifiche:

Verifica	Cosa cercare	Azione correttiva
Verticale (per persona)	Troppe A o R su una persona sola	Ridistribuisci il carico
Orizzontale (per attività)	Nessun A, o più di un A	Assegna un unico Accountable
Colonne vuote	Un ruolo senza nessuna assegnazione	Chiediti se serve davvero nel progetto
Righe piene	Tutti coinvolti in un'attività	Riduci i C e I non necessari
Nessun R	Attività senza esecutore	Assegna chi fa materialmente il lavoro

Passo 5: Condividi e ottieni il buy-in

Una RACI imposta dal project manager senza il consenso del team non funziona. Condividi la bozza con tutti gli stakeholder, raccogli feedback e assicurati che ogni persona concordi con le responsabilità assegnate. La matrice deve essere un contratto sociale condiviso, non un documento calato dall'alto.

---

Esempi pratici di matrice RACI

Vediamo tre esempi di matrice RACI applicati a contesti diversi, per capire come lo strumento si adatta a settori e complessità differenti.

Esempio 1: Progetto IT - Lancio di una nuova funzionalità

Attività	Product Owner	Tech Lead	Developer	Designer	QA	Sponsor
Definizione requisiti	A	C	I	C	I	I
Design UI/UX	C	C	I	A/R	I	I
Architettura tecnica	I	A/R	C		C
Sviluppo backend	I	A	R		I
Sviluppo frontend	I	A	R	C	I
Testing	I	C	C		A/R
Code review		A/R	R
Deploy in produzione	A	R	C		C	I
Comunicazione rilascio	A/R	I				I

In questo esempio nota come il Product Owner sia Accountable per le attività business-critical (requisiti, deploy, comunicazione), mentre il Tech Lead è Accountable per le attività tecniche (architettura, sviluppo, code review).

Esempio 2: Campagna di marketing digitale

Attività	Marketing Manager	Copywriter	Graphic Designer	Social Media Mgr	SEO Specialist	Direttore
Strategia campagna	A/R	C	I	C	C	C
Budget e timeline	A/R					C
Copywriting	A	R	I	C	C
Creatività visual	A	C	R	I
Setup campagne ads	A			R	C
Ottimizzazione SEO	I	C			A/R
Monitoraggio KPI	A			R	R	I
Report finale	A/R			C	C	I

Nota come il Marketing Manager sia Accountable di quasi tutto: è il proprietario del progetto. Ma non è Responsible di tutto, delegando l'esecuzione ai singoli specialisti.

Esempio 3: Progetto edilizio - Ristrutturazione

Attività	Committente	Direttore Lavori	Impresa	Architetto	Elettricista	Idraulico
Progetto esecutivo	C	C	I	A/R	C	C
Richiesta permessi	A	C		R
Demolizioni	I	A	R	I
Impianto elettrico	I	A	C	I	R
Impianto idraulico	I	A	C	I		R
Finiture	C	A	R	C
Collaudo	I	A/R	C	C	C	C
Accettazione lavori	A/R	C	I	C

Nell'edilizia, il Direttore Lavori è l'Accountable della maggior parte delle attività operative, mentre il Committente ha l'ultima parola sulle decisioni chiave (permessi, accettazione). Questa separazione è anche un obbligo normativo.

---

RACI vs RASCI: quale scegliere

La matrice RASCI (a volte chiamata RACI-VS) aggiunge un quinto ruolo: la S, che sta per Supportive (di supporto). Il Supportive è chi fornisce risorse o assistenza al Responsible, senza essere direttamente responsabile del risultato.

Aspetto	RACI	RASCI
Ruoli	4 (R, A, C, I)	5 (R, A, S, C, I)
Complessità	Bassa	Media
Quando usarla	Progetti standard, team piccoli-medi	Progetti con molte interdipendenze
Vantaggio	Semplicità e chiarezza	Distingue chi aiuta da chi esegue
Rischio	Troppo semplificata per progetti grandi	Troppo complessa per progetti piccoli

In generale, inizia sempre con la RACI classica. Se senti che manca qualcosa, valuta il passaggio a RASCI. Non aggiungere complessità se non è necessaria.

---

Errori comuni nella matrice RACI e come evitarli

La RACI è semplice in teoria, ma nella pratica è facile commettere errori che ne annullano l'efficacia. Ecco i più frequenti.

1. Più di un Accountable per attività

Se due persone sono entrambe Accountable, in realtà nessuno lo è. Quando qualcosa va storto, ognuno pensa che sia responsabilità dell'altro. La regola è ferrea: un solo A per riga, sempre.

2. Troppi Consulted

Consultare molte persone sembra democratico, ma rallenta enormemente i processi. Se per ogni decisione devi aspettare il parere di sei persone, il progetto si ferma. Chiediti: "Il contributo di questa persona è davvero necessario, o è solo un nice-to-have?" Se è un nice-to-have, declassalo a Informed.

3. Confondere R e A

Nei team piccoli, R e A spesso coincidono, e va bene. Ma nei team grandi, questa confusione crea problemi. Il developer che è sia R che A non ha nessuno che verifichi il suo lavoro. Separa i ruoli ogni volta che la dimensione del team lo permette.

4. La RACI nel cassetto

Creare la matrice e non consultarla mai è il modo più sicuro per sprecare tempo. La RACI è un documento vivente: aggiornala quando cambiano i ruoli, i team o le attività. Appendila in un luogo accessibile (wiki del progetto, spazio condiviso) e fai riferimento a essa nelle riunioni.

5. Granularità sbagliata

Una RACI con 200 righe è illeggibile. Una con 3 righe è inutile. Il livello giusto è quello delle macro-attività o dei deliverable: tra 10 e 30 righe per un progetto di media complessità. Se hai bisogno di più dettaglio, crea RACI separate per sotto-progetti.

6. Non coinvolgere il team nella creazione

La RACI imposta unilateralmente dal PM non funziona. Le persone devono concordare sulle proprie responsabilità. Organizza una sessione di lavoro di 30-60 minuti con i ruoli chiave, proietta la matrice e compilatela insieme. Il processo di discussione è quasi più prezioso del documento finale.

---

Integrare la RACI con i software di Project Management

I moderni strumenti di PM non hanno sempre una vista RACI dedicata, ma offrono funzionalità che la rendono implicita nella gestione quotidiana del progetto.

Come implementare la RACI nei tool principali

Software	Implementazione RACI	Approccio consigliato
Jira	Campi custom "Accountable", "Consulted"	Usa i ruoli del progetto + campo personalizzato per A/C/I
Monday.com	Colonne "Person" multiple	Crea colonne separate per R, A, C, I su ogni board
Asana	Assignee (R) + Custom fields	L'assignee è il R; usa custom fields per A, C, I
Trello	Label + Members	I membri della card sono R; usa label colorate per A/C/I
Google Sheets	Matrice nativa	Crea la matrice classica con conditional formatting

L'approccio più pragmatico è usare la RACI come documento di riferimento separato (un foglio Google condiviso o una pagina Confluence) e implementare i ruoli R e A direttamente nel tool di PM tramite i campi assegnatario e approvatore.

---

Quando usare (e quando NON usare) la matrice RACI

Usa la RACI quando:

• Il team è cross-funzionale: persone di dipartimenti diversi che non hanno mai lavorato insieme
• I ruoli si sovrappongono: non è chiaro chi decide cosa, o più persone pensano di avere lo stesso compito
• Il progetto coinvolge stakeholder esterni: fornitori, clienti, consulenti che devono sapere i propri confini
• Ci sono stati conflitti di responsabilità in progetti precedenti: la RACI previene il ripetersi degli stessi problemi
• L'organizzazione è matriciale: le persone riportano a più manager e il rischio di confusione è alto
• Il progetto è regolamentato: settori come farmaceutico, finanziario o edilizio richiedono tracciabilità delle responsabilità

NON usare la RACI quando:

• Il team è molto piccolo (2-3 persone): tutti sanno chi fa cosa, la RACI aggiunge burocrazia senza valore
• Il progetto è breve e semplice: una task list con assignee è sufficiente
• L'organizzazione è piatta e Agile: team auto-organizzati dove i ruoli sono fluidi possono trovare la RACI troppo rigida
• Non hai il buy-in del team: una RACI imposta senza consenso diventa carta straccia in pochi giorni

La RACI è uno strumento, non un dogma. Il suo valore sta nel processo di discussione che genera tanto quanto nel documento finale. A volte, il solo fatto di riunire il team per discutere "chi fa cosa" risolve ambiguità che la RACI formale non avrebbe il tempo di catturare. Come per ogni strumento di project management, il buon senso deve guidare l'applicazione.

---

Domande frequenti sulla matrice RACI