Compilare una RACI

Compilare una matrice di responsabilit√† RACI sembra molto semplice ed intuitivo, eppure nasconde alcuni tranelli in cui c’√® il rischio di cadere. Una RACI compilata correttamente aiuta a definire le responsabili, quindi gli interlocutori corretti. Una RACI sbagliata crea entropia e fraintendimenti. Alcune regole di base aiutano a definire una RACI in modo tale che la RACI sia di aiuto e supporto alle attivit√† progettuali. L’acronimo sta per:

(R)esponsible: Colui che √® responsabile operativamente dell’esecuzione dell’attivit√†, diversi attori possono essere Responsible

(A)ccountable: Colui che ha le leve operative per far si che i (R)esponsible possano portare a termine il lavoro e colui che prende le decisioni in merito all’attivit√†.

(C)onsulted: E’ un soggetto che viene consultato, spesso in qualit√† di esperto della materia (es: SME – Subject matter expert). Non svolge attivit√† operativa, si limita a dare suggerimenti se interpellato

(I)nformend: E’ un soggetto che DEVE essere informato sul evolversi delle attivit√†. Non ha leve dirette sul progetto, ma la sua influenza pu√≤ essere di ostacolo o beneficio per il progetto

Regola 1 РUn solo (A)ccountable per attività

Una matrice RACI ha un solo accountable, ed √® colui che prende le decisioni in merito all’attivit√† che deve essere portata a termine. Vale sempre la regola di base che la responsabilit√† di una decisione √® personale. Chi deve prendere una decisione pu√≤ appoggiarsi a un team di esperti, avvalersi di comitati o anche fare delle votazione. La responsabilit√† della decisione rimane personale indipendentemente dal metodo scelto. (Qui si sarebbe molto da dire in merito alla responsabilit√† individuale e di come molti sfruttino dei comitati per de-responsabilizzarsi.) A differenza del (A)ccountable, i (R)esponsible possono essere diversi e sono i soggetti che lavorano sull’attivit√†, gli esecutori.

Regole 2 РLa giusta granularità di attività

Una matrice RACI viene sempre scritta per uno scopo ben preciso. In funzione dello scopo la RACI pu√≤ avere un diverso livello di dettaglio delle attivit√†. Esattamente come per le WBS si pu√≤ rimanere a un livello molto alto o scendere a un livello di dettaglio esasperato. La granularit√† molto spinta fa si che ogni responsible possa diventare l’ Accauntable del livello inferiore. Pensiamo un team che esegue dei test, avremo un accountable per tutta la parte dei test, ossia colui che prende le decisioni sui test. Avremo pi√Ļ esecutori (R), ossia le persone che eseguono i test. Ciascuno di essi diventa responsabile (A) per la propria attivit√† entrando nel livello di attivit√† che seguono. In questo modo avremo avremo un responsabile (A) per i test funzionali, per i test di integrazione quelli di performance. Il punto delicato √® capire a che livello fermarsi nel dettaglio delle attivit√† rappresentate in una RACI. In genere la scelta migliore √® sempre il compromesso, una RACI da allegare un contratto tender√† a essere di alto livello. Il project manager ne predisporr√† una in cui rappresenta i principali riporti e stakeholder, in queste RACI si trova spesso il nome del team di riferimento pi√Ļ che il nome di una persona, indicavo in questo modo che la responsabilit√† (A) √® in capo al team leader. Ogni team del progetto pu√≤ predisporre una RACI nominativa per le proprie risorse.

Regola 3 – I soggetti corretti

Come per le attivit√† anche i soggetti presenti nelle RACI possono essere rappresentati a diversi livelli. Nel livello pi√Ļ alto, anche qui usato nei contratti, i soggetti sono le societ√† che partecipano al contratto o al progetto. Ogni societ√† andr√† poi a creare una propria RACI in cui rappresenta le responsabilit√† di diversi team coinvolti nelle attivit√† e ciascun team organizzer√† (se occorre) delle RACI in cui i soggetti sono i nomi delle risorse. La scelta della granularit√† dei soggetti √® legata prevalentemente allo scopo per cui viene scritta la RACI. Pi√Ļ si scende di livello nelle attivit√† pi√Ļ i soggetto sono gruppi sempre pi√Ļ ristretti fino ad arrivare al nominativo di una risorsa.

Un esempio sbagliato

Mi è capitato di vedere la matrice qui di seguito riportata come allegato a un contratto:

Il pallino nero indica il fornitore, il pallino rosso indica il cliente. Si tratta quindi di una matrice di alto livello e ha come obiettivo quello di definire le responsabilit√† delle due societ√†. La matrice contiene diversi errori, il primo errore evidente √® che nella colonna accountable in alcuni casi sono presenti due soggetti, sia il cliente che il fornitore. Il doppio accountable √® sempre da evitare perch√© la responsabilit√† delle decisioni non mai congiunta. Il secondo errore √® nella colonna (R), ossia chi esegue operativamente l’attivit√†. In una RACI che definisce le responsabilit√† cliente/fornitore il fornitore non ha (praticamente mai) leve per far fare al cliente delle attivit√† funzionali al progetto. Il fornitore non pu√≤ infatti pretendere di avere la disponibilit√† delle risorse cliente nei momenti in cui servono (es: testing della RACI). Per questo motivo il fornitore non pu√≤ essere accountable per attivit√† in cui responsible √® il cliente. Se si verifica realmente una situazione di questo tipo avremo uno scarso commitment del cliente e un rischio altissimo (quasi certezza) di fallimento del attivit√†. Attenzione, pu√≤ valere l’opposto, il cliente √® accountable per attivit√† di cui √® responsible il fornitore. Esempio palese √® l’attivit√† time & material. Responsabilit√† cliente risorse fornitore. Il terzo errore √® nell’attribuzione della responsabilit√† (accountable) errata, ossia il fornitore si assume la responsabilit√† di attivit√† per le quali non ha alcun tipo di leva operativa, come ad esempio la ‘roll out strategy’.

La RACI che abbiamo appena visto ed allegata ad un contratto porta a dire che il rapporto cliente/fornitore non √® chiaro. In particolare l’aspettativa del cliente √® che il fornitore si assuma la responsabilit√† per ogni aspetto progettuale, anche quelli su cui obiettivamente non pu√≤ intervenire. La stessa RACI ci dice che il fornitore √® in una posizione di debolezza ed √® disposto ad accertare condizioni inaccettabili pur di aggiudicarsi la commessa. Pessimo presupposto progettuale.