Negli anni i progetti legati alle evoluzioni tecnologiche hanno consegnato deliverable (più avanti anche detti prodotti) sempre più innovativi, performanti e all’avanguardia. Alcuni prodotti hanno concluso il loro ciclo di vita e quindi sono stati ritirati mentre altri sono nella fase di crescita o maturità.
Il PMBOK definisce come ciclo di vita di un prodotto l’insieme delle fasi che rappresentano l’evoluzione del prodotto, dalla concezione alla consegna, crescita, maturità e ritiro. Il project manager, per ogni progetto, gestirà anche il gruppo di processi di chiusura dedicati al completamento o chiusura formale del progetto, di una fase o di un contratto. È sull’importanza di questo gruppo di processi che voglio porre l’attenzione sottolineando che sia il committente che l’appaltatore devono svolgerla meticolosamente.
Assunto quanto detto finora e conoscendo che il ciclo di vita del progetto si conclude con il risultato del progetto, spesso un prodotto consegnato ha la necessità di ulteriori progetti per il mantenimento, l’aggiornamento alle nuove tecnologie e/o esigenze del settore. Il project manager è nello svolgimento del gruppo di processi di chiusura dei progetti che si occuperà di archiviare la documentazione di progetto con informazioni relative alle decisioni prese, al trasferimento di conoscenze alla produzione e/o alle attività operative, alla transizione del prodotto, servizio o risultato finale e ancora di più.
Scendendo nel dettaglio, tra le informazioni contenute nel documento Report Finale ci sono quelle su chi effettuerà il supporto al deliverable, se ci sarà la necessità di accordi post progetto, il riepilogo dei rischi e delle questioni affrontati e risolti, quali stakeholder hanno partecipato e quali stakeholder hanno fatto la formazione. Porto all’attenzione un paio di esempi.
Sia i progetti software che i progetti hardware devono soddisfare altri requisiti oltre quelli per i quali esiste il progetto. Come requisito di esempio per i progetti software consideriamo il “Privacy by default e by design” (Art. 25 del Regolamento UE 2016/679). Il project manager inserirà questo requisito nella documentazione di progetto indicando come è stato affrontato e sarà documentato, anche se in modo sintetico, nel Report Finale dove verrà indicato se ci si è avvalsi di una Valutazione di Impatto sulla protezione dei dati (DPIA) o meno. Questa informazione sarà utile e sarà utilizzata sia dal committente che dall’appaltatore quando ci sarà la necessità di evolutive e/o modifiche del prodotto.
Il requisito di esempio per i progetti di infrastrutture tecnologiche Datacenter è la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico (Art. 32 paragrafo 1 lettera c del Regolamento UE 2016/679). Il project manager inserirà questo requisito nella documentazione di progetto indicando i parametri di RPO e RTO, questi ultimi utilizzati per dichiarare i tempi di ripristino delle condizioni di normale attività, ma anche altre informazioni progettuali quali i criteri dell’Uptime Institute Tier Standard e/o successivi utilizzati per valutare l’affidabilità di un’infrastruttura datacenter, ma ancora, l’adozione delle norme CEI 64-8 relative all’efficienza energetica per gli impianti elettrici, ASHRAE 90.4/TC 9.9 per l’impianto di condizionamento, IEC62040 per gli UPS e così via. Tutte scelte che influiscono sul trattamento del requisito.
Il project manager, come per l’esempio precedente, inserirà questo requisito nella documentazione di progetto indicando come è stato affrontato e sarà documentato, anche se in modo sintetico, nel Report Finale. Tali informazioni saranno utili sia al committente che all’appaltatore per le future scelte strategiche riguardanti l’infrastruttura e/o il suo miglioramento della Riservatezza, Integrità e Continuità.
Come anticipato, perché il committente possa gestire in modo autonomo e corretto il prodotto durante il suo ciclo di vita è fondamentale che il project manager svolga e condivida il gruppo di processi di chiusura.
