analisi-disegno.com
Ogni eventualità che può compromettere o ritardare il successo del progetto è un rischio.
I progetti hanno tipicamente più rischi rispetto alle gestioni di servizi ed alle attività di routine.
I rischi influenzano la pianificazione del progetto, in quanto è opportuno pianificare e controllare le attività necessarie per evitarli o ridurne l'impatto.
I rischi cambiano nel corso del progetto, quindi vanno gestiti in modo sistematico per tutta la durata del progetto.
Una template per documentare i rischi (nei formati excel e ods)
Tra i più frequenti:
La classificazione riportata nella tabella qui sotto, più esaustiva, è tratta da un articolo di David Garmus e David Herron "Estimating Software Earlier and More Accurately", pubblicato su CrossTalk, June 2002.
|
MANAGEMENT:
|
DEFINITION:
|
DESIGN:
|
|
BUILD:
|
TEST:
|
ENVIRONMENT:
|
I rischi non hanno tutti lo stesso peso. Differiscono per probabilità e impatto.
Le valutazioni di probabilità e impatto possono condurre ad un'analisi qualitativa o (se opportuno) quantitativa.
Le tabelle seguenti sono una base di partenza per un'analisi qualitativa (i valori proposti sono da considerarsi come esempi):
| Impatto del rischio (fonte: PMBOK, semplificato) | |||||
| Obiettivi \ Valore | Molto basso | Basso | Medio | Elevato | Molto elevato |
| Costi | incremento dei costi non significativo | incremento dei costi < 10% | incremento dei costi tra 10 e 20% | incremento dei costi tra 20 e 40% | incremento dei costi > 40% |
| Tempi | incremento dei tempi non significativo | incremento dei tempi < 5% | incremento dei tempi tra 5 e 10% | incremento dei tempi tra 10 e 20% | incremento dei tempi > 20% |
| Funzionalità prodotto | diminuzione poco percepibile | riduzione di aspetti minori | riduzione di aspetti rilevanti | riduzione non accettabile dal committente | prodotto risultante inutile |
| Qualità | diminuzione qualità poco percepibile | impattati solo aspetti marginali | la riduzione richiede una approvazione del committente | riduzione non accettabile dal committente | prodotto risultante inutile |
| Probabilità del rischio | |
| Livello probabilità | Criterio |
| molto bassa | improbabile che si verifichi |
| bassa | più probabile che non si verifichi |
| media | probabilità uguale che si verifichi o non si verifichi |
| alta | più probabile che si verifichi |
| molto alta | improbabile che non si verifichi |
Evitare: eliminare i fattori che possono ingenerare il rischio.
Trasferire: cedere a terzi la gestione dell’impatto negativo del rischio.
Mitigare: diminuire la probabilità o l’impatto di un rischio fino a raggiungere una soglia accettabile.
Accettare: quando i possibili rimedi sono peggiori dell’impatto negativo del rischio.
I rischi vanno tenuti nascosti in un cassetto? No. La gestione dei rischi deve essere aperta a tutti gli stakeholder (le parti interessate).
Gestire i rischi in un progetto è troppo importante per essere fatto a livello individuale, e necessita del contributo di punti di vista diversi.
Attenzione: ciò che per qualcuno è un rischio, per altri può essere una opportunità, ma condividere e confrontare i punti di vista sui rischi è necessario per perseguire una logica “win-win”.
In ogni relazione committente-fornitore non consolidata, tra i rischi per il committente ci può essere l’inaffidabilità del fornitore, e viceversa. Comunque, la maggioranza dei rischi di progetto può avere un impatto negativo sia sul committente che sul fornitore.
Pagina principale sui processi di sviluppo software
analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.