Prodotto (project management)
Nel campo del project management il prodotto rilasciato, indicato solitamente con il termine deliverable[1] nella letteratura tecnologica, indica un oggetto materiale o immateriale realizzato (fornito/consegnato) come risultato di un'attività del progetto. Un deliverable può essere costituito da un insieme di deliverable più piccoli. In altre parole si tratta di un risultato verificabile, di significativa rilevanza, rilasciato da un task di progetto o programma.
Descrizione
modificaNel corso della fase di pianificazione di un progetto, al momento della sua strutturazione in attività (o task)[2] ossia al momento della definizione della work breakdown structure del progetto, è fondamentale che a ciascun task venga associato almeno un deliverable e, viceversa, ciascun deliverable elementare del progetto sia assegnato ad un (unico) task.
Normalmente il deliverable è un oggetto/risultato sottoposto alla accettazione del committente del progetto, il quale deve assicurarsi (direttamente o tramite altra persona o struttura da lui delegata) che il deliverable prodotto soddisfi i requisiti definiti e concordati nella fase di progettazione nel senso che si attribuisce normalmente al concetto di qualità. Naturalmente, ed è così nella maggior parte dei casi, nel caso di progetti non banali il processo di accettazione viene innescato su deliverable più complessi, ossia composti da deliverable più piccoli eventualmente prodotti da più task.
Il concetto di deliverable differisce da quello di milestone, comunemente inteso in senso tecnico come punto di verifica dell'avanzamento di un progetto verso i risultati prestabiliti.
I deliverable permettono di rendere evidente la progressione dei lavori e agiscono, una volta sottoposti a verifica qualitativa, come milestone (tradotto dall'inglese "pietre miliari") nello sviluppo del processo che porterà ai risultati finali. Tali prodotti intermedi, hanno inoltre lo scopo di "allineare" le aspettative degli sponsor, dei clienti e della squadra di progetto.
Esempi
modificaEsempi di deliverable possono essere manufatti, documentazione, software funzionante, ecc. oppure risultati immateriali come il raggiungimento di un obiettivo di fatturato di un'azienda, il conseguimento di un risparmio percentuale di una certa risorsa, il miglioramento di un indicatore fisico/chimico/economico/sociale ecc., purché questo risultato sia prodotto da attività correlate ad un progetto che li assuma in coerenza ad un determinato scopo.
Nei casi di progetti di sistemi complessi (ad esempio l'impianto di condizionamento di un'automobile) o di opere (una strada) i deliverable sono ovviamente decine se non centinaia: elaborati, prototipi, campioni, relazioni, ecc. via via raffinati con il proseguire delle attività. Non bisogna confondere un deliverable con un qualsiasi output/risultato di progetto: i deliverables sono solo quelli critici, fondamentali, rilevanti specie quando richiedono l'approvazione da parte del committente o dell'utente. Spesso i deliverable sono specificati (o dovrebbero esserlo) a livello contrattuale, condivisi e documentati su documenti allegati o richiamati (capitolato, piano di progetto, ecc.).
Un milestone invece può consistere, ad esempio, nel completamento della fase di pianificazione di un progetto; in questo caso il raggiungimento del milestone implica che tutti i deliverable prodotti da quella fase (nella fattispecie è presumibile che si tratti di documenti) siano stati resi disponibili e accettati dal committente del progetto.
Principali deliverable legati alle attività di project management
modificaI documenti di questa lista (indicati in italiano) riportano a fianco il corrispondente nome (o i nomi) in inglese, in modo da facilitare i riferimenti ad oggetti conosciuti in ambito professionale e nella letteratura tecnica:
- Obiettivi di progetto* / Project charter
- Specifiche preliminari di progetto* – Allegato tecnico di progetto* / Preliminary Scope Statement - Statement of work
- Studio di fattibilità* - Business case* / Feasibility Study
- Specifiche di progetto* / Scope Statement
- Pianificazione di progetto / Project Initiation Document
- Struttura analitica di progetto / work breakdown structure
- Controllo variazioni di progetto / Change Control Plan
- Gestione dei rischi / Risk Management Plan
- Piano di comunicazione / Communications Plan
- Modello di gestione / Governance Model
- Pianificazione delle risorse / Resource Management Plan
- Scadenziario dei compiti del progetto / Project Schedule
- Matrice delle responsabilità / Responsibility assignment matrix
A seconda dell'approccio utilizzato e della complessità del progetto, questa lista può essere più breve o anche più articolata, comprendendo per esempio anche documenti del tipo:
- Risk Breakdown Structure
- Piano della Qualità / Quality Plan
- Piano di addestramento / Training Plan
- Piano di accettazione / Acceptance Plan
Altri deliverable di project management specificamente legati alle attività di controllo del progetto e sviluppati durante il suo corso sono:
- Project Action List - Registro dei rischi e problemi / Action Item List - Risk Register - Issue Log
- Stato Avanzamento Lavori (SAL) / Project Status Report
Tutti questi documenti sono normalmente sviluppati e manutenuti in un ambiente condiviso (di solito nella intranet del progetto) con i committenti e il team di progetto (o per lo meno con le persone chiave del team). Gli aggiornamenti effettuati ad alcuni di questi documenti (quelli contrassegnati con '*') dovrebbero essere esplicitamente annotati nel log degli aggiornamenti di versione che di solito compare nelle prime pagine di ogni documento di progetto rilasciato; il documento Controllo variazioni di progetto quando presente ha proprio lo scopo di tracciare le variazioni accadute agli obiettivi, alle specifiche, alle macro-pianificazioni e alle altre principali condizioni determinanti del progetto.
