Cos'è una matrice RACI? Definizione, modelli ed esempi (2026)
La guida completa per chiarire i ruoli, eliminare la confusione e portare a termine i progetti senza ostacoli imprevisti
Cos'è una matrice RACI?
Una matrice RACI è una matrice di assegnazione delle responsabilità che associa ogni attività di un progetto alle persone che la eseguiranno, la approveranno, forniranno consulenza in merito o ne saranno informate. L'acronimo sta per Responsible, Accountable, Consulted e Informed: quattro distinti livelli di coinvolgimento che, se assegnati correttamente, eliminano la causa più comune di fallimento di un progetto: l'ambiguità su chi debba fare cosa.
Le matrici RACI sono solitamente visualizzate sotto forma di griglia. Le attività o i deliverable sono elencati nelle righe a sinistra, mentre i ruoli o i nomi dei singoli sono elencati nelle colonne in alto. In ogni intersezione, una singola lettera (R, A, C o I) indica il coinvolgimento della persona in quell'attività. Il risultato è un elemento visivo di una sola pagina che risponde, per ogni lavoro, alle quattro domande che un project manager riceve più spesso: chi se ne occupa, chi approva, chi deve dare un parere e chi deve essere informato.
Il framework ha avuto origine nella gestione dei processi industriali negli anni '50 ed è stato formalizzato come strumento di project management dal Project Management Institute negli anni '80. Oggi viene utilizzato nello sviluppo software, nell'edilizia, nella sanità, nel marketing, nel settore manifatturiero, nella pubblica amministrazione e nella consulenza. Le varianti moderne includono RACIO (con l'aggiunta di Out of the loop), RASCI (con l'aggiunta di Support) e DACI (Driver, Approver, Contributor, Informed per il lavoro incentrato sulle decisioni), ma la versione originale RACI rimane la forma più insegnata e adottata.
Una matrice RACI ben costruita trasforma le ipotesi implicite sulla titolarità in impegni espliciti e documentati. Quando uno stakeholder chiede perché qualcosa è andato storto, puoi fare riferimento alla matrice e avere una conversazione precisa su quale persona ricopriva quale ruolo e dove si è verificata l'interruzione. Senza una matrice RACI, la stessa conversazione degenera in accuse reciproche e versioni contrastanti dei fatti.
Cosa significano R, A, C e I — con esempi
Responsible (R) è la persona che esegue materialmente il lavoro. Scrive il codice, redige il documento, esegue i test, crea la funzionalità. Può esserci più di una persona Responsible per una singola attività: ad esempio, un ingegnere frontend e uno backend potrebbero essere entrambi responsabili della distribuzione di una funzionalità che copre entrambi i livelli. Il ruolo Responsible riguarda l'esecuzione: mani sulla tastiera, mani sugli strumenti.
Accountable (A) è l'unica persona che risponde del risultato e firma per l'approvazione finale. Questa è la regola più importante della matrice RACI: deve esserci esattamente una persona Accountable per attività. Se due persone sono Accountable, non lo è nessuno: quando qualcosa va storto, entrambi daranno per scontato che se ne occupi l'altro. La persona Accountable può eseguire o meno il lavoro in prima persona, ma è colui il cui nome compare accanto al deliverable alla consegna e la cui revisione sblocca il passaggio successivo. Per il lancio di una funzionalità, il ruolo Accountable appartiene tipicamente al product manager o al lead engineer.
Consulted (C) è una persona il cui contributo è richiesto prima che il lavoro sia finalizzato. Le relazioni di tipo Consulted sono bidirezionali: la persona Responsible cerca attivamente il loro feedback e loro lo forniscono attivamente. I ruoli Consulted comuni includono esperti in materia, addetti alla revisione della sicurezza, consulenti legali, designer che supervisionano il lavoro di ingegneria e team di customer success che offrono consulenza sui cambiamenti rivolti ai clienti. La consultazione avviene prima che il deliverable sia completato, non dopo.
Informed (I) è una persona che ha bisogno di sapere che il lavoro è stato svolto, ma non ha bisogno di intervenire preventivamente. Le relazioni di tipo Informed sono unidirezionali: ricevono notifiche o riepiloghi dopo le milestone chiave. I ruoli Informed comuni includono dirigenti che monitorano i progressi a livello di roadmap, team adiacenti i cui piani dipendono dai tuoi e clienti che ricevono le note di rilascio. Confondere Consulted con Informed è il secondo errore più comune in una matrice RACI (dopo la presenza di più titolari Accountable): trascina le persone in cicli di revisione di cui non dovrebbero far parte.
Un esempio renderà concrete queste distinzioni. Consideriamo l'attività 'Distribuire il servizio di autenticazione in produzione'. L'ingegnere backend senior è il Responsible perché esegue effettivamente la distribuzione. L'engineering manager è l'Accountable perché approva il lancio e risponde di eventuali incidenti in produzione. L'architetto della sicurezza è il Consulted perché la sua revisione del flusso di autenticazione è richiesta prima della distribuzione. Il team del supporto clienti è Informed perché deve sapere che la distribuzione è avvenuta per rispondere alle domande dei clienti, ma non ha potere di blocco sulla distribuzione stessa. Quattro ruoli, quattro livelli di coinvolgimento, nessuna ambiguità.
Quando usare una matrice RACI (e quando no)
Le matrici RACI sono estremamente preziose nei progetti interfunzionali in cui più team o ruoli devono coordinarsi per consegnare un deliverable. Il segnale classico è la domanda 'chi è il responsabile di questo?' posta più di una volta in una singola riunione. Se il tuo team si ritrova a discutere sulla titolarità dei compiti in tempo reale, una matrice RACI ripagherà l'impegno in meno di una settimana.
Usa una matrice RACI per il lancio di nuovi progetti, il rilascio di funzionalità principali, ristrutturazioni organizzative, programmi di conformità e audit, l'onboarding di fornitori e qualsiasi iniziativa che coinvolga cinque o più persone in due o più team. La matrice è preziosa anche per l'inserimento di nuovi membri nel team: fornisce loro una mappa in un'unica pagina su con chi parlare e per cosa.
Evita la matrice RACI per lavori piccoli, ben definiti e gestiti da un singolo team. Un'attività per due persone in cui entrambi conoscono chiaramente i propri ruoli non beneficia di un framework a quattro lettere. Il tempo necessario per creare e mantenere la matrice supera il suo valore quando la comprensione implicita è già chiara. Usa il buon senso: se il team dovesse inventarsi i compiti solo per riempire la matrice, probabilmente è lo strumento sbagliato per quel tipo di lavoro.
Evita le matrici RACI in lavori altamente sperimentali in cui i ruoli cambiano legittimamente di settimana in settimana. La fase iniziale di ricerca e scoperta beneficia spesso di una titolarità più fluida, in cui chiunque prenda in carico un compito ne diventi il proprietario. Definire i ruoli troppo presto può soffocare quel tipo di esecuzione opportunistica su cui si basa il lavoro esplorativo. Passa alla RACI una volta che il lavoro si è stabilizzato in un piano di progetto strutturato con deliverable e scadenze.
Come creare una matrice RACI in 7 passaggi
Fase 1: Elenca ogni deliverable, attività o decisione del progetto. Sii sufficientemente granulare affinché ogni riga rappresenti un'unità di lavoro assegnabile a una persona specifica, tipicamente da una a due settimane di impegno. Evita righe generiche come 'Project management' o 'Comunicazione'; usa invece voci specifiche come 'Approvazione budget finale' o 'Firma contratto fornitore'. Un progetto tipico di medie dimensioni ha dalle 15 alle 40 righe.
Fase 2: Elenca tutti i ruoli o i nomi delle persone nella parte superiore della matrice. Usa i ruoli quando il team è numeroso e le persone possono ruotare (Project Manager, Lead Engineer, Designer, Responsabile QA). Usa i nomi individuali quando il team è piccolo e stabile. Includi i ruoli esterni dove pertinente — Cliente, Fornitore, Consulente Legale, Revisore Esterno — affinché i passaggi di consegna tra organizzazioni diverse siano espliciti.
Fase 3: Per ogni riga, identifica l'unico Responsabile finale (Accountable). Questa è la fase più difficile della creazione di una matrice RACI e quella in cui si commettono più errori. Sforzati di sceglierne esattamente uno. Se due persone sembrano entrambe Accountable, chiediti: quando questo deliverable sarà finito, nel calendario di chi apparirà il promemoria 'approva versione finale'? Il cui nome comparirà accanto alla casella di completamento? Quella è la tua persona Accountable.
Fase 4: Identifica i Responsabili operativi (Responsible). Può essercene più di uno. Per ogni attività, chiediti: chi svolgerà il lavoro effettivo? Elenca tutti coloro che eseguiranno l'attività, non solo chi guida l'esecuzione. In un'attività di redesign della UI, sia il designer che crea i mockup sia l'ingegnere che li implementa sono Responsible.
Fase 5: Identifica le parti Consultate (Consulted). Chiediti: di chi è necessario il contributo prima che l'attività sia definitiva? Sii estremamente rigoroso in questa fase. Ogni ruolo Consulted allunga i tempi del ciclo perché la persona Responsible deve attendere la loro revisione. Se il lavoro può procedere con una persona Informata anziché Consultata, segnalala come Informed. Il valore predefinito dovrebbe essere Informed; Consulted è l'eccezione che richiede una giustificazione.
Fase 6: Identifica le parti Informate (Informed). Chiediti: chi deve sapere che questo è accaduto, anche se non ha bisogno di intervenire? In genere questo è un elenco più lungo di quello dei Consulted. Includi dirigenti, responsabili di team adiacenti, team a contatto con il cliente e chiunque i cui piani si intreccino con il risultato.
Fase 7: Convalida la matrice con il team. Esaminala riga per riga in una sessione di lavoro. Problemi comuni che individuerai: righe senza alcun Accountable (assegnane uno), righe con due Accountable (negozia chi sia il vero proprietario), righe con troppi Consulted (declassane alcuni a Informed) e ruoli nelle colonne che non compaiono in nessuna riga (rimuovili o aggiungi il lavoro che dovrebbero svolgere). Dopo la convalida, salva la matrice in un luogo accessibile a tutti e aggiornala ogni volta che l'ambito cambia.
Esempio di Matrice RACI: Lancio di un Prodotto Software
Consideriamo il lancio di un prodotto software della durata di sei settimane con i seguenti ruoli: Product Manager, Engineering Lead, Designer, Responsabile QA, Marketing Manager, Responsabile Customer Success e CEO. I deliverable includono l'approvazione dell'ambito delle funzionalità, la revisione del design tecnico, l'approvazione del design della UI, l'esecuzione di build e test, la revisione della sicurezza, il lancio del programma beta, il lancio della campagna di marketing e il go-live finale.
L'approvazione dell'ambito delle funzionalità vede il Product Manager come Accountable, l'Engineering Lead e il Designer come Responsible (forniscono input sulla fattibilità), il CEO come Consulted (il lancio è abbastanza strategico da richiedere il parere esecutivo su cosa includere o meno), e il Marketing Manager e il Responsabile Customer Success come Informed.
La revisione del design tecnico vede l'Engineering Lead sia come Accountable che come Responsible (è il proprietario e l'estensore del progetto), il Product Manager e il Responsabile QA come Consulted, e gli altri ruoli come Informed. L'approvazione del design della UI inverte la proprietà: il Designer è Accountable, il Product Manager è Consulted e l'Engineering Lead è Informed (poiché implementerà quanto specificato dal designer ma non ha potere di veto sul design).
L'esecuzione di build e test elenca più persone Responsible — ogni ingegnere che si occupa dell'implementazione — mentre l'Engineering Lead rimane Accountable. Il Responsabile QA è Responsible per la parte di esecuzione dei test. La revisione della sicurezza vede un Security Architect (aggiunto all'elenco dei ruoli come colonna solo Consulted) come gatekeeper, con l'Engineering Lead come Accountable per la risoluzione di eventuali criticità emerse.
La riga del go-live finale è la più trasversale della matrice: il Product Manager è Accountable, tutti i ruoli di ingegneria e QA sono Responsible, il Marketing Manager e il Responsabile Customer Success sono Consulted (la loro prontezza influisce sulla decisione di go-live) e il CEO è Informed. Questa è la riga in cui la matrice dimostra il suo valore: quando arriva il giorno del lancio, ogni persona sa esattamente quale porta presidia e chi deve dare il via libera.
Errori Comuni da Evitare nella Matrice RACI
Avere più di un Accountable è l'errore più comune e dannoso. Quando due persone sono Accountable, nessuna delle due si sentirà responsabile del risultato ed entrambe presumeranno che sia l'altra a guidare il processo. Sforzati di sceglierne esattamente una. Se il lavoro è realmente in comproprietà, dividilo in due righe dove ogni persona è Accountable per la propria metà.
Troppi Consulted è il secondo errore più comune. Ogni ruolo Consulted aggiunge giorni o settimane di attesa per la revisione. Una riga con cinque ruoli Consulted richiederà cinque volte più tempo di una riga con uno solo. Controlla le assegnazioni dei Consulted ogni trimestre e declassa chiunque il cui ruolo di Consulted non modifichi attivamente il deliverable.
Confondere i ruoli con le persone crea fragilità. Se la matrice indica che il 'Lead Engineer' è Accountable per la revisione della sicurezza, il grafico funziona ancora se il lead engineer cambia ruolo: basterà aggiornare la mappatura ruolo-persona. Se la matrice dice che 'Sara' è Accountable, si rompe nel momento in cui Sara cambia team. Usa i ruoli quando il progetto sopravviverà a persone specifiche, e gli individui quando il progetto è breve e il team è stabile.
Lasciare che la matrice diventi obsoleta è una modalità di fallimento silenziosa. Le matrici RACI sono utilissime quando riflettono la realtà attuale, ma è facile ignorarle una volta che il progetto entra nel vivo. Crea l'abitudine di rivedere e aggiornare la matrice a ogni traguardo importante del progetto: transizioni di fase, cambi di ambito, aggiunte o partenze dal team. Una matrice vecchia di due mesi che nessuno ha toccato è peggio di non avere alcuna matrice, perché è attivamente fuorviante.
Saltare la fase di convalida del team permette il propagarsi di errori iniziali. La prima versione di una matrice RACI è quasi sempre errata in modi impercettibili. La colonna Accountable che hai assegnato in solitudine potrebbe non corrispondere a come il team concepisce effettivamente la responsabilità. Sottoponi sempre la matrice al team in una vera sessione di lavoro prima di dichiararla definitiva. La discussione stessa rappresenta metà del valore: anche se nessuna riga dovesse cambiare, il team uscirà dalla riunione con una comprensione condivisa di chi possiede cosa.
Abbinare le Matrici RACI ai Diagrammi di Gantt in Instagantt
Le matrici RACI indicano il "chi", mentre i diagrammi di Gantt indicano il "quando". I due strumenti sono complementari, non alternativi. Un ottimo piano di progetto include entrambi: una matrice RACI che definisce la responsabilità di ogni deliverable e un diagramma di Gantt che posiziona tali deliverable su una cronologia con dipendenze e milestone.
In Instagantt, puoi rispecchiare la tua struttura RACI impostando un assegnatario su ogni attività come proprietario principale (la figura Accountable), aggiungendo ulteriori collaboratori per il ruolo Responsible e utilizzando i commenti o le descrizioni delle attività per identificare le parti Consulted e Informed. La timeline di Gantt rende quindi visibile il lavoro RACI nel tempo: quando un Accountable ha più deliverable raggruppati nella stessa settimana, la vista del carico di lavoro li segnala prima che si verifichi un collo di bottiglia.
La funzione di snapshot pubblico di Instagantt ti consente di condividere entrambe le visualizzazioni con gli stakeholder senza concedere loro l'accesso in modifica. Invia alle parti Consulted un link allo snapshot qualche giorno prima che sia necessario il loro contributo; invia alle parti Informed una visualizzazione limitata alle milestone che possono consultare in pochi secondi. Abbinare la mappa delle responsabilità RACI a una timeline di Gantt in tempo reale trasforma la comunicazione del progetto da una riunione ricorrente a un link self-service.
Per i programmi più ampi, i workbook di Instagantt consentono di raggruppare più progetti in un unico spazio di lavoro. I ruoli RACI definiti per ogni progetto vengono aggregati in una vista portfolio in cui puoi vedere, ad esempio, se lo stesso Accountable si trova sul percorso critico in tre progetti simultanei. Questo tipo di visibilità della responsabilità tra progetti è impossibile in una matrice RACI su un foglio di calcolo statico ed è uno degli argomenti più forti a favore della gestione della RACI all'interno di uno strumento di progetto piuttosto che separatamente.
Prova il piano gratuito di Instagantt per creare il tuo primo diagramma di Gantt basato sulla RACI. Importa il tuo elenco di attività da un foglio di calcolo, assegna i responsabili utilizzando le definizioni RACI riportate sopra, aggiungi dipendenze tra i deliverable e condividi uno snapshot pubblico con il tuo team. La combinazione di una chiara attribuzione di responsabilità e di una timeline visibile trasforma il grafico da un semplice documento formale in uno strumento di pianificazione quotidiana.