Operazione: Identificazione e valutazione del rischio
Questo compito descrive come identificare, analizzare ed assegnare una priorità ai rischi di un progetto, definire le adeguate strategie di gestione del rischio, e come riportarle nel relativo RL (Risk List, elenco dei rischi).
Scopo
  • Identificazione, analisi ed assegnazione di una priorità ai rischi di un progetto
  • Definizione delle strategie di gestione del rischio adeguate
  • Aggiornamento dell'elenco dei rischi in modo che rifletta lo stato attuale del progetto
Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio:
  • Nessuno
Facoltativo: Esterno:
  • Nessuno
Output
Passi
Identificazione dei rischi potenziali
Scopo Creare un inventario di 'ciò che può andar male' in un progetto. 

Per avviare l'elenco dei rischi (nella fase di inizio validità):

Riunire il team del progetto (che in questa fase dovrebbe essere relativamente ridotto, se vi sono più di cinque o sette persone, limitare il processo di valutazione del rischio ai leader dell'attività).

In fase di identificazione dei rischi si considera 'cosa può andare male'. In generale, logicamente, tutto può andare male. Il punto è non impostare una visione pessimistica del progetto, ma identificare le barriere sulla strada della sua riuscita così da ridurle o eliminarle. Per ulteriori informazioni, consultare Linea guida del prodotto di lavoro: Elenco dei rischi.

Più in dettaglio, si cercano gli eventi che potrebbero ridurre le probabilità di produrre il progetto con le funzioni ed i requisiti di qualità corretti, in tempo e rispettando il budget.

Nelle riunioni del team del progetto, richiedere a ciascun partecipante di identificare un potenziale rischio per il progetto. Sono consentite domande chiarificatrici, ma il rischio non va valutato o commentato dal gruppo. Continuare finquando non vengono identificati altri rischi.

Coinvolgere tutte le parti in questo processo, senza preoccuparsi troppo della forma o di eventuali duplicati, si potrà ripulire l'elenco successivamente. Utilizzare gruppi omogenei di persone (clienti, utenti, personale tecnico e così via). Si facilità così il processo di raccolta dei rischi, le persone sono meno inibite con i propri pari (in mansioni e gerarchia) che in un ambiente misto.

Chiarire a tutti i partecipanti che far emergere un rischio non significa in alcun modo candidarsi alla sua risoluzione. Se la segnalazione di un potenziale rischio dovesse significare farsi carico della sua risoluzione, nessuno ne identificherebbe alcuno (o i rischi evidenziati sarebbero banali).

Per cominciare provare con un elenco dei rischi generico come quello incluso in Assessment and Control of Software Risks di Capers Jones [JON94] oppure in the Taxonomy-Based Risk Identification definita dal Software Engineering Institute [CAR93]. Far circolare l'elenco dei rischi: la visualizzazione di ciò che è stato già identificato spesso facilita le persone ad identificarne altri.

Per aggiornare l'elenco dei rischi (nelle fasi successive):

È possibile sollecitare suggerimenti come mostrato in precedenza. Ma generalmente, sulla base dell'elenco esistente di esempio, i nuovi rischi verranno identificati dai membri del team esistente, e raccolti nella normale valutazione dello stato relativa al progetto. Consultare Compito: Valutazione iterazioni.

Analisi ed assegnazione delle priorità ai rischi
Scopo Combinare i rischi simili (per ridurre la dimensione dell'elenco dei rischi).
Classificare i rischi in base al loro impatto sul progetto. 

Quando si trovano più rischi, considerare l'elenco dei rischi come un gruppo, per vedere se vi siano raggruppamenti naturali (ricorrenze dello stesso rischio), e, dove possibile, combinare i rischi in modo da eliminare i duplicati. A volte, i rischi identificati potranno essere sintomi di rischi più importanti, in questo caso, raggruppare i rischi collegati in un rischio più importante.

Le tecniche di gestione del rischio quantitativo consigliano di assegnare le priorità ai rischi in base alla esposizione complessiva da questo rappresentata per il progetto. Per determinare l'esposizione di ciascun rischio il gruppo dovrà valutare le seguenti informazioni:

Impatto del rischio  Lo scostamento dal piano di pianificazione, impegno o costi se si verificasse il rischio 
Probabilità che si verifichi  La probabilità che il rischio si verifichi effettivamente (solitamente espresso in percentuale) 
Esposizione al rischio  Calcolata moltiplicando l'impatto per la probabilità che si verifichi 

In qualità di gruppo, l'esposizione di ciascun rischio deve essere ricavata tramite consenso. Differenze di opinione significative devono essere discusse per vedere se tutti interpretano il rischio allo stesso modo. Solitamente questa informazione è inclusa come colonna in un Elenco dei rischi tabulare.

È nella natura umana preoccuparsi dei rischi con impatto maggiore, ma se questi hanno poche probabilità di verificarsi sono in realtà meno importanti di rischi moderati spesso trascurati. Considerando sia l'impatto del rischio che la sua probabilità di avvenire, si permette ai responsabili di progetto di concentrare il proprio impegno di gestione del rischio sulle aree che maggiormente influenzano la produzione del progetto.

Una volta determinata l'esposizione dei diversi rischi, è possibile organizzarli in ordine decrescente di esposizione in modo da creare un Elenco dei rischi con classifica.

Siccome la stima delle probabilità e delle spese è di per sé costosa e rischiosa, è solitamente opportuno misurare unicamente l'impatto dei primi 10 o 20 rischi. In progetti più piccoli è possibile considerare meno rischi, mentre progetti più grandi presentano un 'ambito di rischio' maggiore e di conseguenza hanno un numero maggiore di rischi rilevanti.

Oltre a classificare i rischi in ordine decrescente di esposizione, è possibile anche raggrupparli in categorie in base alla dimensione del loro impatto sul progetto (potenza del rischio). In molti casi sono sufficienti 5 categorie:

  1. Alto
  2. Significativo
  3. Moderato
  4. Lieve
  5. Basso

Documentare i rischi e distribuirli a tutti i membri del team del progetto.

Identificazione di strategie di elusione del rischio
Scopo Riorganizzare il progetto in modo da eliminare i rischi 

Per quanto non sempre possibile, a volte si possono evitare i rischi del tutto. Spesso il rischio è causato da uno scadente ambito di sistema; se si può ridurre l'ambito del sistema (eliminando requisiti non essenziali), una serie di sezioni dell'elenco dei rischi verranno a cadere assieme ai requisiti eliminati. Non ultimo il rischio di non avere risorse sufficienti (compreso il tempo) per il lavoro.

In altri casi si potrà prevedere l'acquisizione di materiale tecnologico per ridurre il rischio nella generazione di determinate funzionalità, una forma di elusione del rischio in cui un insieme di rischi (quelli legati alla generazione di una tecnologia) viene scambiato per un altro (quelli legati alla dipendenza di fattori fuori dal proprio controllo).

In fine il rischio può essere trasferito ad un'altra organizzazione.

Identificazione di strategie di attenuazione del rischio
Scopo Sviluppo di azioni per l'attenuazione dei rischi, cioè per ridurre l'impatto del rischio. 

Per i rischi diretti, cioè   i rischi sui quali il progetto ha un livello di controllo, identificare quali azioni saranno intraprese per ridurre la probabilità che si verifichi, o per ridurre il suo impatto sul progetto (strategie di attenuazione). Solitamente, il rischio è generato da una mancanza di informazioni; spesso la strategia di attenuazione consiste nel approfondire l'argomento per ridurre le incertezze.

Vi sono rischi per i quali devono essere eseguite delle azioni perché si materializzino o scompaiano. In un processo di sviluppo iterativo, allocare tali azioni nelle prime iterazioni, per attenuare il rischio il prima possibile. Confrontare il rischio al più presto possibile. Se il rischio è nella forma "X potrebbe non funzionare come pianificato?", provare X il prima possibile.

Esempi:

  • Per ridurre il rischio che i prodotti X e Y possano non essere integrati, verrà costruito un prototipo per verificare la difficoltà di integrazione. Le seguenti funzioni (da enumerare in un elenco) verranno verificate per assicurare che l'integrazione riesca.
  • Per ridurre il rischio che il Database A possa funzionare in modo non adeguato, si verificheranno le sue prestazioni con una serie di test che modelleranno il carico di lavoro dell'applicazione di destinazione.
  • Per ridurre il rischio che lo strumento di test Z non riesca ad eseguire un test di regressione dell'applicazione, lo acquisiremo e lo utilizzeremo nella seguente iterazione.

Il risultato di queste azioni deve essere quello di ridurre la probabilità che determinati rischi si verifichino, possibilmente vicino allo zero. Nei casi in cui il rischio sia confermato, si agisce con un piano contingente (Consultare Identificazione di strategie contingenti).

Identificazione di strategie contingenti
Scopo Sviluppare piani alternativi 

Per ciascun rischio, anche in presenza di un piano di attenuazione, si devono definire le azioni da intraprendere quando o se il rischio si dovesse materializzare, cioè quando diventa un problema, nel gergo assicurativo un 'evento di perdita'. Questo viene comunemente chiamato "piano 'B'" o piano contingente. Un piano contingente è necessario quando l'elusione, il trasferimento o l'attenuazione del rischio non siano riusciti, ed è necessario affrontare il rischio frontalmente. Tale eventualità si verifica solitamente con i rischi indiretti, cioè i rischi sui quali il progetto non ha alcun controllo, oppure quando le strategie di attenuazione sono troppo dispendiose da realizzare.

Il piano contingente deve considerare:

Rischio 

Indicatore 

Azione 

Qual'è il rischio?  Come si capisce che il rischio si è realizzato? Come si riconosce "l'evento di perdita"?  Cosa si deve fare per affrontare "l'evento di perdita" (come si può arrestare il "sanguinamento"?) 

Identificazione degli indicatori di rischio

Alcuni rischi possono essere controllati utilizzando i valori del progetto, verificando la tendenza e la soglia; ad esempio:

  • Rilavorazione rimasta troppo elevata
  • Danni troppo elevati
  • Spesa effettiva al di sopra delle previsioni

Alcuni rischi possono essere controllati tramite i requisiti del progetto ed i risultati dei test; ad esempio:

  • Tempo di risposta di un ordine di grandezza superiore ai requisiti.

Alcuni rischi sono associati a determinati eventi; ad esempio:

  • Un componente software che non viene consegnato in tempo da terze parti.

Ci sono molti altri indicatori più "leggeri", nessuno dei quali potrà diagnosticare completamente il problema. Ad esempio, c'è sempre il rischio di un abbassamento di morale (in realtà, in determinati punti del progetto è quasi prevedibile). Esistono diversi indicatori: borbottio, "umore nero", scadenze non rispettate, bassa qualità e così via. Nessuna di queste misurazioni è un indicatore certo; scherzare sulla futilità di un risultato può essere un modo salutare per alleviare lo stress, ma se diventa continuo, potrebbe essere un segnale che il team avverte un crescente senso di giudizio incombente.

Ascoltare tutti gli indicatori senza giudicare. È facile etichettare un portatore di 'cattive notizie' come qualcuno che ha un atteggiamento sbagliato; dietro il cinismo si cela spesso qualche verità. Spesso, 'il portatore di cattive notizie' si comporta come la 'coscienza del progetto'. Molte persone vogliono che il progetto riesca, e sono frustrati quando la tendenza va in un'altra direzione.

Identificazione delle "Azioni di perdita", o "piano B"

Nei casi più semplici il piano contingente enumera soluzioni alternative. L'impatto consiste solitamente nei costi ed nei ritardi derivanti dalla dismissione della soluzione attuale e dalla implementazione della nuova.

Per gli altri rischi "leggeri" spesso non c'è un'unica azione da intraprendere quando si verifica una perdita, ma diverse. Se si verifica un abbassamento del morale, ad esempio, è meglio prenderne atto della condizione e riunirsi in gruppo per discutere degli atteggiamenti prevalenti del progetto. Ascoltare le preoccupazioni, identificare i problemi, ed in generale lasciare che le persone si sfoghino. Dopo una adeguata dose di sfoghi, però, procedere all'identificazione dei motivi di preoccupazione. Utilizzare l'elenco dei rischi per indirizzare la discussione. Tradurre le preoccupazioni in un piano di azioni concrete assegnando nuove priorità ai rischi e riformulando i piani di iterazione per affrontare i rischi maggiori in modo sistematico. Azioni positive hanno un effetto più forte di parole positive (ma vuote).

A parte il morale del momento, il verificarsi di una perdita ha un lato positivo: forza la necessità di agire. Troppo spesso si pospongono i rischi ignorandoli, cullati verso il compiacimento dalla calma apparente. Quando si verifica un evento di perdita, è richiesto un intervento. Il rischio non è più tale, non c'è più incertezza sulla possibilità che si concretizzi.

Il concretizzarsi di un rischio è anche il fallimento del tentativo di eludere o attenuare il rischio. Deve forzare una rianalisi dell'elenco dei rischi per determinare se il team del progetto possa avere dei punti oscuri. Quanto più difficile e sincera sarà l'auto verifica tanto più potrà evitare futuri problemi.

Riverifica dei rischi durante l'iterazione
Scopo Assicurare che l'elenco dei rischi sia attuale per tutta la durata del progetto. 

La verifica del rischio è un processo costante, e non uno che si attua a determinati intervalli durante il progetto. Quanto meno si deve:

  • Verificare l'elenco con frequenza settimanale per vedere cosa è cambiato.
  • Rendere visibili i rischi maggiori a tutto il progetto ed insistere perché siano intraprese azioni su di essi. Allegare spesso l'elenco dei rischi ai prospetti di valutazione dello stato.
Riverifica dei rischi al termine dell'iterazione
Scopo Assicurare che l'elenco dei rischi sia attuale per tutta la durata del progetto. 

Al termine dell'iterazione concentrarsi sui suoi scopi rispetto all'elenco dei rischi. Specificatamente:

Non preoccuparsi se ci si rende conto che l'elenco dei rischi cresce nelle fasi di inizio validità ed elaborazione. Durante la lavorazione i membri del progetto realizzano che ciò che avevano considerato insignificante conteneva invece dei rischi. Procedendo con l'integrazione si potrà trovare qualche difficoltà nascosta. Tuttavia i rischi dovrebbero calare in modo costante quanto più il progetto si avvicina al termine dell'elaborazione e durante la costruzione. Se non è così, è possibile che si stiano gestendo i rischi in modo non appropriato o che il proprio sistema sia troppo complesso, o impossibile da costruire in modo sistematico e prevedibile. Per ulteriori informazioni, consultare Linea guida del prodotto di lavoro: Elenco dei rischi.



Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile