Basta Puntare il Dito—Usa una Matrice RACI (con Suze Haworth)

Leggi la Trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un programma software. Perdonaci eventuali errori di battitura: il bot non è corretto al 100% delle volte.

Ben Aston:

Forse una delle cose più difficili nella gestione dei progetti è che dobbiamo lavorare con... beh, persone, e le persone sono incredibilmente variabili. Siamo incoerenti, egocentrici, inaffidabili e incredibilmente volubili, e sto solo parlando di me stesso. Quindi mi chiedo se i tuoi progetti siano simili ai miei. Quando le cose vanno male, e naturalmente capita prima o poi, può rapidamente trasformarsi in un brutto esercizio di scaricabarile, dove sembra che tutti accusino tutti gli altri di non fare bene il proprio lavoro. Quindi, come possiamo gestire un progetto avendo tutto ciò da affrontare? Oggi lo scoprirai.

Grazie per averci ascoltato. Sono Ben Aston e questo è il Podcast di The Digital Project Manager. Questo podcast è offerto da Clarizen, il leader nei software di project e portfolio management per le aziende. Visita Clarizen.com per saperne di più. Oggi sono qui con Suze Haworth, una delle nostre esperte DPM di The Digital Project Manager. Suze, grazie mille per essere qui con noi.

Suze Haworth:

Grazie, Ben, grazie per avermi invitata.

Ben Aston:

Lasciami introdurre per bene Suze, perché è nuova. Credo sia il nostro primo podcast insieme.

Suze Haworth:

Sì.

Ben Aston:

Suze è una freelance digital project director a Londra, con molta esperienza: lavora nel settore da oltre 13 anni, iniziando come account manager, come me, per poi passare alla gestione di progetti. Ma invece di leggere la tua bio, Suze, puoi raccontarci quali tipi di progetti stai seguendo ora?

Suze Haworth:

In questo momento? Beh, in realtà lo scorso anno sono diventata freelance, quindi ho lavorato, come hai detto, per diversi anni in varie agenzie, ma l'anno scorso ho iniziato a lavorare da freelance. Al momento ho un incarico in un'agenzia a Londra e sto seguendo due grandi progetti: uno è un sistema di design per un grande brand del retail e l'altro è la gestione di un programma di lavoro per un altro brand del retail. Sono progetti abbastanza interessanti.

Ben Aston:

Quindi il retail è la tua specialità?

Suze Haworth:

In realtà lavoro in settori diversi. Ho molta esperienza nel retail, ma anche in broadcasting, associazioni no profit, un po' di tutto, però sì, ultimamente sto lavorando molto con il retail, quindi potremmo dire di sì.

Ben Aston:

Interessante. Nella tua esperienza da freelance, cosa trovi più difficile? Quali sono le sfide più grandi che stai affrontando ora?

Suze Haworth:

Credo che la sfida più grande, e penso sia così per tutti i project manager, sia che devi gestire e fare molte cose diverse di cui sei responsabile. Non solo devi consegnare con successo il progetto, ma devi anche gestire tempi, budget, deliverable del team, i membri del team veri e propri, quindi numerosi problemi di team, e poi chiaramente anche il cliente. È davvero difficile incastrare tutto nel tempo che hai. Spesso mi sembra una continua lotta per inserire tutto in una giornata sola.

Ben Aston:

Hai trovato più difficile il passaggio dal lavoro a tempo indeterminato a quello da freelance? O come ti sei trovata?

Suze Haworth:

Penso che sia diverso, nel senso che come freelance sei più responsabile del tuo tempo, cioè del come ti fai pagare dall'agenzia. Non puoi trovarti nella situazione in cui non puoi dire di no alle cose. Ho imparato che se hai troppi impegni puoi solo fare il possibile e farlo bene, quindi meglio fissare dei limiti, invece che dire sempre sì a tutto.

Ben Aston:

Sì. Quando ero un contractor, anch'io ho vissuto questo. In realtà c'è qualcosa di bello nell'essere contractor: puoi... non hai l'obiettivo della promozione. Certo, vuoi mantenere il contratto e continuare a lavorare, ma non ti interessa impressionare i colleghi come quando sei un dipendente fisso e pensi "meglio dire di sì, altrimenti faccio una brutta figura".

Suze Haworth:

Sì, esattamente. Ovviamente vuoi comunque dare una buona impressione. Il settore è piccolo, tutti conoscono tutti, ma è bello a fine giornata poter dire "ok, le mie ore sono finite" un po' più facilmente rispetto al lavoro a tempo indeterminato.

Ben Aston:

Da quando fai la contractor, in quante aziende diverse hai lavorato?

Suze Haworth:

Finora solo un paio, perché non lo faccio da molto. È stato positivo, perché in quest'agenzia ho potuto lavorare abbastanza a lungo da conoscere bene colleghi e clienti e da seguire i progetti e i conti con costanza.

Ben Aston:

Lavori in sede o in remoto?

Suze Haworth:

In sede. In realtà promuovo il lavoro da remoto con tutti, penso sia importante e possa essere produttivo per molti, ma ho notato che molte agenzie, specialmente a Londra, lavorano ancora soprattutto in sede.

Ben Aston:

Interessante. So che oltre a essere freelance scrivi anche. Hai scritto per DPM, e parteciperai anche al DPM Summit quest'anno. Ci racconti qualcosa?

Suze Haworth:

Certo. Sono davvero entusiasta. L'anno scorso ho parlato al DPM Summit a Las Vegas, quest'anno invece terrò un workshop. È un argomento interessante perché come PM siamo tutti abbastanza ossessionati dalle metodologie, specialmente Agile. Nel workshop parlerò di combinare più approcci, in particolare uno che sto adottando ora: il Dual-Track approach. Prende alcuni aspetti di Agile e li fonde con altri. Parlerò di questo, Kanban, Lean, e di come puoi mescolare diversi approcci nei tuoi progetti, adattando le metodologie esistenti senza doverne seguire una pura o rigida.

Ben Aston:

Bello. È davvero importante, ed è anche quello che... Suze è una delle nostre DPM Experts e parteciperà al nostro corso Mastering Digital Project Management. Se non sai cosa–

Suze Haworth:

Sì, esatto.

Ben Aston:

È in programma questo venerdì, sarà la prima volta di Suze. Una delle cose di cui parliamo nel corso è non fossilizzarsi troppo sul nome della metodologia o sulle etichette–

Suze Haworth:

Sì, esattamente.

Ben Aston:

Alla fine conta trovare il modo migliore per consegnare il lavoro che funzioni per il team, il progetto, il cliente, e essere pragmatici, invece che dogmatici, su Scrum o altri nomi. Alla fine, conta solo il risultato.

Suze Haworth:

Proprio così. Ho visto spesso ossessioni inutili per il processo: si pensa sempre a far calzare il progetto in un “processo” invece di valutare di cosa abbia veramente bisogno il progetto o il prodotto che si sta creando. Ogni progetto è diverso, quindi meglio adattarsi e mescolare.

Ben Aston:

Giusto. Penso che alcuni siano scettici sulle metodologie ibride, ma io non le ho mai viste funzionare al 100% pure.

Suze Haworth:

No, esatto. So che ci sono molte discussioni sulle preferenze personali, ma sono aperta a usarle tutte. Specialmente in agenzia serve davvero un processo ibrido, per le situazioni che si presentano.

Ben Aston:

Al di là di conferenze, articoli, lavoro: ti sei posta degli obiettivi su cui vorresti migliorare quest’anno?

Suze Haworth:

Oddio, è difficile. Ora sono così focalizzata sul presente che a volte è dura pensare al futuro. Però, una grande sfida, come dicevo prima, è imparare a dire di no e cercare di delegare di più e lasciare andare un po’ di responsabilità, cosa che per me non è mai stata semplice. Come PM si tende a essere molto controllanti, quindi delegare è sicuramente un obiettivo a lungo termine.

Ben Aston:

Delegare è difficile, soprattutto da freelance: A, non sai se chi deleghi ti prenderà sul serio, essendo tu “solo” un contractor; B, non hai una storia di lavoro con loro, quindi non sai se puoi davvero delegare.

Suze Haworth:

Esatto.

Ben Aston:

Parliamo di strumenti: lavorando in diversi posti ne avrai provati tanti. C’è qualcosa che ora ti semplifica la vita e che consiglieresti a tutti?

Suze Haworth:

Da freelance, avendo lavorato in molte agenzie, anche da dipendente, ho usato davvero moltissimi strumenti e uso quello che l’azienda sceglie. Non posso dire di aver mai trovato uno strumento perfetto, senza problemi o limiti. Ne ho trovati di utili e altri meno, ma ognuno presenta lati positivi e negativi. L'unico strumento che amo davvero, se così si può chiamare, sono i fogli Google: puoi davvero usarli per tutto, o quasi.

Ben Aston:

Hai mai provato Monday.com?

Suze Haworth:

No, non ancora.

Ben Aston:

Per chi ama gestire su fogli di calcolo, penso che Monday potrebbe piacerti–

Suze Haworth:

Sono una geek.

Ben Aston:

La cosa bella dei fogli è che sono gratuiti, o almeno Google Sheets lo è, e sono molto flessibili. Monday aggiunge solo un livello di automazione e controllo in più. Dovresti dargli un'occhiata: è come fogli di calcolo potenziati.

Suze Haworth:

Lo proverò sicuramente. Sembra perfetto per me.

Ben Aston:

Bene. Parliamo del tuo articolo allora. È da un po’ che lo hai scritto: tornando sul tema centrale, come gestiamo le persone che vogliono sempre prendere il controllo di un progetto o, al contrario, non si assumono nessuna responsabilità? L'articolo di Suze spiega proprio come usare una matrice RACI a questo scopo. Per chi non l’ha letto: cos'è una matrice RACI?

Suze Haworth:

RACI sta per Responsible (Responsabile), Accountable (Supervisore), Consulted (Consultato), Informed (Informato), cioè una semplice matrice dove elenchi le attività o deliverable del progetto associandole ai vari stakeholder o membri del team, assegnando ad ognuno delle quattro lettere un ruolo in ogni attività. Quindi ci sarà qualcuno responsabile, qualcuno supervisore, qualcuno da consultare e qualcuno da informare. È un ottimo modo per assegnare chiaramente la responsabilità, evitando che troppi siano coinvolti in ogni decisione e assicurando chiarezza di chi fa cosa durante il progetto.

Ben Aston:

Uno dei dubbi più frequenti non riguarda chi sia da consultare o informare, ma la confusione tra chi deve essere responsabile e chi accountabile. Come distinguere e gestire chi vuole essere responsabile ma non accountable? Spiegaci come funziona.

Suze Haworth:

È davvero la parte più difficile della RACI, l’ho affrontata spesso. Ed è anche il motivo per cui la matrice a volte diventa laboriosa: serve tempo per capire chi deve ricoprire i vari ruoli. In modo semplice, il responsabile è chi fa l’attività (esegue o la gestisce). L'accountable è chi approva, supervisiona, non fa direttamente. Spesso si tende ad assegnare l’accountable al project manager o product owner, ma bisogna cercare chi sia davvero senior rispetto a quell'attività: per esempio, su design, può essere il direttore creativo (dell’agenzia o del cliente). Non bisogna assegnare sempre tutto il ruolo di accountable al project manager o product owner.

Ben Aston:

È fondamentale, perché l’errore comune è rendere tutti responsabili o accountable. "Serve responsabilità o accountability collettiva" si pensa.

Suze Haworth:

Esatto. E poi si rischia che cinque persone lavorino sulla stessa attività e siano tutte responsabili. Bisogna restringere e snellire i ruoli, perché se si distribuisce tutto a tutti, la RACI perde senso: serve a individuare chiaramente chi è il punto di riferimento su ogni attività.

Ben Aston:

Chi fa realmente il lavoro si individua di solito con facilità. Più difficile, come dicevi, è distinguere tra consultati e informati, perché spesso in realtà la confusione verte tra accountabile e consultato. Ne basta davvero uno accountabile, che abbia l’ultima parola, quasi fosse il controllo di qualità; i consultati possono essere diversi, e gli informati anche di più: a loro basta essere messi a conoscenza (“Ehi, questa è la proposta”).
I consultati sono quelli che possono complicare il progetto, perché hanno voce in capitolo: non devono rispettare le scadenze, ma possono dire la loro. Il vero limite è fra accountable e consultato: la lotta di potere tra chi vuole imporre la propria opinione, ma non ha la responsabilità finale.

Suze Haworth:

Vero, e il problema è che un consultato, avendo un ruolo riconosciuto, pretende di far valere la propria voce. Qui l'accountable è cruciale: è lui a dover guidare la consegna e assicurarsi che i consultati diano input, ma senza far deragliare il progetto con troppi feedback o intoppi.

Ben Aston:

Ma dici la verità: la matrice RACI la usi sempre o è un documento che di solito si lascia perdere? Come evitare che diventi solo una work breakdown structure con nomi associati?

Suze Haworth:

Sono davvero contraria a creare documentazione inutile solo per il gusto di farlo. Se fai una RACI, deve essere utile: va usata. Non crearla all’inizio e dimenticarla. Va consultata e aggiornata durante il progetto, e da rivedere a fine progetto per capire se si è rivelata utile o se va migliorata la prossima volta.

Ben Aston:

Quindi la usi nelle riunioni di status per verificare chi è accountable/responsabile? Oppure come la usi settimana per settimana?

Suze Haworth:

Non la uso sempre nelle riunioni di status. Serve più che altro come riferimento interno per ricordare chi coinvolgere, contattare per un deliverable, o a chi assegnare responsabilità. È uno strumento di supporto, ma può essere utile richiamare i ruoli quando le cose non filano lisce.
Ad esempio, se compare troppa gente che vuole consultare o approvare un'attività, puoi riferirti chiaramente alla matrice e parlare con il referente principale per ricordare gli accordi presi: "Abbiamo costruito insieme questa matrice all’inizio proprio per evitare inefficienze e comunicazioni inutili".

Ben Aston:

Quindi nelle tue matrici RACI coinvolgi sia agenzia che cliente? O ne fai due distinte?

Suze Haworth:

Dipende dal progetto. Se ci sono due grandi team, agenzia e cliente, a volte conviene farne due. Recentemente ho fatto una matrice specifica lato cliente quando c’erano molti stakeholder, perché è importante sapere chi coinvolgere e quando. Se la squadra agenzia è più snella si può rappresentare come un unico blocco. Bisogna sempre adattarla al progetto.
Soprattutto chiediti se la matrice serve davvero: su team piccoli o progetti semplici non è necessaria. Serve quando bisogna gestire molte persone, internamente o lato cliente, e chiarire le aspettative. Va sempre adattata allo scenario.

Ben Aston:

Il bello della RACI è che aiuta a evitare che le cose vengano trascurate. "Perché non sono stato coinvolto? Pensavo toccasse al design annotare il wireframe."
Non è sempre necessario dare al cliente piena visibilità di come gestiamo noi ruoli e responsabilità: spesso creerebbe solo confusione. Ma lato cliente, su team ampi o molto politici, va chiarito chi sia accountable e ricordarlo al bisogno: "Era questo il ruolo all’inizio del progetto? Se qualcosa è cambiato, va aggiornata la matrice, il processo o l’offerta".

Suze Haworth:

Sì, è fondamentale coinvolgere chi avrà ruoli chiave direttamente nella definizione della matrice, progettandola insieme e non in isolamento. Così si evitano incomprensioni e si parte con aspettative chiare su chi fa cosa.

Ben Aston:

In quali casi la RACI smette di funzionare? Quando inizia a sfaldarsi? Cosa dobbiamo monitorare?

Suze Haworth:

Credo siano tre i problemi ricorrenti: se non c’è accordo tra tutti all’inizio e la matrice si crea senza coinvolgere chi avrà i ruoli chiave (solo assegnandoli d’autorità), oppure se viene usata solo come check box iniziale e non più aggiornata. Serve consultarla durante il progetto e rivederla dopo per migliorare quelle future.

Ben Aston:

Domanda: quando le cose si sfaldano (perché succede... si documentano ruoli, ma saltano fuori fraintendimenti, scaricabarile, ecc.), come riporti ordine?

Suze Haworth:

È facile tentare di mostrarla come uno "strumento di accusa", tipo "Hai accettato questo all’inizio", ma non deve essere usata in questo modo. Serve invece a riportare tutti agli accordi di efficienza e chiarezza presi all’inizio: "Se non rispettiamo questa matrice rischiamo di complicare il progetto". Parlarne con chi sta creando confusione, spiegando perché quella struttura era stata adottata, quali sono i rischi e quali ruoli erano stati considerati.

Ben Aston:

Aiuta ricordare alle persone il motivo delle regole: "C’è un motivo se non sei accountable per questo compito: forse non hai le competenze, ad esempio".

Suze Haworth:

E qui la matrice torna utile solo se è stata creata per ottimizzare il progetto: risorse limitate, tempi o budget, servono motivazioni reali per farla. Altrimenti è uno spreco di tempo.

Ben Aston:

Non è facile. Vuoi scaricare un modello di matrice RACI? Suze ne ha preparato uno, assieme a un ottimo esempio tratto da "Il Signore degli Anelli" per spiegare come potrebbe essere applicata a un progetto. Sai, quando abbiamo mandato la newsletter con quell’esempio, qualcuno mi ha scritto indignato: "Non posso credere che perdiate tempo con queste cose". Poi mi ha mandato un’email il giorno dopo: "Ho letto l’articolo, era ottimo! Non mi piace solo ‘Il Signore degli Anelli’."

Suze Haworth:

Lo so! E quando ho creato quella matrice ero sicura di aver sbagliato qualche ruolo! È un esempio volutamente leggero, più per rendere l’idea che per essere perfetto, ma serve ad agganciare il concetto e renderlo comprensibile.

Ben Aston:

La parte interessante è che chi conosce “Il Signore degli Anelli” capisce al volo l’esempio. Ma ovviamente è un argomento divisivo! Comunque, Suze, grazie mille per essere stata con noi, è stato un piacere.

Suze Haworth:

Grazie a voi.

Ben Aston:

Se vuoi partecipare alla discussione, commenta il post oppure vai nella sezione Risorse di TheDigitalProjectManager.com per unirti al nostro team su Slack, dove troverai conversazioni interessanti. E se vuoi sentire ancora Suze, vai nella sezione Formazione di TheDigitalProjectManager.com e iscriviti al prossimo corso di master in digital project management, dove Suze sarà tra i docenti. Grazie per averci ascoltato!