Gestione per eccezione

Questo è un termine poco noto a chi non è familiare con la metodologia PRINCE2 ma, come ti renderai conto leggendo, è un punto fondamentale per una sana gestione e controllo di progetti. Siccome è molto importante che tu capisca bene questo concetto, inizierò da una definizione molto semplificata e poi passerò alla definizione ufficiale PRINCE2. Quando consideriamo fattori come tempi, costi e scope/ambito, il Project Manager dovrebbe avere un pò di libertà (o tolleranza) di gestione prima di elevare una questione al comitato di progetto (p.e. i costi possono variare in un range di ±10%). Quindi, se un problema è di entità piccola e rientra nei limiti delle tolleranze concordate (p.e. i costi aumentano del 2% – inferior al limite massimo concordato di 10%), allora il Project Manager può gestirlo e non deve allertare il comitato.

La gestione per eccezione viene applicate a tutti I livelli dell’organizzazione di progetto e, tramite l’applicazione di questo principio, il livello superior gestisce il livello sottostante. Il livello sottostante dovrebbe notificare il livello sopra solo nei casi incui ci siano questioni o issues talmente rilevanti da causare una previsione di superamento delle tolleranze concordate. Il termine PRINCE2 per queste questioni o issue rilevanti è “eccezione”, che significa che l’issue ha un impatto che eccede la tolleranza concordata.

Ora, immagina per un attimo di sedere nel comitato di progetto. Se tutto sta procedendo bene (o meglio, all’interno delle tolleranze predefinite), non sentirai notizie dal Project Manager, eccetto per I report di frequenza concordata inoltrati durante le fasi ed alla fine delle stesse, a meno che si presenti un’eccezione; ecco il motivo del termine “gestione per eccezioni”. La definizione PRINCE2 delle gestione per eccezione è la seguente: Un progetto PRINCE2 ha tolleranze predefinite per ciascuno degli obiettivi di progetto, e tali tolleranze stabiliscono i limiti di delega dell’autorità decisionale da parte del livello immediatamente superiore.

Le tolleranze, quindi, si stabiliscono sugli obiettivi di progetto, i quali sono:

• Tempi
• Costi
• Qualità
• Ambito
• Rischi
• Benefici

Di seguito alcuni esempi di tolleranze sugli obiettivi di qualità, scopo, rischi, benefici, tempi e costi:

• Tolleranza di qualità: Stai sviluppando un nuovo cellulare GSM e vuoi che la tastiera duri per 7 anni (in media) con una tolleranza di ±5%.
• Tolleranza dell’ambito di progetto - scope: I requisiti per il nuovo GSM saranno costituiti da requisiti necessary (must to have) e requisiti desiderati (nice to have). In questo modo il progetto può decidere quali requirements ‘nice to have’ includere se sarà possibile, ma si è consapevoli di quali requirements siano assolutamente necessari.
• Tolleranza di beneficio: Un benefit è un miglioramento, per uno o più stakeholder, misurabile e risultante dal progetto. Questi sono i benefici per gli stakeholder di progetto. Per esempio, l’incremento della quota di mercato del 5%, oppure la creazione di un nuovo segmento di mercato più profittevole. Una domanda importante fatta durante il progetto è la seguente: “I benefici attesi sono in linea con quelli previsti dal progetto?”
• Tolleranza di rischio: Userò ancora una volta l’esempio del cellulare GSM. Ci sarà un set di tolleranze per il rischio e se si identificano rischi che superano tali tolleranze, il PM dovrà elevare il punto al comitato di progetto. Esempio: Ti rendi conto che c’è un rischio troppo elevato – che uno dei fornitori critici non potrà fornire una camera di 5 megapixel con le specifiche di integrazione richieste. Questo rischio, nel caso accada, potrebbe causare molti problemi al progetto.

Per ricapitolare: La Gestione per Eccezioni fornisce al livello di gestione sovrastante un Sistema di controllo del livello sottostante, evitando di essere disturbato per qualsiasi singola questione ma solo quanto davvero è necessario. In due parole: la gestione per eccezioni evita il fenomeno del “micro-management” oppure, dall’altro lato, assicura l’attenzione del comitato di progetto o della direzione quanto davvero serve una decisione dall’alto per proseguire con il progetto stesso.