RACI 2.0: Un RACI Nuovo e Migliorato per il Futuro
Alcuni anni fa, McKinsey ha pubblicato uno studio che ha evidenziato come l’80% delle organizzazioni intervistate ritenesse inefficace il proprio processo decisionale: troppo lento e/o con decisioni di scarsa qualità.
Quasi la metà degli intervistati pensava che la propria organizzazione non prendesse decisioni abbastanza rapidamente. Gli intervistati hanno dichiarato di sprecare gran parte del proprio tempo in processi decisionali inefficaci—quasi un terzo del tempo—e questa percentuale cresce salendo nei livelli organizzativi.
Che caos, vero? Specialmente mentre le aziende cercano di stare al passo con la digitalizzazione di tutto.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Per questo il RACI è perfetto per questo momento: in tutto il Project Management Institute’s PM Book of Knowledge è l’unico strumento di gestione progetti che si concentra sulle decisioni—su chi le prende e dove.
Aiuta anche a capire chi svolge quale lavoro. Per questi due motivi, spesso definisco l’acronimo RACI una vera e propria Scatola di Pandora—uno strumento molto semplice che svela ogni tipo di questione interessante su autorità, empowerment e accountability.
Se vuoi un ripasso sullo strumento RACI di base, inizia qui: Come creare una RACI Chart (più un modello) e qui: Dominare le RACI Chart in 30 minuti (per accedere al mini corso devi essere iscritto). Puoi inoltre trovare un ottimo whitepaper e altre risorse sul mio sito web.
Il RACI è per la costruzione del team
Poiché ho imparato per la prima volta il RACI come consulente di cambiamento organizzativo, lo vedo in modo un po’ diverso. Invece di pensare a quanto sia potente per la gestione progetti (e lo è), lo considero prima di tutto uno strumento per costruire il team.
Ma cosa succede a un team quando i suoi membri non sono chiari sui propri ruoli? Ecco alcuni sintomi comuni:
- I carichi di lavoro sembrano sbilanciati, con alcune persone che provano risentimento verso altri membri del team perché non si fanno carico della loro parte di lavoro.
- Duplicazione del lavoro, di solito attribuita a una comunicazione inefficace.
- Le persone si sentono offese se non vengono consultate prima che vengano prese decisioni o pianificate attività.
- Il team si sente come se dovesse sempre gestire emergenze invece di procedere in modo proattivo.
- Stereotipi attribuiti a persone di altri reparti o con un’identità professionale diversa
Tutto ciò è deleterio per il morale del team e, peggio ancora, può sembrare che i problemi siano relazionali tra le persone. Come se fossero questioni di personalità. Invece, la maggior parte di questi sono semplicemente casi di ciò che in ambito accademico si definisce “confusione di ruolo”, risolvibile con una semplice chiarificazione dei ruoli tramite RACI.
Quanto può essere frustrante far lavorare un team su un progetto per sei mesi, solo per vedere qualcuno a un livello superiore dell’organizzazione bloccare la raccomandazione? Quanto può demoralizzare lavorare su un problema senza adeguato supporto? Una buona e franca conversazione RACI può far emergere questi problemi prima di aver sprecato tempo prezioso dei membri del team.
Si scopre che i team con ruoli ben chiari hanno molte più probabilità di ottenere alte performance. E—che sorpresa—i team ad alte performance, di solito, godono anche di un morale alto.
Problemi Comuni con il RACI Originale
Ora che McKinsey si sta concentrando sul tema decisionale, ha anche pubblicato un blog sui problemi del RACI qui. Molti project manager hanno un rapporto di amore/odio con questo strumento. Una volta una cliente mi disse che avrebbe preferito morire piuttosto che creare un’altra matrice RACI con il suo team perché “era come guardare la vernice che si asciuga”.
Il primo problema è che la R (Responsabile) e la A (Accountable) spesso si confondono fra loro. L’intero scopo dello strumento è eliminare la confusione sui ruoli, quindi questa ironia è davvero paradossale.
Il secondo problema è che, quando si lavora su un progetto complesso che coinvolge più persone nella produzione di un deliverable (quindi più ‘R’), la confusione di ruolo torna a galla.
Il terzo problema della RACI è che non include scadenze né una timeline. La chiarezza dei ruoli è fantastica, ma non deve andare a scapito del rispetto dei tempi.
Il quarto problema è che il ruolo C (Consultato) spesso tende a esagerare il proprio mandato, con persone che credono di avere più autorità di quella realmente assegnata.
Cos’è il RACI 2.0 & Quali Sono i Suoi Vantaggi Rispetto alla Versione Originale?
Affrontiamo questi quattro problemi uno alla volta, con un RACI migliorato che io chiamo RACI 2.0.
Problema Uno: La confusione tra R e A
Con il nostro RACI 2.0, facciamo una distinzione molto chiara tra questi due ruoli.
- Il ruolo R è colui che svolge il lavoro, il che spesso include la creazione di un risultato concreto. Questo può significare compiere un'azione (come prenotare una cena) o dare una raccomandazione (“In base alla mia analisi, consiglio di ingaggiare questa agenzia, e questi sono i 3 motivi.”). Diciamo che il ruolo R (la persona responsabile) è un ruolo da "operoso". Se non stai producendo qualcosa, probabilmente non hai davvero un ruolo R.
- Il ruolo A prende le decisioni. In RACI 2.0, definiamo la A come Autorizzare oltre che Accountable (crediamo che Autorizzare sia più chiaro). Comunque lo si chiami, è importante che sia chiaro che questa è la persona responsabile con l'autorità di prendere decisioni finali su qualcosa. (Stesso esempio, decidere dove andare a cena. Oppure accettare la raccomandazione di qualcun altro—o meno.). Questo ruolo ha anche autorità di supervisione, il che significa che questa persona può dire: “Torna indietro e rifai una seconda bozza di ciò che sia finché non DECIDO che è abbastanza buono.”
Si noti che il Project Management Institute, con l'originale RACI, è molto chiaro: può esserci solo UN ruolo A per ogni attività. Questo rende davvero il processo decisionale più snello ed è una best practice. Ma pensando al mondo reale, da quante approvazioni diverse passa in media il design di un sito web?
Soprattutto con il lavoro cross-funzionale (che coinvolge più dipartimenti), può essere davvero difficile ridurre il RACI a un solo decisore. In RACI 2.0, incoraggiamo tutti a rivedere il numero di decisori A assegnati all'inizio e ridurlo il più possibile. Nessuna garanzia di riuscire a lasciarne solo uno.
Problema Due: Troppi Ruoli R
Nell'RACI originale, puoi assegnare un numero illimitato di R alla creazione di un risultato, e ciò rispecchia la realtà della collaborazione. Ma questo può anche creare più duplicazione del lavoro e confusione—fai tu questa parte o devo farla io? E chi tiene traccia di tutto ciò?
In RACI 2.0, abbiamo introdotto il ruolo R-Prime (o R1) per questa situazione. Ogni volta che ci sono più persone con il ruolo R, basta designarne una come R-Prime. Questo R1 si assicura che il risultato sia in linea (come un mini project manager per quel preciso risultato).
Più R collaborano, più cruciale diventa il ruolo R-Prime. Orchestrano il lavoro di più persone—ma questo non significa che prendano decisioni (quello resta il dominio dell'A).
Ecco un esempio (basato sull'esempio LOTR di questo articolo sulla tabella RACI)
| Attività/Partecipante | R1 | R | A |
| Scrivere i testi del sito web | Sam Gamgee | Pippin Took | |
| Approvare i testi del sito web | Frodo Baggins |
Significa che Pippin lavora sui testi INSIEME a Sam, ma come R1, Sam deve assicurarsi che tutto il lavoro si completi. Nota: i ruoli R1 spesso CONTRIBUISCONO anch’essi al lavoro.
Problema Tre: Nessuna tempistica o scadenza
Con RACI 2.0, consigliamo di aggiungere una colonna alla tua tabella RACI che includa la scadenza per ogni task di progetto. Nel lavoro cross-funzionale, poco si conclude senza una scadenza, come molti di noi sanno per esperienza diretta. Per fortuna, questa è facile da risolvere!
| Attività/Partecipante | R1 | A | Scadenza |
|---|---|---|---|
| Scrivere i testi del sito web | Sam Gamgee | N/A | 3 aprile |
| Approvare i testi del sito web | N/A | Frodo Baggins | 5 aprile |
Problema Quattro: I C che esagerano
Il ruolo C sta per Consultare. I C possono essere esperti della materia con un know-how prezioso da condividere, e ci interessa davvero sapere cosa pensano di un progetto.
Ma non sono A, il che significa che non possono cambiare il corso del progetto—né rallentarlo. La persona con il ruolo A può chiedere la loro opinione o assicurarsi che siano aggiornati, ringraziarli e poi anche ignorarli se decide. I C non possono approvare né hanno diritto di veto. Possono solo consigliare.
Puoi sempre fissare una scadenza anche per l'input dei C. Dopo un certo "entro questa data" puoi andare avanti con il progetto. Se non hanno dato il loro contributo, puoi mandare loro un sollecito (il bello di avere una scadenza, ancora una volta) e poi sei libero di proseguire. Il messaggio è: "Hai avuto la tua possibilità".
Usa RACI 2.0 Come Una Lingua
Ci piace pensare a RACI come un linguaggio che il team di progetto e l'organizzazione possano imparare a parlare fluentemente. Vogliamo che i nostri clienti diventino organizzazioni “fluente in RACI”.
Quando sei fluente in RACI, è facile per i colleghi ridefinire i ruoli al volo. “Ehi, sono sommerso questa settimana, puoi prenderti il mio R per (questo deliverable)?”
Le persone possono chiarire l'autorità all'istante, “Chi ha la A per questo, comunque?” o più probabilmente, “Chiediamo chiarezza a chi di dovere, sembra che tutti pensino di avere una A per questo redesign del sito!” “C'è una scadenza per questi stakeholder C? Stanno bloccando tutto!”
More Articles
Il modello RACI originale è superato?
No, i diagrammi RACI sono ancora preziosi (purché si aggiunga la colonna delle scadenze, vedi sopra). Tuttavia, rappresentano un investimento di tempo: quindi valuta attentamente quando è necessario utilizzarli e quando invece non lo è.
L'inizio di un progetto che coinvolge più dipartimenti, aree geografiche e/o fusi orari è un ottimo momento per fermarsi con il team trasversale e dialogare insieme sulla creazione di una matrice RACI.
Affrontare un lavoro nuovo—qualcosa che non avete mai fatto insieme prima—è un'altra buona occasione per fermarsi all’inizio e chiarire i ruoli di ciascuno.
Le start-up e gli innovatori spesso parlano di iniziare con un prodotto minimo funzionante (MVP), poi testare l’idea sul mercato e successivamente effettuare un pivot, spesso anche più di una volta.
Questo tipo di agilità non si concilia bene con le descrizioni di lavoro (che tendono ad essere piuttosto ampie e statiche), ma si adatta molto bene al RACI. La matrice delle responsabilità che si crea all’inizio di un progetto può cambiare e adattarsi man mano che il progetto evolve e che le persone entrano ed escono dal team.
Finché voi e il vostro team parlate fluentemente "RACI", potete gestire i cambi di ruolo.
La tua esperienza
Ci piacerebbe conoscere la tua esperienza—positiva, negativa o critica—nell’applicare il modello RACI classico, così come nel testare la versione aggiornata RACI 2.0.
Ci sono tanti modi per vedere i benefici del RACI—con risultati come riunioni più efficaci, onboarding più rapido dei nuovi assunti e una maggiore capacità di negoziare risorse con lo sponsor di progetto.
Per approfondire su RACI e la gestione dei team, iscriviti alla newsletter di The Digital Project Manager, oppure scopri un'alternativa al RACI, i diagrammi RASCI.
