Registri PM²: rischi, issue, decisioni e modifiche come sistema di governo
Ventottesimo articolo della serie “Imparare PM² attraverso un progetto”
Un registro non serve a “tenere traccia” in senso burocratico. Serve a rendere visibili le informazioni che altrimenti si perdono tra chat, riunioni, ticket e memoria delle persone: cosa può accadere, cosa è già accaduto, cosa si vuole cambiare e perché è stata presa una decisione.
In PM², Risk Log, Issue Log, Change Log e Decision Log sono strumenti complementari. Se usati bene, collegano il monitoraggio quotidiano alla governance; se usati male, diventano quattro elenchi scollegati e obsoleti.
Quattro registri, quattro domande
| Registro | Domanda a cui risponde | Oggetto registrato |
|---|---|---|
| Risk Log | Che cosa potrebbe accadere e danneggiare o favorire il progetto? | Evento incerto, probabilità, impatto, risposta, owner e trigger. |
| Issue Log | Quale problema reale richiede azione? | Evento o condizione presente, impatto, azioni, owner, scadenze ed escalation. |
| Change Log | Che cosa si chiede di modificare rispetto a una baseline approvata? | Change request, impatto, decisione e aggiornamenti conseguenti. |
| Decision Log | Quale scelta importante è stata presa, da chi e perché? | Decisione, opzioni, razionale, azioni e responsabilità. |
La distinzione più importante è temporale: il risk è incerto; l’issue è reale. La change è una richiesta di alterare qualcosa di approvato; la decisione registra la scelta che può riguardare un rischio, un’issue, una change o un altro tema di governance.
Come i registri si collegano
flowchart TD
A[Risk Log: evento incerto] -->|si materializza| B[Issue Log: problema reale]
B -->|può richiedere| C[Change Log: modifica a baseline]
A -->|risposta o accettazione| D[Decision Log]
B -->|trade-off o escalation| D
C -->|approvata, respinta o rinviata| D
D --> E[Piani, baseline e comunicazioni aggiornati]
Non ogni freccia è obbligatoria. Un rischio può essere mitigato senza una decisione formale; un’issue può essere risolta dal team senza change; una change può essere respinta senza produrre lavoro. Il valore del modello è sapere quando collegare le informazioni e non farle sparire.
Risk Log: rendere l’incertezza azionabile
Un record di rischio efficace include:
| Campo | Esempio |
|---|---|
| Causa-evento-effetto | A causa di un provider esterno, le policy push potrebbero cambiare, ritardando il go-live. |
| Probabilità e impatto | Media / alta. |
| Owner | Responsabile tecnico dell’integrazione. |
| Risposta | Mitigare: test anticipato, monitoraggio policy, fallback definito. |
| Trigger | Avviso del provider o fallimento dei test end-to-end. |
| Rischio residuo | Ancora medio dopo la mitigazione. |
La parola “monitorare” da sola non è una risposta completa. Occorre specificare chi osserva cosa, con quale frequenza e quale evento attiva un’azione.
Issue Log: trasformare un problema in azione verificabile
| Campo | Esempio |
|---|---|
| Issue | Le notifiche push non arrivano a una parte dei dispositivi Android. |
| Impatto / priorità | Alto: lista d’attesa e go-live sono a rischio. |
| Owner | Responsabile tecnico del modulo notifiche. |
| Azioni | Analisi log, correzione configurazione, test su dispositivi, fallback email. |
| Scadenza / escalation | Diagnosi entro 48 ore; escalation a PO/BM se il fallback diventa necessario. |
| Chiusura | Evidenza dei test e decisione sulla soluzione adottata. |
Un’issue non è chiusa perché si è scelto un workaround. Può chiudersi con un workaround accettato, ma il log deve indicare chi ha accettato l’impatto e quale eventuale azione successiva rimane.
Change Log: proteggere la baseline senza bloccare il valore
Una change request non è un “desiderata” disperso in un meeting. È una richiesta identificabile che modifica un requisito, scope, piano, costo, calendario, deliverable, criterio di accettazione o altra baseline.
| Campo | Esempio |
|---|---|
| Richiesta | Aggiungere export CSV delle presenze. |
| Motivazione | Il gestore deve riconciliare presenze con un sistema esterno. |
| Impatto | Cinque giorni di effort, nuovi test, possibile ritardo go-live. |
| Opzioni | Includere e rinviare data; sostituire altra funzione; rinviare alla release successiva. |
| Decisione | Rinviata alla release successiva per proteggere il go-live. |
| Azioni | Aggiornare backlog/piano e comunicare l’esito al richiedente. |
Il Change Log conserva anche change respinte o ritirate: impedisce che la stessa richiesta rientri più tardi come se fosse nuova e senza il contesto della decisione precedente.
Decision Log: non perdere il razionale
Il Decision Log non duplica gli altri registri. Cattura il punto che gli altri non sempre rendono esplicito: la scelta, l’autorità, il perché e le conseguenze.
| Campo | Esempio |
|---|---|
| Decisione | Attivare fallback email per la lista d’attesa al go-live. |
| Contesto | Issue Android non chiusa entro la data prevista. |
| Opzioni | Rinviare go-live; rilasciare senza notifiche; usare fallback email. |
| Decision maker | PO/BM, con fattibilità confermata dallo SP. |
| Razionale | Proteggere data e funzionalità principale riducendo l’impatto sugli utenti. |
| Azioni | Configurare email, aggiornare guida, pianificare correzione push e monitorare adozione. |
Le decisioni minori e reversibili non richiedono sempre un log formale. Il criterio è il valore della memoria: se tra un mese servirà sapere chi ha deciso, sulla base di quali opzioni e con quali conseguenze, va registrato.
Una review dei registri davvero utile
La review non deve consistere nel leggere tutte le righe. A ogni cadenza utile, il PM e gli owner verificano:
- rischi nuovi, aumentati, materializzati o non più rilevanti;
- issue senza owner, azione, data o evidenza di chiusura;
- change in attesa di analisi o decisione;
- decisioni con azioni non completate;
- collegamenti da aggiornare nel Work Plan, nelle baseline, nelle comunicazioni e nei piani.
| Segnale | Azione |
|---|---|
| Rischio senza trigger o risposta | Completare analisi o ridurne la priorità in modo esplicito. |
| Issue “in corso” da molte settimane | Rivalutare owner, azioni, tolleranze ed escalation. |
| Change senza impatto stimato | Non portarla a decisione finché manca un’analisi proporzionata. |
| Decisione senza follow-up | Assegnare azioni, owner e data; altrimenti non è stata realmente attuata. |
Il caso Annotatio: dalla dipendenza esterna alla decisione
Per Prenotazioni Smart, il provider di notifiche annuncia una modifica API imminente.
| Momento | Registro | Esempio |
|---|---|---|
| Annuncio non ancora effettivo | Risk Log | Rischio di incompatibilità; test anticipato e fallback come mitigazione. |
| Test fallisce | Issue Log | Notifiche Android non funzionano; owner tecnico e diagnosi entro 48 ore. |
| Serve modificare il go-live o il comportamento | Change Log | Proposta: rilasciare con fallback email, modificando il criterio operativo di notifica. |
| Si sceglie l’opzione | Decision Log | PO/BM approvano fallback email; azioni su guida, configurazione e fix successivo. |
Questa catena evita due errori opposti: trattare il rischio come un problema già reale, oppure lasciare un problema reale bloccato nel Risk Log senza azioni urgenti.
Dove tenere i registri
PM² non impone uno strumento. Per un progetto piccolo possono essere tabelle semplici; per un progetto complesso possono vivere in un sistema di portfolio, ticketing o repository integrato. I requisiti minimi restano gli stessi:
- fonte unica o riferimenti ufficiali chiari;
- identificativi univoci e collegamenti fra registri;
- accesso appropriato a ruoli e informazioni riservate;
- storico e versioni sufficienti per audit e apprendimento;
- review regolare e responsabilità visibili.
Lo strumento deve ridurre il costo di aggiornare e consultare la verità del progetto, non aumentarlo.
Da non confondere
| Affermazione | Correzione |
|---|---|
| “Un rischio grave è un’issue.” | No: resta un rischio finché è incerto; diventa issue quando è reale. |
| “Il Decision Log sostituisce il Change Log.” | Una decisione può approvare una change, ma il Change Log conserva richiesta e impatto specifici. |
| “Un workaround chiude automaticamente l’issue.” | Può chiuderla solo se l’impatto è accettato e la chiusura è documentata. |
| “I registri servono solo al PM.” | Servono a owner, team e governance per agire e decidere su dati affidabili. |
Tre domande per fissarlo
- Questo elemento è incerto, reale, una richiesta di modifica o una scelta già presa?
- Quale registro deve contenere l’informazione primaria e quali altri devono essere collegati?
- Quale azione, owner e data rendono questo record utile al progetto?
Flashcard
D: Qual è la differenza fra Risk Log e Issue Log?
R: Il Risk Log gestisce eventi incerti; l’Issue Log gestisce problemi già reali.
D: Perché una change respinta resta nel Change Log?
R: Per conservarne motivazione, impatto e decisione, evitando che ricompaia senza contesto.
D: A cosa serve il Decision Log?
R: A registrare la scelta, le opzioni, il decision maker, il razionale e le azioni conseguenti.
Domanda in stile esame
Durante una review, il team nota che il rischio “fornitore potrebbe ritardare” si è verificato. Il PM aumenta soltanto il punteggio di impatto nel Risk Log e continua il normale monitoraggio.
Qual è la correzione migliore?
Risposta: il rischio si è materializzato e deve diventare un’issue con owner, azioni, scadenze e possibili escalation. Il Risk Log va aggiornato per mantenere la storia e l’apprendimento, ma non sostituisce la gestione urgente del problema reale.
Fonte
Change Log, Risk Log, Issue Log, Decision Log e i relativi piani di gestione sono descritti nella PM² Methodology Guide 3.1 della Commissione europea.
Nel prossimo articolo: Report di progetto e controllo dell’avanzamento, per trasformare dati e registri in previsioni, decisioni e azioni tempestive.