Usa questo modello
Una buona documentazione di progetto è ciò che evita che un progetto deragli ed è ciò che aiuta il team successivo a imparare dal tuo. Con Trupeer puoi risparmiare ore nella stesura dei documenti di progetto partendo da un modello di documentazione di progetto gratuito, personalizzandolo con le tue linee guida del brand e trasformando la documentazione in una chiara presentazione video dettagliata che gli stakeholder guardano davvero.
Che cos'è un modello di documentazione di progetto e chi lo legge?
La documentazione di progetto comprende tutto ciò che viene messo per iscritto in un progetto: il brief, il piano, i requisiti, i report sullo stato di avanzamento, i registri dei rischi e dei problemi, le richieste di modifica, i risultati dei test, il materiale di passaggio delle consegne e la relazione conclusiva.
Un modello ti fornisce la serie di documenti e la struttura per ciascuno di essi. Cercandone uno, ti verrà proposta una struttura a cartelle oppure un unico documento suddiviso in sezioni, a seconda che la fonte intenda la documentazione come una raccolta o come un report.
La domanda più utile è chi lo legge, perché i destinatari sono due e sono separati da anni di distanza.
Il primo pubblico è il progetto stesso: il team, lo sponsor, il comitato di governance. Hanno bisogno di aggiornamenti sullo stato, decisioni e approvazioni, e ne hanno bisogno subito, questa settimana.
Il secondo pubblico è costituito da chiunque gestisca, supporti o modifichi l'opera in seguito. Queste persone arrivano da diciotto mesi a cinque anni dopo, quando nessuno dei soggetti coinvolti è più disponibile, e hanno bisogno di sapere che cosa è stato realizzato, perché è stato fatto in quel modo e che cosa è stato preso in considerazione e poi scartato.
Quasi tutta la documentazione di progetto viene redatta per il primo pubblico. Quasi tutto il valore risiede nel secondo.
La documentazione di progetto ha due destinatari separati da anni di distanza
Le esigenze del primo pubblico sono ampiamente soddisfatte, perché sono obbligatorie. La governance richiede un piano, un report di stato, un registro dei rischi e una procedura di gestione delle modifiche, che vengono quindi prodotti indipendentemente dal fatto che qualcuno li ritenga utili o meno.
Le esigenze del secondo pubblico non sono affatto imposte, e si vede.
Chiedi a chi gestisce la manutenzione di un sistema realizzato tre anni fa che cosa vorrebbe avere a disposizione: la risposta è sorprendentemente coerente. Perché è fatto così? Cos'altro è stato preso in considerazione? Che cosa sapeva il team originale che noi non sappiamo? Che cosa è stato deliberatamente escluso? Chi ha approvato questa scelta?
A nessuna di queste domande risponde un report di stato, un piano o un registro RAID. I report di stato registrano i progressi rispetto a un piano che è cambiato. I piani registrano intenzioni che sono state superate. I registri dei rischi registrano le preoccupazioni delle persone, che raramente coincidono con ciò che è poi accaduto.
Di conseguenza, un progetto può produrre trecento documenti senza rispondere a nessuna delle domande che verranno poste in seguito.
C'è una tipologia di documento che vale la pena prendere in prestito dalle operation. L'impiego di una SOP nel project management ha senso per qualsiasi attività ripetuta dal team, come la gestione delle richieste di modifica, il reporting sullo stato di avanzamento o l'onboarding di nuovi membri del team.
Come personalizzare questo modello in Trupeer
Passaggio 1: apri la sezione Modelli
Accedi alla sezione Modelli dal menu di navigazione principale.
Passaggio 2: seleziona e apri un modello
Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.
Passaggio 3: espandi la visualizzazione del modello
Se necessario, espandi la visualizzazione del modello per vedere chiaramente il layout completo e i dettagli.
Passaggio 4: modifica il modello
Fai clic su Modifica per iniziare a personalizzare il modello selezionato.
All'interno dell'editor puoi:
Aggiungere nuove sezioni
Definire o aggiornare le regole di formattazione
Aggiungere un logo e regolarne la posizione e le impostazioni correlate
Passaggio 5: salva il modello personalizzato
Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per archiviare il modello aggiornato tra i tuoi.
Passaggio 6: visualizza l'anteprima e perfeziona il modello
Quando desideri controllare l'aspetto del modello personalizzato, apri l'Anteprima.
Dalla schermata di anteprima, se necessario, puoi continuare ad apportare modifiche direttamente, assicurandoti che il modello appaia esattamente come desideri.
Con un modello di documentazione di progetto puoi:
Risparmiare ore di scrittura: evita la pagina bianca con una struttura progettata per qualsiasi tipologia di progetto.
Allineare gli stakeholder: sezioni integrate per ambito, obiettivi e deliverable mantengono tutti sulla stessa lunghezza d'onda.
Mantenere la coerenza del brand: applica logo, font e colori utilizzando il brand kit di Trupeer: perfetto per i deliverable destinati ai clienti.
Velocizzare l'onboarding: i nuovi membri del team diventano operativi rapidamente quando il contesto del progetto è illustrato con chiarezza.
Raccogliere le lezioni apprese: le sezioni retrospettive integrate facilitano l'apprendimento da ogni progetto.
Coinvolgere team globali: traduci la documentazione di progetto in oltre 65 lingue con un solo clic.
I documenti che nessuno impone sono proprio quelli di cui si ha bisogno
Classificando i documenti di progetto in base al fatto che qualcuno li legga o meno dopo la chiusura, il pattern appare evidente.
Obbligatori e inutili in seguito: report di stato, versioni del piano, versioni del registro RAID, verbali delle riunioni, moduli di richiesta di modifica, schede presenze (timesheet), documenti per il comitato di guida (steering committee).
Opzionali e preziosi in seguito: il registro delle decisioni, la descrizione dell'opera così come costruita (as-built), le opzioni scartate, i limiti noti, il materiale per il passaggio di consegne, le motivazioni alla base di qualsiasi anomalia.
Questa asimmetria non è una coincidenza. I documenti obbligatori esistono per soddisfare la governance, un processo incentrato sul controllo durante il ciclo di vita del progetto. Nessun elemento di questo processo si chiede di cosa avrà bisogno la persona successiva, perché quest'ultima non è presente nella stanza e non si lamenterà per almeno due anni.
La risposta pratica è aggiungere un unico documento all'insieme di quelli obbligatori ed essere rigorosi su ciò che viene archiviato. Il documento da aggiungere è il registro delle decisioni, ed è l'argomento della sezione successiva.
Il registro delle decisioni e perché un registro RAID non lo sostituisce
La maggior parte dei progetti ritiene di essere a posto perché mantiene un registro RAID. Non è così, e la distinzione è importante.
Un registro RAID annota rischi, assunzioni, problemi e dipendenze. Sono tutti e quattro stati di preoccupazione orientati al futuro. Nessuno di essi documenta una scelta.
Un registro delle decisioni documenta le scelte. Cinque campi per voce, e nessuno di essi è facoltativo.
Cosa è stato deciso, formulato in modo che chiunque sia esterno al progetto possa comprenderlo.
Quando, con una data precisa.
Chi ha deciso, specificando nome e ruolo, non genericamente "il comitato di progetto".
Cosa è stato scartato, indicando le altre opzioni che erano concretamente sul tavolo.
Perché, in una o due frasi.
Il quarto campo è quello che rende il registro davvero prezioso. Chiunque, prima o poi, può risalire a cosa è stato deciso osservando ciò che esiste. Nessuno può risalire a cosa è stato preso in considerazione e poi respinto: ed è esattamente ciò di cui ha bisogno chi si troverà a modificare il sistema tre anni dopo, poiché il suo primo istinto sarà quello di proporre l'opzione che avevi già escluso.
Aggiornalo settimanalmente, in un unico posto, aggiungendo elementi anziché riscriverli. Dieci minuti a settimana producono qualcosa che sopravviverà al progetto per anni, ed è l'unico documento di progetto che viene costantemente consultato dopo la chiusura.
Come organizzare l'elenco dei documenti in base al valore post-chiusura
Documento | Letto durante il progetto | Letto dopo la chiusura | Da archiviare? |
|---|---|---|---|
Registro delle decisioni | Occasionalmente | Costantemente | Sempre, e renderlo facilmente reperibile |
Descrizione as-built | Raramente | Costantemente | Sempre |
Limiti noti e soluzioni alternative (workaround) | A volte | Costantemente | Sempre |
Materiale di passaggio consegne | Alla fine | Per anni | Sempre |
Brief e criteri di successo | Frequentemente | In sede di revisione dei benefici | Sì, una sola versione |
Requisiti | Costantemente | Occasionalmente, per il contesto | Sì, solo la versione finale |
Risultati dei test | Costantemente | Raramente, tranne che per ambiti regolamentati | Solo il set finale |
Piani di progetto | Costantemente | Quasi mai | Solo la baseline finale |
Report di stato | Settimanalmente | Mai | No |
Versioni del registro RAID | Costantemente | Quasi mai | Solo la versione finale |
Verbali delle riunioni | A volte | Quasi mai | No, estrarre invece le decisioni |
Richieste di modifica | Costantemente | Occasionalmente, per comprenderne le motivazioni | Estrarre le decisioni, eliminare i moduli |
Applica questo criterio ai tuoi documenti alla chiusura del progetto invece di archiviare tutto: l'archiviazione indiscriminata è la prassi predefinita e crea un archivio che nessuno consulta perché le informazioni utili sono sommerse dal superfluo.
La riga che cambia davvero le abitudini riguarda i verbali delle riunioni. I verbali registrano che un argomento è stato discusso. Non registrano quasi mai ciò che è stato concluso, motivo per cui cercare sessanta menzioni di un argomento nei verbali non serve a nulla. Estrai le decisioni nel registro man mano che vengono prese e i verbali perderanno la loro criticità.
Modello gratuito di documentazione di progetto: il set che vale la pena conservare
Copia da qui. Sette documenti anziché una complessa struttura di cartelle.
Uno. Brief. Il problema, i vincoli e i criteri di successo, secondo il nostro modello di project brief. Un'unica versione, archiviata.
Due. Registro delle decisioni. I cinque campi sopra indicati, aggiornati settimanalmente, mai riscritti. L'artefatto di maggior valore che il progetto produrrà.
Tre. Piano. Ambito, pianificazione temporale, risorse e dipendenze, secondo il nostro modello di piano di progetto IT. Operativo durante la fase di consegna, con la baseline finale archiviata.
Quattro. Requisiti o specifiche. Ciò che doveva essere realizzato. Versione finale archiviata, bozze precedenti eliminate.
Cinque. Descrizione as-built. Ciò che esiste concretamente ora, a differenza di quanto era stato specificato. Include tutto ciò che differisce dai requisiti e il relativo perché. Questo è il documento che spesso non viene redatto ed è il primo che i team operativi richiedono.
Sei. Limiti noti. Ciò che il sistema non fa, cosa ne compromette il funzionamento ed eventuali soluzioni alternative (workaround) in uso al momento del passaggio di consegne. Breve, trasparente e di enorme valore.
Sette. Pacchetto di passaggio consegne (handover pack). Chi ne assume la proprietà, che cosa ha ricevuto, il materiale operativo e di manutenzione e le modalità di supporto. Nel caso in cui il progetto abbia consegnato un bene fisico, il nostro modello di manuale di uso e manutenzione copre adeguatamente questo aspetto.
I documenti di governance, ovvero report di stato, note per il comitato di guida e versioni del RAID, servono durante il progetto e non devono entrare nell'archivio, tranne quando richiesto da specifici standard.
Copia fino a qui.
La società di credito edilizio che non riusciva a spiegare il proprio sistema
Calderbank, una società di credito edilizio con circa millequattrocento dipendenti, ha sostituito la propria piattaforma per la concessione di mutui nel 2022. Quattordici mesi di lavoro, circa 3,1 milioni di sterline di costo.
Il progetto ha prodotto circa trecentoquaranta documenti: cinquantotto report di stato settimanali, quarantuno versioni del registro RAID, settantasei richieste di modifica, centododici verbali di riunione, ventitré versioni del piano, oltre a requisiti, script di test e materiale formativo. Si è concluso con la firma di convalida del completamento della documentazione.
Nel 2025 una modifica normativa ha imposto un adeguamento al modo in cui un calcolo di sostenibilità economica considerava una particolare categoria di reddito. Il sistema esistente la escludeva e nessuno riusciva a stabilirne il motivo. Si trattava di una scelta strategica consapevole, di un limite del software del fornitore o di un errore passato inosservato?
La risposta era fondamentale, poiché un'esclusione deliberata e supportata da una motivazione documentata ha implicazioni normative ben diverse da una dovuta a una svista accidentale.
Hanno esaminato tutti i trecentoquaranta documenti. Il requisito figurava solo come una singola riga nel documento dei requisiti. Nessuna richiesta di modifica ne faceva menzione. La parola "sostenibilità" (affordability) compariva sessantuno volte nei verbali, sempre come argomento di discussione e mai come decisione.
La risposta è stata infine trovata in una serie di email personali, inoltrata da un consulente esterno che aveva lasciato l'azienda nel 2023, e solo perché qualcuno si è ricordato del suo coinvolgimento.
Sono trascorse sette settimane prima di riuscire a definire l'ambito della modifica. La modifica in sé ne ha richieste quattro. È stata ingaggiata una consulenza legale esterna per confermare la posizione normativa a fronte dell'impossibilità di dimostrare la logica originaria, con un costo di circa ventottomila sterline. Inoltre, non essendo stato possibile determinare la motivazione originaria, la modifica è stata dimensionata in modo prudenziale ed è stata ricostruita una parte di sistema superiore al necessario, quantificata dal programma a posteriori in circa centoquarantamila sterline di lavoro evitabile.
Su trecentoquaranta documenti, nessuno era un registro delle decisioni. Ogni decisione rilevante era stata presa durante una riunione, verbalizzata come semplice discussione e poi implementata.
Il programma successivo, una sostituzione della piattaforma di risparmio durata undici mesi, ha adottato un registro delle decisioni sin dalla prima settimana. Cinque campi, aggiornato settimanalmente, settantaquattro voci alla chiusura. Ha prodotto centonovanta documenti in totale e ne ha archiviati trentuno.
Diciotto mesi dopo la chiusura di quel programma, sono emerse tre distinte domande sul perché il sistema fosse configurato in un certo modo. Tutte e tre hanno trovato risposta grazie al registro nel giro di una giornata.
Come creare la documentazione di progetto, passo dopo passo
Stabilisci fin dall'inizio quali documenti dovranno essere creati e quali saranno archiviati. Rimandare questa scelta alla chiusura porta ad archiviare tutto, e un archivio indistinto diventa impossibile da consultare.
Avvia il registro delle decisioni nella prima settimana, prima ancora che ci siano decisioni importanti da annotare: un registro iniziato più avanti non viene mai completato retroattivamente.
Redigi il brief e i criteri di successo prima del piano di progetto, in modo che il piano sia funzionale alla risoluzione del problema e non il contrario.
Estrai le decisioni dalle riunioni inserendole direttamente nel registro, durante la riunione stessa. Bastano dieci minuti a settimana. Affidarsi ai verbali significa pretendere che in futuro qualcuno legga sessanta menzioni di un argomento per dedurne le conclusioni.
Redigi la descrizione as-built durante lo sviluppo anziché alla fine, aggiornandola via via che le cose cambiano. Se viene redatta alla chiusura ci si affida alla memoria, trasformandola nel documento con la più alta probabilità di contenere inesattezze inosservate.
Riporta i limiti noti con assoluta trasparenza. La tentazione di ometterli durante il passaggio di consegne è forte, ma rischia di minare la fiducia del team ricevente su tutto il resto della documentazione.
Alla chiusura, organizza il set di documenti utilizzando la tabella precedente, archivia ciò che ha reale valore ed elimina il resto.
Documentazione di progetto per il software e progetti accademici
Una quota consistente di ricerche di questo termine proviene da studenti che documentano un progetto software o web da presentare: i requisiti accademici sono sostanzialmente diversi, quindi vale la pena affrontarli direttamente senza fare finta di nulla.
La documentazione di progetti accademici segue solitamente il ciclo di vita dello sviluppo software e richiede una struttura ben definita: introduzione e definizione del problema, rassegna della letteratura o dei sistemi esistenti, analisi dei requisiti, progettazione del sistema con diagrammi, note di implementazione, collaudo con risultati e conclusioni con gli sviluppi futuri. Le linee guida fornite dal tuo istituto sono quelle vincolanti e differiscono da qualsiasi modello reperibile online: parti quindi sempre dai criteri di valutazione anziché da un fac-simile generico.
Due aspetti dell'ambito professionale possono essere applicati con grande efficacia anche qui.
Il registro delle decisioni. I criteri di valutazione premiano le scelte motivate, e disporre di una traccia di ciò che è stato scartato e del perché rappresenta esattamente la prova che distingue una progettazione ponderata da una arbitraria. La maggior parte della documentazione degli studenti dichiara delle scelte senza spiegarne il motivo.
La sezione dedicata ai limiti noti. Esplicitare chiaramente ciò che il tuo sistema non fa, e spiegarne il motivo, è indice di maturità e competenza anziché di debolezza, ed è proprio da qui che prende forma la sezione sugli sviluppi futuri.
Ciò che invece non è utile importare è il materiale di governance. I report di stato e i registri RAID non sono necessari in un elaborato accademico.
Cosa archiviare alla chiusura e cosa eliminare
Archiviare indiscriminatamente tutto è la prassi abituale, ma equivale a rifiutarsi di scegliere. Il risultato è una cartella che nessuno consulterà mai, perché una ricerca restituisce centododici verbali di riunione e quarantuno versioni di un registro dei rischi.
Da archiviare: il registro delle decisioni, la descrizione as-built, i limiti noti, il pacchetto di passaggio consegne, il brief, i requisiti definitivi, la baseline finale del piano e qualsiasi documento previsto dai tuoi obblighi normativi o contrattuali.
Da eliminare: i report di stato, le versioni superate del piano e del RAID, i verbali delle riunioni una volta estratte le decisioni, i moduli di richiesta di modifica dopo averne registrato le determinazioni e qualsiasi tipo di bozza.
Qualora una norma, un ente regolatore o un contratto imponga la conservazione del materiale di governance, conservalo separatamente dall'archivio destinato alla consultazione comune. La conservazione per fini di conformità e la documentazione utile a fini pratici rispondono a scopi diversi e mescolarle vanifica la seconda.
Colloca l'archivio in una posizione facilmente accessibile per il team che erediterà il lavoro, non all'interno dell'ufficio di gestione progetti (PMO), dove di norma i progetti archiviano i file e dove nessuno andrà più a cercare a distanza di due anni. Il nostro modello di documentazione IT illustra come gestire la conservazione continua del materiale as-built.
Documentazione di progetto o documentazione di processo?
Si tratta di due documenti distinti con nomi simili; la differenza risiede nel fatto che l'attività abbia o meno una conclusione.
La documentazione di progetto descrive un lavoro che ha un inizio e una fine precisi. Viene redatta una sola volta, archiviata alla chiusura del progetto e letta in seguito da chi eredita il risultato finale. Il suo valore è di tipo storico: cosa è stato realizzato, perché e che cosa è stato scartato.
La documentazione di processo descrive un'attività ripetitiva. Viene aggiornata costantemente, consultata da chi esegue operativamente il lavoro e ha un valore contingente e attuale. Il nostro modello di documentazione di processo illustra questo approccio, spiegando anche perché la gestione delle eccezioni sia più importante della descrizione dei singoli passaggi.
Spesso un progetto produce come output documentazione di processo. Il progetto documenta come è stato realizzato il nuovo sistema; il processo documenta come deve essere gestito ora. Sono documenti diversi, con proprietari diversi e cicli di vita differenti: unirli significa archiviare la parte operativa insieme al progetto, con la conseguenza che un processo ancora attivo risulterà descritto soltanto nella cartella di un progetto ormai chiuso.
Nel caso in cui l'output del progetto debba essere trasferito interamente a un altro team, la nostra SOP per il passaggio delle competenze illustra come gestire un passaggio che la sola documentazione non riuscirebbe a garantire.
È possibile ottenere un modello di documentazione di progetto in Word o Excel?
Word o Google Docs sono indicati per i documenti narrativi: brief, descrizione as-built, limiti noti e pacchetto di passaggio consegne. Sono testi discorsivi destinati alla lettura continua piuttosto che all'ordinamento dati.
Excel è invece fondamentale per due elementi. Il registro delle decisioni, che ha una struttura tabellare e deve poter essere cercato, filtrato e arricchito con nuove voci senza richiedere riformattazioni. E il registro dei documenti, che elenca ogni documento con il relativo proprietario, la versione e l'indicazione se debba essere archiviato o eliminato alla chiusura.
È vivamente consigliabile insistere sull'uso di un foglio di calcolo per il registro delle decisioni anziché di un documento di testo: il suo valore risiede esclusivamente nella possibilità di fare ricerche in seguito, mentre un registro delle decisioni redatto come documento di testo si trasforma in un muro di testo illeggibile entro tre mesi.
Il formato PDF è ideale per il set di documenti archiviati alla chiusura, esportati dalle fonti originali, con data e numero di versione impressi chiaramente.
Come documentare ciò che è stato realizzato contestualmente alla realizzazione
Il documento con il più alto valore post-chiusura e il minor tasso di completamento è la descrizione as-built, e la ragione è molto semplice. Redigerlo significa descrivere configurazioni e schermate su cui si è appena passati mesi di lavoro e di cui si è ormai esausti, proprio nella fase in cui il progetto non ha più tempo a disposizione.
Di conseguenza, alla chiusura viene compilato affidandosi alla memoria, oppure viene semplicemente spuntato nell'elenco senza essere realmente redatto.
L'intelligenza artificiale di Trupeer rivoluziona questo processo rendendo l'acquisizione possibile durante la fase operativa. Chi configura o realizza qualcosa registra il procedimento una sola volta mentre lavora: il risultato finale è una descrizione scritta con tutti i passaggi e le schermate già registrati. Il documento as-built si accumula progressivamente invece di dover essere creato artificialmente alla fine, risultando accurato perché registrato sul momento anziché ricostruito a memoria.
Registralo. Personalizzalo con il tuo brand. Traducilo. Rendilo perfetto con Trupeer.
Le stesse registrazioni servono per il pacchetto di passaggio consegne e per il materiale operativo, che in genere occorrono nello stesso momento ma non sono quasi mai pronti. La nostra documentazione tecnica copre la tracciabilità interna e il materiale viene organizzato nella tua knowledge base con un'immagine coordinata uniforme. Le istruzioni di configurazione sono disponibili nella guida alla configurazione del modello di documento.
Domande frequenti
Esiste un modello gratuito di documentazione di progetto in Word?
Il set di sette documenti descritto in precedenza può essere gestito perfettamente in Word o Google Docs, che rappresentano la sede naturale per i documenti descrittivi. Non sono richiesti download vincolati né la compilazione di moduli. Mantieni invece il registro delle decisioni in un foglio di calcolo anziché in un documento di testo, poiché la sua utilità dipende interamente dalla facilità di ricerca a due anni di distanza.
Esiste un modello gratuito di documentazione di progetto in Excel?
Excel è ideale per il registro delle decisioni e per il registro dei documenti. Il registro richiede cinque colonne: decisione, data, presa da chi, opzioni scartate e motivazione. Il registro dei documenti necessita di: documento, proprietario, versione e indicazione se archiviarlo o eliminarlo alla chiusura. Entrambi risultano molto più utili di qualsiasi modello narrativo generico.
Dove posso trovare un esempio di documentazione di progetto in PDF?
Gli esempi disponibili online sono facili da trovare ma presentano livelli qualitativi estremamente variabili, poiché gli standard di documentazione di progetto cambiano a seconda dell'organizzazione e della metodologia adottata. Esaminali per ricavarne l'elenco dei documenti necessari piuttosto che per i contenuti, e verifica se includono un registro delle decisioni: la maggior parte ne è priva, e questa assenza è proprio la criticità evidenziata in questa pagina.
Esiste un esempio di documentazione per un progetto web in PDF?
Se la documentazione serve per un corso di studi o una tesi finale, attieniti scrupolosamente ai criteri di valutazione del tuo istituto anziché a un fac-simile generico, poiché le sezioni richieste possono variare e sono proprio quei criteri a determinare il tuo voto. La sezione sopra dedicata al software e ai progetti accademici illustra ciò che può essere utilmente ripreso dalla pratica professionale, in particolare il registro delle decisioni e una descrizione trasparente dei limiti noti.
Quanta documentazione di progetto è sufficiente?
Meno documenti di quanti ne produca la maggior parte dei progetti, ma con una tipologia in più rispetto a quelli solitamente presenti. Sette documenti costituiscono un insieme efficace per un progetto di dimensioni rilevanti. Il parametro di giudizio non è la quantità, ma la capacità di chi subentrerà tra due anni di capire perché le cose sono state fatte in un determinato modo: a questa domanda risponde un singolo documento mirato, non una raccolta di trecento file disordinati.
Chi dovrebbe redigere la documentazione di progetto?
Il project manager è responsabile dell'intero set di documenti e, in particolare, del registro delle decisioni, partecipando a ogni riunione in cui vengono prese decisioni strategiche. La descrizione as-built deve essere redatta da chi ha concretamente realizzato l'opera, contestualmente alla fase di sviluppo. Una documentazione redatta interamente da un ufficio di gestione progetti (PMO) al momento della chiusura descriverà la burocrazia del progetto piuttosto che il suo effettivo risultato.
Per quanto tempo deve essere conservata la documentazione di progetto?
Il registro delle decisioni, la descrizione as-built e i limiti noti vanno conservati per tutto il ciclo di vita dell'opera realizzata, un periodo che di solito supera di gran lunga le tempistiche previste dalle policy di archiviazione standard. Il materiale di governance va invece conservato per il tempo richiesto dalle normative, dai contratti o dagli enti regolatori, avendo cura di archiviarlo separatamente dai documenti destinati alla consultazione ordinaria.
Documentazione di progetto o piano di progetto: qual è la differenza?
Il piano di progetto è un singolo documento interno alla documentazione di progetto complessiva e illustra come verrà erogato e gestito il lavoro. La documentazione di progetto rappresenta l'intero insieme informativo, comprendendo ciò che è stato deciso, ciò che è stato realizzato e ciò che è stato trasferito con il passaggio di consegne. Un progetto dotato di un piano eccellente ma privo di un registro delle decisioni è un progetto ben gestito nell'immediato ma inspiegabile a posteriori: ed è questo l'errore più comune.
