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.

Rispondere alle RFI

Arriva in azienda un richiesta di informazioni da parte di un cliente, la classica RFI. La macchina commerciale si mette in motto, account, commerciali, sales, presale, team tecnici si mettono al lavoro per rispondere al cliente e superare il primo scoglio: la qualificazione per arrivare alla gara, la famigerata RFP. Come rispondere? Che taglio dare? Mostrarsi capaci, validi e poco costosi è un must, ma proporre la luna per 4 noccioline ha senso? E’ efficace?

Come funzionano le RFI viste dal cliente? Che obiettivi ha il cliente? In genere una RFI serve al cliente per avere un’idea di massima della fattibilità tecnica, sostenibilità economica di un progetto oltre all’individuazione dei fornitori che parteciperanno a una gara. Se il cliente ha già le idee chiare procede con una gara senza perdere tempo con una RFI. Quindi in genere, sottolineo in genere, l’RFI contiene alcune idee e spunti che il cliente vuole portare avanti e chiede ai fornitori aiuto per dare concrettezza alle idee. Per il cliente un’RFI è un modo veloce per scremare i fornitori e individuare quelli che meglio capiscono le esigenze e che propongono soluzioni fuori dagli schemi. Quest’ultimo punto è secondo fondamentale. Nel ruolo “da cliente” non ho mai proposto RFI su temi già noti. Non ha senso ad esempio inviare ai fornitori un’RFI per un CMS, a meno che il CMS in questone debba avere caratteristiche innovative.

Per il fornitore l’ansia da prestazione può essere forte, soprattutto su clienti nuovi. La tentazione di rispondere in modo affermativo ed esagento a qualsiasi domanda è forte. Partendo dal presupposto che nella tecnologia e in particolare informatica si può fare qualsiasi cosa, la risposta che non sarebbe neanche tanto scorretta. Confezionando le frasi nel modo corretto con ‘si può fare’, ‘la piattaforma è predisposta’, ‘abbiamo esperienza’ si riesce a proporre qualsiasi cosa, anche la luna. Avere una quotazione di massima sensata durante un RFI è quasi impossibile. In genere le informazioni richieste dal cliente sono molto generiche e offrono spazio per diverse proposte di soluzioni. La risposta corretta dovrebbe essere da tanto a poco, con una forbice enorme legata all’assenza di requisiti di dettaglio. stesso per una eventuale pianificazione delle attività.

Ovviamente ognuno risponde a un RFI come meglio ritiene opportuno e ho visto RFI (ma anche RFP) in cui la luna veniva proposta per 4 noccioline e i costi di progetto che lievitano in modo esponenziale. La risposta a un RFI deve contenere gli spunti di innovazione che il fornitore può al cliente, evidenziare in modo chiaro gli asset presenti e idee che devono essere sviluppate insieme (a 4 mani con il cliente), un indicazione di quando può durare e ha senso che costi e duri un’iniziativa progettuale basandosi su esperienze analoghe e senza calare questa valutazione sul contesto specifico perché ovviamente non ha senso per assenza di un requisito chiaro.

Per me l’obiettivo della risposta è fornire elementi al cliente per capire se c’è un match tra le sue idee e l’impostazione del fornitore. Arrivare a partecipare alla gara deve essere la conseguenza del ‘match’ cliente/fornitore, non l’obiettivo della risposta al RFI. E’ una sottile differenza ma molto importante. Rispondere al RFI con l’obiettivo di arrivare alla gara porta il fornitore a proporre la luna per 4 noccioline. La risposta dovrebbe essere chiara e trasparente e basata su ciò che il fornitore è in grado fare e non esclusivamente sulle aspettative del cliente. Aggiungerei anche breve, la risposta deve essere breve. Va sempre ipotizzato che il cliente ha inviato all’RFI a diversi fornitori, più di quelli che partecipano a una gara, a volte anche più di 10. L’obiettivo del cliente è chiarirsi le idee velocemente per definire il contenuto di una gara. Se le risposte sono lunghe e confuse vengono archiviate velocemente.

Aspettative e requisiti

A volte con disappunto il cliente comunica che il risultato non soddisfa le aspettative, eppure tutti i requisiti tracciati nelle fasi preliminari sono stati correttamene implementati e accettati dal cliente.

Quello descritto è un rischio molto concreto dell’approccio tradizionale waterfall su progetti di carattere innovativo. Le macro fasi tipiche waterfall prevedono: analisi, disegno, implementazione e test (più altre non rilavanti per l’argomento). Nella fase di analisi dei requisiti l’interazione cliente/fornitore è molto intensa ed è il momento in cui il cliente trasmette al fornitore le proprie necessità e aspettative. Questa fase inizia con un processo più o meno formale in cui il cliente comunica “cosa” si aspetta che il sistema faccia e termina con un processo formale in cui il fornitori descrive “come” intende implementare le richieste cliente. Il documento che descrive “cosa” si aspetta il cliente, ossia le aspettative del cliente, è il documento dei requisiti. Il documento che descrive “come” viene implementato il requisito è il documento di analisi tecnico-funzionale.

Si arriva alla fine dello sviluppo e l’amara sorpresa per cliente e fornitore è che il sistema sviluppato non soddisfa le aspettative. I costi per risolvere una situazione come questa sono molto alti, occorre mettere in campo numerosi giorni uomo per smontare quanto implementato e implementare in modo diverso. La ricerca delle “responsabilità” diventa quindi una missione per cliente e fornitore.

L’origine di questa situazione è legata a queste due situazioni:

  1. Il cliente non ha espresso i requisiti con sufficiente dettaglio. Il livello di dettaglio dei requisiti è fondamentale e anche nella vita quotidiana e un approccio superficiale può mettere in difficoltà. Immaginate di voler comprare una macchina, descrivete ogni singolo dettaglio vi viene in mente, colore, optional, motorizzazione… ma non esprimete nulla sulla ruota di scorta. Date per scontato che arrivi il kit riparazione e invece arriva il ruotino.
  2. L’analisi non è sufficientemente dettagliata per consentire al cliente di capire gli impatti e le implicazione di quello che verrà implementato. Nel esempio di prima supponiamo che il cliente specifica anche che desidera il kit di riparazione, perché sa che è più pratico. Quando riceve il veicolo scopre che i tagli non possono essere riparati con il kit riparazione, si aspettava di poter risolvere qualsiasi foratura.

Al di là della responsabilità formale, ciò che vorremo è evitare che si presenti una situazione di macato soddisfacimento delle aspettative. Il problema si presenta soprattutto nei progetti waterfall e si accentua se il progetto ha carattere di innovazione per il cliente. L’innovazione infatti non consente al cliente di mettere a fuoco tutti gli aspetti del nuovo sistema, soprattutto gli impatti sui processi interni, ruoli e attività. Il requisito diventa spesso vago e molto generico con repentini cambi di idea e prospettiva. E’ qui che il fornitore dovrebbe intervenire con un approccio Agile, scomponendo il progetto in Sprint, con time frame limitati aiuta focalizzare su singole tematiche più gestibili. Inoltre al termine dello Sprint abbiamo un risultato tangibile da condividere con il cliente.

La principale critica a quest’approccio è la poca visibilità di insieme e il fatto che potrebbero essere necessari numerosi re-work con conseguente aumento dei costi. La seconda critica mossa è la difficoltà se non impossibilità ad avere una stima dei costi complessivi e del tempi necessario. In effetti entrambe le critiche sono corrette in un progetto Waterfall guida lo scope/perimetro, il tempo e i costi ne sono una conseguenza del perimetro. E’ bene ricordare sempre che un approccio Waterfall si applica bene (leggesi: rispetto tempi, costi) solo se il perimetro di progetto è ben definito, dettagliato e con poche variazioni nel tempo.

In un progetto Agile i dati certi sono la durata di uno Sprint e la composizione del team, tutto il resto è flessibile e viene determinato al proseguire delle attività. Questa flessibilità ha il vantaggio di ridurre il rischio di arrivare a fine lavoro e scoprire che la soluzione non soddisfa le aspettative, consente di effettuare cambi di direzione in corsa e rende quasi impossibile una stima del impegno complessivo a inizio lavori.

RACI: Accountable vs. Responsible

Un limite tutto italiano

Una delle digressioni più comuni sulle matrici RACI riguarda la distinzione tra Accountable e Responsible, entrambi termini vengono tradotti in italiano come “responsabile”. Questo spesso genera confusione anche perché non sempre viene fatta chiarezza e nelle discussioni ci si dimentica di usare i termini inglesi durante. L’equivoco è dietro l’angolo e rischia di infiammare gli animi. Basta la domanda o l’affermazione interpretabile: “Sei tu il responsabile dell’attività XYZ?” e la miccia difficile da spegnere è innescata.

Chi ha un minimo di basi sa che una matrice RACI ammette un solo “Accountable”,  la persona con il compito di decidere e approvare il lavoro, e molti “Responsible”, le persone che materialmente eseguono il lavoro. Nel caso di un cantiere edile il capo cantiere è la persona “Accountable”, mentre i muratori sono “Responsible”. Il primo è responsabile per l’esito del lavoro, i secondi sono responsabili nel eseguirlo. Se l’attività non è eseguita correttamente il primo ad accorgersene deve essere l’ “Accountable” ed è la persona che interviene se i “Responsible”, ovvero chi esegue il lavoro non lo fa correttamente.

Ecco, tutto questo in italiano è molto più complesso da esprimere perché mancano i termini adeguati. Il capo cantiere è responsabile, ma lo sono anche i muratori. La sottile differenza tra decisore ed esecutore viene a mancare quando si parla di responsabilità.

Può sembrare una banalità ma questo ha diverse ripercussioni pratiche. L’assenza nel linguaggi di questa distinzione porta i responsabili “Accountable” e i responsabili “Responsible” a sentirsi meno responsabili gli uni per le decisioni da prendere, gli altri nell’esecuzione dell’attività. Di fatto si creano degli alibi. Parlando con chi è accountable ricevo spesso delle risposte “ma sono loro responsabili per l’attività, perché chiedi a me” e dall’altro lato parlando con chi è “Responsible” ricevo come risposta il rovescio della medaglia “perché chiedi a noi è il responsabile dell’attività, noi siamo esecutori facciamo quello che ci viene detto di fare”.

In realtà a ben vedere il limite non è solo linguistico, è un limite mentale, per gli italiani in una RACI il“Responsible” e“Accountable” sono la medesima cosa. Noi italiani prediligiamo il “one man show”, la piccola imprenditoria in italia dilaga anche per questo.

PMP vs. Agile

Anche di recente mi sono ritrovato coinvolto in una discussione in cui le metodologie Agile sono state definite come destrutturate e prive delle caratteristiche necessarie al raggiungimento di un obiettivo. Diciamo come una piuma la vento, che si fa trasportare in tutta leggerezza e svolazza senza meta. Dall’altro lato qualcuno ha descritto le dottrine PMI come qualcosa di farraginoso e talmente strutturato da fornire alibi a chiunque per il mancato raggiungimento degli obiettivi. Credo che per entrambe le posizioni la verità sta nel giusto equilibrio.

La gestione dei progetto con metodologie tradizionali si presta bene quando c’è una buona conoscenza del dominio applicativo oggetto del progetto. Se devo asfaltare una strada, con tutte le difficoltà che posso incontrare il perimetro è ben definito e la conoscenza è ben consolidata. Una delle prime lezioni del PMBOK, il libro che descrive i processi PMI, dice che è compito del PM con il team di progetto individuare quali di tutti i processi sono necessari per il progetto e con quale livello di implementarli. Ad esempio per un progetto privo di rischi (o pochi e noti) non predispongo un registro dei rischi. Per usare una metafora, la gestione progetti tradizionale è come una vacanza in macchina, pianifico le tappe, le soste, gli alberghi. Posso ri-pianificare se un posto non mi piace e voglio scappare, avrò da affrontare degli imprevisti, una gomma bucata, lo sciopero dei benzinai, ma in un modo o nell’altro riuscirò a visitare i posti che mi sono prefissato.

Agile si applica quando l’incertezza è tale da richiedere costanti variazioni a piani di progetto con eventuale rivisitazione del perimetro. Di fatto è come separare il progetto in tanti piccoli progetti di poche settimane (sprint) che consentono di verificare costantemente se si procede nella direzione giusta mantenendo sotto controllo i tempi. In ogni sprint ho tutte le fasi tipiche gestione progetti tradizionle, compresse nel tempo e quindi con formalismi più snelli. Mi azzardo a dire, irritando i puristi) che per alcuni versi “Agile” è più strutturato delle metodologie PM tradizionali, direi che si aggiunge alle metodologie tradizionali come un add-on. Anche usando metodologie Agile posso avere un piano dei rischi un registro degli stakeholder o qualsiasi altro strumento PM che ritengo utile. Sempre usando una metafora, “Agile” è come una vacanza in barca a vela, quando sono in navigazione devo fare il punto nave ogni due ore per correggere la rotta e se il vento e corrente non sono favorevoli rispetto a dove voglio arrivare, può essere che debba cambiare destinazione. Ma la cambusa devo averla pianificata bene secondo un approccio “tradizionale”.

Riassumo:

  • se ho un vincolo forte sul perimento di progetto ma posso variare i tempi e costi di progetto adotterò un approccio tradizionale.
  • se ho un vincolo forte sui tempi ma ho la possibilità di variare il perimetro e i costi adotterò un approccio agile. (Questo approccio è tipico delle newco e dei progetti innovativi perché essendo “nuovi” è molto improbabile riuscire a definire a priori il dettaglio delle caratteristiche)

L’ultima osservazione, nel mondo ideale esiste un progetto che rispetta tempi, costi, perimetro e qualità, nel mondo reale non ne ho mai visti. Ma ho visto molti progetti di successo, sono quelli che soddisfano le aspettative del cliente.

WP to LinkedIn Auto Publish Powered By : XYZScripts.com