Tematiche

Da PRINCE2 wiki Italiano.

L’articolo sulle tematiche PRINCE2 è disponibile anche in Inglese, Spagnolo, Portugais, Francese, Polacco, Olandese, Russo.

PRINCE2 afferma che le tematiche sono aspetti di un progetto che vanno applicate durante il ciclo intero dello stesso. Una spiegazione alternativa può essere la seguente: le tematiche sono aree di conoscenza, di conseguenza ciascuna tematica fornisce strumenti di conoscenza (indicazione su come fare qualcosa) su aree specifiche di project management, come il Business Case, la Pianificazione, la Qualità, ecc. Ok..abbiamo superato il faticoso momento della definizione…, ora concentrati sulla seguente domanda per un momento:

Domanda: Quali attività dovrai fare all’avvio di un progetto per impostarlo, definirlo e poi, monitorare e controllare il progetto durante tutto il suo ciclo?

Facile..la risposta a questa domanda sarà: le Tematiche PRINCE2:

  • Abbiamo bisogno di un Business Case per definire le ragioni per le quali dobbiamo condurre il progetto ed, inoltre, per monitorare e verificare se queste ragioni resteranno ancora valide man mano che il progetto avanzi. Questi aspetti vengono trattati nella tematica del Business Case.
  • Dobbiamo sapere con chiarezza “chi” lavora nel team, “cosa” fanno, quali sono le loro responsabilità. Tutto viene trattato nella tematica dell’Organizzazione.
  • Dobbiamo creare Descrizioni del Prodotto e, successivamente, creare un Piano di Progetto per guidare il progetto e sviluppare i prodotti richiesti. Questo è coperto dalla tematica dei Piani.
  • Dobbiamo monitorare come rispetteremo i requisiti del cliente o degli utenti, per poi definire senza ambiguità che i prodotti consegnati saranno utilizzabili come da aspettative iniziali. Tutto ciò viene trattato nella tematica della Qualità.
  • Un progetto include una buona dose di incertezza e dobbiamo avere un metodo per valutare e gestire tali incertezze. Questo è trattato nella tematica dei Rischi.

Ricorda che le tematiche sono attività che vanno eseguite all’avvio del progetto per impostarlo correttamente, e poi per gestire e monitorare il progetto durante tutto il suo ciclo di vita. Potremmo anche definire le tematiche come delle linee guida su come andrebbero eseguite le principali attività nella gestione di un progetto. Naturalmente, le tematiche andrebbero adattate al particolare contesto di progetto. Questo dipenderà, quindi, dalla dimensione e complessità del progetto e dall’ambiente di lavoro. Per esempio, se stai costruendo un modulo lunare, avrai una sola possibilità di successo, in tal caso le tematiche della Qualità e dei Rischi dovrebbero essere applicate con notevole dettaglio.

La Tematica del Business Case

Il Business Case risponde a domande del tipo:

  • Perchè stiamo facendo questo progetto?
  • Quali sono le ragioni strategiche e commerciali?
  • Quali saranno i benefici per l’azienda?

Questa tematica, inoltre, assicura l’esistenza di un valido Business Case all’avvio di un progetto e permette di verificare la viabilità di progetto durante tutto il suo ciclo. Il presidente del Comitato Direttivo di Progetto, l’Executive, è responsabile della creazione del Business Case, ma potrebbe essere anche scritto da terzi o con l’aiuto di terzi. Per esempio, Il presidente del Comitato potrebbe richiedere il supporto di qualcuno del dipartimento di amministrazione per l’analisi ed elaborazione dei dati finanziari.

Il mandato di progetto contiene di solito già alcune informazioni del Business Case. Queste info vanno poi sviluppate in una bozza di Business Case all’avvio di progetto e farà parte del Project Brief. Successivamente, nella fase di inizio, si dettaglierà l’informazione in un Business Case definitivo che andrà a far parte della Documentazione di Inizio Progetto.

I documenti del Business Case in un progetto PRINCE2

Avvio di Progetto: La bozza di Business Case viene scritta dal Presidente del Comitato di Progetto e farà parte del Project Brief

Planning: Il vero documento di Business Case viene creato durante la fase di inizio partendo dalla bozza o outline consegnata nel Project Brief. I dati per il costo del progetto viene preso dal Project Plan

Il Piano di Review dei Benefici (PRB) è un piano di verifica dei benefici da eseguire durante e dopo il progetto (dipende dai casi progetto). La maggior parte delle info in merito ai benefici attesi arriveranno dagli Utenti Senior (Senior User)

It Ch 4 1.png

Limite di Fase: Il Business Case è un documento vivo che va gestito durante il progetto. Per esempio, se il progetto è in ritardo del 50%, allora il Ritorno dell’Investimento-ROI cambierà rispetto al riferimento iniziale. Il Project Manager aggiornerà il Business Case, alla fine della fase in corso, per farlo verificare poi dal Comitato di Progetto, che valuterà se il progetto abbia ancora ragioni strategiche di esistere.

Limiti di Fase: Il piano dei review dei benefici: In certi progetti, alcuni prodotti potrebbero essere consegnati ai clienti prima della fine del progetto stesso, ed in tali casi sarà possibile verificare se i prodotti consegnati hanno creato i benefici attesi. Il Project Manager aggiungerà i risultati raggiunti al registro del piano di review dei benefici e ne riporterà lo status nei report del limite di fase.

Chiusura di un Progetto: Il Business Case viene aggiornato per l’ultima volta per la chiusura del progetto ed, in tale occasione, il Project Manager potrà aggiungere i reali costi finali del progetto stesso. Il Project Manager aggiornerà il ROI ed userà molte informazioni del piano di review dei benefici. Il Comitato o Project Board comparerà il Business Case aggiornato con quello iniziale (consegnato durante la fase di inizio) per valutare la performance del progetto.

Benefits Review Plan: Il Project Manager lascerà il progetto una volta approvata la sua chiusura; per questo motive occorrerà pianificare le review dei benefici che si dovranno tenere nel futuro: per esempio. Eseguire review ogni 6 mesi per i prossimi 4 anni. Queste sessioni di review si terranno, di solito, tra gli utenti senior (Senior Users) e qualcuno della Direzione Aziendale o, laddove esiste, del Program Management. Il Project Manager includerà, inoltre, informazioni sui benefici derivanti dalle ultime fasi di consegna.

Tematica dell’Organizzazione

La tematica dell’Organizzazione risponde alle seguenti domande:

  • Chi è chi nel progetto?
  • Chi sta sponsorizzando il progetto?
  • Chi è responsabile del Business Case?
  • Chi rappredenta gli utenti/client ed i fornitori/sviluppatori di progetto?
  • Quali sono i ruoli e le responsabilità assegnate?
  • Chi è il Project Manager?

La tematica dell’organizzazione fornisce le informazioni sul team di progetto, il Project Management Team, la sua struttura e le sue responsabilità.

Un progetto PRINCE2 si basa su un contesto cliente/fornitore. Da una parte c’è il cliente, che specificherà il prodotto o risultato richiesto e molto probabilmente pagherà per il progetto. Dall’altra parte ci sono i fornitori, che forniranno le risorse, eseguiranno il lavoro e produrranno i risultati di progetto.

PRINCE2 afferma che Team di Progetto di successo dovrebbe:

  • Essere rappresentato dal punto di vista strategico e commerciale, degli utenti o utilizzatori e dei fornitori o esecutori.
  • Avere responsabilità nel dirigere, gestire ed eseguire il progetto.
  • Avere una strategia efficace per la gestione dei flussi di comunicazione tra tutti gli stakeholders o interessati al progetto.

Documenti in merito all’organizzazione da gestire durante un progetto PRINCE2

Avvio: I livelli più alti del Project Management Team devono essere avviati già dall’avvio. Per esempio, i Senior User, l’Executive o Presidente del Comitato di Progetto, i Senior Supplier, il Project Manager , il Change Authority... Naturalmente, i Senior User ed i Senior Supplier potrebbero essere anche più di uno.

It Ch 4 2.png

Planning: Il documento di Communication Management Strategy (template) viene aggiornato in questa fase e l’impegno principale si ripercuote nell’analisi degli Stakeholder Analysis e nel decider come e con chi bisogna comunicare durante il progetto.

In questa fase i diversi ruoli del Project Management Team vengono aggiornati per rispondere alle esigenze del progetto ed, infine, questo document andrà a far parte del Project Brief. Tanti progetti usano i ruoli definiti nel manuale ufficiale PRINCE2 per poi adattari al contesto specifico. Limite di Fase: Non è sempre possibile continuare a lavorare, per tutta la durata del progetto, con le stesse persone nel team. Di conseguenza, PRINCE2 raccomanda di sfruttare il processo di Limite di Fase per l’analisi, ed eventuale modifica, del Project Management Team per poi riportare l’aggiornamento nel report di fine fase.

La Tematica della Qualità

La tematica della Qualità risponde alle seguenti domande:

  • Quale dovrebbe essere il livello di qualità del prodotto alla fine del progetto tale da essere correttamente utilizzato come inizialmente inteso, oppure in altre parole, essere “fit for use”?
  • Come potremmo verificare la qualità ed assicurarci che il progetto consegni il prodotto che il livello di qualità richiesto ed atteso?

Questa tematica aiuta, con i suoi strumenti, a scoprire e chiarire i requisiti di qualità all’interno del progetto. L’approccio PRINCE2 alla qualità è di concentrarsi sui prodotti il prima possibile, chiedersi del livello di qualità atteso per ciascun prodotto da produrre nel progetto ed infine, documentare le informazioni di qualità nelle Descrizioni di Prodotto.

Il documento della Strategia di Gestione della Qualità viene utilizzato per definire come verrà gestita la qualità all’interno del progetto, per esempio gli standard che saranno applicati e le varie responsabilità assegnate per il raggiungimento dei livelli di qualità durante il corso del progetto stesso.

I documenti della Qualità durante un progetto PRINCE2

Avvio: La Descrizione del Prodotto di Progetto (PPD) è la principale descrizione di prodotto e fornisce una visione sul prodotto finale ed elenca le caratteristiche e gli attributi (i criteri di accettazione) che devono essere forniti al cliente affinchè esso potrà accettare quanto consegnato. Planning: Il documento di Strategia della Qualità viene solitamente fornito dalla società committente e che andrebbe poi adattato al progetto specifico; fornisce una panoramica su come verrà pianificata, controllata e riportata la qualità di progetto. Le Descrizioni di Prodotto includono informazioni sulla qualità richiesta di ciascun prodotto che dovrà essere consegnato ed in questo modo il team di esecuzione o sviluppo prodotto avrà chiaro l’obiettivo. e.g. Criteri di qualità per la batteria GSM: ricarica 80% in < 20 minuti .

It Ch 4 3.png

Il Registro della Qualità: I criteri di qualità si aggiungono all’apposito Registro della Qualità che includerà informazioni su come si tester il prodotto, chi approverà i test e le date attese per il completamento dei test stessi (quando noti). Limiti di Fase: Nuove descrizioni di prodotto possono essere create o aggiornate durante la pianificazione della fase successiva; questi includeranno i criteri di qualità, parte del piano della fase successiva.

Controllo di una Fase: Queste Descrizioni di Prodotto vengono distribuite sottoforma di “Pacchetti di Lavoro”, o Work Packages, al team di sviluppo che dovrà consegnare i prodotti al livello richiesto di qualità. I prodotti vengono poi ispezionati alla consegna ed i risultati aggiunti sul registro della qualità. Chiusura di un Progetto: Alla fine del progetto il prodotto finale verrà consegnato al cliente. Il cliente userà i criteri di accettazione (solitamente sottoforma di checklist), definito inizialmente nella Descrizione del Prodotto di Progetto, per confermare che il prodotto rispetti i requisiti attesi. Infine, il progetto verrà chiuso

La Tematica della Pianificazione

Questa tematica risponde alle seguenti domande:

  • Come faremo a creare i prodotti di progetto?
  • Quali passi seguiremo?
  • Come effettuare una pianificazione basata sul prodotto?
  • Quale qualità dovremo raggiungere?
* Quanto costerà?
  • Quale sarà il livello di dettaglio richiesto per ciascun piano?
  • Chi verrà coinvolto nell’azienda e quale sarà la loro responsabilità?
  • Quando verranno eseguite certe attività?
  • Chi dovrà ricevere una copia dei piani?

Un piano PRINCE2 non è soltanto un Gantt chart; Comprende molte più informazioni. E’ un documento che descrive in modo comprensivo come, quando e da chi un set di obiettivi verranno raggiunti. Questi obiettivi includeranno i prodotti di progetto, le tempistiche, i costi, obiettivi di qualità e benefici attesi. Solitamente un piano include molto testo per descrivere come si raggiungeranno gli obiettivi di progetto.

Il Piano di Progetto viene aggiornato alla fine di ciascuna fase per riportare cosa è stato fatto, i prodotti sviluppati finora ed il piano per la fase successiva. Il piano di progetto darà una fotografia aggiornata dello status del progetto stesso che potrà essere comparata con il piano di baseline, o di riferimento, per verificare come siamo messi rispetto a quanto inizialmente previsto. In un corso PRINCE2 imparerai i diversi livelli di pianificazioni: (a) il Piano di Progetto, di alto livello ed utilizzato sopratutto dal Comitato di Progetto o Project Board; (b) il Piano della fase, di dettaglio anche quotidiano per il Project Manager; ed (c) il Team Plan, utilizzato se necessario dal Team Manager per pianificare in estremo dettaglio lo sviluppo e consegna dei prodotti di ciascun pacchetto di lavoro.

I documenti di pianificazione in un progetto PRINCE2

Pre-progetto o Avvio: il Project Product Description (PPD) è la descrizione principale di prodotto e fornisce una vision globale del prodotto finale. E’ un documento, di 1 o al massimo 3 pagine, di alto livello e strategico.

Il primo piano creato dal Project Manager è quello per la fase di Inizio, il quale definisce: come, in quanto tempo e da chi verranno eseguiti i piani di progetto e della prima fase esecutiva o di delivery.

Fase di Inizio: La tecnica del Product Based Planning consente di creare una Product Breakdown Structure, le Product Descriptions ed il Flusso di Diagramma del Prodotto. La maggiorparte dello sforzo andrà nella scrittura delle Product Descriptions e, per fare ciò, il Project Manager collaborerà a stretto contatto con il cliente ed i Team Managers. Sono queste Product Descriptions a formare la parte più importante del Piano di Progetto. Il Project Manager includerà, inoltre, uno schedule di alto livello per il progetto intero.

It Ch 4 4.png

Limiti di Fase: I Piani di Fase vengono creati nel processo della gestione dei limiti di fase per pianificare quanto andrà prodotto nella fase appena successiva. Questa attività comporterà anche l’aggiornamento delle Product Descriptions esistenti oppure la creazione di nuove. Piani dell’Eccezione vengono creati soltanto nei casi incui si prevede di uscire dalle tolleranze prefissate durante la fase in corso.

Anche il Piano di Progetto viene aggiornato durante questo processo alla fine di ciascuna fase per verificare il progresso rispetto al baseline iniziale e, di conseguenza, aggiornare eventualmente il forecast per il completamento del progetto con i suoi tempi e costi. 

Gestire la Consegna di Prodotto: Qui il Team Manager crea i Piani del proprio Team usando la tecnica a loro più consona. Il Project Manager è solo interessato al rispetto degli obiettivi prefissati per ciascun pacchetto di lavoro.

Chiusura di un Project: Il piano di progetto va aggiornato alla fine del progetto stesso per riportare il seguente: 1) Cosa doveva essere consegnato, 2) Cosa è stato consegnato ed eventualmente cosa non è stato consegnato, 3) Date di Consegna, 4) Il costo finale del progetto.

La Tematica del Rischio

Tutti i progetti sono unici, per quanto “simili” possono sembrare rispetto a quanto fatto in precedenza. Ogni volta che avviamo un progetto un nuovo ci sarà una quota di certezza e, quindi, di rischio che dovrà essere gestito fin da subito.

Questa tematica ci permette di rispondere alle seguenti domande:

  • Cosa sono i rischi?
  • Cosa succede se un determinato rischio accade per davvero?
  • Come possiamo identificare, analizzare e documentare i rischi nel modo più opportuno?
  • Come possiamo ridurre la probabilità che un rischio accade per davvero?
  • Come possiamo gestire e monitorare i rischi durante il corso del progetto?

Il rischio è un evento incerto (oppure un insieme di eventi) che, nel caso accadessero, creerebbero un effetto positivo o negativo sugli obiettivi di progetto. Usiamo la parola “Minaccia o Threat” per descrivere i rischi che avrebbero un impatto negativo, mentre usiamo la parola “Opportunità” per descrivere quei rischi ad impatto favorevole o positivo.

Ti suggerisco di pensare ai rischi come eventi incerti che potrebbero avere impatti sugli obiettivi di progetto invece che sul progetto stesso. Mi spiego meglio, un rischio impatta su ciò che il progetto desidera fare, sul suo risultato finale. La gestione del rischio, o risk management, tratta le procedure o metodi di identificazione e valutazione di questi rischi. Non solo: il risk management ci dice come pianificare e come rispondere ai rischi identificati. Il documento di Risk Management Strategy, invece, descrive le tecniche di Risk Management scelte per il nostro progetto.

I documenti di rischio durante un progetto PRINCE2

Pre-progetto o Avvio: Alcuni dei principali rischi possono essere aggiunti al Business Case outline, parte del Project Brief, ma questo documento è solitamente molto contenuto e sintetico. Durante il processo di avvio, nel pre-progetto, aggiungiamo tutti i rischi noti sul Daily log e poi, durante la fase di Inizio, trasferiremo questi rischio (o almeno quelli ancora rilevanti) nel Registro dei Rischi. Questo Registro verrà poi gestito per tutto il corso del progetto. Fase di Inizio: I rischi vengono aggiunti al Risk Register ed il Project Managers facilita e coordina la raccolta dei rischi dagli stakeholders di progetto. Al documento del Business Case si aggiungerà soltanto un sommario dei principali rischi di progetto, in modo che possano essere condivisi con il Comitato di Progetto o Project Board.

Il documento del Risk Management Strategy verrà adattato al contesto del progetto e descriverà come verranno gestiti i rischi.

It Ch 4 5.png

Limite di Fase: Verso la fine della fase in corso si aggiornano, necessario, le informazioni sui rischi nel Business Case per poi riportare al Comitato di Progetto.


Controllo di una Fase: Il Rapporto di Rilievo viene utilizzato anche per riportare informazioni sul rischio al Comitato di Progetto durante il corso di una fase. Il Risk Register viene aggiornato continuamente durante il processo di controllo di una fase, aggiornandolo con nuovi rischi, rimuovendo i rischi risolti ed aggiornando l’assessment di quelli già noti.

La Tematica del Cambiamento

Tutti i progetti (ma proprio tutti!) avranno questioni da gestire, ..issues, i quali richiederanno richieste di modifica, per esempio nuovi requisiti. Questa Tematica tratta la seguente domanda: “Qual’è l’impatto della questione o issue di progetto?”

Pertanto, questa tematica descrive: (1) come si andrà a valutare queste questioni/issues e richieste di cambiamento, (2) Come rispondere agli stessi e (3) Come gestirli. Tutte queste questioni e cambiamenti potrebbero avere un diretto impatto diretto sul piano di progetto originale. Qualsiasi cambiamento proposto deve essere correttamente gestito. Tutti i progetti necessitano di una buona gestione delle issue (questioni) e cambiamenti o modifiche. Questo approccio di gestione partirà dell’identificazione dei cambiamenti, la loro valutazione o assessment ed, infine, il controllo.

L’issue e change control (il controllo delle questioni/issues e dei cambiamenti o modifiche) avviene durante l’intera vita del progetto. Ricordati, l’obiettivo NON è di prevenire modifiche al progetto ma di gestire questi cambiamenti, concordandoli prima del loro avvenimento. E’ da notare che la tematica del Cambiamento copre anche il Configuration Management. Ciascun progetto richiede un sistema di Configurazione, che fa tracking dei prodotti, le loro versioni, le issue e modifiche al progetto. Il documento delConfiguration Management Strategy descrive come avverrà questa gestione e risponde a domande del tipo:

  • Come verranno pianificati, identificati, controllati e verificati i prodotti di progetto?
  • Come si gestiranno le issues e le modifiche?
  • Quali strumenti utilizzeremo (e.g., SharePoint, Niku Clarity, Shared Drive)?
  • Quali dati dobbiamo gestire per ciascun prodotto (e.g., Product Description, Configuration Item Records, etc.)?

I documenti per la Gestione dei Cambiamenti di Progetto durante un progetto PRINCE2

La Fase di Inizio: Il documento del Configuration Management Strategy va adattato al particolare contesto. Questo documento descrive il processo e l’approccio che si andrà ad utilizzare per gestire i cambiamenti e la configurazione durante il progetto stesso. In questo momento viene anche creato il Registro delle Questioni, meglio noto come l’Issue Register dove verranno aggiunte man mano tutte le questioni da prendere in carico. I Configuration Item Record (o Schede di Configurazione) possono essere create per ciascuno dei prodotti nel Product Breakdown Structure oppure appena le Descrizioni di Prodotto sono state create.

Limiti di Fase: Gli Product Status Accounts sono report molto semplici usati per riportare lo status dei prodotti alla fine di ciascuna fase. Per intenderci: I Product Status Accounts possono consistere anche nel risultato di una query in un database oppure, nei casi meno complessi, al risultato di un filtro su un foglio Excel...

It Ch 4 6.png

Controllo di una Fase: L’Issue Report viene utilizzato per “allertare” il Project Board nel caso incui una questione di progetto porti ad una previsione di fuori tolleranza. In tal caso, il Comitato di Progetto darà indicazioni al Project Manager su come procedere. L’Issue Register va continuamente aggiornato ogni volta che si presentino nuove issues o questioni ed ogni volta bisogna aggiornare informazioni circa le issues esistenti e già registrate precedentemente.

Configuration Item Records: Un archivio sull’avanzamento di status dei prodotti del progetto: per esempio. Product Description completato, da sviluppare in fase X, in via di sviluppo, quality tested, approvato…

Chiusura di un Progetto: Infine, i Product Status Accounts servono per riportare efficacemente lo status di tutti i prodotti alla fine del progetto. Questi report vengono consegnati alle persone che avranno il compito di gestire il prodotto dopo la chiusura del progetto stesso. I Configuration Item Records vengono, infine, aggiornati per l’ultima volta e consegnati anch’essi alle persone che dovranno “mantenere” il prodotto dopo la chiusura del progetto.

Tematica del Progresso

Il progetto deve essere monitorato durante il suo intero percorso. Allo stesso tempo, occorrerà riportare lo status agli Stakeholders on opportuni report di rilievo e di fine fase. Inoltre, si dovranno eseguire verifiche per assicurarsi che il processo di escalation stia funzionando correttamente. Oltre a tutto ciò, e non solo, si dovrà valutare continuamente la bontà “commerciale” del progetto e se vale ancora la pena completarlo o meno. Gli aspetti descritti costituiscono tutti punti della tematica del progresso di progetto.

Questa tematica, quindi, risponde alle seguenti domande:

  • Come verrà controllato il progetto?
  • Come avverrà il reporting di progetto?
  • Dove siamo rispetto alla baseline o al piano iniziale?
  • E’ ancora fattibile il progetto?

Lo scopo di questa tematica può essere spiegata in 3 punti:

  • Serve per stabilire come monitorare il progetto e come comparare i risultati raggiunti rispetto a quanto pianificato.
  • Serve a fornire un forecast (una previsione) per gli obiettivi di progetto ed a verificare continuamente la sua fattibilità.
  • Serve a controllare eventuali deviazioni, rispetto ai criteri di accettazione, non accettabili

In altre parole, il progresso tratta la verifica dell’avanzamento di progetto rispetto al piano, la verifica della fattibilità di quanto prevediamo di eseguire ed il controllo di eventuali deviazioni o non conformità rispetto ai criteri di accettazioni e requisiti iniziali. Il controllo di progetto è costituito prevelentamente da “decision-making” con l’obiettivo di assicurare la validità e fattibilità del Business Case inizialmente approvato. Per tutti questi motivi il Project Control è uno degli aspetti più importanti del project management.

I documenti del Controllo di Progresso durante un progetto PRINCE2

Fase di Inizio: Esiste un paragrafo del PID (o Documentazione di Inizio Progetto) dedicate al Controllo del Progresso di Progetto. Questa sezione ha l’obiettivo di mostrare l’approccio scelto per monitorare e controllare l’avanzamento e status di progetto specificando per esempio i seguenti punti: tolleranze, # di fasi e lunghezze delle stesse, frequenza e tipologia di report ecc. Inoltre, ricordiamoci che le Product Descriptions contengono informazioni sul livello di qualità richiesta per l’accettazione di ciascun prodotto che andrà consegnato. Il Piano di Progetto, invece, include informazioni sugli obiettivi di: Tempi, Costi, Qualità, Scope, Benefici e Rischi. Il Piano di Review dei Benefici contiene, invece, i dati sui benefici attesi e, di conseguenza, diventa uno strumento di misura del valore del progetto nel corso del tempo.

It Ch 4 7.png

Limiti di Fase: Il Report di Fine Fase è lo strumento principale usato per riportare lo status del progetto alla fine della fase e, quindi, come è andata la fase rispetto al suo piano iniziale. Il Controllo di una Fase: Durante questo processo il Project Manager setta le tolleranze di progetto (sui Tempi, Costi, Qualità, Rischi..). Tali tolleranze vengono indicate sui Pacchetti di Lavoro o Work Packages assegnati ai vari Responsabili di Team. I Report di Rilievo si usano per riportare ad alto livello lo status al Comitato di Progetto e, nei casi incui si preveda una deviazione fuori tolleranza a causa di un problema o issue, usiamo un Report dell’Eccezione per innescare l’escalation verso l’alto.

La Gestione della Consegna del Prodotto: I Responsabili dei Team (o Team Managers) usano Checkpoint Reports per riportare lo status periodicamente al PM. La Chiusura di Progetto: Il progetto non potrà essere chiuso se non si dimostra il raggiungimento dei risultati al Comitato e la loro accettazione. Il Project Manager comunica questi risultati, e quindi lo status e performance del progetto intero, attraverso il Report di Fine Progetto.

Riferimenti