Il Deliverable Non è un Documento
Un errore frequente tra i progettisti junior è confondere il deliverable con la documentazione tecnica interna. La documentazione serve al team di progettazione — tiene traccia delle scelte, dei calcoli, delle revisioni. Il deliverable serve allo stakeholder: deve farlo capire, decidere o agire.
Questa distinzione cambia tutto: il livello di dettaglio, il linguaggio, la forma visiva, la densità informativa.
Un investitore non ha bisogno di vedere la matrice di fattibilità con tutti i parametri di simulazione. Ha bisogno di tre numeri: rendimento atteso, orizzonte temporale, rischio. Un ente autorizzativo non ha bisogno di capire la strategia commerciale. Ha bisogno della conformità normativa, firmata e timbrata.
Il deliverable giusto è quello che permette al destinatario di fare esattamente ciò che ci aspettiamo da lui — e nient'altro.
La Tassonomia dei Deliverable Energetici
Nel settore delle energie rinnovabili e dei sistemi energetici complessi, i deliverable si dividono per funzione:
Deliverable decisionali — usati per sbloccare una fase progettuale o un investimento. Contengono analisi di fattibilità, simulazioni, business plan, confronto scenari. Il destinatario è chi decide: CDA, comitato investitori, direzione generale. Il formato privilegia sintesi, scenari, raccomandazioni nette.
Deliverable autorizzativi — richiesti da enti pubblici per ottenere permessi, connessioni, incentivi. Seguono format imposti per legge (disciplinari tecnici, capitolati GSE, documentazione Terna/DSO). Non si può improvvisare: ogni campo ha un contenuto atteso, ogni firma ha un peso legale.
Deliverable contrattuali — prodotti per un committente privato nell'ambito di un contratto di progettazione o EPC. Definiti nel piano della qualità e nel contratto stesso. Generano obblighi: il progettista risponde di quello che ha firmato.
Deliverable informativi — aggiornamenti periodici allo stakeholder durante la vita del progetto. Report O&M, dashboard di performance, report trimestrale investitori. Non richiedono decisioni immediate ma mantengono la fiducia e l'allineamento.
I Quattro Assi di un Deliverable Ben Costruito
Ogni deliverable va valutato su quattro dimensioni:
Contenuto — i dati, i calcoli, le analisi, le raccomandazioni. È la sostanza tecnica. Deve essere corretta, verificabile, firmata da chi ne risponde.
Forma — layout, tipografia, struttura visiva. Un documento che non si legge non comunica. Nel settore energetico professionale, la forma segnala la serietà del proponente tanto quanto i numeri.
Livello di dettaglio — la granularità dell'informazione deve matchare le necessità del destinatario. Troppo dettaglio su un deliverable decisionale genera confusione. Troppo poco su un deliverable autorizzativo genera richieste di integrazione.
Tono — tecnico-formale per enti e banche, più diretto e sintetico per investitori, più narrativo per comunicazioni esterne. Il tono sbagliato, anche su contenuto corretto, crea attrito.
La Matrice Stakeholder × Deliverable
Prima di produrre qualsiasi documento, il progettista deve rispondere a tre domande:
- Chi legge questo documento? Ruolo, competenza tecnica, obiettivo.
- Cosa deve fare dopo averlo letto? Approvare, finanziare, autorizzare, monitorare.
- Quale informazione gli serve — e quale no?
Una matrice semplice a uso interno, aggiornata per ogni progetto, aiuta a non confondere i flussi. Asse orizzontale: gli stakeholder (investitore, Comune, GSE, banca finanziatrice, cliente EPC, comunità locale). Asse verticale: i deliverable previsti. Ogni cella specifica cosa riceve ogni stakeholder, in quale fase e con quale formato.
Questa matrice non è solo uno strumento organizzativo: è la prova che il progettista ha mappato i suoi interlocutori prima di iniziare a scrivere.
La Firma e la Responsabilità
Un deliverable tecnico firmato da un professionista abilitato ha valore legale. Nel settore energetico, molti documenti richiedono la firma di un ingegnere iscritto all'albo: relazioni tecniche, studi di fattibilità inviati a banche, dichiarazioni di conformità impiantistica.
La firma non è una formalità: è l'atto con cui il progettista si assume la responsabilità del contenuto. Firmare un deliverable che non si conosce — o che è stato prodotto da altri senza la propria revisione critica — è un errore professionale e, in alcuni casi, un rischio legale.
Regola pratica: non firmare mai un documento che non saresti in grado di difendere riga per riga in una riunione tecnica.