Project Work Plan in PM²: trasformare il mandato in lavoro governabile
Ventisettesimo articolo della serie “Imparare PM² attraverso un progetto”
Un elenco di attività non è ancora un piano. Per gestire un progetto servono un risultato da consegnare, il lavoro necessario per produrlo, una sequenza credibile, stime, responsabilità e una visione aggiornata di ciò che può bloccare il percorso.
Il Project Work Plan in PM² è l’artefatto che organizza questo insieme. Collega scope, deliverable, attività, risorse, effort, calendario, dipendenze e milestone: è la base per coordinare l’esecuzione e controllare tempi e costi.
Dal Charter al lavoro effettivo
| Artefatto | Livello |
|---|---|
| Project Charter | Perché il progetto esiste, cosa autorizza e con quale governance. |
| Project Handbook | Come sarà gestito il progetto: ruoli, piani, log e regole. |
| Project Work Plan | Che cosa deve essere realizzato, da chi, in quale sequenza e con quali stime/date. |
Il Work Plan non sostituisce Requirements Management o Change Management. Usa requisiti e scope approvati per organizzare il lavoro; quando questi cambiano, il piano viene aggiornato in modo controllato.
I componenti essenziali
| Componente | Funzione |
|---|---|
| Deliverable | Risultati verificabili che il progetto deve produrre. |
| Work Breakdown Structure (WBS) | Scomposizione del lavoro necessario per produrre i deliverable. |
| Attività | Unità di lavoro pianificabili, assegnabili e monitorabili. |
| Stime | Effort, durata, costi e risorse necessari. |
| Dipendenze | Relazioni che determinano ordine, attese e vincoli. |
| Schedule | Date, milestone e sequenza temporale. |
| Responsabilità | Owner o team che eseguono e coordinano il lavoro. |
| Baseline e forecast | Riferimento approvato e previsione aggiornata del completamento. |
Il livello di dettaglio è proporzionato. Un’attività di mezz’ora non deve necessariamente comparire nel piano di progetto; una dipendenza che può ritardare il go-live sì.
Prima i deliverable, poi le attività
Iniziare dalle attività porta spesso a un piano del tipo “fare analisi, sviluppare, testare”. È difficile verificare completezza e valore. Iniziare dai deliverable obbliga invece a chiedersi che cosa sarà concretamente consegnato e accettato.
flowchart TD
A[Scope e requisiti approvati] --> B[Deliverable]
B --> C[WBS]
C --> D[Attività]
D --> E[Stime, risorse e dipendenze]
E --> F[Schedule e milestone]
F --> G[Baseline e controllo]
Una WBS non è solo una lista gerarchica: aiuta a non dimenticare lavoro necessario ma poco visibile, come documentazione, sicurezza, test, formazione, acceptance, transizione e supporto iniziale.
Stime: effort, durata, costo e incertezza
| Concetto | Che cosa misura |
|---|---|
| Effort | Il lavoro necessario, ad esempio giornate-persona. |
| Durata | Il tempo di calendario necessario, considerando capacità e dipendenze. |
| Costo | Valore economico di effort, licenze, forniture e altre spese. |
| Contingency | Riserva ragionata per incertezza o rischi identificati. |
Una stima utile dichiara assunzioni e grado di incertezza. “Tre giorni” senza dire se include test, review, disponibilità dell’ambiente e feedback dell’utente è una promessa ambigua, non una stima.
Per attività incerte, una tecnica semplice è la stima a tre punti:
| Stima | Domanda |
|---|---|
| Ottimistica | Se tutto va bene, quanto serve? |
| Più probabile | Nelle condizioni normali attese, quanto serve? |
| Pessimistica | Se emergono difficoltà realistiche, quanto serve? |
Non serve applicarla ovunque; è utile sulle attività con elevata incertezza o impatto.
Dipendenze e percorso critico
Le dipendenze definiscono quando un’attività può iniziare o completarsi rispetto a un’altra. Le più frequenti sono finish-to-start: un’attività inizia dopo che un’altra è terminata. Ma esistono anche dipendenze da decisioni, fornitori, ambienti, utenti e norme.
| Dipendenza | Esempio Annotatio |
|---|---|
| Tecnica | Le notifiche push richiedono configurazione del provider prima dei test end-to-end. |
| Organizzativa | L’acceptance richiede disponibilità del gestore della palestra pilota. |
| Decisionale | Una nuova regola di priorità richiede decisione del PO prima dello sviluppo. |
| Esterna | Un acquisto o un’autorizzazione deve essere completato prima del go-live. |
Il percorso critico è la sequenza di attività che determina la prima data possibile di fine progetto: un ritardo su una di esse ritarda il risultato finale, se non esiste margine. Non tutte le attività urgenti sono critiche; il Work Plan aiuta a distinguerle.
Milestone: eventi di controllo, non attività lunghe
Una milestone è un punto significativo senza durata propria: una decisione, un gate, un deliverable accettato o un momento di rilascio.
| Milestone | Esempio |
|---|---|
| RfE approvato | Il progetto è autorizzato a entrare in Executing. |
| Prototipo validato | Utenti chiave hanno confermato il flusso principale. |
| Acceptance completata | Criteri verificati e deliverable accettati. |
| Go-live | Soluzione attivata per gli utenti previsti. |
Scrivere “test” come milestone è impreciso: il test è un’attività; “test completati e accettati” può essere una milestone.
Costruire una baseline, poi gestire il forecast
Una volta approvato, il Work Plan diventa il riferimento per monitoraggio e controllo. Durante l’esecuzione, il PM aggiorna il forecast con avanzamento reale, lavoro residuo, issue, rischi e decisioni.
| Baseline | Forecast |
|---|---|
| Piano approvato rispetto al quale misurare scostamenti. | Migliore previsione attuale di date, costi ed effort a finire. |
| Cambia solo con Change Management e approvazione. | Può cambiare frequentemente con nuove evidenze. |
Sostituire la baseline ogni settimana con il piano aggiornato elimina la possibilità di capire quanto e perché il progetto è cambiato.
Il caso Annotatio: Work Plan semplificato
Per Prenotazioni Smart, una parte del piano potrebbe essere:
| Deliverable | Attività chiave | Dipendenza | Owner | Milestone |
|---|---|---|---|---|
| Flusso di prenotazione | Dettagliare requisiti e criteri; implementare; testare. | Validazione del gestore. | Team Annotatio. | Flusso accettato. |
| Lista d’attesa | Definire regole; sviluppare promozione e timeout; testare casi limite. | Provider notifiche configurato. | Team Annotatio. | Lista d’attesa accettata. |
| Readiness go-live | Configurare ruoli, guida, formazione, supporto e fallback. | Funzioni accettate. | BM + PM + SP. | Go-live autorizzato. |
| Misura benefici | Definire baseline no-show e dashboard di monitoraggio. | Dati storici disponibili. | BM + gestore. | KPI baseline approvata. |
Questo piano fa emergere lavoro che una roadmap puramente tecnica potrebbe ignorare: formazione, supporto, disponibilità utente e misurazione dei benefici.
Pianificazione rolling-wave
Non ogni parte del progetto può essere pianificata allo stesso livello di dettaglio fin dall’inizio. Il rolling-wave planning pianifica in dettaglio il lavoro vicino nel tempo e mantiene a livello più alto quello lontano, raffinandolo quando emergono dati migliori.
Non è una licenza per non pianificare il futuro: milestone, dipendenze, rischi e orientamento di lungo periodo devono rimanere visibili. Cambia il livello di dettaglio, non la disciplina del controllo.
Da non confondere
| Affermazione | Correzione |
|---|---|
| “Il Work Plan è una lista di task.” | Collega deliverable, attività, stime, dipendenze, risorse, milestone e controllo. |
| “Più dettaglio significa automaticamente un piano migliore.” | Il dettaglio deve essere utile al coordinamento e al controllo; troppo dettaglio crea manutenzione inutile. |
| “Dieci giorni di effort significano dieci giorni di calendario.” | Durata dipende da capacità, parallelismo, dipendenze e attese. |
| “Il forecast sostituisce la baseline.” | Il forecast aggiorna la previsione; la baseline resta il riferimento approvato finché non cambia formalmente. |
Tre domande per fissarlo
- Quale deliverable accettato dimostra il completamento di questa parte di scope?
- Quale dipendenza può davvero spostare la data finale?
- Quale assunzione rende la stima più incerta e va resa esplicita?
Flashcard
D: A cosa serve il Project Work Plan?
R: A organizzare deliverable, attività, stime, risorse, dipendenze, calendario e milestone per coordinare e controllare il progetto.
D: Perché iniziare dai deliverable?
R: Per verificare completezza e valore, poi identificare il lavoro necessario per produrli e accettarli.
D: Qual è la differenza tra baseline e forecast?
R: La baseline è il piano approvato; il forecast è la migliore previsione aggiornata di completamento.
Domanda in stile esame
Il PM elenca sviluppo, test e rilascio nel piano, ma non inserisce disponibilità degli utenti per l’acceptance, formazione e configurazione del supporto. A pochi giorni dal go-live, scopre che nessuno può accettare il deliverable e gestire il servizio.
Qual è la causa principale?
Risposta: il Work Plan è stato costruito come lista tecnica di attività, non come piano completo orientato ai deliverable e alla transizione. Le dipendenze organizzative, l’acceptance e la readiness operativa dovevano far parte della WBS e dello schedule.
Fonte
Project Work Plan, WBS, stime, scheduling, milestone e tecniche di pianificazione sono trattati nella PM² Methodology Guide 3.1 della Commissione europea.
Nel prossimo articolo: Registri PM², per usare Risk, Issue, Change e Decision Log come strumenti vivi di governo del progetto.