Issue e Decision Management in PM²: risolvere ciò che è reale e ricordare perché si è scelto

Diciannovesimo articolo della serie “Imparare PM² attraverso un progetto”

Un progetto non è in difficoltà perché ha issue. È in difficoltà quando le issue restano implicite, non hanno owner, scadenza o escalation, e ricompaiono settimana dopo settimana nei report.

In PM², Issue Management tratta problemi già presenti o già accaduti; Decision Management conserva le scelte importanti, il loro razionale e le conseguenze. Sono due attività diverse ma strettamente collegate.

Issue: un problema reale che richiede gestione

Un’issue è un evento, una condizione o un problema attuale che richiede attenzione e azione. Può riguardare requisiti, risorse, tempi, qualità, fornitori, sicurezza, stakeholder o decisioni bloccate.

Non è un’issue	È un’issue
“Il fornitore potrebbe ritardare.” — rischio.	“Il fornitore ha comunicato il ritardo.” — issue.
“Potremmo avere pochi tester.” — rischio.	“Due tester assegnati non sono disponibili.” — issue.
“Vorremmo aggiungere una funzione.” — change request.	“La funzione approvata non rispetta un criterio di accettazione.” — issue.

Questa distinzione evita trattamenti sbagliati: un rischio richiede prevenzione e monitoraggio; un’issue richiede contenimento, risoluzione o escalation.

Il ciclo di Issue Management

flowchart LR
  A[Identifica e registra] --> B[Analizza impatto e urgenza]
  B --> C[Assegna owner e azioni]
  C --> D[Monitora e comunica]
  D --> E{Risolta?}
  E -- No --> F[Escala o rivedi risposta]
  F --> D
  E -- Sì --> G[Chiudi con evidenza]

La chiusura non coincide con “non se ne parla più”. Richiede evidenza che l’azione sia completata e che l’effetto sia accettabile; in caso contrario, l’issue resta aperta oppure genera una nuova issue, risk o change.

Cosa rende utile un Issue Log

Un Issue Log efficace permette di rispondere in pochi secondi a: che cosa è successo, quanto conta, chi se ne occupa, entro quando e qual è il blocco?

Campo	Utilità
Descrizione e data	Rendere concreto il problema.
Impatto e priorità	Decidere quanto rapidamente agire.
Owner	Rendere qualcuno responsabile del coordinamento della risoluzione.
Azioni e scadenze	Trasformare il problema in lavoro verificabile.
Stato e decisioni collegate	Evitare aggiornamenti vaghi e ripetuti.
Escalation	Chiarire quando e a chi portare un blocco.
Evidenza di chiusura	Dimostrare che il problema è stato effettivamente risolto o accettato.

L’owner non deve risolvere personalmente tutto: deve fare in modo che la risoluzione venga guidata, verificata e comunicata.

Priorità: impatto, urgenza e tolleranze

Non tutte le issue sono emergenze. Una classificazione utile distingue:

Priorità	Esempio	Risposta
Critica	Rilascio bloccato o rischio di sicurezza.	Azione immediata, visibilità alta, escalation se necessaria.
Alta	Una milestone o un requisito rilevante è minacciato.	Owner e piano di risposta a breve; monitoraggio frequente.
Media	Problema con workaround accettabile.	Pianificare e verificare la correzione.
Bassa	Impatto limitato e nessun effetto su obiettivi o utenti.	Gestire nel flusso ordinario o accettare consapevolmente.

La priorità non si basa solo sulla gravità tecnica. Una piccola anomalia in un dato legale può essere più urgente di un difetto visivo molto evidente.

Decision Management: la memoria delle scelte

Ogni progetto compie decisioni: accettare un trade-off, scegliere un’opzione tecnica, rinviare un requisito, autorizzare una change, accettare un rischio residuo, fare escalation o modificare una dipendenza.

Una decisione importante va registrata perché, dopo settimane, si tende a ricordare la scelta ma non il motivo. Il Decision Log rende verificabili contesto e responsabilità.

Campo	Esempio
Decisione	Rilasciare Prenotazioni Smart senza esportazione CSV nella prima versione.
Contesto / problema	L’esportazione ritarda il go-live di cinque giorni.
Opzioni considerate	Includere e rinviare; sostituire altra funzione; rinviare CSV.
Decision maker	PO/BM, secondo la governance concordata.
Data e razionale	Proteggere la data di lancio e validare prima la funzionalità principale.
Conseguenze / azioni	Registrare la change come rinviata; pianificarla nella release successiva; aggiornare comunicazioni.

Un Decision Log non sostituisce una minuta quando serve, né sostituisce il Change Log o il Risk Log. Li collega: una decisione può chiudere un’issue, approvare una change o accettare un rischio.

Quando fare escalation

Il PM non deve aspettare che una situazione diventi irreversibile. L’escalation è opportuna quando:

l’issue supera tolleranze di tempo, costo, qualità o scope;
manca l’autorità o la capacità necessaria per risolverla nel team;
occorre una scelta tra opzioni con impatto business;
due stakeholder hanno un conflitto che il PM non può dirimere;
ritardare la decisione aumenta significativamente il danno o il costo.

Una buona escalation porta fatti, impatto, opzioni, raccomandazione e decisione richiesta. Dire soltanto “abbiamo un problema” trasferisce pressione, non abilita una decisione.

Il caso Annotatio: notifiche Android non funzionanti

Durante il pilota di Prenotazioni Smart, le notifiche Android non arrivano su alcuni dispositivi. L’issue potrebbe essere registrata così:

Campo	Contenuto
Issue	Le notifiche di promozione dalla lista d’attesa non raggiungono una parte degli utenti Android.
Impatto	Alto: rischio di posti liberi e malfunzionamento del flusso di attesa.
Owner	Responsabile tecnico del modulo notifiche.
Azioni	Analizzare log e configurazione; testare modello di dispositivo; predisporre fallback via email o in-app.
Scadenza	Diagnosi entro 48 ore; decisione sul go-live dopo test di correzione.
Escalation	Se non risolto entro 48 ore, PO/BM scelgono tra rinvio, fallback o scope ridotto.

La decisione collegata potrebbe essere: “mantenere il go-live, attivare email come fallback per Android e pianificare la correzione push entro la prima settimana”. È una decisione di trade-off, non la semplice chiusura dell’issue.

Da non confondere

Affermazione	Correzione
“Un’issue è un rischio grave.”	No: è un problema già reale.
“Se un’issue ha owner, il PM può dimenticarsene.”	Il PM monitora, facilita, comunica e fa escalation quando serve.
“La decisione è implicita nella chat o nella riunione.”	Se è rilevante, va resa esplicita e registrata con razionale e owner delle azioni.
“Chiudere un’issue significa cancellarla dal log.”	Va mantenuta traccia della soluzione e dell’evidenza di chiusura.

Tre domande per fissarlo

Questo elemento è un rischio, un’issue o una change request?
Quale owner, azione e data rendono l’issue gestibile?
Quale decisione serve, chi la deve prendere e quali opzioni deve valutare?

Flashcard

D: Che cos’è un’issue?
R: Un problema, evento o condizione reale che richiede attenzione e azione.

D: A cosa serve il Decision Log?
R: A conservare decisione, contesto, opzioni, decision maker, razionale e azioni conseguenti.

D: Quando il PM deve fare escalation?
R: Quando supera tolleranze o autorità disponibile, serve un trade-off business o ritardare la decisione aumenta l’impatto.

Domanda in stile esame

Una dipendenza esterna ha già bloccato il collaudo. Il PM la mantiene nel Risk Log con probabilità alta e attende il prossimo status meeting prima di coinvolgere altri ruoli.

Qual è l’approccio corretto?

Risposta: il blocco è un’issue, non più un rischio. Il PM deve registrarlo nell’Issue Log, valutarne urgenza e impatto, assegnare owner e azioni, e fare escalation tempestiva se il team non può risolverlo entro le tolleranze. Il Risk Log può essere aggiornato come rischio materializzato.

Fonte

Issue Management, Issue Management Plan, Issue Log e le attività di gestione delle decisioni sono trattati nella PM² Methodology Guide 3.1 della Commissione europea.

Nel prossimo articolo: Quality Management, per costruire qualità nel lavoro e non limitarci a controllarla alla fine.