Partiamo da un semplice esempio

Esempio 1: Durante lo sviluppo di un progetto software l’unico dev, insoddisfatto del salario, che conosceva un modulo di importanza critica lascia la società, rallentando in modo serio lo sviluppo del progetto (nonchè aumentandone i costi, nel tentativo di cambiare il modulo conosciuto solo dal dev) fino a farlo uscire troppo in ritardo rispetto, ad esempio, alle opportunità di marketing a cui puntava.

Un esempio del genere non è così raro e il risk management si occupa di prevenire questo tipo di complicazioni e fallimenti.

Definizione: Il risk management è la disciplina che si occupa di identificare, gestire e potenzialmente eliminare i rischi prima che questi diventino una “minaccia” per il successo del progetto (o anche per eventuali situazioni di revisione del progetto stesso).

Definizione: Il rischio è la possibilità che ci sia un danno. Bisogna cercare di prevenire un evento che può portare ad un danno serio.

Definizione: La risk exposure è una grandezza che calcola quanto un progetto sia esposto ad un rischio. Viene calcolato come

$$ \text{RE} = P(\text{UO}) \cdot L(\text{UO}) $$

• $P(\text{UO})$ è la probabilità che effettivamente un danno (o risultato non soddisfacente) sia prodotto (unsatisfactory outcome)
• $L(\text{UO})$ è l’entità del danno stesso, ovvero la perdita per le parti interessate se il risultato non è soddisfacente.

Tanto più un rischio è probabile e tanto più il rischio crea un danno tanto cresce il risk exposure.

Definizione: L’unsatisfactory outcome è un risultato non positivo che riguarda diverse aree:

• esperienza degli utenti: se i problemi sono gravi si hanno alti rischi, come l’utenza che smette di usare il prodotto, o anche a conseguenze legali
• dev: superamento del budget e prolungamenti delle deadlines
• manutentori: qualità bassa di sw/hw

Il primo elemento su cui soffermarsi è lo studio degli eventi che lo abilitano, detti risk triggers, per evitare che avvengano. In base all’esempio 1 si potrebbe pensare di non assumere un solo dev con una certa conoscenza o comunque di alzare la paga, per evitare di attivare i risk triggers.

Abbiamo quindi due principali classi di rischio:

1. process-related risks: rischi con impatto negativo sul processo e sugli obiettivi di sviluppo, come ritardi o superamento di costi
2. product-related risks: rischi con impatto sul prodotto e su obiettivi del sistema funzionali o meno, come fallimenti riguardanti la qualità del prodotto (sicurezza, prestazioni, ecc) o la distribuzione dello stesso

Entrambe le classi possono portare al fallimento del progetto e quindi vanno gestite entrambe.