Matrice RACI progetto: guida pratica con esempi 2026

Perché ogni progetto ha bisogno di chiarezza sui ruoli?

La gestione dei ruoli di progetto è il primo punto di tensione quando un team supera le 5-6 persone o quando lavori in contesti di Multi Project Management. Non è una questione di buona volontà: è strutturale. Più persone coinvolte significano più interpretazioni su chi debba decidere, chi debba eseguire, chi debba semplicemente essere informato.

Nei miei anni a seguire progetti di media complessità, ho visto lo stesso schema ripetersi quasi sempre. Un’attività resta in sospeso per giorni. Nessuno l’ha dimenticata, eppure nessuno l’ha fatta. Il motivo, quasi invariabilmente, è che ognuno pensava fosse responsabilità di qualcun altro. Non c’era cattiveria, non c’era negligenza. C’era solo ambiguità.

E l’ambiguità costa.

Quando manca un riferimento condiviso su chi ha l’autorità finale su un’attività, le decisioni si bloccano. Si aspettano approvazioni da figure che non sapevano nemmeno di essere coinvolte. Si convocano riunioni per chiarire cose che avrebbero dovuto essere chiare in fase di pianificazione. Il progetto rallenta, i costi salgono, i team si frustrano.

La matrice RACI progetto nasce esattamente per rispondere a questo problema, in modo visivo e immediato. È classificata come Responsibility Assignment Matrix (RAM) nel project management tradizionale (fonte: QRP International) ed è uno strumento che mette in una tabella, con poche lettere, chi fa cosa su ogni attività del progetto. Niente di più. Ma quella semplicità è il punto di forza.

Per questo le best practice raccomandano di introdurla nelle fasi iniziali di pianificazione, non a progetto avviato (fonte: Taskom). Costruirla tardi significa che le incomprensioni si sono già sedimentate. I ruoli informali si sono già cristallizzati. E cambiarli diventa un problema politico, non solo organizzativo.

Ma c’è un aspetto che spesso si sottovaluta. La matrice RACI non serve solo per i progetti con un inizio e una fine. Si usa anche per i processi aziendali ricorrenti: onboarding, cicli di approvazione, gestione delle eccezioni. In soldoni, qualsiasi flusso di lavoro in cui più persone si incrociano ha bisogno di sapere chi risponde di cosa.

Tutto sommato, la domanda non è se il tuo progetto abbia bisogno di chiarezza sui ruoli. La risposta è sempre sì. La domanda è se vuoi affrontare quella chiarezza prima o dopo che i problemi si manifestino.

Cosa succede quando i ruoli non sono definiti formalmente?

L’assenza di una matrice RACI strutturata produce conseguenze concrete e misurabili su tempi, qualità e clima del team. Non si tratta di teoria: chi ha gestito anche un solo progetto di media complessità sa che bastano poche settimane senza un’assegnazione chiara dei ruoli per vedere il lavoro rallentare, i conflitti aumentare e le scadenze slittare in modo che nessuno riesce davvero a spiegare.

Il primo problema, e probabilmente il più sottovalutato, riguarda il ruolo Consulted. Atlassian identifica come errore frequente assegnare troppi soggetti a questa categoria: quando si deve consultare cinque persone per approvare una decisione che potrebbe prenderla una, il processo si inceppa. Nei miei anni a seguire team di progetto ho visto esattamente questo schema ripetersi: una lista di consultati che cresce settimana dopo settimana, ognuno convinto di dover dire la sua, nessuno disposto ad assumersi la responsabilità finale.

E qui arriva il secondo nodo: la mancanza di ownership chiara sull’Accountable. Le linee guida operative, comprese quelle di Atlassian, raccomandano esplicitamente di non assegnare mai più di un Accountable per attività. Quando ci sono due persone “responsabili ultime”, in realtà non ce n’è nessuna. Ognuna aspetta che l’altra si muova. Il deliverable resta in sospeso. A conti fatti, avere un Accountable condiviso equivale ad averne zero.

Il terzo effetto è il sovraccarico su singole risorse. Senza perimetri scritti, le attività vanno sempre verso chi è più disponibile, o più visibile, o semplicemente più bravo a dire sì. Quella persona accumula lavoro che non è formalmente suo, mentre altri colleghi operano in zone d’ombra dove nessuno verifica cosa producono. Secondo Canva, una RACI ben costruita serve proprio a evitare questi squilibri, rendendo esplicito “chi fa cosa” in ogni fase del progetto.

Ma il danno più costoso, in termini economici, arriva dall’ultimo problema della lista. Gli stakeholder che intervengono tardi.

Quando non è chiaro dall’inizio chi deve essere coinvolto e in quale fase, accade che figure chiave vengano consultate solo a deliverable quasi completato. A quel punto le loro osservazioni, spesso legittime, generano rework su lavoro già fatto. Un ciclo di revisione tardiva può vanificare settimane di avanzamento. Personalmente, a mio avviso questo è il motivo più forte per investire tempo nella costruzione della matrice RACI prima di avviare l’esecuzione, non dopo il primo intoppo. Kaizenkey lo sintetizza bene: una matrice RACI migliora i flussi di comunicazione e previene imprevisti dovuti a mancate consultazioni o interventi tardivi dei decisori chiave.

Quindi, tutto questo non è una questione di burocrazia o di formalismo fine a sé stesso. È una questione di quante ore si vogliono perdere a cercare chi ha l’ultima parola su qualcosa che avrebbe dovuto essere scritto il primo giorno.

Cos’è la matrice RACI e cosa significa l’acronimo?

La matrice RACI è una matrice di assegnazione delle responsabilità che associa ogni attività di progetto a un livello specifico di coinvolgimento delle risorse coinvolte. Nel project management tradizionale viene classificata come Responsibility Assignment Matrix (RAM) ed è considerata una tecnica standard per definire chi fa cosa, chi decide e chi deve sapere. In soldoni: evita quel caos tipico dei progetti in cui tutti pensano che il problema tocchi a qualcun altro.

L’acronimo descrive quattro relazioni precise tra una risorsa e un’attività: Responsible, Accountable, Consulted, Informed. Quattro lettere. Quattro livelli di coinvolgimento completamente diversi tra loro.

Nei miei anni di formazione sul project management ho visto più volte team ben intenzionati costruire piani di progetto dettagliati e poi bloccarsi su una domanda banale: “Ma chi approva questo deliverable?” La matrice RACI esiste esattamente per chiudere quella domanda prima che il progetto cominci, non mentre è già in corso.

Responsible: chi esegue il lavoro

Il Responsible è la persona che materialmente svolge l’attività. Può essere uno solo o più persone, a seconda della complessità del task. Ma attenzione: avere troppi Responsible sulla stessa attività è un segnale di allarme. Le best practice, tra cui quelle documentate da Atlassian, raccomandano di verificare che non ci siano duplicazioni di lavoro o inefficienze proprio controllando quante risorse portano questa lettera sullo stesso compito.

Più Responsible possono coesistere, ma ognuno deve sapere esattamente quale parte del lavoro gli appartiene. Altrimenti il rischio è che tutti aspettino che lo faccia qualcun altro.

Accountable: chi risponde del risultato

Questa è la lettera più critica della matrice RACI progetto, e personalmente penso che sia anche quella più spesso mal applicata. L’Accountable è la figura che approva il lavoro, prende le decisioni critiche e si assume la responsabilità ultima del risultato, come chiarisce tecnovation.it nella sua analisi della matrice.

La regola d’oro è ferrea: un solo Accountable per attività. Sempre. Senza eccezioni.

E non è una regola burocratica. È logica pura. Quando due persone sono entrambe “responsabili ultime” di qualcosa, in pratica non lo è nessuna. Il conflitto decisionale si inceppa, le approvazioni si bloccano e il progetto accumula ritardi che poi diventano difficili da giustificare. L’Accountable può coincidere con il Responsible, ma non necessariamente: un project manager può essere Accountable di un’attività tecnica eseguita da un ingegnere.

Consulted: chi fornisce input e competenze

Il Consulted è chi deve essere interpellato prima o durante l’esecuzione dell’attività. Non esegue, non approva. Ma fornisce input che possono cambiare il risultato. Tipicamente sono esperti di dominio, rappresentanti legali, stakeholder tecnici.

Ignorare questa figura ha conseguenze concrete. Se un’attività viene completata senza consultare chi detiene una competenza critica, il lavoro può dover essere rifatto integralmente. Quindi la RACI, in questo caso, non è un formalismo: è un risparmio di tempo reale.

Ma anche qui vale una regola di buon senso: non si mette tutto il mondo nella colonna Consulted. Solo chi ha davvero qualcosa di utile da dire su quella specifica attività.

Informed: chi viene tenuto al corrente

L’Informed è l’ultimo livello di coinvolgimento. Chi porta questa lettera non interviene nel lavoro, non decide, non viene interpellato. Riceve semplicemente un aggiornamento a cose fatte, o in certi momenti chiave del progetto.

Spesso sono figure di senior management, clienti, sponsor di progetto. Hanno bisogno di sapere come avanza il lavoro, ma non devono essere coinvolti nelle decisioni operative. Ignorare gli Informed, però, è uno degli errori che creano i problemi più difficili da gestire: uno sponsor che scopre a fine progetto una scelta importante che non condivide è un problema molto più grande di una riunione di aggiornamento in più.

Quindi, a conti fatti, la matrice RACI progetto non è un documento formale da archiviare. È uno strumento vivo che, secondo le linee guida di QRP International, aiuta a promuovere la collaborazione nel team e a prevenire imprevisti dovuti a mancate consultazioni o a interventi tardivi dei decisori chiave.

Come si costruisce una matrice RACI passo dopo passo?

La costruzione di una matrice RACI segue una sequenza di quattro passi che puoi completare in 60-90 minuti per un progetto di media complessità. Non serve software dedicato: un foglio Excel o Google Fogli con ruoli nelle colonne, attività nelle righe e le lettere R/A/C/I nelle celle è tutto ciò di cui hai bisogno per partire, come confermano le indicazioni operative di kaizenkey.com.

Step 1: elencare attività, milestones e decisioni nelle righe

Qui si sbaglia più spesso. Molto spesso.

Il problema è riempire le righe con voce come “riunione di allineamento settimanale” o “call con il cliente”. Le linee guida di taskom.at sono esplicite su questo punto: le attività generiche o puramente amministrative non appartengono alla matrice RACI. Appartengono al calendario.

Nelle righe vanno attività concrete e deliverable: “Redazione del documento di analisi requisiti”, “Approvazione del piano di test”, “Consegna del prototipo funzionante”. E le decisioni critiche, quelle che bloccano il progetto se rimangono sospese. Tra i team che ho seguito nel tempo, quelli che inserivano decisioni esplicite come righe separate risolvevano i blocchi molto prima rispetto a chi lasciava le responsabilità decisionali implicite nel piano.

Step 2: inserire ruoli o membri del team nelle colonne

Puoi usare i nomi delle persone o i ruoli funzionali. Dipende dal contesto.

Per progetti brevi con team piccolo, i nomi propri funzionano bene. Per processi aziendali ricorrenti o strutture più grandi, i ruoli (Project Manager, Tech Lead, Responsabile Qualità) garantiscono che la matrice resti valida anche quando cambia una risorsa specifica. Anzi, se inserisci i nomi e poi una persona lascia il progetto, la matrice diventa immediatamente un documento inaffidabile.

Tieni le colonne sotto controllo: una matrice con 12 colonne di stakeholder diversi è quasi sempre un segnale che il progetto ha un problema di governance, non di strumenti.

Step 3: assegnare R, A, C o I in ogni cella

Questa è la parte che richiede più attenzione. E più coraggio, a volte, perché assegnare una A significa dire apertamente a qualcuno “questa decisione è tua”.

La regola fondamentale: ogni riga deve avere esattamente un Accountable. Una sola persona. L’Accountable è la figura che approva il lavoro e si assume la responsabilità ultima del risultato, come chiarisce tecnovation.it. Se metti due A sulla stessa riga, stai di fatto dicendo che nessuno è davvero responsabile. E lo sa chiunque abbia lavorato in un progetto dove “tutti erano responsabili” di qualcosa.

Per la R, invece, ci possono essere più persone. Ma anche qui c’è un limite pratico: troppi Responsible sulla stessa attività creano duplicazioni e conflitti. Secondo Atlassian, una delle linee guida più diffuse è proprio quella di evitare troppe R per attività singola.

C e I si assegnano con meno ansia. Ma ricorda: ogni C aggiunge un ciclo di consultazione, quindi metti C solo dove il contributo è davvero necessario al risultato.

Step 4: validare con il team e allineare al piano di progetto

Una matrice RACI compilata da soli non vale molto.

Vale quando il team l’ha letta, discussa e accettata. La validazione non è una formalità: è il momento in cui emergono i disaccordi su chi fa cosa, prima che emergano in produzione. Personalmente, ho visto sessioni di validazione di 30 minuti evitare settimane di blocchi operativi in seguito.

Ma c’è un passaggio spesso saltato: allineare la matrice al piano di progetto. Le best practice di taskom.at raccomandano esplicitamente questo allineamento, in modo da evitare incoerenze tra i ruoli definiti nella RACI e le scadenze operative del piano. Se nel piano è previsto che il documento di requisiti sia pronto alla settimana 3, nella RACI deve essere chiarissimo chi lo scrive (R) e chi lo approva (A) entro quella data.

Tutto sommato, la matrice RACI è uno strumento vivo. Se cambiano le risorse o la struttura del progetto, va aggiornata. Un documento statico che non riflette più la realtà del team non è uno strumento di lavoro: è carta.

Quali sono gli errori più frequenti nell’uso della RACI?

Gli errori nella matrice RACI non emergono il giorno della compilazione, ma 3-4 settimane dopo, quando il progetto entra in fase esecutiva. A quel punto, il documento che sembrava pulito e condiviso comincia a scricchiolare: due persone fanno la stessa cosa senza saperlo, una decisione rimane bloccata perché nessuno sa chi la deve prendere, e il team smette di consultare la matrice perché “tanto non è aggiornata”. Ho visto questo schema ripetersi in progetti di settori diversi, e quasi sempre la causa risale a uno degli stessi quattro errori.

Troppi Responsible sulla stessa attività

Assegnare più persone come Responsible su una singola attività sembra prudente. Non lo è.

Quando due o tre persone sono tutte indicate come Responsible per la stessa voce della matrice RACI, senza un coordinamento esplicito, si crea un vuoto di regia: ognuno aspetta che l’altro faccia il primo passo, oppure tutti e tre lavorano in parallelo producendo versioni diverse dello stesso output. Le linee guida Atlassian raccomandano espressamente di verificare che per ogni attività non ci siano troppe persone catalogate come Responsible, proprio per evitare queste duplicazioni. La duplicazione del lavoro non è solo uno spreco di tempo: genera conflitti su quale versione sia quella “ufficiale” e rallenta il deliverable nel momento peggiore.

La regola pratica è semplice: un solo Responsible per attività, oppure due con ruoli distinti indicati fuori dalla matrice. Se non riesci a decidere chi mettere, probabilmente l’attività è troppo generica e va spezzata.

Più di un Accountable o nessun Accountable

Questo è, a mio avviso, l’errore più costoso in assoluto.

L’Accountable nella matrice RACI è la figura che approva il lavoro, prende le decisioni critiche e si assume la responsabilità ultima del risultato. Un solo Accountable per attività è la regola standard per evitare conflitti di ownership, come confermano le best practice citate da Atlassian. Ma nella pratica si incontrano due situazioni opposte: la cella Accountable rimane vuota (nessuno vuole formalmente la responsabilità) oppure ci sono due nomi, spesso perché il project manager non ha avuto l’autorità di scegliere.

Nel primo caso, le decisioni fluttuano senza atterrare. Nel secondo, le decisioni si bloccano perché i due Accountable devono accordarsi ogni volta. Entrambe le situazioni producono ritardi. Tagliare la testa al toro fin dall’inizio, anche se crea tensioni politiche, vale molto di più che gestire lo stallo a progetto avviato.

Liste di Consulted troppo lunghe

Inserire qualcuno come Consulted è un gesto che sembra inclusivo. E spesso lo è troppo.

Quando la colonna Consulted di una attività contiene cinque, sei, sette persone, raccogliere i loro input prima di procedere diventa un’operazione burocratica. Ogni stakeholder ha diritto a esprimersi, ognuno risponde con tempistiche diverse, e chi deve poi integrare i feedback si trova con materiale contradditorio e scadenze sforate. La matrice RACI, nata per semplificare la comunicazione, finisce per produrre l’effetto opposto.

Il test che uso io è questo: se una persona nella lista Consulted non cambia mai il contenuto del lavoro con il suo feedback, allora appartiene agli Informed, non ai Consulted. Spostala. La lista Consulted deve contenere solo chi ha un contributo tecnico o decisionale reale e irrinunciabile.

Matrice non aggiornata quando il team cambia

Un progetto di durata media vede almeno un cambio di risorsa. Spesso di più.

Le linee guida operative di Canva indicano che la matrice RACI va aggiornata ogni volta che cambiano le risorse del team o la struttura del progetto, in modo che rimanga un riferimento affidabile per i ruoli effettivamente in carica. Ma nella pratica questo aggiornamento non avviene. Il nuovo arrivato lavora senza sapere cosa gli è stato assegnato, chi ha lasciato il progetto risulta ancora Accountable su attività che nessuno presidia, e il team smette di usare la matrice perché “tanto è vecchia”.

Perdita di affidabilità. Questo è il risultato finale di una matrice RACI abbandonata a se stessa.

La soluzione non è complicata: bastano due revisioni formali della matrice, una a metà progetto e una a ogni cambio significativo di team, per mantenere il documento allineato alla realtà. Senza questo presidio, la matrice diventa carta. E alla fine della fiera, un documento che nessuno consulta non serve a nessuno.

Esempio pratico: matrice RACI per un progetto IT

Un esempio concreto vale più di qualsiasi definizione: vediamo come applicare la matrice RACI a un progetto di rilascio software di 6 settimane. Il caso che uso qui è tratto da un progetto reale di migrazione su ambiente cloud, con un team piccolo e tempi stretti. Funziona bene come modello perché le dinamiche sono familiari a chiunque lavori in ambito IT: decisioni tecniche veloci, sponsor lontani dal dettaglio operativo, consulenti esterni da coinvolgere senza bloccare tutto.

Setup: progetto di rilascio software in 6 settimane

Il progetto ha 8 attività principali, 5 ruoli nel team e 1 sponsor. I ruoli sono: Project Manager, Tech Lead, Sviluppatore Backend, Tester QA, Architetto di Sistema. Lo sponsor è il responsabile IT di business, esterno alle attività quotidiane ma coinvolto nelle approvazioni critiche.

Prima di mettere mano alla matrice RACI, ho elencato le attività allineandole al piano di progetto. Questa operazione non è opzionale: se le attività nella RACI non corrispondono alle milestone reali, il documento diventa carta straccia nel giro di due settimane. Le best practice lo dicono chiaramente, e l’esperienza lo conferma ogni volta.

Le 8 attività identificate sono:

• Definizione dei requisiti funzionali
• Approvazione architettura
• Sviluppo moduli core
• Integrazione con sistemi esterni
• Test funzionali e di regressione
• Revisione della sicurezza
• Deploy in ambiente di staging
• Go-live e rilascio in produzione

Attività chiave e ruoli coinvolti

Worksection definisce la matrice RACI come uno strumento critico che assicura che ogni componente cruciale del progetto sia assegnato a qualcuno. In soldoni: se una cella rimane vuota, significa che nessuno sa di doversi occupare di quella cosa. E nei progetti IT, le zone grigie si pagano care.

Per ogni attività ho verificato due cose. Primo: c’è un solo Accountable? Secondo: ci sono troppi Responsible? Una linea guida di Atlassian mette in guardia esattamente su questo punto: più persone catalogate come Responsible sulla stessa attività generano duplicazioni e, paradossalmente, rallentano il lavoro invece di accelerarlo.

Una RACI ben costruita, come ricorda Canva, aiuta a evitare sovraccarichi e ambiguità sul chi fa cosa. Ma la costruzione è tutto. Non basta compilare la tabella in fretta durante un’email di gruppo.

Compilazione cella per cella

Prendiamo l’attività più delicata: Approvazione architettura.

Questa è la cella che crea più conflitti nei team IT. Tutti vogliono dire la loro, ma qualcuno deve decidere. L’assegnazione corretta è questa:

• Responsible: Architetto di Sistema (produce il documento di architettura)
• Accountable: Tech Lead (approva il lavoro, si assume la responsabilità ultima del risultato)
• Consulted: Sviluppatore Backend, Sponsor
• Informed: Tester QA, Project Manager

Perché il Tech Lead è Accountable e non l’Architetto? Perché il ruolo Accountable, per definizione, è l’autorità finale: prende le decisioni critiche e risponde del risultato davanti al progetto e allo sponsor. L’Architetto produce, il Tech Lead approva. La distinzione non è formale, è operativa.

E il Project Manager? Informed, non Consulted. Deve sapere cosa succede, ma non è nel ciclo decisionale tecnico. Questa assegnazione libera il PM da riunioni che non aggiungono valore al suo lavoro.

Compilazione cella per cella: gestire i Consulted senza paralizzare il progetto

Il rischio più concreto con i Consulted è l’eccesso. Se su ogni attività hai 3-4 persone in C, ogni decisione diventa una consultazione infinita. Ho visto progetti slittare di settimane per questo motivo specifico.

La regola che uso è semplice: un Consulted deve avere informazioni che il Responsible non ha. Non opinioni generali, informazioni specifiche e non replicabili. Se il Backend Developer non ha dati che cambiano l’architettura, va spostato in Informed.

Ma attenzione. Togliere qualcuno dai Consulted senza spiegarlo crea risentimento nel team. Durante il workshop di validazione, dedica due minuti a spiegare il criterio. Non è diplomazia, è gestione del rischio: chi si sente escluso senza motivo tende a bloccare le decisioni in modo informale, fuori dalla RACI.

Validazione finale con il team

Personalmente, considero il workshop di validazione la parte più importante dell’intero processo. Non perché la tabella sia incompleta, ma perché è lì che emergono i disaccordi che altrimenti restano sommersi.

Con 8 attività e 6 ruoli (team più sponsor), un workshop ben condotto si chiude in 90 minuti. La struttura è lineare: si leggono le righe una per una, si chiede se qualcuno ha obiezioni sull’assegnazione, si annotano le modifiche in tempo reale. Niente presentazioni, niente slide. Solo la tabella aperta davanti a tutti.

Quindi, a conti fatti, la validazione non è un passaggio burocratico. È il momento in cui la matrice RACI smette di essere un documento del Project Manager e diventa uno strumento condiviso da tutto il team. La differenza, nella pratica, è enorme: una RACI validata collettivamente viene rispettata, una imposta dall’alto viene ignorata alla prima difficoltà.

Un ultimo punto. La matrice va aggiornata se cambiano le risorse o la struttura del progetto. In un rilascio di 6 settimane può sembrare eccessivo, ma se entra un nuovo sviluppatore alla settimana 3, o se il Tech Lead viene sostituito, la RACI deve riflettere la realtà. Altrimenti smette di essere un riferimento affidabile e diventa solo un allegato dimenticato nel repository del progetto.

Quando usare la RACI oltre i progetti singoli?

La matrice RACI non è uno strumento limitato al singolo progetto: si estende a processi ricorrenti e portafogli multipli con la stessa logica. Molti la usano una volta, la archiviano e la dimenticano. Ma la stessa struttura che chiarisce chi fa cosa in un progetto one-shot funziona con la stessa precisione ovunque ci siano attività, decisioni e persone coinvolte in modo ricorrente.

Processi aziendali ricorrenti

Secondo Worksection, la matrice RACI può essere utilizzata per processi aziendali ricorrenti al fine di chiarire il responsabile di ogni fase e garantire continuità operativa. In soldoni: se ogni mese si ripete lo stesso processo di fatturazione, approvazione budget o gestione reclami, costruire una RACI su quel processo evita che ogni volta ci si chieda da capo a chi spetta cosa.

Nei miei anni di formazione project management ho visto organizzazioni spendere ore in riunioni su processi che si ripetevano identici da anni, solo perché nessuno aveva mai fissato i ruoli nero su bianco. Una matrice RACI sui processi ricorrenti taglia questo spreco alla radice.

E qui c’è un punto che spesso si sottovaluta. Un processo ricorrente senza RACI genera ambiguità crescente nel tempo: le persone cambiano, i ruoli si spostano, ma nessuno aggiorna le responsabilità. Le linee guida operative raccomandano di aggiornare la matrice ogni volta che cambiano le risorse del team o la struttura organizzativa, proprio per mantenere un riferimento affidabile. Sui processi ripetibili, questo aggiornamento è se possibile ancora più importante che sui progetti: il danno di un’ambiguità si moltiplica a ogni ciclo.

Multi Project Management

Quando si gestiscono più progetti in parallelo, le sovrapposizioni di ruolo diventano il problema principale. Chi è Responsible su tre deliverable contemporaneamente? Chi approva quando l’Accountable è allocato su un altro progetto? Domande concrete, con impatti concreti sulle scadenze.

La matrice RACI è considerata essenziale nei contesti di Multi Project Management proprio per ridurre sovrapposizioni e conflitti tra team paralleli (fonte: Tecnovation). Ma non basta costruire una RACI per singolo progetto: in un portfolio, la visione deve essere trasversale. Serve confrontare le matrici dei vari progetti per individuare dove la stessa persona compare come Accountable su attività concorrenti nel tempo.

Anzi, a mio avviso il vero valore della RACI in contesti multi-progetto non sta nella singola matrice ma nella capacità di leggerle insieme. Quando le metti fianco a fianco scopri colli di bottiglia decisionali che nessun Gantt ti avrebbe mostrato.

Praticamente: un project manager che governa tre iniziative contemporaneamente dovrebbe avere una RACI per ciascuna e un momento mensile per verificare che nessuna risorsa critica risulti Accountable su attività con scadenze coincidenti. Non è burocrazia. È prevenzione.

Onboarding di nuovi membri del team

Una risorsa appena entrata in un team ha bisogno di capire due cose. Subito. Chi decide e chi fa.

La matrice RACI di progetto è forse il documento più utile che si possa consegnare a un nuovo membro il primo giorno. Non il piano di progetto con le durate, non il registro dei rischi: la RACI, perché risponde in una pagina alle domande che il nuovo arrivato altrimenti farebbe per settimane disturbing colleghi già sotto pressione. Chi approva il mio deliverable? Con chi devo coordinarmi prima di procedere? Chi ha l’ultima parola su questa decisione?

Tutto ciò ha un effetto diretto sui tempi di ingresso operativo. Però funziona solo se la matrice è aggiornata: una RACI con nomi di persone uscite dal team o ruoli ridisegnati non aiuta, confonde. Ma questo è un problema di manutenzione, non di strumento.

Quindi, alla fine della fiera, la matrice RACI di progetto non è un artefatto da produrre per i processi di certificazione e poi dimenticare. È un riferimento vivo, utile su tre fronti distinti: governa i processi ricorrenti, riduce i conflitti nei portfolio e accelera l’integrazione di nuove risorse. Chi la usa solo per il singolo progetto sta sfruttando meno della metà del suo potenziale.

Studio autodidatta o percorso strutturato per padroneggiare la RACI?

Imparare la matrice RACI da soli è possibile; padroneggiarla in contesti enterprise richiede un percorso formativo strutturato. La distinzione non è sottile: chiunque può leggere un articolo, capire l’acronimo e compilare una tabella su Excel in meno di un’ora. Ma costruire una matrice RACI che regga davanti a uno sponsor di progetto, che sopravviva a un cambio di risorse a metà sprint e che si integri con un piano di governance formale è un’altra cosa.

QRP International definisce la RACI “uno strumento semplice ma essenziale” per la collaborazione di team, e questa definizione è esatta, però nasconde una trappola. La semplicità dell’acronimo (Responsible, Accountable, Consulted, Informed) porta molti a sottostimare la complessità dell’applicazione reale. Nei miei anni di formazione su progetti strutturati ho visto decine di matrici costruite male non per ignoranza dell’acronimo, ma per mancanza di un framework di riferimento più ampio, quello che i percorsi certificati danno quasi per scontato.

La RACI è classificata nei manuali di project management tradizionale come tecnica standard di Responsibility Assignment Matrix (RAM), e i corsi che preparano alla certificazione PMP o alla norma UNI 11648 la trattano in questo contesto: dentro un sistema di governance, accanto a strutture di Work Breakdown, piani di comunicazione e processi di change management. Non come strumento isolato.

La differenza pratica si vede in due scenari.

Nel primo, un project manager autodidatta costruisce la matrice, la condivide con il team e la dimentica nel cassetto. Funziona finché il progetto è piccolo e le variabili sono poche. Nel secondo, un project manager con una formazione certificata usa la stessa matrice RACI come documento vivo: la aggiorna quando cambiano le risorse, verifica che per ogni attività non ci siano troppi Responsible (evitando duplicazioni e inefficienze), e soprattutto sa spiegare a uno sponsor perché quella tabella giustifica certe decisioni di budget e certe scelte di escalation. Sono due competenze diverse. E il mercato le paga in modo diverso.

Questo è il punto che, a mio avviso, viene sistematicamente sottovalutato: saper costruire la matrice RACI è una competenza tecnica di base. Saper difenderla in una riunione di steering committee, con dati, con riferimenti a standard riconosciuti, con la capacità di contestualizzarla rispetto al piano di progetto complessivo, quella è la competenza che distingue un project manager senior da un esecutore.

I percorsi certificati inseriscono la matrice RACI dentro un framework più ampio proprio perché nessuno strumento di governance funziona da solo. E le certificazioni riconosciute, in contesti senior, danno una credibilità immediata che l’autodidatta fatica a costruire senza un lungo storico di progetti alle spalle. In soldoni: se stai puntando a ruoli di coordinamento su progetti complessi o processi aziendali ricorrenti, dove la RACI serve a garantire continuità operativa ben oltre il singolo progetto, un percorso strutturato non è un’opzione, è il percorso più diretto.

Domande frequenti su matrice RACI progetto

Le domande più frequenti sulla matrice RACI riguardano la distinzione tra i ruoli, gli strumenti operativi e l’aggiornamento nel tempo. Raccoglierle in un unico posto serve a togliersi i dubbi veloci senza dover setacciare manuali di project management.

Qual è la differenza tra Responsible e Accountable nella matrice RACI?

La differenza è sostanziale, non solo terminologica. Responsible è chi esegue concretamente il lavoro: scrive il codice, redige il documento, consegna il deliverable. Accountable è chi ha la responsabilità ultima del risultato: approva il lavoro, prende le decisioni critiche e risponde dell’esito anche se non ha messo mano all’attività. Nei miei anni a seguire team di progetto ho visto che confondere i due ruoli è la causa numero uno di decisioni bloccate a metà.

In soldoni: Responsible fa, Accountable risponde. Uno solo dei due firma.

Quanti Accountable possono esserci per attività?

Uno. Le best practice, citate anche da Atlassian, indicano un solo Accountable per attività. Mettere due persone in quella casella non distribuisce la responsabilità: la annulla. Quando tutti sono responsabili, nessuno lo è davvero. Se senti la tentazione di assegnare due Accountable, è quasi sempre il segnale che l’attività va spezzata in due task separati.

Si può creare una matrice RACI gratis con Excel?

Sì, e funziona bene per la maggior parte dei progetti. Microsoft Excel e Google Fogli sono strumenti adeguati per costruire la matrice RACI senza costi aggiuntivi: bastano righe per le attività, colonne per i ruoli e le quattro lettere R, A, C, I nelle celle. Ma attenzione: la semplicità dello strumento non semplifica il lavoro di definizione dei ruoli. Quello è tutto umano. Lo strumento è solo un foglio.

Ogni quanto va aggiornata la matrice RACI?

Non esiste una cadenza fissa uguale per tutti. La matrice RACI va aggiornata ogni volta che cambia qualcosa di strutturale: un membro del team lascia il progetto, arriva una nuova risorsa, si ridefinisce la portata di un’attività o cambia chi prende le decisioni. Tenerla ferma mentre il progetto evolve la trasforma da strumento vivo a documento inutile. E un documento inutile, nella pratica, nessuno lo legge più.

La RACI è prevista nel PMBOK?

La matrice RACI rientra nella categoria delle Responsibility Assignment Matrix (RAM), citate nel project management tradizionale e nei manuali di riferimento del settore. QRP International la descrive come uno strumento standard di definizione dei ruoli. Non è l’unico formato possibile per una RAM, ma è quello più diffuso e riconoscibile nei team internazionali.

Quali attività non vanno inserite nella matrice RACI?

Quelle troppo generiche o puramente amministrative. Le riunioni di routine, i check settimanali, le attività burocratiche ricorrenti non appartengono alla RACI. La matrice serve per attività di progetto concrete, traguardi e decisioni chiave, non per coprire ogni micro-movimento del team. Anzi, inserire troppo rende la matrice illeggibile e quindi inutilizzata. Meglio una RACI corta e precisa che una lunga e ignorata da tutti.