Il secondo principio è la distinzione tra segnale e rumore. I radiotelescopi impiegano sofisticati algoritmi di filtraggio per separare i segnali cosmici dal rumore di fondo, e la maggior parte di ciò che captano è interferenza. In un processo di lavoro reale, la proporzione è analoga: la maggior parte delle attività è rumore operativo, attese, sincronizzazioni, micro-compiti amministrativi, espedienti per problemi contingenti. Il lavoro che effettivamente trasforma un dato iniziale in un risultato utile è una frazione piccola del tempo totale.
La specifica del NAVFAC interpreta questo principio attraverso una prescrizione che, a prima vista, potrebbe apparire meramente tecnica: le attività di costruzione non dovevano essere impiegate per rappresentare riferimenti non-work, quali lettere seriali, richieste di informazione e verbali di riunione. Tali elementi dovevano essere riportati nel Notebook dell’attività a cui si riferivano, separati dal flusso logico della schedulazione. Questa regola serve a distinguere il lavoro dal discorso sul lavoro, la costruzione dalla sua documentazione. Il segnale, ovvero ciò che contribuisce fisicamente all’avanzamento del progetto, deve poter essere isolato dal rumore amministrativo che lo accompagna.
In un progetto di supporto applicativo (solita combinazione Jira, Confluence e accessori Tempo Timesheets BigPicture eazyBI) per un noto player del settore del lusso, durato diciotto mesi, l’analisi dei dati ha mostrato che oltre la metà del carico di lavoro derivava da modifiche richieste dal cliente durante l’esecuzione. Questo dato era nascosto nel flusso originale, dove tutte le attività erano considerate uguali, pianificate o reattive. Ridisegnando il flusso per distinguere il lavoro pianificato dalle modifiche in corso, abbiamo reso visibile una struttura ricorrente che erodeva la capacità predittiva del gruppo. L'informazione, una volta resa chiaramente visibile, è stata usata nelle negoziazioni contrattuali. Il flusso di lavoro ha trasformato l’intuizione “il cliente cambia sempre idea” in un dato quantificabile. Questa operazione non si impara nei syllabus, tanto meno conseguendo una qualsiasi certificazione di project management "agile", ma solo facendo, sul campo.
Il terzo principio è la calibrazione contestuale. Le enormi parabole SATCOM devono essere calibrate per l'ambiente elettromagnetico specifico in cui operano: la stessa stazione di terra che funziona perfettamente nel deserto del New Mexico, dove il QRN è minimo e lo spettro è pulito, riceverebbe soltanto interferenze nel centro di una città industriale, dove ogni trasformatore e ogni linea elettrica irradia rumore a larga banda.
Il Weather Calendar della specifica del NAVFAC era un esercizio di calibrazione contestuale di notevole precisione: il contractor doveva costruire un calendario dei giorni non lavorativi previsti per maltempo basandosi sui dati meteorologici storici della zona, non su medie nazionali o stime generiche. Il cantiere era in Sicilia, con il suo scirocco e le sue piogge autunnali specifiche, e il cronoprogramma doveva riflettere questa specificità. È un principio che conserva un'applicazione universale: ogni flusso di lavoro esiste all'interno di una specifica ecologia organizzativa, una cultura aziendale, una distribuzione di competenze, una configurazione di potere, un insieme di sistemi tecnici interconnessi, e ignorare questo contesto produce strumenti teoricamente eleganti e praticamente inutilizzabili. Un gruppo di cinque persone altamente collaborative ha bisogno di un flusso minimalista con quattro o cinque stati. Il medesimo flusso in un contesto con cinquanta persone distribuite geograficamente sarebbe problematico, quasi certamente.
Il quarto principio è la risoluzione appropriata. I radiotelescopi operano a gradi di risoluzione differenti: uno strumento ottimizzato per la survey mappa ampie porzioni di cielo con bassa risoluzione angolare, identificando gli oggetti interessanti, mentre uno dedicato li osserva poi con altissima risoluzione, rivelando dettagli invisibili alla ricognizione. Entrambi sono necessari, nessuno dei due potrebbe sostituire l'altro.
La specifica del NAVFAC prescriveva che nessuna attività di cantiere potesse superare i venti giorni lavorativi di durata e che ciascuna attività dovesse contenere dettaglio sufficiente per assegnare squadre, attrezzi e materiali. Era una regola di risoluzione minima: se un'attività durava più di venti giorni, era troppo grande per essere osservata con efficacia, e andava scomposta in unità più piccole. Allo stesso tempo, una risoluzione massima per le milestone contrattuali, che dovevano avere durata zero e rappresentare punti di decisione, conclusioni formali, verifiche (le famose "milestone"). La tensione fra risoluzione alta, per le attività operative, e risoluzione bassa, per i traguardi strategici, è la stessa tensione che attraversa qualsiasi sistema di governance di portafoglio.
Il quinto principio è l'interpretabilità del segnale. I dati grezzi raccolti da un radiotelescopio sono inutili senza un modello teorico che spieghi cosa significhino certe frequenze, certe modulazioni, certi profili spettrali. L'interpretazione trasforma il segnale in conoscenza. La specifica del NAVFAC affrontava questo problema con la Time Impact Analysis: un metodo rigoroso per trasformare un ritardo grezzo in conoscenza azionabile.
Ogni volta che si verificava un evento che modificava il cronoprogramma, il contractor doveva produrre un'analisi che inseriva un fragnet, un frammento di rete logica che rappresentava l'evento e le sue conseguenze, nel cronoprogramma aggiornato, e "ricalcolava" le date per determinare l'impatto sulla data di completamento. L'analisi doveva distinguere fra ritardi compensabili, quelli causati dal committente, e ritardi non compensabili, quelli causati dal contractor o da forza maggiore.
Era un protocollo di interpretazione: il dato grezzo, "il cantiere è fermo", veniva trasformato in conoscenza strutturata, "il cantiere è fermo per causa X, con impatto Y sulla data di completamento Z, e la responsabilità ricade sulla parte W".
La specifica del NAVFAC, dunque, conteneva tutti e cinque i principi del radiotelescopio organizzativo. Li conteneva, però, nella forma sbagliata. Li esprimeva nel linguaggio del controllo anziché in quello della comprensione. E questa differenza di linguaggio genera patologie che ho imparato a riconoscere, nel corso degli anni, come malattie ricorrenti dei sistemi di governance progettuale.
Le ho ritrovate in almeno sei flussi su dieci tra quelli che mi venivano sottoposti per revisione, durante la mia attività di consulente Atlassian. Ho pensato che ciò fosse dovuto a qualche bisogno profondo dell'organizzazione, anche se quel bisogno è spesso la protezione dalle informazioni che il flusso, se ben progettato, rivelerebbe.
La prima patologia è l'eufemismo semantico: stati con nomi vaghi, confortevoli, privi di contenuto operativo. "In corso", "in lavorazione", "attivo": tutte formulazioni che significano, nella sostanza, "qualcuno dovrebbe occuparsene, forse". Il problema è che sono semanticamente collassate: comprimono nel medesimo stato indistinto situazioni profondamente diverse, e le metriche che ne derivano mentono con la precisione dei numeri ben formattati.
La specifica del NAVFAC mitigava in parte l’insorgenza di tale patologia, grazie alla precisione tassonomica intrinseca al linguaggio militare. Tuttavia, la generava in maniera differente: prescrivendo denominazioni per le attività che dovevano conformarsi a una struttura rigida, la Work Breakdown Structure (WBS), senza considerare se tali denominazioni coincidessero con il linguaggio spontaneamente utilizzato dal personale di cantiere.
Un’attività che nel linguaggio del capocantiere veniva espressa come “preparazione del massetto per il bagno del secondo piano” si trasformava, nella WBS della specifica, in un codice alfanumerico associato a un numero di specifica CSI MasterFormat. La precisione formale era impeccabile, mentre la comprensibilità per l’operatore esecutore risultava trascurabile.
La seconda patologia è il labirinto delle eccezioni. La specifica del NAVFAC ne soffriva in forma acuta: diciassette sotto-tipologie di attività di commissioning, ciascuna con il proprio protocollo, i propri documenti, le proprie condizioni di approvazione. Pre-DALT/TAB/PVT Meeting, TAB Design Review Report, TAB Pre-Field Engineering Report, DALT Field Work, DALT Field Acceptance Testing, e così via per altre dodici varianti. Il flusso normale, quello che un essere umano potrebbe comprendere e navigare senza un manuale, era sepolto sotto strati di eccezioni codificate. La specifica tentava di gestire ogni eventualità, e facendolo rendeva incomprensibile il percorso ordinario.
La soluzione che ho trovato più efficace, nel corso degli anni, consiste nel progettare il flusso per il percorso normale, che copre la grande maggioranza dei casi, e prevedere un meccanismo esplicito per le eccezioni: le attività che deviano dal percorso standard escono temporaneamente, vengono gestite manualmente, e rientrano. Questo mantiene il flusso principale leggibile e rende visibile il tasso di eccezioni, che è di per sé un segnale prezioso sullo stato di salute del processo.
La terza patologia, che ho chiamato il parcheggio ontologico, consiste nell'usare stati come categorie anziché come fasi. "Cliente X", "alta priorità", "quarto trimestre 2024" sono attributi dell'attività, proprietà che la descrivono, e non fasi del processo che la collocano in un percorso temporale. Il sintomo è inconfondibile: attività che rimangono nel medesimo stato per settimane o mesi, il che è logicamente impossibile se lo stato rappresenta una fase genuina.
La specifica del NAVFAC evitava questa patologia per le attività di costruzione, dove la logica di predecessore e successore era imposta con rigore, ma la introduceva surrettiziamente per le attività amministrative: le modifiche contrattuali, le approvazioni governative, i permessi, vivevano in una zona grigia del cronoprogramma dove il tempo si fermava in attesa di una decisione esterna. La specifica lo accettava come inevitabile, senza riconoscere che un'attività ferma per mesi è il sintomo di un problema organizzativo che il cronoprogramma dovrebbe rendere visibile, piuttosto che normalizzare.
Esiste poi una quarta patologia, la più significativa nel contesto di questo saggio: l'illusione dell'esaustività. Ogni campo, ogni formato, ogni scadenza, ogni procedura. Il Designated Project Scheduler doveva aver preparato e mantenuto almeno tre cronoprogrammi precedenti, di dimensione e complessità analoga, usando Primavera Project Planner. I diagrammi dovevano essere stampati in formato landscape su fogli di dimensioni specifiche. I colori dovevano identificare chiaramente le attività sul Longest Path. Gli aggiornamenti mensili dovevano includere un Log Report, un Narrative Report, un Earned Value Report, un diagramma Schedule Variance Control, e un sommario dell'attività produttiva giornaliera in formato spreadsheet.
L'accumulo di prescrizioni produce l'illusione che, se tutto viene compilato correttamente, il progetto sia sotto controllo. È la stessa illusione che produce una matrice di rischio compilata una volta e mai rivista: l'illusione del controllo senza la sostanza. Ho osservato, in troppe organizzazioni, la dinamica che accompagna questa illusione: il project manager che segnala un rischio elevato viene percepito come pessimista, come qualcuno che "crea problemi" anziché risolverli. In queste culture, i rischi vengono sistematicamente sottovalutati nelle segnalazioni ufficiali, e quando si materializzano generano sorpresa e biasimo, due reazioni altrettanto sterili.
Il documento poteva imporre la frequenza degli aggiornamenti, i tempi di consegna dell'analisi di impatto, il formato e la struttura di ogni report. Poteva, in altre parole, prescrivere tutto ciò che è prescrivibile. Il limite era altrove: nessuna prescrizione è in grado di generare, in chi governa un progetto, la comprensione di ciò che quel progetto sta attraversando. Si possono obbligare le persone a compilare campi, produrre documenti, rispettare scadenze. Obbligarle a capire resta al di fuori della portata di qualsiasi clausola contrattuale. E la comprensione è ciò che distingue la governance dalla burocrazia.
Nota sulle fonti
La specifica di schedulazione a cui si fa riferimento in questo saggio e nel precedente apparteneva al corpus delle NFGS, le NAVFACENGCOM Guide Specifications, il sistema di specifiche tecniche che il Naval Facilities Engineering Command utilizzava per i progetti costruttivi nelle installazioni della U.S. Navy prima dell'unificazione interforze del 2001, quando le NFGS confluirono nelle attuali Unified Facilities Guide Specifications (UFGS). La versione che ebbi fra le mani a Sigonella nei primi anni Novanta era redatta per Primavera Project Planner, il predecessore dell'attuale Primavera P6. L'architettura prescrittiva di quel documento è sopravvissuta intatta alle successive revisioni: la specifica attuale, identificata come UFGS 01 32 17.00 20, Network Analysis Schedules (NAS), conserva la medesima struttura e la medesima filosofia, ed è disponibile sul sito del Whole Building Design Guide (wbdg.org).
Il contesto operativo delle comunicazioni satellitari militari in cui quel cantiere si inseriva è ricostruito nell'Appendice B, "The Navy and Satellite Communications", contenuta nel rapporto del National Research Council, Technology for the United States Navy and Marine Corps, 2000-2035: Becoming a 21st-Century Force. Volume 3: Information in Warfare(Washington, DC: The National Academies Press, 1997. DOI 10.17226/5864), disponibile gratuitamente sul sito delle National Academies.
Per una ricostruzione delle capacità SATCOM in banda SHF della U.S. Navy nel periodo specifico in cui si colloca questo saggio, la tesi di Gregory M. Strickland, U.S. Navy SHF SATCOM: Past, Present and Future (Monterey, CA: Naval Postgraduate School, 1993), disponibile nell'archivio digitale Calhoun della NPS, copre con precisione il contesto tecnico e operativo di Sigonella nei primi anni Novanta, incluse le carenze emerse durante la Guerra del Golfo e i requisiti per i sistemi di nuova generazione.
Chi desidera approfondire l'architettura delle stazioni di terra SATCOM, le bande di frequenza, il link budget e la progettazione dei ground segment può fare riferimento a Bruce R. Elbert, The Satellite Communication Ground Segment and Earth Station Handbook, 2nd ed. (Norwood, MA: Artech House, 2014. ISBN 978-1608077267). Il testo, pur essendo posteriore al periodo narrato, descrive principi ingegneristici e architetture di sistema che erano già consolidati all'epoca della costruzione del complesso di Sigonella.
I riferimenti epistemologici e organizzativi citati nell'intero saggio saranno comunque raccolti nella bibliografia ragionata che accompagnerà la terza e ultima parte.