Report di progetto e controllo dell’avanzamento in PM²: dai dati alle decisioni

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

Uno status report non è una cronaca delle attività svolte né un documento per dimostrare che il team è occupato. È uno strumento di governance: mostra se il progetto sta ancora procedendo verso gli obiettivi approvati e rende visibili le decisioni necessarie prima che gli scostamenti diventino irreversibili.

In PM², il reporting è parte di Monitor & Control. Raccoglie evidenze dal Project Work Plan, dai registri, dai test e dagli stakeholder; le confronta con le baseline e le trasforma in forecast, azioni, escalation e decisioni.

I tre livelli: dato, informazione, decisione

Un report utile non salta direttamente dai dati al semaforo. Spiega cosa significa lo scostamento e quale azione o decisione serve.

Controllare rispetto a una baseline

Il controllo ha bisogno di un riferimento approvato: scope, schedule, costi/effort, qualità e criteri di acceptance. Il PM confronta l’effettivo e il forecast con tali baseline.

flowchart LR
  A[Baseline approvata] --> B[Dati effettivi]
  B --> C[Analisi di scostamento]
  C --> D[Forecast]
  D --> E{Entro tolleranze?}
  E -- Sì --> F[Azioni e monitoraggio]
  E -- No --> G[Escalation o change decision]
  G --> H[Comunicazione e aggiornamento controllato]

La baseline non va riscritta per far sparire un ritardo. Il forecast può peggiorare o migliorare con le evidenze; la baseline cambia solo dopo un cambiamento approvato.

Che cosa deve dire un Project Status Report

Il formato varia, ma un report efficace risponde in modo sintetico alle domande che interessano a chi governa il progetto.

Il dettaglio operativo può restare nel Work Plan, nei board o nei ticket. Il report deve rendere leggibile il quadro per il destinatario, non duplicare tutti gli strumenti.

Semafori: utili solo se spiegati

Un sistema verde/giallo/rosso può aiutare a dare una lettura rapida, purché le regole siano chiare.

Un “rosso” non è un fallimento e un “verde” non è una garanzia. Sono indicatori di attenzione. Ogni colore deve essere accompagnato da causa, impatto, owner, azione e previsione.

Avanzamento reale: evitare percentuali ottimistiche

Dire “siamo al 90%” può essere fuorviante se il 10% rimanente contiene integrazione, acceptance o una dipendenza critica. L’avanzamento va collegato a deliverable e criteri di completamento osservabili.

La domanda non è quanti task risultano chiusi, ma se i deliverable che producono valore sono pronti e accettabili nel tempo e costo disponibili.

Forecast e analisi degli scostamenti

Ogni scostamento utile va formulato in modo completo:

Baseline: go-live il 30 giugno.
Effettivo / evidenza: issue Android aperto e dashboard non avviata.
Forecast: go-live più probabile il 7 luglio, salvo riduzione scope.
Impatto: ritardo di una settimana o rinvio di un deliverable.
Azione / decisione richiesta: PO/BM decidono entro venerdì tra rinvio, scope ridotto o capacità aggiuntiva.

Questo formato separa fatti, inferenze e decisioni. Evita sia la frase vaga “siamo in ritardo” sia l’ottimismo non verificabile “recupereremo”.

Il caso Annotatio: un report che consente di scegliere

Per Prenotazioni Smart, il report settimanale potrebbe indicare:

Il report non chiede genericamente “attenzione”. Chiede a ogni ruolo competente una scelta precisa, supportata da evidenze.

Ritmo di controllo e livelli di reporting

La cadenza deve essere proporzionata al ritmo del progetto e alla velocità con cui cambiano i rischi.

Un report mensile può essere sufficiente per la governance strategica ma troppo lento per un issue che blocca una milestone nella settimana corrente. Le informazioni urgenti vanno comunicate sul trigger, non aspettano il prossimo ciclo.

Escalation: il report deve abilitare, non scaricare il problema

Quando servono decisioni fuori dalla delega del PM, la sezione di escalation dovrebbe contenere:

• fatto e impatto verificati;
• baseline e forecast;
• opzioni reali con pro e contro;
• raccomandazione del PM e pareri rilevanti;
• decision maker e data entro cui decidere;
• conseguenza di una mancata decisione.

Questo trasforma l’escalation da “c’è un problema” a “questa è la decisione necessaria per proteggere il progetto”.

Da non confondere

Tre domande per fissarlo

1. Rispetto a quale baseline stai dichiarando uno stato verde, giallo o rosso?
2. Quale deliverable o milestone, non quale task, determina il rischio sul risultato finale?
3. Quale decisione serve, chi la deve prendere e entro quando?

Flashcard

D: A cosa serve il Project Status Report?
R: A confrontare avanzamento, scostamenti, forecast, rischi e issue con le baseline e ad abilitare azioni e decisioni tempestive.

D: Che cosa rende utile un semaforo?
R: Regole chiare e contesto: baseline, causa, impatto, owner, azione e forecast.

D: Qual è la differenza fra baseline e forecast nel reporting?
R: La baseline è il riferimento approvato; il forecast è la previsione aggiornata basata sui dati reali.

Domanda in stile esame

Il PM aggiorna ogni settimana il piano ufficiale con le nuove date previste. Nel report seguente, il progetto appare verde perché tutte le milestone coincidono con le date appena aggiornate.

Qual è l’errore?

Risposta: ha sostituito la baseline con il forecast, cancellando la visibilità dello scostamento. Le nuove date possono essere riportate come forecast; la baseline cambia solo dopo una change approvata. Il report deve mostrare differenza, causa, impatto e decisione o azione necessaria.

Fonte

Project Reporting, Monitor Project Performance, Control Schedule, Control Cost e Information Distribution sono trattati nella PM² Methodology Guide 3.1 della Commissione europea.

Nel prossimo articolo: Project-End Report e Lessons Learned, per chiudere il progetto con evidenze, responsabilità e conoscenza riutilizzabile.