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.
Lascia un commento