Project Handbook in PM²: il riferimento operativo del progetto
Ventiseiesimo articolo della serie “Imparare PM² attraverso un progetto”
Un progetto può avere un Charter chiaro e continuare a lavorare in modo confuso: ruoli non aggiornati, piani sparsi, log difficili da trovare, regole diverse per ogni persona e decisioni senza un punto di riferimento.
Il Project Handbook in PM² è il contenitore operativo che riunisce le informazioni necessarie per gestire il progetto in modo coerente. Non è un documento da scrivere per archiviarlo: deve essere consultabile, mantenuto aggiornato e calibrato alla complessità reale del progetto.
Charter, Handbook e Work Plan: tre livelli diversi
| Artefatto | Domanda a cui risponde |
|---|---|
| Project Charter | Che progetto è, perché esiste, chi lo governa e quali sono i limiti iniziali? |
| Project Handbook | Come sarà organizzato e gestito quotidianamente il progetto? |
| Project Work Plan | Quale lavoro faremo, con quali stime, dipendenze e date? |
Il Handbook non sostituisce gli altri due. Li collega: parte dal mandato del Charter, incorpora o riferisce i piani e rende applicabile il Work Plan attraverso ruoli, processi, log e regole operative.
Che cosa contiene il Project Handbook
PM² lo struttura come una raccolta di elementi che il PM adatta al progetto. Non tutto deve essere sempre presente o avere lo stesso livello di dettaglio.
| Sezione | Contenuto tipico |
|---|---|
| Ruoli e responsabilità | Organizzazione del progetto, governance, RAM/RASCI e deleghe. |
| Project Management Plans | Piani per requisiti, cambiamenti, rischi, issue, qualità e comunicazione. |
| Project-Specific Plans | Piano di acceptance, transition, business implementation, outsourcing, se pertinenti. |
| Domain-Specific Artefacts | Artefatti tecnici, sicurezza, protezione dati, UX, procurement o altri domini applicabili. |
| Altri riferimenti | Project Work Plan, Stakeholder Matrix, log, repository, strumenti, convenzioni e decisioni. |
Il Handbook può essere un documento strutturato con allegati, uno spazio collaborativo con pagine collegate o un insieme di artefatti versionati. Ciò che conta è avere una fonte autorevole, una struttura comprensibile e riferimenti aggiornati.
Il principio del tailoring
PM² è intenzionalmente adattabile. Il tailoring non significa eliminare tutto ciò che sembra documentazione; significa mantenere soltanto ciò che aggiunge valore al controllo del progetto, senza perdere gli elementi essenziali di governance e tracciabilità.
| Situazione | Tailoring ragionevole |
|---|---|
| Piccolo progetto interno, team stabile | Handbook leggero, con sezioni brevi e log essenziali in un unico spazio. |
| Progetto con molti stakeholder e fornitore esterno | Piani e responsabilità più dettagliati, regole di comunicazione e acceptance formalizzate. |
| Progetto ad alto rischio o regolato | Maggiore evidenza su qualità, sicurezza, decisioni, audit trail e controlli. |
Non è tailoring dire: “non abbiamo tempo per il Risk Log”. Se il rischio esiste, il progetto ha bisogno di un modo proporzionato per gestirlo. Il tailoring sceglie forma e profondità, non nega il bisogno.
Un Handbook utile è orientato all’azione
Ogni sezione deve aiutare qualcuno a decidere o lavorare meglio. Una verifica semplice è chiedersi:
| Contenuto | Verifica di utilità |
|---|---|
| Ruoli | Una persona sa chi decide, chi esegue e a chi fare escalation? |
| Piano rischi | È chiaro dove registrare un rischio, chi lo possiede e come monitorarlo? |
| Piano cambiamenti | È chiaro come proporre, valutare e approvare una change? |
| Comunicazione | Ogni stakeholder sa quale informazione riceve e dove trovare quella ufficiale? |
| Qualità / acceptance | Si sanno criteri, evidenze e responsabilità prima della consegna? |
Se la risposta è no, aggiungere pagine non risolve: serve rendere il contenuto più operativo o trovare la forma adatta.
Governance e responsabilità nel Handbook
Il Handbook è il luogo naturale per rendere utilizzabile la RAM/RASCI. Non basta un organigramma: per le attività rilevanti deve essere chiaro chi è Responsible, Accountable, Support, Consulted e Informed.
| Attività | Esempio di chiarimento nel Handbook |
|---|---|
| Approvare una change rilevante | Chi prepara l’analisi, chi decide, chi deve essere consultato e informato. |
| Accettare un deliverable | Criteri, soggetto che verifica, soggetto che accetta e gestione di eccezioni. |
| Gestire un issue critico | Owner, soglia di escalation, canale e autorità competente. |
| Preparare il go-live | Responsabili di transizione tecnica, formazione, supporto e decisione di readiness. |
Questo evita sia il “tutti sono responsabili” sia il “nessuno ha l’autorità”.
Il caso Annotatio: un Handbook leggero ma completo
Per Prenotazioni Smart, il Handbook non deve diventare un manuale di cento pagine. Può avere una struttura pratica:
| Sezione | Contenuto |
|---|---|
| Overview | Link al Charter, obiettivo, scope iniziale, milestone principali e repository ufficiale. |
| Ruoli | PO, SP, BM, PM, team tecnico, gestori pilota e RAM per decisioni chiave. |
| Work Plan | Link al piano con attività, dipendenze, owner e date. |
| Piani essenziali | Regole leggere per requisiti, change, risk, issue, qualità e comunicazione. |
| Acceptance e transition | Criteri della lista d’attesa, test, checklist go-live, supporto e fallback notifiche. |
| Log | Link a Risk, Issue, Change e Decision Log con owner e stato. |
| Documentazione tecnica | API, configurazione push, ruoli, istruzioni operative e runbook. |
L’obiettivo non è duplicare le informazioni. È permettere a una persona che entra nel progetto di capire rapidamente come si lavora, quali decisioni contano e dove si trova la fonte affidabile.
Versioning e manutenzione
Un Handbook statico diventa rapidamente pericoloso, perché dà un falso senso di controllo. Il PM deve definire almeno:
- dove risiede la versione ufficiale;
- chi può modificare le sezioni principali;
- quando le modifiche richiedono review o approvazione;
- come sono collegati piani e log aggiornati;
- quale versione è stata approvata al gate RfE e quali aggiornamenti successivi sono rilevanti.
Non tutte le modifiche richiedono un comitato. Aggiornare un contatto o una data operativa può essere ordinario; cambiare ruoli, tolleranze o processo di acceptance può richiedere una decisione controllata.
Da non confondere
| Affermazione | Correzione |
|---|---|
| “Il Handbook è un documento aggiuntivo oltre ai piani.” | È il contenitore o punto di accesso che collega piani, ruoli, log e regole. |
| “Tailoring significa ridurre la documentazione al minimo.” | Significa calibrare gli artefatti al valore e al rischio, mantenendo controllo e tracciabilità. |
| “Se abbiamo Jira o Teams, non serve il Handbook.” | Gli strumenti non sostituiscono la struttura, le regole e la fonte autorevole. |
| “Il Handbook si completa in Planning e non cambia più.” | Va mantenuto vivo quando cambiano ruoli, piani, governance o condizioni operative. |
Tre domande per fissarlo
- Dove troverebbe un nuovo membro le regole ufficiali per gestire rischi, change e issue?
- Quale contenuto merita una sezione dedicata perché il suo rischio o impatto è alto?
- Quale artefatto può essere semplificato senza perdere una decisione, responsabilità o evidenza essenziale?
Flashcard
D: A cosa serve il Project Handbook?
R: A raccogliere e collegare ruoli, piani, log, artefatti e regole operative necessarie per gestire il progetto in modo coerente.
D: Qual è la differenza tra Handbook e Work Plan?
R: Il Handbook spiega come il progetto è organizzato e gestito; il Work Plan dettaglia il lavoro, le stime, il calendario e le dipendenze.
D: Che cosa significa tailoring in PM²?
R: Adattare forma e profondità degli artefatti a complessità e rischio del progetto, senza eliminare il controllo necessario.
Domanda in stile esame
Un PM decide di non preparare il Project Handbook perché tutte le attività sono già tracciate in uno strumento di ticketing. Dopo alcune settimane, il team non sa quale versione dei criteri di acceptance sia valida, chi approvi le change e dove siano registrate le decisioni.
Qual è la valutazione corretta?
Risposta: il ticketing può contenere informazioni, ma non sostituisce un riferimento operativo coerente. Il Project Handbook deve rendere espliciti struttura, ruoli, piani, fonti ufficiali e collegamenti a log e artefatti, in una forma proporzionata al progetto.
Fonte
Project Handbook, Project Management Plans, Project-Specific Plans e tailoring sono trattati nella PM² Methodology Guide 3.1 della Commissione europea.
Nel prossimo articolo: Project Work Plan, per passare dal mandato e dalle regole al lavoro effettivo, stimato e sequenziato.