Planning in PM²: trasformare l’approvazione in un piano eseguibile
Decimo articolo della serie “Imparare PM² attraverso un progetto”
Dopo il Gate RfP, il progetto ha una giustificazione e una definizione ad alto livello. Non è però ancora pronto a spendere risorse in modo intensivo: deve chiarire come verrà realizzato, controllato e introdotto nel business.
Questo è lo scopo della fase di Planning.
Planning risponde a: “Sappiamo chi deve fare cosa, quando, con quali risorse, rischi, controlli e criteri di accettazione?”
Da Charter a piano operativo
Il Project Charter definisce il progetto ad alto livello. Durante il Planning, questa definizione diventa abbastanza concreta da permettere un impegno consapevole nella delivery.
| In Initiating | In Planning |
|---|---|
| Roadmap preliminare | Calendario e milestone dettagliati |
| Budget stimato | Budget pianificato e baseline |
| Scope ad alto livello | Work package, attività, deliverable e dipendenze |
| Governance iniziale | Modalità operative, ruoli e soglie decisionali |
| Rischi principali | Log, analisi, responsabili e risposte pianificate |
Planning non è soltanto “scrivere documenti”. Serve a rendere verificabile il modo in cui il progetto intende raggiungere i propri obiettivi.
I due artefatti centrali
| Artefatto | Domanda a cui risponde |
|---|---|
| Project Handbook | Come verrà gestito il progetto? |
| Project Work Plan | Che lavoro faremo, quando e con quali risorse? |
Project Handbook: come verrà gestito il progetto
Il Project Handbook descrive l’approccio di gestione. È il riferimento condiviso per governance, responsabilità, processi, comunicazioni e tailoring della metodologia.
Può chiarire:
- organizzazione e ruoli PM²;
- responsabilità e RAM/RASCI;
- composizione e funzionamento del PSC;
- modalità di decisione, escalation e approvazione;
- cadenza di reporting e riunioni;
- gestione di rischi, issue e modifiche;
- gestione di qualità e accettazione;
- stakeholder e comunicazioni;
- strumenti, repository e convenzioni documentali;
- modalità di tailoring PM²;
- collegamento con approcci Agile, se adottati.
Nel progetto Prenotazioni Smart
Il Handbook può stabilire che il PSC si riunisca mensilmente, che le modifiche oltre una soglia siano approvate dal PO o dal PSC, che Jira sia lo strumento operativo, che il Risk Log sia rivisto settimanalmente e che il PCT adotti iterazioni brevi per la delivery.
Il Handbook non è un manuale teorico. Deve spiegare come questo specifico progetto verrà governato.
Project Work Plan: il piano della delivery
Il Project Work Plan (PWP) documenta work package, attività, deliverable, calendario, risorse e budget dettagliati. È il riferimento principale contro cui vengono poi monitorati avanzamento e scostamenti.
Un PWP utile collega almeno:
- deliverable attesi;
- work package e attività;
- sequenza e dipendenze;
- stime e assegnazione delle risorse;
- milestones e date;
- budget;
- responsabilità;
- criteri di completamento;
- collegamenti con rischi, transizione e Business Implementation.
Nel progetto Prenotazioni Smart
Il PWP può includere work package per analisi, UX, backend, web app, app mobile, notifiche, test, pilota e rilascio. Ogni work package deve produrre risultati riconoscibili, avere dipendenze chiare e una responsabilità assegnata.
Il PWP non è una lista di task
Una lista di task può essere utile al team, ma un Project Work Plan deve mantenere la visione del progetto: deliverable, budget, milestones, dipendenze e baseline. Uno strumento Agile può supportarlo, a condizione che l’informazione necessaria alla governance resti visibile.
Baseline: il riferimento per controllare il progetto
Una baseline è una versione approvata del piano che diventa il riferimento per monitorare lo stato reale.
Senza baseline, non si può dire con rigore che il progetto sia in ritardo, fuori budget o fuori scope: si può soltanto dire che il piano continua a cambiare.
Le baseline principali riguardano normalmente:
- scope e deliverable;
- calendario e milestones;
- budget e risorse;
- criteri di qualità e accettazione.
Aggiornare il piano operativo perché un’attività è completata non equivale sempre a cambiare una baseline. Una modifica significativa a scope, tempi, costi o qualità deve essere valutata e approvata attraverso la governance prevista.
Una baseline non blocca il cambiamento: rende il cambiamento esplicito, misurabile e decidibile.
I Project Logs: memoria operativa e trasparenza
Durante Planning vengono predisposti o completati i principali log. Non sono archivi passivi: sono strumenti vivi di Monitor & Control.
| Log | Scopo |
|---|---|
| Risk Log | Minacce, opportunità, valutazioni, responsabili e risposte |
| Issue Log | Problemi già materializzati e azioni per risolverli |
| Change Log | Richieste di modifica, impatti e decisioni |
| Decision Log | Decisioni prese, motivazione e azioni conseguenti |
| Stakeholder Log | Stakeholder, influenza, aspettative e strategia di coinvolgimento |
| Lessons Log | Lezioni raccolte durante il progetto |
Per Prenotazioni Smart, il rischio che le notifiche non siano affidabili su tutti i dispositivi entra nel Risk Log; un difetto già osservato nel pilota entra nell’Issue Log. La differenza è essenziale: un rischio può accadere, un’issue è già accaduta.
Pianificare transizione e Business Implementation
Un progetto non è pianificato completamente se considera solo la costruzione tecnica. Il Planning deve preparare anche:
- integrazione e transizione verso l’operatività;
- formazione e comunicazione;
- aggiornamento di processi e procedure;
- supporto iniziale agli utenti;
- misurazione dell’adozione;
- azioni per realizzare i benefici.
Il Transition Plan coordina il passaggio della soluzione verso esercizio e supporto. Il Business Implementation Plan organizza le attività perché il business adotti la soluzione e ne ricavi benefici.
Nel caso di Annotatio, rilasciare il software senza istruzioni per palestre e clienti, senza una procedura per le liste d’attesa e senza supporto iniziale sarebbe una delivery incompleta.
Qualità e accettazione devono essere pianificate prima
Un errore frequente è lasciare i criteri di accettazione all’Executing. Nel Planning occorre stabilire:
- quali deliverable saranno sottoposti ad accettazione;
- chi li verifica e chi approva;
- quali criteri devono essere soddisfatti;
- quali evidenze sono richieste;
- come gestire non conformità e rilavorazioni.
L’accettazione non è “a sensazione”. Deve confrontare il deliverable con criteri concordati.
Il Gate RfE: Ready for Executing
Il Gate Ready for Executing verifica che il progetto sia abbastanza preparato da impegnare risorse nella delivery.
Le domande essenziali sono:
- Project Handbook e Project Work Plan sono sufficientemente maturi?
- scope, calendario, budget e principali criteri di qualità sono baselined?
- ruoli, responsabilità e soglie decisionali sono chiari?
- rischi, dipendenze e assunzioni principali sono gestiti?
- transizione, Business Implementation e accettazione sono pianificate?
- risorse e capacità necessarie sono effettivamente disponibili?
- il PSC e gli organismi competenti hanno approvato il passaggio?
RfE non garantisce che il progetto non incontrerà problemi. Conferma che è pronto a gestirli con un piano, una governance e un riferimento di controllo.
Caso pratico: il piano sembra pronto, ma non lo è
Il PCT ha stimato sviluppo e test, ma nessuno ha definito come le palestre saranno formate, chi approverà il rilascio, come verranno gestite le richieste di modifica o chi sosterrà il prodotto dopo il pilota.
Il progetto non è pronto per RfE. Il piano tecnico può essere solido, ma mancano elementi essenziali di governance, accettazione, transizione e adozione.
Planning è completo solo quando delivery e business implementation sono pianificate insieme.
Da non confondere
| Coppia | Differenza |
|---|---|
| Project Handbook e Project Work Plan | Il Handbook definisce come si gestisce; il Work Plan definisce il lavoro da fare. |
| Piano operativo e baseline | Il piano evolve; la baseline è la sua versione approvata usata per il controllo. |
| Risk Log e Issue Log | Il rischio può accadere; l’issue è già avvenuta. |
| Transition Plan e Business Implementation Plan | Il primo cura handover e integrazione operativa; il secondo adozione e benefici business. |
| RfE e inizio informale dello sviluppo | RfE autorizza formalmente l’Executing con piani e controlli adeguati. |
Verifica ciò che ricordi
- Qual è la differenza tra Project Handbook e Project Work Plan?
- Perché una baseline è necessaria?
- Dove viene registrato un problema già materializzato?
- Che cosa pianifica il Business Implementation Plan?
- Che cosa autorizza RfE?
Risposte
- Il Handbook definisce approccio di gestione e governance; il Work Plan dettaglia la delivery.
- Per confrontare stato reale e piano approvato e gestire le modifiche in modo esplicito.
- Nell’Issue Log.
- Attività di adozione e realizzazione dei benefici.
- L’ingresso nell’Executing Phase.
Flashcard
D: Quale artefatto definisce l’approccio di gestione?
R: Project Handbook.
D: Quale artefatto dettaglia work package, attività, calendario e budget?
R: Project Work Plan.
D: Che cos’è una baseline?
R: Una versione approvata del piano usata come riferimento di controllo.
D: Dove si registra una richiesta di modifica?
R: Nel Change Log.
D: Quale Gate conclude Planning?
R: RfE – Ready for Executing.
Domanda in stile esame
Quale affermazione descrive correttamente il Project Handbook?
A. È il piano dettagliato di attività, risorse e budget.
B. Definisce l’approccio di gestione, governance e modalità operative del progetto.
C. Registra rischi e issue quotidiane.
D. È prodotto esclusivamente durante Closing.
Risposta corretta: B. Il Project Work Plan dettaglia la delivery; i log registrano informazioni operative; il Project Handbook stabilisce come il progetto viene gestito.
Nel prossimo articolo
Nel prossimo articolo entreremo nell’Executing: delivery, accettazione dei deliverable, transizione, Business Implementation e Gate RfC.
Fonti essenziali
- European Commission, PM² Project Management Methodology Guide v3.1.
- European Commission, PM² Project Management Methodology – Highlights, 2025 Edition.