Project Definition Document - P.M. Consulting
Menu principale:
- Home Page
- Mission
- Servizi
-
Spazio P.M.
- Introduzione
- Fondamenti
- Processi
- Ciclo di Vita
- Pratiche di Project Mgmt
- Coffee Break
Il Project Definition Document
Il "Project Definition Document", chiamato anche "Statement of Work" è il documento fondamentale di un progetto. Idealmente viene realizzato nella sua prima stesura nella fase di Sviluppo della Soluzione, come Allegato Tecnico descrittivo dei componenti principali della Proposta Commerciale presentata al Cliente. Il suo scopo è quello di rappresentare in modo chiaro e comprensibile come il progetto sarà attuato.
Durante la fase di Start-
La versione definitiva del Project Definition Document costituisce quindi la base di riferimento per gestire il Progetto e per orientare i membri del Team durante lo svolgimento delle attività.
Iniziare le attività di Progetto senza aver completato la stesura di questo documento è estremamente rischioso in quanto incrementa di molto il rischio di incomprensioni e di errate aspettative tra Cliente e Fornitore su ciò che deve essere fatto
E' opportuno che il Project Definition Document sia parte integrante del Contratto e come tale venga gestito per tutta la durata del Progetto per cui, ogni eventuale variazione a questo documento (ad esempio una variazione dei requisiti del progetto) è anche una modifica contrattuale (Change Request) e come tale va formalizzata.
Project Definition
La Struttura
1. Background
2. Obiettivi
3. Ambito (Scope)
4. Deliverables
5. Approccio
6. Assumptions
7. Vincoli, dipendenze esterne
8. Fattori critici di successo
9. Attrezzature e logistica
10. Responsabilità del Cliente
Guida alla Stesura di un "Project Definition Document"
Sezione 1. Background
In questa sezione introduttiva del documento vengono brevemente riassunte le ragioni di business che giustificano il progetto. Il testo deve essere chiaro, diretto e conciso, andando direttamente al punto chiave. Lo scopo principale di questa sezione è quello di rendere evidenti le ragioni del progetto anche a chi ha minore familiarità con il contesto.
Sezione 2. Obiettivi
Questa sezione descrive gli obiettivi del progetto e i risultati attesi alla fine delle attività. E' importante che siano ben distinte e riconosciute due categorie di obiettivi:
gli obiettivi propri del Progetto
gli obiettivi di business del Committente
Obiettivi di Business del Committente
Sono i principali obiettivi che il Committente ha individuato come fine ultimo del progetto. Tipicamente sono collegati a miglioramenti della profittabilità, riduzione di costi, miglioramento nell'efficienza operativa, aumento delle quote di mercato. ll progetto può contribuire al raggiungimento di tutti questi obiettivi ma non è necessariamente detto che sia l'unico contributore. Occorre essere molto cauti ne l dichiarare questi obiettivi, per non attribuire al progetto potenzialità che non gli sono proprie. Attenzione a non generare false aspettative che potrebbero rivelarsi controproducenti.
In linea generale, nella declinazione degli obiettivi di business si suggerisce di evitare, o perlomeno ponderare bene, dichiarazioni impegnative come:
miglioramento della produttivita del xx%
aumento delle quote di mercato del yy%
riduzione dei costi operativi del zz%
aumento della soddisfazione dei dipendenti e riduzione del turn-
over del ...
Obiettivi del Progetto
Questi sono gli obiettivi definiti specificamente per il progetto e raggiungibili indipendentemente da altri fattori dipendenti dall'azienda o dalla divisione committente. Tipicamente essi sono relativi alle attività proprie del progetto e/o di specifici prodotti da rilasciare.
Possono rientrare in questa categoria obiettivi come:
Sostituire il sistema xyz con il software package ....
Realizzare e mantenere l'infrastruttura tecnica a supporto di ....
Definire e disegnare xx aree di business che ....
Sviluppare piani organizzativi e di formazione per ......
Nella definizione degli obiettivi è utile indicare le priorità. Se c'è accordo su questi punti, è più semplice prendere decisioni condivise nel corso del progetto.
Sezione 3. Ambito
Lo scopo della sezione "Ambito" è quella di individuare con la maggior precisione possibile ciò che rientra nei compiti del progetto (in scope) ma, soprattutto, ciò che NON vi rientra (out of scope). E' estremamente importante definire i confini del progetto, per poter affermare con certezza cosa va realizzato al prezzo concordato.
L'ambito di un progetto deve poter essere misurabile con precisione; Un metodo tra i più efficaci quello è dei "6 Domìni del Cambiamento", che fa parte della metodologia Catalyst (TM).
Il metodo consiste nel descrivere nel modo più dettagliato possibile come e quanto ciascuno dei sei domini è interessato dal progetto. In questo modo è possibile declinare ciò che il progetto si propone di produrre in termini di risultati e quali sinao i suoi confini.
PROCESSI: che cosa fa l'entità di business (azienda, divisione, etc.) interessata dal progetto, come, le regole, i processi interessati e i risultati ottenuti
ORGANIZZAZIONE: strutture, unità organizzative, sistemi di supporto; e le persone che ne fanno parte in termini di cultura, ruoli, competenze;
LOCATION: paese/i, regione, campus, edifici, postazioni di lavoro, dove il lavoro viene svolto, comprendendo sede centrale ed eventuali sedi periferiche con tutte le strutture logistiche di supporto;
DATI: strutture, relazioni, contenuti, informazioni utilizzate dall'entità di business;
APPLICAZIONI: sistemi, sottosistemi, interfacce, schermate, reports, moduli;
TECNOLOGIA: piattaforme,sistemi operativi, database, network, processori;
Sezione 4. Deliverables
Questa sezione descrive i "Deliverables", cioè i prodotti di ciascuna delle fasi principali del progetto che richiedono un'accettazione da parte del Cliente, indicando per ciascuno il valore che aggiunge al progetto e/o il vantaggio che porta con sé.
Un "deliverable" può essere fisico -
Un deliverable deve avere un contenuto tangibile e verificabile in termini di adeguatezza a determinate specifiche e standard per il suo completamento. Le specifiche guidano sia la fase di realizzazione sia quella di verifica sotto forma ad esempio di una check list di attributi e valori di cui assicurare la compatibilità secondo quanto concordato con la committenza.
Sezione 5. Approccio
Lo scopo di questa sezione è di descrivere la soluzione individuata per il "problema" individuato nella sezione "Ambito". L'Ambito (Scope) definisce la portata del lavoro da svolgere, mentre l'Approccio definisce la profondità del lavoro in termini di attività che devono essere portate a termine. Ambito e Approcccio insieme forniscono le basi per valutare l'impegno richiesto dal progetto, dato questo che ci porta a definire i costi.
5a. Approccio Gestionale
L'approccio Gestionale (il Project Management vero e proprio) individua gli standard che saranno adottati nel corso del progetto, evidenziando ogni eventuale eccezione rispetto alle policy o alle procedure aziendali.
Questa sezione documenta le "regole di ingaggio" che saranno applicate per monitorare il progetto e controllarne l'avanzamento, risolvere le issues, gestire i rischi, accertarsi che i deliverables siano prodotti con il livello di qualità richiesto e nei tempi previsti e siano accettati dal Cliente. Ciascuno di questi processi viene documentato con chiarezza in modo che non vi siano dubbi su come vadano interpretati ed eseguiti, sia da parte del team di progetto che da parte del Cliente.
5b. Approccio Tecnico
Descrive il lavoro che deve essere svolto e come sarà svolto per ogni attività o componente principale. Non è necessario scendere qui sino al livello di ogni singola task del progetto, questo è compito della Work Breakdown Structure. Comunque il linguaggio utilizzato in questa fase deve consentire un facile collegamento con il piano di progetto.
E' bene invece evidenziare chi ha la principale responsabilità per ogni attività, se il Cliente, il Fornitore, o una Terza Parte, affinché non vi siano dubbi al proposito.
I processi da documentare sono i seguenti:
ORGANIZZAZIONE: partendo da una chart organizzativa del progetto, che comprende tutte le risorse coinvolte sia del Fornitore che del Cliente, delinea i ruoli e definisce le responsabilità di ciascuno
CONTROLLO DEL PROGETTO: definisce gli strumenti utilizzati per monitorare le attività, come Status Report, Status Meetings, Timesheet recording, etc.
CHANGE MANAGEMENT: definisce i tipi di modifica coperti da questo processo, indica le modalità per registrarli, i criteri di classificazione, prioritizzazione e approvazione, con le relative implicazioni di costo e schedulazione. Occorre anche chiarire che il tempo necessario a valutare una modifica al progetto, non essendo pianificato, può avere un impatto sul progetto stesso e, quindi, va autorizzato.
ISSUE MANAGEMENT:definisce come vengono gestite le issue di progetto, identificazione, documentazione, assegnazione, risoluzione
RISK MANAGEMENT: descrive il processo per l'individuazione dei rischi del progetto, elementi cioè al di fuori del controllo sia del Cliente che del Fornitore, e per la definizione dei relativi piani di mitigazione.
ACCEPTANCE PROCESS: individua i punti di contatto con il Cliente per assicurare la puntuale e tempestiva valutazione dei deliverables prodotti dal progetto, la gestione e risoluzione di ogni eventuale issue, fino all'accettazione.
Sezione 6. Assumptions
Questa sezione mette in evidenza le decisioni che sono state prese prima dell'inizio delle attività e che sono incorporate nel Piano di Progetto. Le Assumptions non vanno gestite in quanto tali, ma occorre monitorarle, perché possono risultare critiche per la consegna del progetto. Ogni assumption può associare un potenziale rischio nel senso che, se non si verifica quanto previsto, il progetto ne può risentire. Ad esempio, se si assume un certo tasso di produttività nello sviluppo del codice software, il tempo di sviluppo previsto dal piano sarà calcolato di conseguenza. Qualora il tasso di produttività risultasse in realtà inferiore, tutto il piano ne risentirebbe, provocando un ritardo nella consegna.
Sezione 7. Vincoli e Dipendenze Esterne
Un vincolo è una restrizione associata ad un progetto (obbligo di fare o di non fare, ad utilizzare un dato elemento piuttosto che no, etc...) e può riguardare sia l'approccio con cui il progetto viene condotto, così come l'ambiente dove il progetto si svolge oppure la tecnologia utilizzata, così come il personale in forza al progetto, le priorità imposte dal Committente, i cicli di decisione, gli strumenti e le tecniche utilizzati, etc...
Le dipendenze esterne invece sono quegli eventi, attività o decisioni che hanno luogo al di fu ori del progetto ma che ne possono condizionare le attività. Ad esempio per poter iniziare una fase del progetto devo necessariamente avere a disposizione un certo prodotto che però è ancora in fase di sviluppo da parte della casa produttrice.
Sezione 8. Fattori Critici di Successo
Qui si individuano le circostanze che devono necessariamente svolgersi positivamente per rendere possibile il successo del progetto. Ad esempio la disponibilità di una certa competenza professionale è irrinunciabile per realizzare quanto il progetto si propone di fare.
Sezione 9. Attrezzature e Logistica
Descrive l'ambiente fisico necessario alla realizzazione del progetto: i locali, il supporto tecnico, gli strumenti e tutte le risorse necessarie.
Sezione 10. Responsabilità del Cliente
Identifica la parte di responsabilità che il Cliente / Committente ha nel completamento del progetto, includendo l'eventuale lavoro che personale del Cliente deve portare a termine, il tipo e la qualità delle risorse che devono essere messe a disposizione e il supporto che deve essere fornito. Va anche evidenziato l'impatto che può avere per il progetto la non disponibilità di quanto richiesto.
P.M. Consulting s.a.s. di Donato Dolini & C. | chi siamo | dove siamo | contattaci