Gestione della TD Risk Based
Come anticipato nel contesto della gestione del portfolio, si ricorda che ogni progetto, programma e portfolio stesso di iniziative, è esposto per intrinseca natura a fattori esogeni ed endogeni di incertezza che denominiamo minacce e opportunità, a seconda del rispettivo impatto negativo o positivo sugli obiettivi progettuali e sulle variabili di prestazione.
Si rende dunque necessaria una proattiva gestione di tali eventi incerti, anche tenendo in considerazione che la gestione dei rischi influenza ed è influenzata da ogni area/macro attività della gestione del portfolio: es. il ribilanciamento delle iniziative, potrebbe mettere a rischio il rispetto dei tempo per l’accesso a fondi esterni di finanziamento di progetto; la ripianificazione del portfolio e delle sue sotto-iniziative richiede un riesame e rivalutazione dei rischi presenti in ciascuna; le resistenze - come vedremo in particolare più avanti – degli stakeholder impattati da transizioni digitali/automazioni – costituiscono una fonte di rischio da considerare e che rafforza la necessità di un’adeguata gestione dei rischi.
Di conseguenza, la gestione dei rischi si applica sia a livello strategico, sia di programma, sia di progetto, sia ancora a livello operativo, in funzione del livello di cambiamento introdotto dai risultati dei progetti. I principi guida della gestione dei rischi prevedono per ciascun livello di iniziativa (progettuale e programmatica) di:
Comprendere il contesto progettuale: obiettivi, stakeholder, cultura organizzativa e prassi di riferimento
Coinvolgere le parti interessate
Definire chiari obiettivi di progetto
Sviluppare l’approccio del progetto alla gestione del rischio
Fornire a cadenza regolare informazioni sui rischi
Definire chiari ruoli e responsabilità nella gestione del rischio.
L’obiettivo nella gestione dei rischi consiste dunque nell’individuare, valutare e gestire con azioni preventive o correttive i fattori di incertezza legati al progetto/programma, per migliorarne le possibilità di successo. Per tale motivo, la gestione del rischio deve svilupparsi come attività cadenzata e iterativa lungo tutto il ciclo di vita dell’iniziativa e appannaggio dei ruoli della governance di progetto/programma.
In primis, come per ogni altra area da gestire nelle iniziative di cambiamento, occorre formalizzare (ovvero pianificare) le modalità con cui i rischi verranno individuati, valutati e gestiti nel ciclo di vita progettuale.
Dunque:
Il piano di gestione dei rischi descrive processi, tecniche di gestione del rischio da applicare e le responsabilità di implementazione del piano stesso. Spesso tali processi e tecniche sono già adottati a livello organizzativo, almeno per la gestione dei rischi legati a cogenze normative come quelli afferenti alla Salute e Sicurezza – nel contesto della Legge 81 – e quelli relativi alla privacy per la gestione e trattamento dati – nel contesto del Regolamento Europeo GDPR.
Il registro dei rischi invece traduce nello specifico contesto di progetto le linee guida censite nel piano di gestione, in modo da consentire in modo trasparente e condiviso agli stakeholder di progetto la registrazione dei rischi di progetto individuati, il tracciamento nel tempo della loro relativa analisi – in termini di impatto e probabilità –, lo stato e le strategie di gestione identificate.
Nel contesto del piano di gestione dei rischi, vengono documentate le attività di gestione come di seguito visivamente rappresentate:
Identificazione dei rischi - significa individuare:
Contesto, cioè gli obiettivi progettuali a rischio;
Rischi, cioè le specifiche minacce e opportunità riferite al contesto che possono compromettere o incrementare il successo dell’iniziativa.
Tra i rischi trasversalmente insistenti sui progetti rientrano:
Mantenimento e miglioramento dei livelli di servizio
Compliance a standard organizzativi interni
Business continuity
Ottimizzazione/riqualificazione dei processi di lavoro
Compliance normativa
Rispetto delle scadenze contrattuali
Responsabilità sociale
Responsabilità ambientale
Risparmio energetico.
A parte questi, quelli inerenti allo specifico contesto progettuale possono essere enucleati attraverso diverse tecniche che includono sia sessioni “creative” di gruppo sia raccolta di fonti interne, tra le quali:
Brainstorming
Analisi documentale
Risk Breakdown Structure (RBS) – Struttura di Scomposizione dei Rischi
Dati storici organizzativi
Parere di esperti (terze parti)
In particolare, è possibile organizzare in forma di categorie i diversi rischi e scomporli in eventi di dettaglio, ricorrendo proprio alla tecnica RBS. Tra le strutture di cui ci si può avvalere a tal fine, utili come punto di partenza per l’individuazione di rischi specifici a partire dalla macro categorizzazione, troviamo la PESTLE, utile per indagare eventuali rischi strategici – quali, ad esempio, incidenza dell’inflazione sul valore dell’investimento, instabilità di indirizzo politico, impatto del progetto e suo output sulla collettività ecc.; altra RBS, utile per indagare fattori endogeni all’organizzazione di progetto e correlati alla qualità della gestione del progetto, alle risorse umane e ai rischi tecnici sulla fattibilità e integrità della soluzione.
Entrambe, possono essere utilizzate per censire i rischi, utilizzando la prima durante la concezione del progetto e la seconda nel corso della sua pianificazione.
Valutazione dei rischi – significa esaminarne probabilità di accadimento e livello di impatto sugli obiettivi di progetto, al fine di comprenderne l’urgenza di trattamento e l’importanza per le scelte anche di eventuale ripianificazione di porzioni del progetto.
Si precisa che la valutazione è appannaggio degli esperti di dominio dello specifico rischio: il responsabile di progetto supporta i processi di gestione e sarà anche responsabile di individuare, esaminare e trattare quelli relativi alla tempistica, risorse e budget di progetto, ma per tutti gli altri individuati è necessario che il loro fattore (probabilità * impatto) e la relativa strategia di risposta sia in carico ai responsabili, competenti in materia.
La valutazione serve quindi a dare priorità di trattamento e a supportare la successiva analisi circa la risposta più appropriata, commisurata al fattore del rischio. In tal senso, uno strumento utile per avere una panoramica della complessiva esposizione di rischio del progetto è dato dalla Matrice aggregata di valutazione dei rischi che rapporta in modo visivo i fattori di rischio calcolati rispetto a tutti gli eventi presi in esame nel periodo di riferimento:
In base alle valorizzazioni cromatiche di fattore calcolato, il team di progetto e – in particolare – la governance deciderà se, quando e in che modo trattare i rischi a maggior esposizione. È bene precisare che le scale di valutazione così come le soglie di esposizione cromaticamente valorizzate, vanno stabilite nel piano di gestione dei rischi, in base alla propensione al rischio organizzativa e alla natura del progetto (complessità, strategicità, cogenza ecc.).
Sulla base dell’esito della valutazione, si avvia la predisposizione delle relative strategie di risposta, almeno per i rischi a maggior fattore (fasce gialle e rosse in matrice).
Pianificazione risposte – significa:
definire le azioni in risposta, al fine eliminare o ridurre le minacce e massimizzare le opportunità;
bilanciare il costo della risposta (o delle risposte) con l’eventuale danno della minaccia, per capire se vale la pena definire una contromisura per lo specifico rischio;
bilanciare il costo della risposta (o delle risposte) con il profitto dell’opportunità, per capire se vale attivare azioni per accrescere l’opportunità;
valutare l’effetto secondario che le risposte possono avere anche sull’ambiente esterno al progetto e sugli stakeholder.
Ovviamente, esistono diversi approcci di risposta standard che guidano i titolari di ogni rischio nell’identificare le risposte appropriate. Tra queste, per la gestione delle minacce, rientrano:
Evitare
Si modificano alcuni aspetti del progetto, come l'ambito, il fornitore, in modo che la minaccia non si verifichi affatto (azzerando in tal modo impatto e “probabilità”)
Mitigare
Mitigazione della probabilità o dell'impatto della minaccia, attraverso azioni proattive: rappresenta la strategia più frequentemente utilizzata; è il caso dell’utilizzo di un sistema di prioritizzazione dei requisiti che supporta il rapido e condiviso accordo circa le porzioni di progetto/soluzione da post-porre o escludere dall’ambito, quando in ritardo; ancora, è il caso della parallelizzazione delle attività nel piano di progetto per comprimere la schedulazione in previsione di sforamento.
Strategia Alternativa (Fallback)
Si adotta un piano alternativo (reattivo) per le azioni da intraprendere solo nel caso in cui rischio si verifichi in modo da ridurne l'impatto: è il caso dei piani di emergenza per rischi sicurezza o del disaster recovery per i rischi – divenuti eventi fattuali – sulla tenuta delle infrastrutture.
Trasferire
Un terzo si assume una parte (o tutto) l'impatto economico derivante dal rischio: è il caso tipico di un’assicurazione, fidejussione o delle penali imputate nei contratti.
Naturalmente, in base allo stato degli indicatori di pre-allarme che incrementano ad esempio la probabilità di un rischio, il responsabile di progetto darà mandato – sentito il parere del titolare del rischio – di implementare la risposta pianificata e registrarne l’esito progressivo sia sul registro sia nel piano di progetto che sicuramente vedrà attività, risorse, tempistiche e budget modificati dall’azione di risposta messa in campo.
È utile precisare che l’adozione di approcci adattivi (agile) con rilasci iterativi-incrementali, approcci prevalente nei progetti di trasformazione digitale, riduce di per sé molti dei fattori di rischio tipici di progetto:
organizzare il piano di progetto in iterazioni – timebox fissi, inamovibili – implica abbattere il rischio di ritardo;
pianificare il dettaglio della delivery (attività tecniche, requisiti dell’incremento atteso, criteri della qualità sui requisiti) a breve termine dalla delivery stessa (tipicamente, la pianificazione avviene il primo giorno del singolo timebox) significa ridurre l’incertezza relativa alla qualità delle informazioni, alla disponibilità delle risorse;
definire, affinare e implementare i requisiti in modo progressivo – per incrementi – in base alle priorità legate alle esigenze organizzative, consente di gestire dinamicamente ed efficacemente eventuali modifiche, cambiamenti alle esigenze e ai requisiti, senza impattare sull’intera sequenza successiva di lavoro, senza richiedere extra effort ed extra budget. I requisiti prioritizzati di iterazione in iterazione, ovvero quelli ad elevata rilevanza per gli utenti e i loro rappresentanti di interesse verranno qualificati per il timebox e rilasciati in delivery al suo termine; quei requisiti ancora da chiarire, organizzare, sviscerare saranno solo censiti nel documento di raccolta – tipicamente, Product Backlog – per essere successivamente indagati e prioritizzati sia in base alle altre esigenze/requisiti registrati nel Backlog sia in base agli incrementi effettivamente rilasciati al termine delle iterazioni precedenti;
ancora, rilasciare in modo frequente – iterativo/incrementale – consente di valutare rapidamente la qualità e la potenzialità dei benefici attesi dalla soluzione; al contrario, il rilascio dell’intero prodotto di progetto solo al termine dello stesso non consente un’analisi costi/benefici progressiva e una correlata strategia di gestione del rischio di fallimento dell’iniziativa e del suo investimento;
infine, il ricorso alla struttura fissa delle iterazioni, connotate da risorse fisse allocate per il singolo timebox e a budget fisso, elimina l’incertezza data dalle stime che tipicamente nei contesti predittivi introducono alea: nella gestione “agile” di progetto, non è più necessario stimare le durate delle attività tecniche, gli effort delle risorse e commisuratamente elaborare le stime delle voci di costo associate; tali parametri di prestazione sono fissi e inamovibili, l’unica dimensione flessibile è l’ambito (cosiddetto “amount of delivery”) rilasciabile, stabilito in modo concordato per iterazione in base alle scale di priorità (tipicamente, MoSCoW).
Se l’approccio adattivo di gestione del progetto riduce o abbatte questi fattori di rischio, è pur vero che esso stesso ne introduce di altri e propri. In particolare:
la presenza e disponibilità temporale costante delle figure di rappresentanza dell’interesse utente e di strategia organizzativa;
la cultura della comunicazione frequente, osmotica, basata sul feedback, scambio informativo costante e negoziazione;
la disponibilità di risorse umane tecnicamente esperte e responsabilizzate sulla delivery, con effort definito fisso per ogni singola iterazione;
la conoscenza e la prassi consolidata dell’agile “way of working” tra i diversi livelli gestione di progetto (direzionale, gestionale e operativo)
rappresentano le principali fonti di minaccia nell’utilizzo dell’approccio adattivo. Tali fonti vanno dunque indagate all’avvio di progetto, al momento della sua concezione, per capire se e quanto spingere sull’acceleratore della realizzazione tecnica, ricorrendo all’agile “way of working”. Per questo – come censito nel Cap. 4 – è necessario condurre una valutazione di rischio specifico sul contesto organizzativo e sul progetto, se si intende adottare l’approccio adattivo, utilizzando la checklist elaborata ad hoc a tal fine e qui referenziata (cfr. Cap. 4, Tabella 1 - Attività in Avvio obbligatorie). In base all’esito di valutazione condotto mediante tale strumento, la governance di progetto viene guidata nell’identificazione di strategie di contenimento dei rischi tipicamente associati agli approcci adattivi, direttamente registrabili nel registro dei rischi di progetto.
Accanto al focus sui rischi e la rispettiva loro gestione rispetto alla scelta degli approcci di governance, vale la pena sottolineare altri due tipici e spesso sottovalutati macro fattori di rischio nei progetti di TD (e non solo), legati alla gestione degli stakeholder impattati e alle resistenze al cambiamento degli stessi rispetto all’adozione del prodotto di progetto.
Censire infatti i rischi legati alle varie categorie di stakeholder impattati dalla soluzione progettuale, che includono tipicamente:
nuove o aggiornate competenze richieste;
revisione dei processi in essere;
aggiornamento delle procedure da adottare;
adeguatezza del dimensionamento dell’organico per la manutenzione della soluzione post-progetto;
consistenza della documentazione della soluzione per il supporto all’uso della soluzione post-progetto,
è strategico per garantire che l’iniziativa produca i benefici per cui è nata e generi il valore atteso. Non sono queste categorie di rischio vanno individuate alla concezione del progetto e indagate in dettaglio durante la sua pianificazione ma soprattutto vanno valutate ricorrendo a indicatori più strutturati rispetto al calcolo standard del fattore (Probabilità * Impatti) visto dianzi: in particolare, capire l’impatto del rischio strategico legato – ad esempio – alla carenza di risorse di supporto o alle resistenze psicologiche e comportamentali degli operatori impattati dai nuovi processi, strumenti e procedure da utilizzare post progetto, è complesso; o, ancora ad esempio, valutare la probabilità della minore produttività del personale durante una transizione verso una nuova tecnologia (output di progetto) è difficile, se non scomponiamo i target di stakeholder impattati dalla stessa; conseguentemente, valutare l’impatto di tale minore produttività prevede di indagare in dettaglio quali processi/attività potrebbero essere impattati per singolo gruppo di stakeholder. Data questa complessità di indagine, è quindi opportuno dotarsi di una tecnica di valutazione sistemica e più articolata quale quella che presentiamo di seguito, denominata «Stakeholder Impact Assessment» e qui tradotta in «Valutazione di impatto per stakeholder».
Questo strumento può essere utilizzato per comprendere in che modo un cambiamento in un’area organizzativa può avere un impatto su altre e che tipo di riallineamento strategico potrebbe essere necessario intra-progetto e post-progetto. Partire dalla valutazione degli stakeholder esamina la portata del cambiamento e identifica le persone e le aree chiave che devono essere coinvolte per realizzare il cambiamento:
Il primo step consiste nel descrivere in che modo ogni gruppo di stakeholder è impattato dal prodotto del progetto in termini di competenze, modalità operative, responsabilità, strumenti ecc. ovviamente, propedeutico a tale passaggio, c’è l’individuazione iniziale di ogni gruppo di stakeholder di tipo “utente”, inteso come soggetto che:
beneficiario del servizio (es. cittadino a fronte della digitalizzazione di certificati anagrafici)
utilizzerà la soluzione per fornire il servizio (es. operatore di sportello)
fornisce supporto informativo/procedurale al beneficiario (es. servizio URP, customer care)
interviene sulla manutenzione ordinaria dell’infrastruttura (es. servizio IT).
Il secondo step consiste nell’approfondire l’analisi del primo step, rivalutando in dettaglio per singolo gruppo di stakeholder la natura specifica dell’impatto, esaminando le seguenti dimensioni organizzative:
impatto sul ruolo e le responsabilità;
impatto sulla natura e modalità del lavoro;
impatto sui comportamenti professionali e le performances;
impatto sul flusso di comunicazione, informazione e scambio con attori intra-area e trans-area organizzativa;
impatto sulle conoscenze, abilità e competenze.
Il terzo step conclusivo consiste ora nel poter determinare efficacemente la severità di impatto del cambiamento, ricorrendo agli indicatori di valutazione:
Complessità (su scala qualitativa, bassa-media-alta): data dal numero di attività/processi/competenze impattate dal cambiamento;
Copertura (su medesima scala): calcolata sulla percentuale di persone impattate dal cambiamento appartenenti a ciascun gruppo esaminato.
Indagare l’impatto del cambiamento per singolo stakeholder attraverso questa ottica multidimensionale, supporta la pianificazione di contromisure per la gestione dei relativi rischi (cosiddette «barriere» al cambiamento), aiutando così a disegnare il piano di gestione del cambiamento, ovvero a organizzare le attività di accompagnamento al cambiamento organizzativo che dovranno abbracciare l’intera durata del progetto e mantenersi post-progetto, finché l’organizzazione non avrà ri-consolidato il proprio modus operandi, adottando in modo efficace e sistematiche le nuove prassi e modalità operative derivanti dal rilascio della soluzione progettuale.
Le attività dunque identificabili nel piano di gestione del cambiamento organizzativo saranno di natura preventiva (derivanti da questa analisi e dalla proattiva gestione del rischio della resistenza al cambiamento) e saranno volte a garantire la continuità dei servizi durante la transizione della soluzione progettuale, l’utilizzo efficace della soluzione di progetto, l’adozione di nuove procedure, le riduzione delle resistenze al cambiamento di comportamenti e abitudini consolidati, l’acquisizione delle competenze necessarie a fruire e ad adottare la soluzione. La formalizzazione di questa analisi con la “Valutazione di impatto per stakeholder” e le conseguenti strategie di mitigazione dei rischi di resistenza e sfruttamento delle opportunità di cambiamento/miglioramento derivanti dal progetto e dal suo output, rappresentano propriamente i contenuti e la struttura del “Piano di implementazione del cambiamento” suggerito tra le misure necessarie durante la pianificazione nel successivo Cap. 4 e richiamato come modello documentale allegato in Tabella 2 - Elenco modelli/strumenti gestione progetto nel Cap. 4.
Ultimo aggiornamento