La maggior parte delle project review finisce allo stesso modo: tutti aggiornati, nessuno impegnato. La riunione ha mostrato dati e non ha prodotto decisioni. La soluzione non è un'agenda migliore. Sono cinque domande — e la regola che un report è pronto per la review solo quando risponde a tutte.
1. Dove siamo?
Stato misurato, non riportato. La differenza: lo stato misurato confronta l'avanzamento con il piano usando una fonte (un foglio, un sistema, una misurazione). Lo stato riportato è ciò che il team crede — di solito un mese in ritardo e dieci punti più ottimista.
La risposta è uno di tre giudizi: on track (la data regge con le risorse previste), at risk (la data regge solo se cambia qualcosa), off track (la data non regge più e serve una decisione su data, scope o risorse).
2. Dove stiamo andando?
Un forecast, non una speranza. Se il ritmo attuale continua, che data raggiungiamo davvero — e con quale confidenza? Un progetto completo all'80% può essere comunque at risk se il 20% restante contiene il percorso critico.
3. Cosa è cambiato dall'ultima review?
Scostamenti con una causa. L'entità dello scostamento dice quanto; la causa dice cosa fare. Tre famiglie di causa: stima sbagliata (ripiantifica), problema di esecuzione (correggi il lavoro), dipendenza esterna (gestisci la dipendenza). Uno scostamento senza causa è rumore e viene ignorato — correttamente.
4. Cosa può farci deragliare?
I due o tre rischi che possono davvero cambiare l'esito, ognuno con una risposta prevista. Una review che discute quindici rischi non decide nulla; il registro completo vive in un tracker, la riunione discute solo ciò che conta.
5. Cosa serve da voi?
La decisione richiesta — la domanda esplicita alle persone in sala. Non "valutare l'andamento" ma "approvare l'estensione di scope di due sprint, o congelare la funzionalità X entro venerdì". Una buona decisione richiesta ha tre elementi: le opzioni, la raccomandazione di chi propone e la scadenza.
La regola che ne segue
Se il report non risponde alle cinque domande, la riunione non è una review: è un aggiornamento, e gli aggiornamenti si mandano via email. Questa sola regola elimina la maggior parte delle riunioni improduttive.
Una struttura pronta per le cinque domande è disponibile gratis: il generatore di report di avanzamento costruisce il report da cinque campi. Il kit operativo completo — sei template inclusi agenda di steering committee, tracker rischi e decisioni, matrice RACI e modello di review trimestrale, più la guida al metodo in italiano e inglese — è nel Project Review Kit.
Un esempio costruito (non dati di clienti)
Scenario sintetico a scopo illustrativo. La review di una migrazione di piattaforma si apre con un mazzo di 40 slide e nessun forecast. Applicato alle cinque domande, lo stesso progetto produce: stato at risk (una dipendenza critica in ritardo di tre giorni); forecast: il go-live slitta di due settimane se la finestra di integrazione non si sposta; scostamento con causa: fornitore esterno, non pianificato come dipendenza; rischi: ulteriore ritardo del fornitore, mitigato dal piano B già attivato; decisione richiesta: spostare la finestra di integrazione o togliere un modulo dallo scope, entro venerdì.
La review dura venti minuti invece di novanta, e finisce con una decisione.
FAQ
Che differenza c'è tra project review e aggiornamento di stato?
La review finisce con decisioni: risponde alle cinque domande e produce una decisione richiesta esplicita, con owner e scadenza. L'aggiornamento di stato condivide solo informazioni — appartiene a un'email.
Quanto deve durare una project review?
Sessanta minuti bastano quando il report risponde alle cinque domande prima della riunione. La riunione poi decide; non legge.
Chi deve partecipare a una project review?
Le persone che possono prendere la decisione richiesta, l'owner del progetto e chi porta dati misurati. Chi partecipa solo per essere informato può leggere il report.
E se non c'è nulla da decidere?
Non si tiene la review. Si manda il report e si dedica l'ora al progetto.