Deliverable di progetto (PMBOK) vs prodotti di progetto (PRINCE2)
Al centro di entrambi i framework c’è la stessa cosa: i risultati che un progetto deve consegnare. Il PMBOK li chiama deliverable, PRINCE2 li chiama prodotti (products) e, sebbene i due concetti si sovrappongano molto, non sono identici. Le differenze dicono molto su come ciascun framework concepisce il controllo e la responsabilità. Questo articolo confronta i deliverable di progetto (PMBOK) con i prodotti di progetto (PRINCE2): come viene definito ciascuno, dove i concetti differiscono davvero, come si corrispondono e quale termine usare nella tua documentazione di progetto.
Punti chiave:
- Entrambi i termini descrivono risultati di progetto verificabili — risultati che un progetto deve produrre e consegnare per l’accettazione. Il PMBOK tratta il deliverable come un concetto del suo vocabolario, mentre PRINCE2 fa del prodotto il fondamento dell’intero metodo.
- Un deliverable PMBOK è qualsiasi risultato unico e verificabile — un prodotto, un risultato o una capacità necessari a completare un processo, una fase o un progetto, prodotto lungo tutto il ciclo di vita.
- Un prodotto PRINCE2 copre un ambito più ampio — include i prodotti specialistici consegnati agli utenti e i prodotti di gestione come piani, registri e report, ciascuno con criteri di qualità definiti.
- Differenze chiave — PRINCE2 considera gli artefatti di gestione come prodotti a pieno titolo e richiede una descrizione di prodotto per ogni risultato; il PMBOK classifica quegli artefatti come documenti di progetto e lascia il livello di definizione al giudizio professionale.
- Come si corrispondono i concetti — i prodotti specialistici corrispondono ai deliverable di prodotto, i prodotti di gestione ai deliverable di processo. Un unico vocabolario fissato nel project charter previene la confusione.
Perché il PMBOK e PRINCE2 nominano diversamente i risultati di progetto
La differenza di denominazione non è un caso di traduzione, ma il riflesso di ciò che ciascun framework è. Il PMBOK è un corpus di conoscenze descrittivo: cataloga concetti, pratiche e artefatti e si affida al giudizio del project manager su come applicarli. PRINCE2 è un metodo prescrittivo: definisce processi, ruoli e una catena di responsabilità, e ha bisogno di un concetto portante a cui quei processi possano agganciarsi. Quel concetto è il prodotto. Così, mentre entrambi i framework parlano di risultati verificabili, il PMBOK tratta il deliverable come un termine tra tanti, e PRINCE2 costruisce l’intero metodo sul pianificare, delegare e accettare prodotti. Comprendere questa asimmetria è la chiave di ogni differenza descritta di seguito.
Goditi l'accesso completo a FlexiProject per 30 giorni, senza costi né spese
Che cos’è un deliverable nel PMBOK?
Nei termini del PMBOK, un deliverable è qualsiasi prodotto, risultato o capacità di erogare un servizio, unico e verificabile, richiesto per completare un processo, una fase o un progetto. Unico significa che è definito per questo specifico progetto; verificabile significa che il suo completamento può essere controllato rispetto a criteri anziché semplicemente dichiarato. I deliverable compaiono lungo tutto il ciclo di vita: un piano di progetto approvato o un report di test è un deliverable della sua fase così come il sistema finale è un deliverable dell’intero progetto.
Il concetto plasma anche il modo in cui il PMBOK pianifica il lavoro. La struttura di scomposizione del lavoro (WBS) è definita come una scomposizione del lavoro di progetto orientata ai deliverable, il che significa che il piano scende dai risultati alle attività, non il contrario. I deliverable vengono poi verificati nel controllo qualità e accettati formalmente dal cliente o dallo sponsor. Ciò che il PMBOK non fa è prescrivere un documento standard per definire ciascun deliverable; il livello di documentazione è lasciato al giudizio professionale. Per una trattazione completa del concetto, inclusi tipi e tecniche di identificazione, consulta la nostra guida ai deliverable di progetto.
Che cos’è un prodotto in PRINCE2?
PRINCE2 eleva la stessa idea a principio. Uno dei sette principi del metodo è la focalizzazione sui prodotti: un progetto PRINCE2 concorda e definisce i suoi prodotti prima di pianificare il lavoro, e tutto ciò che il progetto crea o modifica conta come prodotto. Il concetto si divide in due categorie con destinatari diversi.
Prodotti specialistici
I prodotti specialistici sono ciò che il progetto esiste per consegnare ai suoi utenti: il sistema, l’edificio, la campagna, il nuovo processo. È la parte del vocabolario di PRINCE2 che coincide con il senso quotidiano e intuitivo di un deliverable. I prodotti specialistici vengono consegnati, accettati rispetto a criteri di qualità e in definitiva giustificano il business case del progetto.
Prodotti di gestione
I prodotti di gestione sono gli artefatti usati per governare il progetto stesso: il piano di progetto, il business case, i registri dei rischi e delle criticità, i report di checkpoint e di sintesi. Il PMBOK conosce anch’esso questi elementi, ma li archivia come documenti o artefatti di progetto. PRINCE2 concede loro il pieno status di prodotto, con composizione e criteri di qualità definiti, secondo la logica che un progetto guidato da report trascurati fallisce con la stessa certezza di uno che costruisce un sistema trascurato. È qui che i due framework divergono davvero.
Descrizioni di prodotto e pianificazione basata sui prodotti
Ogni prodotto PRINCE2 riceve una descrizione di prodotto: il suo scopo, la composizione, i criteri di qualità e chi lo accetta. La pianificazione stessa parte dai prodotti, attraverso una struttura di scomposizione dei prodotti, e solo dopo scende alle attività. La descrizione di prodotto funziona come un contratto: fissa, prima che il lavoro inizi, cosa conterà come fatto. Dove il PMBOK si affida al giudizio del project manager per decidere quanta definizione serva a un risultato, PRINCE2 presuppone che siano proprio i prodotti definiti a rendere possibili trasparenza e responsabilità.
Deliverable di progetto e prodotti di progetto: confronto affiancato
| Deliverable (PMBOK) | Prodotto (PRINCE2) | |
| Definizione | Prodotto, risultato o capacità, unico e verificabile, richiesto per completare un processo, una fase o un progetto | Tutto ciò che il progetto crea o modifica, specialistico o di gestione |
| Rango nel framework | Un concetto nel vocabolario | Fondamento del metodo, sostenuto dal principio di focalizzazione sui prodotti |
| Artefatti di gestione | Classificati come documenti o artefatti di progetto | Prodotti a pieno titolo con descrizioni e criteri di qualità |
| Ruolo nella pianificazione | La WBS è orientata ai deliverable | La pianificazione parte dalla struttura di scomposizione dei prodotti |
| Standard di definizione | Lasciato al giudizio professionale | Descrizione di prodotto obbligatoria per ogni prodotto |
| Accettazione | Verificato e accettato formalmente dal cliente o dallo sponsor | Accettato rispetto ai criteri di qualità indicati nella descrizione di prodotto |
Letta nel suo insieme, la tabella mostra concetti che si sovrappongono forse in quattro casi su cinque. Un’applicazione testata è sia un deliverable sia un prodotto specialistico; la differenza di vocabolario non cambia nulla del lavoro. La divergenza compare ai bordi: nello status degli artefatti di gestione e in quanto rigore di definizione il framework richiede per impostazione predefinita. PRINCE2 compra prevedibilità al prezzo dell’onere documentale; il PMBOK compra flessibilità al prezzo di dipendere dal giudizio e dalla disciplina del singolo project manager.
Cosa significa la differenza nella pratica
Come si corrispondono i due concetti
Se la tua organizzazione distingue i deliverable di prodotto da quelli di processo, o gli esterni dagli interni, stai già usando la suddivisione di PRINCE2 con nomi diversi: i prodotti specialistici corrispondono ai deliverable di prodotto ed esterni, i prodotti di gestione a quelli di processo e interni. La corrispondenza è abbastanza stretta da permettere ai team di tradurre la documentazione tra i due vocabolari quasi meccanicamente, purché qualcuno enunci la corrispondenza una volta invece di lasciarla indovinare a ogni lettore.
Quale termine usare nella documentazione di progetto
Usa il vocabolario del framework che la tua organizzazione segue davvero, e dichiaralo esplicitamente nel project charter. I problemi iniziano negli ambienti ibridi, dove un PMO formato in PRINCE2 legge “deliverable” nel piano in stile PMBOK di un fornitore e presume che manchino i prodotti di gestione, o viceversa. Una frase nel charter, che indichi quale termine il progetto usa e cosa comprende, non costa nulla e impedisce che le riunioni di accettazione si trasformino in seminari di terminologia. Le parole contano meno della disciplina che portano: un risultato con un nome, criteri definiti, un responsabile con un nome.
Sblocca tutte le funzionalità e dai slancio ai tuoi progetti, goditi 30 giorni di FlexiProject gratis!
Gestire deliverable e prodotti in un unico sistema
Qualunque vocabolario prevalga nella tua organizzazione, l’esigenza operativa è identica: un luogo in cui ogni risultato ha una descrizione, criteri di accettazione, una scadenza, un responsabile e uno stato visibile. In FlexiProject, il modulo Prodotti fa esattamente questo per il lato specialistico: ogni deliverable è definito con il suo ambito e i suoi criteri di accettazione, collegato alle attività e alle milestone che lo producono, e monitorato separatamente dal completamento delle attività, così che un’attività eseguita non venga mai scambiata per un risultato accettato. Ne beneficia anche il lato di gestione: i report di stato ricorrenti sono generati da dati di progetto aggiornati anziché assemblati a mano, che è esattamente la qualità che PRINCE2 si aspetta dai prodotti di gestione. I template di progetto chiudono il cerchio standardizzando l’elenco dei prodotti per i progetti ripetibili, così che ogni nuovo progetto parta con risultati, requisiti e modelli di documento già definiti.
Deliverable di progetto e prodotti di progetto: FAQ
Un prodotto PRINCE2 è la stessa cosa di un deliverable di progetto?
Per i prodotti specialistici, in pratica sì: entrambi descrivono un risultato verificabile consegnato agli utenti e accettato rispetto a criteri. I concetti smettono di essere identici agli artefatti di gestione, che PRINCE2 conta come prodotti e il PMBOK classifica come documenti di progetto.
Cosa sono i prodotti di gestione in PRINCE2?
Artefatti usati per governare il progetto: il piano di progetto, il business case, i registri dei rischi e delle criticità, i report di checkpoint e di sintesi. Ognuno ha una composizione e criteri di qualità definiti, esattamente come i prodotti consegnati agli utenti.
Il PMBOK ha un equivalente dei prodotti di gestione?
Sì, nella sostanza: il PMBOK descrive gli stessi piani, registri e report come documenti o artefatti di progetto. La differenza è che il PMBOK non li tratta come deliverable di pari rango rispetto ai risultati del progetto e non richiede una descrizione formale per ciascuno.
Si possono combinare i prodotti PRINCE2 con le pratiche del PMBOK?
Sì, e gli assetti ibridi sono comuni: molte organizzazioni pianificano da una struttura di scomposizione dei prodotti pur usando altrove il vocabolario del PMBOK. La combinazione funziona finché il progetto fissa un vocabolario condiviso e tiene un unico elenco di risultati con responsabili e criteri di accettazione.
I deliverable di progetto nel PMBOK e i prodotti di progetto in PRINCE2 descrivono la stessa cosa fondamentale: risultati verificabili che un progetto deve consegnare. Le differenze reali sono due. PRINCE2 concede agli artefatti di gestione il pieno status di prodotto, mentre il PMBOK li archivia come documenti di progetto; e PRINCE2 impone una descrizione di prodotto per ogni risultato, mentre il PMBOK si affida al giudizio professionale del project manager.
Tutto il resto è vocabolario, e il vocabolario è economico da allineare: una frase nel project charter che fissa i termini usati previene gran parte dell’attrito tra i due approcci. Ciò che non si può saltare in nessuno dei due framework è la disciplina sotto le parole: risultati definiti prima dell’inizio del lavoro, criteri di accettazione concordati in anticipo, responsabili nominati e stato visibile accanto alla schedulazione. Un sistema PPM che tiene questa disciplina in un unico posto, come fa FlexiProject con il suo modulo Prodotti, i report ricorrenti e i template di progetto, serve entrambi i vocabolari senza costringere un team a scegliere tra loro.
