Guida al project management · Pianificazione e ambito
Project Initiation Document (PID): contenuti ed esempio
Un project initiation document (PID) è l'insieme di informazioni che definisce un progetto, spiega come sarà gestito e costituisce la baseline che il project board approva prima dell'inizio della delivery. Nasce da PRINCE2, dove il project manager lo compone durante l'inizializzazione, ma molte organizzazioni usano il PID qualunque sia il loro metodo. Questa guida spiega cosa contiene un PID, come redigerlo, un esempio svolto e in cosa differisce da un charter.
Punti chiave
- Un PID definisce cosa consegnerà il progetto, perché, come sarà gestito ed entro quali limiti.
- In PRINCE2 il project manager lo compone durante Inizializzare un progetto e il project board lo approva.
- Una volta approvato, il PID diventa la baseline e le modifiche passano attraverso il controllo delle modifiche, spesso riesaminate ai limiti di fase.
- Le tolleranze nel PID consentono al project manager di agire senza portare in escalation ogni piccolo scostamento (gestione per eccezione).
- Proporzionalo al progetto: un progetto piccolo o Agile richiede un PID breve, un grande programma molto di più.
Che cos'è un project initiation document?
A project initiation document (PID) è una raccolta di informazioni che definisce un progetto e stabilisce come sarà gestito. Riunisce la definizione del progetto, il business case, la struttura del team, il piano di progetto, gli approcci di gestione, i controlli e l'adattamento. Una volta approvato dal project board, il PID diventa la baseline per gestire e valutare il progetto.
PRINCE2 lo chiama formalmente project initiation documentation, perché non deve essere necessariamente un unico file. Può essere un singolo documento, un insieme di documenti collegati o una pagina in uno strumento di project management, purché tutto sia approvato e controllato insieme.
Il PID risponde alle domande a cui chi decide deve rispondere prima di impegnare denaro e persone:
- Cosa stiamo facendo esattamente, e cosa non stiamo facendo?
- Perché vale la pena farlo, e quali benefici ci aspettiamo?
- Chi è responsabile di cosa, e chi decide?
- Quanto tempo richiederà e quanto costerà?
- Come gestiremo qualità, rischi, problemi, modifiche e comunicazione?
- Di quanto possono variare le cose prima che il project manager debba portarle in escalation?
Anche se il termine deriva da PRINCE2, i PID sono ampiamente usati negli enti pubblici britannici, nei servizi sanitari e in aziende che non seguono PRINCE2 alla lettera.
Perché il PID è importante
PRINCE2 descrive il PID come un contratto tra il project manager e il project board: registra ciò che il board ha approvato e ciò che il project manager si è impegnato a consegnare. In pratica, un buon PID ti offre:
- Una decisione chiara di go o no-go: il board autorizza il progetto sulla base di un quadro completo, non di un'idea approssimativa.
- Una baseline: avanzamento, costi, ambito e benefici sono misurati rispetto a quanto approvato.
- Gestione per eccezione: le tolleranze concordate consentono al project manager di gestire il progetto giorno per giorno e di portare in escalation solo quando si prevede che i limiti vengano superati.
- Governance chiara: ruoli, diritti decisionali e linee di reporting sono concordati prima che sorgano problemi; vedi governance di progetto.
- Continuità: nuovi membri del team, fornitori e membri del board possono comprendere il progetto da un unico punto.
- Un riferimento alla chiusura: alla fine, il board confronta ciò che è stato consegnato con ciò che il PID prometteva.
Dove si colloca il PID in PRINCE2
Il PID viene prodotto nella seconda fase di un progetto PRINCE2, la fase di inizializzazione, e viene poi usato per tutta la durata del progetto. La tabella lo segue attraverso i processi PRINCE2.
| Processo PRINCE2 | Cosa succede al PID |
|---|---|
| Avviare un progetto | Prima che il PID esista, si preparano un breve project brief e un business case preliminare affinché il board possa decidere se valga la pena procedere con l'inizializzazione. |
| Dirigere un progetto (autorizzare l'inizializzazione) | Il project board accetta di investire nella fase di inizializzazione. |
| Inizializzare un progetto | Il project manager sviluppa gli approcci di gestione, il piano di progetto, i controlli e il business case dettagliato e li riunisce nel PID. |
| Dirigere un progetto (autorizzare il progetto) | Il project board esamina e approva il PID, che diventa la baseline. |
| Gestire il limite di fase | Il project manager aggiorna il PID dove necessario (ad esempio il business case e il piano di progetto) affinché il board lo esamini prima della fase successiva. |
| Chiudere un progetto | Il PID viene usato per confrontare il risultato finale con la baseline originale e le modifiche approvate. |
PRINCE2 7, pubblicato da PeopleCert nel 2023, ha rinominato i sette temi come pratiche: business case, organizzazione, piani, qualità, rischio, problemi e avanzamento. Ha inoltre aggiunto approcci di gestione per gli aspetti commerciali, la sostenibilità, il digitale e i dati, e ha introdotto un nuovo capitolo sulle persone. Il PID resta al centro dell'inizializzazione.
Se stai confrontando i framework, vedi PMBOK vs PRINCE2.
Cosa contiene un project initiation document
Secondo le indicazioni PRINCE2, il PID riunisce le parti seguenti. Al di fuori di PRINCE2, la maggior parte dei modelli di PID segue una struttura simile con intestazioni diverse.
| Sezione del PID | Che cosa contiene |
|---|---|
| Definizione del progetto | Contesto, obiettivi, risultati attesi, ambito ed esclusioni, deliverable, vincoli, assunzioni, utenti e interfacce |
| Business case | Motivazioni, opzioni considerate, benefici e svantaggi attesi, costi, tempistiche, valutazione dell'investimento e rischi principali |
| Struttura del team di project management | Il project board, il project manager, i ruoli di assurance e di supporto, spesso sotto forma di organigramma |
| Descrizioni dei ruoli | Responsabilità e autorità per ciascun ruolo |
| Approcci di gestione | Come saranno gestiti qualità, rischi, problemi e modifiche, comunicazione e altre aree |
| Piano di progetto | Fasi, prodotti principali, milestone, risorse, costi e tempistiche |
| Controlli di progetto | Limiti di fase, tolleranze, reporting (ad esempio highlight report) ed escalation |
| Adattamento | Come il metodo è stato adattato al progetto e perché |
Definizione del progetto
Questo è il cuore del PID. Scrivi obiettivi di progettomisurabili, una dichiarazione dell'ambito con esclusioni esplicite, un elenco di deliverable con criteri di accettazione, e i vincoli e le assunzioni entro cui lavori. Molte controversie che sorgono più avanti in un progetto risalgono a una definizione vaga in questa sezione.
Approcci di gestione in PRINCE2 7
Gli approcci di gestione (chiamati strategie nelle edizioni precedenti) spiegano come una determinata area sarà gestita in questo progetto. PRINCE2 7 descrive approcci per aree come:
- Qualità: standard, metodi di qualità, responsabilità e registrazioni.
- Rischio: come i rischi vengono identificati, valutati e gestiti, con scale, responsabili e frequenza di riesame. Vedi gestione dei rischi di progetto.
- Problemi e controllo delle modifiche: come vengono registrati, valutati e decisi problemi e richieste di modifica.
- Comunicazione: quali informazioni vanno a chi, quando e come. Vedi piano di comunicazione.
- Commerciale: come vengono gestiti fornitori e contratti (novità di PRINCE2 7).
- Sostenibilità: come il progetto raggiungerà i propri obiettivi di sostenibilità (novità di PRINCE2 7).
- Digitale e dati: come saranno gestiti i dati e la tecnologia digitale (novità di PRINCE2 7).
PRINCE2 usa anche un approccio di gestione dei benefici, che descrive come e quando i benefici saranno misurati, spesso dopo la chiusura del progetto.
Controlli di progetto e tolleranze
I controlli spiegano come il board manterrà il comando senza gestire i dettagli: come il progetto è suddiviso in fasi di gestione, quali tolleranze si applicano, quali report produce il project manager e con quale frequenza, e quando occorre sollevare un'eccezione. Le tolleranze sono trattate più in dettaglio qui sotto.
PID vs project charter, business case e piano
Diversi documenti di avvio si sovrappongono. La tabella mostra dove si colloca ciascuno.
| Documento | Scopo | Quando | Approvato da |
|---|---|---|---|
| Project brief (PRINCE2) | Breve schema usato per decidere se avviare l'inizializzazione | Avviare un progetto | Project board |
| Business case | Giustifica l'investimento; mantenuto aggiornato per tutta la durata | Preliminare all'avvio, dettagliato nell'inizializzazione | Executive o sponsor |
| Project charter | Autorizza formalmente il progetto e il project manager (stile PMBOK) | Avvio | Sponsor |
| Project initiation document | Baseline completa per autorizzare e gestire il progetto (PRINCE2) | Avvio | Project board |
| Piano di project management | Come il progetto sarà eseguito, monitorato, controllato e chiuso (stile PMBOK) | Pianificazione | Sponsor |
| Statement of work | Descrizione contrattuale del lavoro che svolgerà un fornitore | Acquisti | Acquirente e fornitore |
Il modo più semplice per ricordare la differenza: un charter è breve e dice che il progetto è autorizzato; un PID è più lungo e dice esattamente cosa è stato autorizzato e come sarà gestito. Il PID contiene il piano di progetto, ma include anche il business case, la struttura del team e gli approcci di gestione, che un piano da solo non contiene.
A statement of work è ancora diverso: regola un contratto con un fornitore esterno, mentre il PID regola il progetto internamente.
Come redigere un project initiation document in 9 passaggi
L'ordine seguente funziona per la maggior parte dei progetti. In PRINCE2 questi passaggi avvengono nel processo Inizializzare un progetto; al di fuori di PRINCE2 costituiscono la tua fase di avvio.
- Esamina il project brief o il mandato. Conferma il contesto, gli obiettivi, il business case preliminare e le decisioni già prese dallo sponsor. Verifica che siano recepiti gli esiti dell'eventuale studio di fattibilità .
- Concorda l'adattamento. Decidi quanto formale deve essere il progetto in base a dimensioni, rischio e complessità, e registra queste decisioni.
- Scrivi la definizione del progetto. Stabilisci obiettivi, ambito, esclusioni, deliverable, criteri di accettazione, vincoli, assunzioni e interfacce con altri progetti o sistemi.
- Definisci gli approcci di gestione. Concorda come saranno gestiti qualità, rischi, problemi e modifiche, comunicazione e ogni altra area pertinente. Avvia il registro dei rischi in questa fase.
- Costituisci il team di project management. Nomina l'executive o sponsor, il senior user, il senior supplier e il project manager, con le descrizioni dei ruoli. Una matrice RACI rende chiare le responsabilità.
- Costruisci il piano di progetto. Suddividi il lavoro in prodotti o deliverable, definisci le fasi, stima impegno, costi e durata, e individua milestone e dipendenze.
- Perfeziona il business case. Aggiorna costi, tempistiche, benefici e rischi usando il piano dettagliato. Usa l' analisi costi-benefici dove è utile.
- Stabilisci controlli e tolleranze. Concorda limiti di fase, frequenza del reporting, tolleranze per tempi, costi, ambito e altre aree, e come saranno portate in escalation le eccezioni.
- Assembla, rivedi e sottoponi ad approvazione. Verifica che le parti siano coerenti, chiedi alla project assurance di esaminarle, poi sottoponi il PID al project board insieme a un piano per la fase successiva.
Esempio di project initiation document
L'esempio seguente è illustrativo e semplificato. Mostra come potrebbe presentarsi ciascuna parte di un PID per un'organizzazione di medie dimensioni che sostituisce il proprio sistema di customer relationship management (CRM).
| Sezione del PID | Voce di esempio |
|---|---|
| Contesto | L'attuale CRM non è più supportato dal fornitore e non può integrarsi con il nuovo sistema contabile. |
| Obiettivi | Sostituire il CRM entro il 30 giugno; migrare tutti i record dei clienti attivi; formare tutti gli 85 addetti vendite e assistenza prima del go-live. |
| Ambito | Include supporto alla selezione, configurazione, migrazione dei dati, integrazione con la contabilità e formazione. Esclude il sito web e la marketing automation. |
| Deliverable | CRM configurato; dati migrati e validati; integrazione con la contabilità; materiali di formazione; passaggio di consegne al supporto. |
| Vincoli e assunzioni | Budget fissato a £250,000; il go-live deve evitare il periodo di chiusura d'esercizio. Si presume che l'API del sistema contabile sia disponibile entro marzo. |
| Sintesi del business case | Evita il rischio di usare software non supportato; i benefici attesi sono meno reinserimenti manuali dei dati e un reporting migliore per i responsabili vendite. |
| Team di project management | Executive: Direttore vendite. Senior user: Responsabile assistenza clienti. Senior supplier: referente account del fornitore CRM. Project manager: interno. |
| Approcci di gestione | Qualità: test di accettazione utente approvati dal senior user. Rischio: riesame mensile dei rischi. Modifiche: quelle superiori a £5,000 vanno al board. |
| Piano di progetto | Quattro fasi: inizializzazione; configurazione e integrazione; migrazione e test; formazione e go-live. |
| Tolleranze | Tempi: più o meno due settimane. Costi: più o meno 5%. Ambito: i requisiti must-have non possono essere eliminati senza l'approvazione del board. |
| Reporting | Highlight report quindicinale al board; end stage report a ogni limite di fase. |
| Adattamento | Il board si riunisce mensilmente anziché per ogni decisione; si usa un unico registro combinato di rischi e problemi. |
Ogni voce è abbastanza specifica perché il board possa approvarla o contestarla. Voci vaghe come "migliorare i dati dei clienti" non danno al board alcun parametro a cui vincolare il progetto.
Tolleranze e gestione per eccezione
Le tolleranze sono una delle parti più utili di un PID e una delle più spesso trascurate. Sono i limiti concordati entro cui il project manager può prendere decisioni senza tornare dal board.
PRINCE2 stabilisce tolleranze per aree come tempi, costi, ambito, qualità, rischio e benefici. Esempi tipici:
| Area | Tolleranza di esempio |
|---|---|
| Tempi | Più o meno due settimane sulla data di go-live |
| Costi | Più o meno 5% del budget approvato |
| Ambito | Le funzionalità could-have possono essere eliminate; le must-have no |
| Qualità | Livelli di difetti definiti consentiti al go-live |
| Rischio | Nessun singolo rischio oltre un punteggio di impatto concordato senza riesame del board |
| Vantaggi | I benefici attesi possono variare di una percentuale concordata |
Quando il project manager prevede che una tolleranza verrà superata, solleva un'eccezione al board anziché aspettare che accada. Così le riunioni del board restano concentrate sulle decisioni che lo richiedono, e il project manager ha un'autorità chiara su tutto il resto. La nostra guida al report sullo stato del progetto mostra come riferire rispetto a questi limiti.
Adattare il PID a progetti piccoli e Agile
PRINCE2 prevede che il metodo venga adattato, e questo vale anche per il PID. Un breve progetto interno non ha bisogno di un documento di 40 pagine.
- Progetti piccoli: accorpa le sezioni, usa una sola pagina per definizione e piano, e fai riferimento agli approcci standard dell'organizzazione per qualità, rischio e comunicazione anziché riscriverli.
- Progetti Agile: PRINCE2 Agile usa ancora un PID, ma si concentra su obiettivi, risultati, tolleranze e modi di lavorare. L'ambito dettagliato si trova in un backlog prioritizzato, e le tolleranze di solito consentono all'ambito di variare mentre tempi e costi restano fissi.
- Progetti grandi o ad alto rischio: mantieni il PID come sintesi di controllo e collega documenti separati per il piano dettagliato, i registri e gli approcci.
Per saperne di più su come combinare la governance PRINCE2 con una delivery Agile, leggi PRINCE2 vs Agile.
Errori comuni nel PID e come evitarli
| Errore | Cosa fare invece |
|---|---|
| Copiare un modello lungo e compilare ogni sezione | Adatta la struttura e registra perché le sezioni sono state ridotte o eliminate |
| Obiettivi e ambito vaghi | Usa obiettivi misurabili ed elenca esplicitamente le esclusioni |
| Nessuna tolleranza, o tolleranze pari a zero | Concorda limiti realistici affinché la gestione per eccezione possa funzionare |
| Business case scritto una volta e dimenticato | Aggiornalo a ogni limite di fase e verifica che il progetto valga ancora la pena |
| Ruoli nominati ma non spiegati | Scrivi brevi descrizioni dei ruoli con i diritti decisionali |
| Trattare il PID come burocrazia utile solo per l'approvazione | Usalo nelle riunioni del board, negli highlight report e nei riesami di fase |
| Modificarlo in modo informale | Modifica il PID in baseline solo tramite il controllo delle modifiche |
| Duplicare contenuti di altri documenti | Fai riferimento al registro dei rischi, al piano o ai contratti anziché copiarli |
Modelli per costruire il tuo PID
Non offriamo un unico modello di PID, perché la maggior parte dei contenuti si trova già in documenti che creerai comunque. Questi modelli gratuiti coprono le sezioni principali, e puoi assemblarli o collegarli nel tuo PID:
- Modello di brief di progetto per la sintesi di avvio.
- Modello di business case per motivazioni, opzioni, costi e benefici.
- Modello di project charter per obiettivi, ambito, milestone e ruoli in un unico posto.
- Modello di piano di progetto per fasi, attività e milestone.
- modello di matrice RACI per il team di project management e le responsabilità.
- Modello di registro dei rischi e modello di piano di comunicazione per due degli approcci di gestione fondamentali.
Una volta approvato il PID, il passo successivo è gestire la prima fase di delivery in base a esso.
Modelli gratuiti per questo argomento
Domande frequenti
Che cos'è un project initiation document?
Un project initiation document (PID) è l'insieme di informazioni che definisce un progetto e come sarà gestito: definizione del progetto, business case, struttura del team, piano, approcci di gestione, controlli e adattamento. In PRINCE2 viene approvato dal project board e diventa la baseline del progetto.
Cosa significa PID nel project management?
PID sta per project initiation document. PRINCE2 lo chiama project initiation documentation, perché può essere un unico documento o un insieme di documenti collegati.
Chi redige il PID?
Lo compone il project manager, con il contributo del team, degli utenti, dei fornitori e degli specialisti. L'executive o sponsor è responsabile del business case, e spesso la project assurance esamina il PID prima che arrivi al board.
Chi approva il PID?
In PRINCE2, il project board approva il PID quando autorizza il progetto nel processo Dirigere un progetto. Al di fuori di PRINCE2, l'approvazione arriva di solito dallo sponsor o da un comitato guida.
Quando si redige un PID?
Durante la fase di inizializzazione, dopo che il board ha accettato di investire nell'inizializzazione e prima che inizi il lavoro di delivery principale.
Il PID si usa solo in PRINCE2?
No. Il termine deriva da PRINCE2, ma molte organizzazioni, soprattutto nel settore pubblico britannico, usano il PID qualunque sia il metodo che seguono.
Qual è la differenza tra un PID e un project charter?
A project charter è un documento breve e di alto livello che autorizza un progetto e il suo project manager. Un PID è più dettagliato: aggiunge business case, approcci di gestione, controlli, tolleranze e piano di progetto, e funge da baseline completa del progetto.
Qual è la differenza tra un PID e un piano di progetto?
Il piano di progetto copre fasi, prodotti, milestone, risorse, costi e tempistiche. Il PID contiene il piano di progetto, più la definizione del progetto, il business case, la struttura del team, gli approcci di gestione e i controlli.
Quanto deve essere lungo un PID?
Non esiste una lunghezza prestabilita. Un progetto piccolo e a basso rischio può richiedere poche pagine, mentre un grande programma può richiedere un documento corposo che rimanda a piani e registri separati. Adattalo alle dimensioni e al rischio del progetto.
Il PID può cambiare dopo l'approvazione?
Sì, ma solo tramite il controllo delle modifiche. In PRINCE2, il project manager aggiorna di solito il PID ai limiti di fase affinché il board lo esamini, e qualsiasi modifica alla baseline richiede l'approvazione del board.
I progetti Agile hanno bisogno di un PID?
PRINCE2 Agile usa ancora un PID, di solito più breve e focalizzato su obiettivi, tolleranze e modi di lavorare. L'ambito dettagliato si trova in un backlog prioritizzato anziché nel PID stesso.
Che cosa sono le tolleranze in un PID?
Le tolleranze sono limiti concordati per aree come tempi, costi, ambito, qualità, rischio e benefici. Entro questi limiti il project manager può agire senza escalation; se si prevede che una tolleranza venga superata, solleva un'eccezione al project board.
In cosa un PID è diverso da uno statement of work?
Un PID regola un progetto internamente ed è approvato dal project board o dallo sponsor. Uno statement of work descrive il lavoro che un fornitore esterno consegnerà in base a un contratto.