Affari Rischiosi (con Kiron Bondale di World Class Productivity)

Leggi la trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un programma software. Ci scusiamo per eventuali errori di battitura, poiché il bot non è sempre preciso al 100%.

Ben Aston:

Quindi il 15% dei progetti IT ha sforamenti di costo del 200% e un ritardo sulla tabella di marcia del 70%. Fa paura, vero? E forse ti suona familiare. La verità è che i progetti fanno paura. I progetti sono intrinsecamente rischiosi, e questo perché stiamo cercando di cambiare le cose. I progetti vanno storti tutto il tempo. E come project manager, siamo il bersaglio facile quando qualcosa va storto. Quindi dovresti aver paura. Dovresti temere il fallimento dei tuoi progetti perché quando hai paura, è molto più probabile che tu faccia di tutto per rendere i tuoi progetti meno spaventosi. Quindi continua ad ascoltare il podcast di oggi per scoprire come puoi usare la gestione dei rischi per rendere i tuoi progetti meno spaventosi così potrai dormire meglio la notte.

Grazie per essere all'ascolto. Sono Ben Aston, fondatore di Digital Project Manager. Benvenuto al Podcast DPM. La nostra missione è aiutare i project manager a raggiungere il successo, aiutare le persone che gestiscono progetti a ottenere risultati migliori. Siamo qui per aiutarti a portare il tuo modo di gestire i progetti al livello successivo. Dai un'occhiata a thedigitalprojectmanager.com per scoprire i nostri corsi di formazione e le risorse offerte tramite l'iscrizione. Questo podcast è offerto da Clarizen, leader nei software di Enterprise Project e Portfolio Management. Visita clarizen.com per saperne di più.

Oggi sono in compagnia di Kiron Bondale. Kiron è un consulente senior per World Class Productivity e si occupa di formazione e consulenza. Ha gestito centinaia di progetti diversi. Ha una vasta esperienza nella gestione dei rischi, è stato pubblicato anche su diverse riviste e parla spesso di Agile. Affronteremo anche questo argomento oggi nel podcast. Grazie mille Kiron per essere con noi oggi.

Kiron Bondale:

Grazie Ben. Sono felice di essere qui.

Ben Aston:

Siamo nel 2020. È un nuovo anno. Sono curioso Kiron, succederà qualcosa di nuovo per te con World Class Productivity in merito alla formazione o alla consulenza che offrite? Quali novità ci sono per te?

Kiron Bondale:

Certamente. Quello che c'è di nuovo per noi è che, alla fine dello scorso anno, come saprai tu e i tuoi iscritti, il PMI ha acquisito il Disciplined Agile Consortium o la loro proprietà intellettuale. C'è molto interesse da parte di PMI nell'integrare le loro offerte, incluse alcune delle certificazioni. Quindi, come organizzazione, inizieremo a fornire corsi allineati con Disciplined Agile. Direi che è uno strumento che crediamo davvero sia una grande soluzione per le aziende che desiderano affrontare una trasformazione agile. Direi che proprio lì si concentreranno i nostri principali sforzi, almeno nel primo e secondo trimestre di quest’anno, sia per me che per la nostra organizzazione.

Ben Aston:

Molto interessante. E quindi, per quanto riguarda la formazione, puoi darci un'idea di come si svolge la vostra formazione?

Kiron Bondale:

Sì, certamente. C'è un'offerta standard che il PMI propone chiamata Disciplined Agile Lean Scrum Master. Si tratta di un workshop di due-quattro giorni a seconda dell'esperienza e del background dei partecipanti; noi lo offriamo nel formato di tre giorni, comprendente Lean così come Disciplined Agile. Una cosa positiva di questa formazione è che offre ai partecipanti la possibilità di fare gratuitamente un tentativo d'esame per diventare Certified Disciplined Agilist. Quindi, frequenti il corso e hai una possibilità gratuita di ottenere la certificazione.

Ben Aston:

Sono curioso di conoscere la tua opinione su queste certificazioni Agile. Io stesso ho lo Scrum Master, che è ovviamente un corso di due giorni, e la mia opinione è che dopo due giorni di formazione, essere certificati mi sembra prematuro. Sono curioso di sapere — ovviamente tu sei quello che eroga la formazione quindi magari non vuoi tirarti la zappa sui piedi. Ma dimmi, in cosa sarà diversa questa formazione rispetto allo Scrum Master, e qual è la tua opinione sulle certificazioni, specialmente nel Mondo Agile?

Kiron Bondale:

Domanda molto interessante, Ben. Proprio oggi, un collega, uno dei miei amici virtuali nell’ambito Agile e Project Management, discutevamo di questo. Il PMI entrando ora nel settore delle certificazioni Agile con Discipline Agile aumenta la "confusione" che già esiste.

Ben Aston:

Già.

Kiron Bondale:

Ci sono più di 300 certificazioni nel mondo agile. Quello che apprezzo di quello che sta facendo PMI è il posizionamento: offre diverse opzioni di certificazione per ogni livello di esperienza. Quella che ho citato, il Certified Discipline Agilist, è per chi ha magari solo la parte formativa e non tanta esperienza pratica.

Ben Aston:

Certo.

Kiron Bondale:

Ma poi, se hai un paio d’anni di esperienza pratica nel dominio Agile, puoi ambire alla certificazione Certified Discipline Agile Practitioner oppure mantenere le certificazioni originali PMI, come la PMI ACP, se hai abbastanza esperienza da allineare la formazione.

Man mano che si sale, ci sono ulteriori offerte Disciplined Agile. Quindi, guardando le organizzazioni che offrono certificazioni, hanno tutte questa strategia a livelli—

Ben Aston:

Già.

Kiron Bondale:

… ed è proprio quello che fa PMI: offre opzioni a seconda di dove ti trovi. Nessuno dirà che basta avere un CSM o un CDA o un’altra credenziale agile entry-level per avere l’esperienza necessaria per lavorare davvero in un team agile. Ma almeno puoi "parlare la stessa lingua". Tuttavia, serve esperienza pratica, e lì si valuta se puntare a credenziali di livello più alto.

Ben Aston:

Chiaro. Quindi, le credenziali stanno cambiando e PMI che entra nel mondo agile è una tendenza. Ci sono altri trend importanti a cui rispondere nel 2020 nell’ambito della gestione dei progetti?

Kiron Bondale:

Credo che l’altra grande novità riguarda i cambiamenti che PMI sta apportando al processo di certificazione PMP. Come probabilmente sai, anche chi segue il tuo podcast, l’esame PMP cambierà a fine giugno 2020 e, con questo cambiamento, PMI passerà a un modello diverso per i corsi di preparazione: in passato i fornitori PMI potevano creare contenuti propri e differenziarsi sulla qualità; ora invece tutto il materiale sarà fornito o licenziato da PMI e gli istruttori dovranno essere certificati PMI. La differenziazione sarà quindi sul prezzo e sui servizi aggiuntivi che i provider offrono rispetto alla dotazione PMI.

Questo dovrebbe livellare il campo da gioco e forse eliminare i piccoli provider meno qualitativi. Per i principali provider, da anni presenti con materiali eccellenti, può essere stato uno shock, ma noi abbiamo scelto da tempo di collaborare con il provider migliore di materiali preparatori PMI e utilizziamo i suoi materiali. Decideremo se continuare così o lavorare direttamente con PMI usando i loro materiali, ma almeno non abbiamo dovuto buttare via un investimento.

Ben Aston:

Ottimo. Guardando avanti al 2021, uno dei trend di cui sento parlare sempre più frequentemente nella gestione dei progetti riguarda gli strumenti di intelligenza artificiale e l’IA che potrebbe, di fatto, sostituire il project manager rendendo il suo ruolo ridondante. Ricordo un articolo di Gartner a riguardo. Qual è la tua opinione sull’emergere di strumenti sempre più intelligenti e sul loro ruolo nella gestione dei progetti e su come cambia il ruolo del project manager?

Kiron Bondale:

Ottima domanda Ben. Personalmente sono ottimista sul valore dell’IA nella professione del project manager. Alcuni temono che presto resteremo senza lavoro.

Ben Aston:

Già.

Kiron Bondale:

Io invece penso che l’intelligenza artificiale permetterà ai project manager di essere più efficaci, perché se guardi cosa fa un project manager, c’è una netta distinzione tra l’amministrazione del progetto—le attività di coordinamento, stesura rapporti, previsioni—e la gestione strategica vera e propria, fatta di relazioni, coinvolgimento degli stakeholder e lavoro sulle persone. Per concentrarsi su questo, bisogna liberarsi dalla burocrazia.

Quindi, per tutto ciò che è reportistica, previsioni, generazione di documentazione, il machine learning e l’IA possono aiutare molto. Faccio il paragone con Star Trek: c’è sempre il computer intelligente, ma non c’è mai un momento in cui tutto l’equipaggio si limita a delegare ogni decisione al computer.

Ben Aston:

Esatto.

Kiron Bondale:

Il computer è una risorsa, fornisce probabilità e consigli, ma il comando resta umano. Lo stesso farà l’IA: sarà un potente strumento di supporto decisionale. Se in una compagnia sono stati fatti centinaia di migliaia di progetti, in futuro l'IA potrà consultare quell’archivio e rispondere a domande come: “Quante volte negli ultimi 10 anni si è verificata una certa situazione e com’è andata a finire?”

Quindi sarà di grande supporto decisionale.

Ben Aston:

Certo.

Kiron Bondale:

Renderà i project manager liberi da tanta burocrazia noiosa, ma consentirà anche di concentrarsi sugli aspetti strategici, che danno maggior valore e gratificazione personale.

Ben Aston:

Parliamo allora di questi aspetti strategici della gestione progetti. Quali parti del ruolo ritieni più strategiche rispetto a quelle più amministrative, come la reportistica? Che cosa dovrebbero sviluppare di più i project manager con l’arrivo di questi nuovi strumenti? Parliamo del ruolo nella comunicazione e collaborazione e di come questo aspetto evolverà.

Kiron Bondale:

Direi che ci sono quattro livelli, quattro domini in cui vedo grandi opportunità se il project manager si libera dall’aspetto amministrativo. Il primo è il coinvolgimento degli stakeholder: in ogni progetto significativo ci sono molte persone da coinvolgere, e il project manager deve tenersi in contatto regolarmente, capire se cambia qualcosa in termini di atteggiamento o influenza. Più ci si dedica a queste relazioni, più aumenta la probabilità di successo del progetto. Il secondo aspetto è il business case: spesso risucchiati dalle difficoltà operative ci si dimentica perché stiamo facendo quel progetto e se realmente porta valore o ritorno. Anche se tutto viene realizzato in tempo e rispettando il budget, se non c’è più un ritorno di business, è meglio fermarsi e chiuderlo.

Un terzo aspetto riguarda il team. Bisogna lavorare per sviluppare un gruppo ad alte performance, secondo il concetto di servant leader o host of leaders ripreso anche da Discipline Agile. Serve tempo per lavorare sul team, sulla sicurezza psicologica e la franchezza radicale, come scrive Daniel Pink in “Drive”. L’IA libererà tempo per questo.

Il quarto e ultimo riguarda la gestione dei rischi. Uno dei problemi che noto è che spesso stakeholder e project manager dicono: “Il rischio è incertezza. Può accadere, ma può anche non succedere, perché preoccuparsi?” I project manager spesso trascurano la gestione dei rischi perché troppo impegnati con report e burocrazia, ma se ci si libera da questi compiti si può investire nella gestione dei rischi, che nei progetti complessi fa la differenza tra successo e fallimento.

Ben Aston:

Già, perfetto. E questo ci porta proprio all’argomento di oggi, ovvero come gestiamo il rischio e come possiamo approcciare la gestione del rischio per aumentare il successo dei nostri progetti. Tornando al principio di questo podcast, voglio ricapitolare perché la gestione del rischio è importante. Kiron, puoi aggiungere qualcosa a quanto dirò. Una delle cose che hai menzionato è che spesso le cose vanno male perché il rischio non è stato gestito bene. Se lo gestiamo in modo efficace, possiamo prevenire problemi e mantenere il team vigile.

Tenere team e stakeholder consapevoli che le cose possono andare male li aiuta a prevenire problemi. Aumenta la trasparenza e la fiducia, evitando brutte sorprese. Se gestiamo bene il rischio, aiuta a raccontare “la storia del progetto”.

I report di stato sono utili, ma se usiamo strumenti come il RAID log e annotiamo i rischi, l’incertezza o la probabilità di eventi negativi, e decidiamo come reagire, abbiamo una traccia che ci aiuta a ricordare e a prendere le difese quando i progetti falliscono e il project manager rischia di essere il capro espiatorio.

Nel tuo articolo hai parlato di diversi tipi di risposta al rischio: evitamento, trasferimento, escalation, mitigazione e accettazione. Esistono dunque varie tecniche. Come si fa a capire quale tecnica usare? Puoi darci dei principi guida?

Kiron Bondale:

Certo, Ben. La gestione del rischio parte sempre dalla propensione al rischio della propria organizzazione. È fondamentale capirla, insieme alla mentalità dei principali stakeholder. Un’organizzazione molto avversa al rischio tenderà a scegliere come strategia l’evitamento del rischio, mentre una più dinamica e competitiva sarà più incline ad assumersi rischi per poter progredire e potrebbe rifiutare strategie di evitamento che implicherebbero tagli di scope o persino cancellazioni di progetto.

Quindi bisogna capire bene qual è la propensione al rischio di organizzazione, sponsor e stakeholder principali. Una volta fatto questo, bisogna analizzare il rischio specifico, usando strumenti di analisi qualitativa e quantitativa: qual è la probabilità che accada? Qual è l’impatto sui risultati attesi del progetto? Possiamo rilevare in anticipo se si sta per realizzare? Servono tutte queste informazioni per fare un’analisi costi-benefici.

Se c’è 1% di possibilità di perdere 1.000$, non conviene spenderne 1.000$ per evitarlo. Ma se la probabilità è del 50% o superiore, forse ne vale la pena investirne un centinaio per proteggerci. Ho visto esempi opposti: aziende estremamente avverse al rischio, che “imbustano” i progetti con così tante precauzioni da paralizzarli, e altre altamente rischiose, che ignorano i rischi fino ai punti critici. Dove mi ero fermato?

Ben Aston:

Ti avevo chiesto di spiegare quando usare le varie tecniche di risposta al rischio.

Kiron Bondale:

Perfetto, riprendo. Quando valutiamo le risposte, come hai detto sono cinque o sei. Per i rischi negativi, conta moltissimo la propensione al rischio dell’organizzazione. In alcune aziende, il default è evitare ogni rischio rilevante, in altre – specie quelle nei mercati competitivi – si preferisce gestire il rischio con strategie meno restrittive. Anche la propensione al rischio di sponsor e stakeholder va considerata: il rischio è incertezza che conta; se la nostra risposta è fuori asse rispetto a quanto tollerato, non otterremo supporto.

Una volta chiarita la propensione al rischio, si fa una valutazione puntuale: impatto potenziale sul progetto, probabilità che accada, possibilità di percepirlo in anticipo. In base a ciò si decide se evitare, mitigare o accettare. Fondamentale è anche l’analisi costi-benefici.

Ben Aston:

Mm-hmm (affirmative).

Kiron Bondale:

Bisogna prendere decisioni intelligenti di investimento. Spesso uso l’analogia dell’assicurazione: se compri un’auto da 40.000$, spendere qualche centinaio per proteggerla appare ragionevole.

Ben Aston:

Giusto.

Kiron Bondale:

Ma se l’assicuratore chiedesse 10.000$ l’anno per un’auto da 40.000$, nessuno la comprerebbe o farebbe quella polizza. Vale anche per il rischio: bisogna fare la stessa valutazione, come si fa per la qualità.

Ben Aston:

Abbiamo parlato di evitamento (“basta non fare la cosa rischiosa”), trasferimento (assicurarsi o dare ad altri il rischio), escalation (avvisare gli stakeholder che qualcosa di rischioso potrebbe capitare), mitigazione (investire per ridurre la probabilità che accada), accettazione (se evitare il rischio costa troppo, si accetta che il problema possa capitare).

Kiron Bondale:

Corretto. Naturalmente, esistono rischi che non vogliamo si realizzino mai: ad esempio la classica situazione di una banca in cui rischia di finire in carcere l’amministratore delegato o appare una notizia catastrofica su un quotidiano nazionale. Per questi rischi, anche spendere somme elevate può avere senso. Escludendo questi casi limite, conta sempre il rapporto costo-beneficio. Investire troppo o troppo poco nella gestione dei rischi può essere dannoso.

Ben Aston:

Parliamo della documentazione usando strumenti come il RAID log (rischi, assunzioni, problemi, dipendenze). Ognuno può sembrare più o meno complesso: ci sono dei RAID log automatizzati che impiegano fino a mezz’ora per essere compilati. Tu che ne pensi? Come dovrebbe essere gestita la documentazione del rischio?

Kiron Bondale:

Suggerisco che la documentazione (come tutta la documentazione di progetto) debba essere proporzionata e adattata al contesto del progetto. Se il progetto dura poche settimane con poche persone coinvolte, occorre meno documentazione rispetto a un progetto molto complesso e lungo. Non esiste una soluzione universale: anche i template aziendali devono essere adattabili. Se si offre un unico template senza istruzioni, si rischia di creare zombie dei template.

Secondo aspetto: nel RAID log o registro dei rischi ci saranno informazioni rilevanti solo per il project manager e il team, e informazioni da condividere con gli stakeholder.

Ben Aston:

Giusto.

Kiron Bondale:

Il rischio è incertezza che conta. Se travolgiamo gli stakeholder di dettagli, perderanno interesse; i team di successo presentano ai decisori le informazioni più rilevanti, estratte dal registro e traducendo in linguaggio accessibile quello che realmente serve a chi deve scegliere. È anche fondamentale che RAID log e registro siano aggiornati e corretti. Se vedo dati vecchi e obsoleti, la funzione di gestione rischi perde credibilità. Vale per ogni informazione che condividiamo: se vale la pena raccoglierla, vale la pena aggiornarla.

Ben Aston:

Parliamo ora di come si compila un RAID log. Perché spesso la gente sa che esiste un template, ma come si utilizza concretamente con il team? Nel nostro RAID log abbiamo ID, stato, date, nome, descrizione, probabilità, impatto, piano di mitigazione, azione, responsabile, e la traccia della decisione presa e della data. Come lo usi con il tuo team? Parliamo del coinvolgimento dei vari stakeholder, dalla raccolta dei rischi alle fasi successive del ciclo di vita del progetto.

Kiron Bondale:

La gestione del rischio avviene lungo tutto il ciclo. All’inizio, con gli stakeholder principali, si fa la prima identificazione e analisi. Con il progredire della pianificazione, si aggiorna. Io consiglio due tipi di “trigger”: uno temporale (es. ogni due settimane, se il progetto è lungo), dove si fa una breve revisione di tutti i rischi e si raccolgono eventuali nuovi rischi da team e stakeholder; e uno événement-based: se si verifica un rischio importante, o un cambiamento critico di progetto (scope, milestone, ecc.), bisogna immediatamente rivedere la lista dei rischi per capire se altri possono essere a rischio imminente o se vanno chiusi o aggiunti nuovi.

Ben Aston:

Bene. E quando la gestione rischi non funziona? Dove vedi i punti deboli? Hai detto che parte del lavoro è raccontare la storia e rendere i rischi contestualizzati per coinvolgere chi deve agire. Ma dove fallisce la gestione del rischio?

Kiron Bondale:

Vedo due casi frequenti. Uno è quando si tratta la gestione del rischio come una procedura burocratica: magari, per governance, si compila il registro ma con rischi e piani di risposta generici, non specifici, senza vero coinvolgimento del team. In pratica, è come non fare nulla. L’altro caso, più raffinato, vede un buon lavoro del team centrale nell’identificazione e risposta, ma chi dovrebbe mettere in pratica le risposte, gli owner, non agisce per mancanza di coinvolgimento vero. Oppure sono troppo impegnati o non interessati e tutto diventa accademico: “Bello il registro, ma niente cambia”. Un terzo caso è quando non si impara dall’esperienza: dovremmo sempre consultare i lesson learned e i report dei problemi nei progetti simili del passato. Spesso manchiamo di “lanciare la rete” abbastanza in là nella fase di identificazione. Insomma: la gestione rischi fallisce se è solo di facciata, se non si agisce, o se si parte da una base troppo ristretta di dati.

Ben Aston:

Molto utile. Vorrei approfondire il tema dell’owner dei rischi. Spesso c’è resistenza a prendersi la responsabilità dei rischi, per paura di dover agire o affrontarne le conseguenze, e spesso ricade tutto sul project manager. Come coinvolgi gli stakeholder nella gestione attiva dei rischi e impedisci che il PM sia responsabile di tutto?

Kiron Bondale:

Bella domanda. Puoi mettere il PM come owner di ogni rischio, puoi anche licenziarlo se i rischi si realizzano, ma chi subisce davvero i danni è l’organizzazione, non il PM. Bisogna far capire il valore del progetto e “vendere” il rischio come un’assicurazione. Per far accettare la responsabilità sugli owner, bisogna evitare di sommergerli di dettagli inutili, scrivere descrizioni di rischio chiare e specifiche, dare tutte le informazioni sul rischio e legare la performance anche ai risultati di progetto. Se un owner ha “skin in the game”, apprezzerà il risultato e agirà. Spesso l’insuccesso della risk response è dovuto al fatto che la persona incaricata non ha nulla da perdere o guadagnare.

Ben Aston:

Condivido. Questi suggerimenti sono davvero preziosi. Mi colpisce in particolare il tema dello storytelling: bisogna rendere il rischio reale, concreto e capire le ripercussioni sulla persona responsabile. Spesso la gestione rischi fallisce perché facciamo solo “copia e incolla” dai progetti passati senza rivedere le lesson learned, e non impegniamo davvero gli stakeholder. Impegnarsi in una gestione rischi continua, non solo all’inizio, ci proteggerà meglio.

Kiron, chi sta iniziando come project manager e non sa bene cosa sia un RAID log né come si gestisce il rischio, qual è la cosa fondamentale da fare perché la gestione del rischio funzioni?

Kiron Bondale:

Fai in modo che sia importante. Puoi registrare mille rischi e mille dettagli, ma se non hanno impatto reale, non vale nulla. Meglio identificare pochi rischi ma che fanno alzare l'attenzione degli stakeholder e portano ad azioni concrete. Fai anche un retrospettivo regolare: l’impegno nella gestione dei rischi sta portando benefici? C’è attenzione, vengono attuate le risposte? Sta calando il profilo di rischio? Se no, cosa si può fare di diverso?

Ben Aston:

Ottimo. Kiron, grazie mille per essere stato con noi oggi.

Kiron Bondale:

Grazie a te, Ben.

Ben Aston:

Cosa ne pensate? Quali sono i vostri trucchi e consigli per gestire i rischi? Scrivetelo nei commenti e fateci sapere cosa vi ha funzionato o dove avete fallito. Se volete imparare di più e crescere professionalmente, unitevi alla nostra community su DPM membership: thedigitalprojectmanager.com/membership per accedere a Team Slack, template, workshop (compresi quelli sui rischi), orari di consulenza, eBook e tanto altro. Se il podcast vi è piaciuto, iscrivetevi e lasciateci una recensione su Apple Podcast. Amiamo i nostri fan e riceviamo poche recensioni anche se sappiamo di avere migliaia di ascoltatori, quindi lasciateci un voto e diteci la vostra. Alla prossima puntata, grazie per averci seguito.