Questo è un sito di contenuti disponibili anche in formato

eBook

Benvenuto

  Avvio Progetto

1.0 Definizione del Lavoro

2.0 Sviluppo Schedulazione e Budget

3.0 Gestione Schedulazione e Budget

4.0 Gestione Problemi

5.0 Gestione Modifiche

6.0 Gestione Comunicazione

7.0 Gestione Rischio

8.0 Gestione Risorse Umane

9.0 Gestione Qualità

10.0 Gestione Metriche

  Chiusura Progetto

    Estensione per Acquisti

Glossario TenStep

PMP-Prep Online

L'esame di certificazione in  meno di 100 giorni

White Paper 

Se trovi utili questi contenuti, sostienici con una donazione

 

3.1.3.2 Chiusura Progetto

 90.0.P.1 Panoramica

Così come è importante avviare il progetto con una riunione di kick-off, è altrettanto importante chiudere con successo il progetto. Una chiusura pianificata del progetto consente di normalizzare tutte le informazioni e le esperienze maturate durante progetto. Se una volta implementata la soluzione,il team viene disciolto, non vi sono altre opportunità per  collegare  le conclusioni, fare la valutazione del personale, documentare ciò che si è appreso o assicurarsi che le appropriate deliverable siano state trasferite al supporto. Naturalmente, un progetto può terminare lo stesso con successo. Comunque, anche in questo caso, si possono raccogliere lezioni apprese, valutare il team e svolgere altre attività di sintesi, per le attività realizzate nel corso del progetto.

Quando si crea la schedulazione di progetto, bisogna pensare alle attività da svolgere per chiudere il progetto in modo appropriato e con grazia. Queste attività comprendono:

  • Tenere una riunione conclusiva. Tenere una riunione con il team di progetto, lo sponsor e gli Stakeholder appropriati per chiudere formalmente il progetto. La riunione comprenderà un riassunto dei passi del progetto, documentando le cose andate bene e le cose andate male, i punti di forza ed i  punti di debolezza del progetto e del relativo processo di project management, ed i passi rimanenti per terminare il progetto. Identificare come lezioni del progetto le tecniche ed i processi che hanno funzionato particolarmente bene, o che non hanno funzionato. Se il tuo reparto ha un modo per pubblicare o diffondere le lezioni apprese, esse dovrebbero essere trasmesse al gruppo appropriato per la pubblicazione. Le cose che hanno funzionato in modo eccellente, possono essere  applicate ad altri progetti ed in molte occasioni potrebbero essere elevate al livello di  best practice ed essere utilizzate per progetti similari in futuro.

    L’agenda della riunione di chiusura dovrebbe porre l'attenzione su cosa il progetto doveva produrre e cosa ha realmente prodotto. La discussione dovrebbe tendere ad esaltare ciò che è andato bene e ciò che è andato male. L'agenda potrebbe essere la seguente:

  • Discutere lo scopo della riunione

  • Sviluppare regole di fondo (facoltativo)

  • Elencare cosa avrebbe dovuto produrre il progetto?

  • Descrivere cosa realmente è accaduto?

  • Discutere il  "Perchè" delle discrepanze tra cosa bisognava fare e cosa è accaduto

  • Concordare sulle lezione appresa per progetti futuri

  • Elencare e documentare eventuale lavoro rimanente per chiudere il progetto. Ciò comprende azioni tipo quelle descritte di seguito.  

  • Dichiarare il successo o il fallimento. A volte, è ovvio che il progetto è stato un successo e in altri casi il progetto è totalmente fallito. Però, in molti casi, c'è un mix di risultati. Per esempio, le principali deliverable possono essere state completate, ma il progetto ha sforato il budget. Oppure, il team di progetto ha consegnato in tempo ed entro il budget, ma la soluzione soddisfa solo l'80% dei requisiti di business. La chiave per dichiarare il successo è definire in anticipo quali sono i criteri per determinare il successo del progetto. Se viene raggiunto un accordo su cosa significa successo con lo sponsor ed il capo funzionale, allora il team di progetto può essere valutato rispetto a questi criteri. Il team di progetto si auto valuta rispetto a questi criteri, e poi chiede al management appropriato di convalidare la valutazione.

  • Trasferire la soluzione al supporto (se applicabile). Se la soluzione esisterà dopo il progetto, allora dovrebbe essere trasferita all'organizzazione appropriata per il supporto. Il transito comprende il trasferimento delle conoscenze al team di supporto, il trasferimento dei documenti completi, il trasferimento della lista dei lavori pendenti, etc.

  • Sostituzione dei file di progetto (se applicabile). Si dovrebbe discutere con  l'organizzazione di supporto per determinare quali materiali raccolti durante il progetto dovrebbero essere ceduti al team di supporto. Sulla base di questo accordo, parte del materiale di progetto può essere cancellato o distrutto, salvato, archiviato, etc. Questi file e documenti necessari per l'organizzazione di supporto devono essere  consegnati per essere memorizzati nelle appropriate strutture del supporto.

  • Revisione delle prestazioni. Se il progetto è stato consistente o molto lungo, può essere appropriato verificare le prestazione del team a fine progetto. In questo caso, il capo del  project manager e lo  Sponsor di progetto valutano il  project manager. Il  project manager valuta l'intero team o almeno i riporti diretti (e poi i riporti diretti valutano i loro collaboratori, finché tutti sono stati valutati). A volte il team viene valutato complessivamente e poi i membri del team utilizzano tale posizionamento  come input della  propria valutazione personale, basata solo sul proprio contributo dato  al progetto. Ci deve essere un collegamento, comunque, tra la prestazione del team e quella del singolo.

  • Riassegnare il team di progetto. Quando tutte le attività sono terminate, i restanti membri del team di progetto devono essere assegnati ad altro progetto. Per alcune persone, questo può significare un progetto completamente nuovo. Per le risorse esterne su contratto, può significare la fine dell'assegnazione.  Per le persone a tempo parziale, può significare il ritorno al loro lavoro a tempo pieno. Alcuni membri del team possono essere trasferiti al reparto di supporto per continuare a lavorare sulla stessa soluzione.

E’ responsabilità del project manager sviluppare le attività di chiusura nella schedulazione di progetto. Queste devono essere viste come una parte vitale del progetto, non come una iettatura, cioè come se il team dovesse essere disperso. Il progetto non può essere considerato concluso finché le attività di chiusura non sono state eseguite – esattamente come se non fosse stata completata un’attività di implementazione.

90.0.P2 Chiudere i Contratti

Far riferimento all’ Estensione del Processo TenStep per gli Acquisti per ulteriori informazioni su questo argomento.

 

 

English Spanish Dutch Portuguese Bulgarian English Spanish Croatian Spanish French German Greek Hungarian Indian English Hebrew Italian Macedonian Malay/English Spanish Polish Portuguese Romanian and Moldavian Russian Spanish Caribbean Dutch Swedish Ukrainian English

Condizioni Generali            |        Mappa del sito principale              |        Cerca nel sito            |          Informativa sulla Privacy          |         Contattaci        |   

TenStep Italia di Vito Madaio - Via Orazio Console 140 -  00128 Roma  -  tel. 39-348-3974474 - 39-06-5088134 - P. IVA 07627281004 - Copyright ©2004 - 2010


Ecco cosa possiamo offrirti immediatamente:

Gestione Progetti

Project Management Office

Portfolio

Metodologia

Formazione

PMBoK

Consulenza

   Registrati al nostro sito  e consulta le ultime novità in materia di Project Management  

Aggiornato a Tuesday, 20 July 2010 00.12