La lamentela ricorrente sui progetti IT non è che falliscano del tutto, sebbene alcuni lo facciano. È che non riescono a essere prevedibili. Un programma che finisce con sei mesi di ritardo e il quaranta percento oltre budget è dannoso, ma un portafoglio in cui un dato progetto potrebbe finire in tempo oppure slittare di un anno, senza un modo affidabile di stabilire in anticipo quale dei due, è corrosivo in modo diverso. Rende impossibile la pianificazione a livello di business. Insegna ai dirigenti a gonfiare ogni stima e a scontare ogni impegno, il che a sua volta insegna ai team di delivery che le stime sono teatro. L'intero sistema scivola in un equilibrio di bassa fiducia in cui nessuno crede al piano e ognuno si protegge.

Questo conta oggi più di quanto contasse un decennio fa, per una ragione precisa. Il cambiamento IT non è più un evento discreto che un'azienda assorbe di tanto in tanto. È continuo ed è intrecciato con ricavi, regolamentazione ed esperienza del cliente in modi che lasciano poco margine. Quando una migrazione core banking slitta, o un consolidamento ERP si arena, le conseguenze non si limitano a una voce di budget IT. Si propagano negli impegni commerciali, nelle scadenze di conformità e nella credibilità della leadership che ha sponsorizzato il lavoro. Il costo dell'imprevedibilità è aumentato anche là dove il costo del singolo fallimento non lo è.

La verità scomoda è che gran parte dell'imprevedibilità viene fabbricata sin dall'inizio, prima che sia scritta una riga di codice o predisposto un server. Viene fabbricata trattando la stima come una negoziazione, impegnandosi su un ambito mai realmente compreso e adottando un approccio di delivery scelto per comodità culturale anziché per la natura effettiva del lavoro. La prevedibilità è determinata in larga misura da decisioni prese quando il progetto è ancora poco costoso da plasmare. È da lì che la disciplina deve partire.

La decisione fondante in qualsiasi progetto IT non è quale framework adottare. È una diagnosi di dove risiede l'incertezza. In linea generale, l'incertezza nella delivery si presenta in due forme, che richiedono risposte opposte. La prima è l'incertezza di esecuzione: sappiamo con precisione cosa dobbiamo costruire, ma costruirlo è grande, complesso o rischioso. La seconda è l'incertezza di requisito: potremmo costruirlo con competenza se solo sapessimo di cosa si tratta, ma la risposta giusta emergerà solo attraverso il feedback dell'uso reale. Confondere queste due forme è all'origine della maggior parte dei fallimenti legati al metodo.

Dove l'incertezza dominante è di esecuzione e il requisito è genuinamente stabile, la delivery plan-driven non è un residuo di cui scusarsi. È lo strumento corretto. Una migrazione di data center, una modifica di reporting regolamentare con una specifica legale fissa o il rollout di un pacchetto ben compreso verso nuove sedi hanno tutti un ambito conoscibile e traggono enorme beneficio da un dettagliato sequenziamento a monte, dalla mappatura delle dipendenze e dalla gestione del percorso critico. Fingere che un lavoro simile sia un viaggio di scoperta spreca l'unico vantaggio che esso offre, ovvero la possibilità di pianificarlo correttamente.

Dove l'incertezza dominante è di requisito, l'approccio plan-driven diventa attivamente dannoso, perché impone un impegno prematuro su decisioni che dovrebbero restare aperte. Qui la delivery adattiva si guadagna il suo posto: cicli brevi, incrementi funzionanti e contatto frequente con utenti reali convertono le incognite in certezze al ritmo sostenibile più rapido. Lo scopo dell'iterazione non è la velocità fine a se stessa. È la ritirata sistematica del rischio di requisito. Un team che itera ma non confronta mai i propri incrementi con un feedback utente autentico ha adottato il cerimoniale senza il meccanismo, e non ne ricava nulla.

La posizione onesta, e quella che questo articolo sostiene, è che la maggior parte dei programmi sostanziali contiene entrambi i tipi di incertezza in proporzioni diverse tra le sue componenti. Il giudizio maturo non è dichiarare l'intera impresa agile o waterfall, ma scomporla, applicare il rigore plan-driven dove l'ambito è stabile e la scoperta adattiva dove non lo è, e gestire deliberatamente la giuntura tra i due. È in quella giuntura che risiede la vera abilità.

Diversi sviluppi hanno ridisegnato la gestione dei progetti IT negli ultimi anni, e vale la pena separare ciò che è sostanziale da ciò che è di moda. Il più sostanziale è il passaggio dal pensiero per progetti al pensiero per prodotti nelle parti del panorama IT che sono di lunga durata. Una piattaforma di pagamenti o un portale clienti non è un progetto che finisce; è un prodotto che persiste, finanziato con continuità e affidato a un team stabile. Per questa classe di lavoro, il costrutto del progetto con la sua data di fine fissa e la dispersione del team al completamento è diventato una vera e propria passività, perché ottimizza per la consegna anziché per la titolarità duratura che mantiene sano il software.

Allo stesso tempo, e in qualche tensione con il movimento verso il prodotto, si è formalizzata la disciplina della gestione delle dipendenze su scala. Quando le organizzazioni fanno lavorare decine di team su un'architettura condivisa, il vincolo determinante sulla delivery raramente è la produttività di un singolo team. È il costo di coordinamento tra di essi: i servizi condivisi, il sequenziamento delle integrazioni, le capacità di piattaforma da cui dipendono più flussi. I framework di delivery su scala sono, nel loro nucleo utile, un tentativo di rendere visibili queste dipendenze tra i team e di schedularle prima che diventino la ragione per cui tutti sono bloccati.

Un terzo cambiamento è la maturazione della continuous delivery e l'automazione del percorso verso la produzione. Quando distribuire una modifica è un evento raro, manuale e ad alto rischio, l'economia spinge verso lotti grandi e cicli di rilascio lunghi, che a loro volta spingono verso una pesante pianificazione a monte. Quando la distribuzione è automatizzata, testata e di routine, gli incrementi piccoli diventano poco costosi da rilasciare, e l'intero ritmo della delivery può spostarsi verso il feedback frequente da cui dipende il lavoro adattivo. Molto di ciò che viene attribuito alla metodologia è in realtà una conseguenza di questa capacità ingegneristica. Un team non può iterare in modo significativo verso il valore se può rilasciare solo due volte l'anno, indipendentemente da quale framework sia scritto sulla parete.

Una delivery prevedibile è tanto una proprietà di come il lavoro è strutturato quanto di come è gestito. La leva più potente in assoluto è la scomposizione in incrementi che ciascuno consegni qualcosa di dimostrabile e, idealmente, qualcosa di utilizzabile. Non si tratta di un vezzo amministrativo di progetto. Un incremento che produce software funzionante costringe a rispondere presto e ripetutamente alle domande di integrazione e test, anziché rinviarle a una fase finale in cui esplodono tutte insieme. Il classico fallimento dell'integrazione big-bang, in cui mesi di componenti costruiti separatamente vengono combinati alla fine e si scopre che non combaciano, è un fallimento della progettazione degli incrementi prima ancora di essere un fallimento della gestione.

L'architettura delle dipendenze è il secondo principio. Ogni dipendenza tra team, sistemi o fornitori è un vincolo di schedulazione e un rischio. Una buona progettazione della delivery si adopera per minimizzarle e sequenziarle deliberatamente: individuando quali componenti si trovano sul percorso critico, quali capacità condivise devono esistere prima che il lavoro dipendente possa iniziare, e quali impegni esterni, come una consegna di un fornitore o un'approvazione regolamentare, si collocano al di fuori del controllo del team e richiedono quindi la massima attenzione anticipata e il buffering più conservativo. Le dipendenze scoperte tardi sono le più costose, perché quando emergono le opzioni per risolverle si sono ormai ristrette.

Il terzo principio è progettare per la reversibilità dove il requisito è incerto e per la robustezza dove è consolidato. Le decisioni poco costose da revocare possono essere prese rapidamente e riviste alla luce del feedback; le decisioni costose da revocare, come un modello dati al cuore del sistema o la scelta di una piattaforma da cui tutto il resto dipenderà, meritano uno scrutinio sproporzionato prima di essere bloccate. Un progetto ben condotto spende la sua analisi accurata dove la revoca è costosa e si muove rapidamente dove non lo è, anziché applicare un cerimoniale uniforme a ogni scelta. Confondere le due cose, angosciarsi sul banale mentre si affrettano le scelte irreversibili, è una causa di problemi comune e silenziosa.

Lo scope creep travestito da flessibilità. La delivery adattiva viene spesso usata a sproposito come licenza per non fissare mai l'ambito. L'iterazione genuina affina la soluzione verso un obiettivo stabile; il cambiamento indisciplinato sostituisce un obiettivo con un altro ogni poche settimane e lo chiama reattività. La distinzione sta nel fatto che i cambiamenti convergano o meno. Un progetto in cui ogni ciclo avvicina l'esito a un obiettivo coerente sta imparando. Un progetto in cui ogni ciclo aggiunge un nuovo obiettivo non sta gestendo l'ambito, lo sta abbandonando, e non finirà.

Il report di stato anguria. Verde all'esterno, rosso all'interno. È il prodotto naturale del giudicare i progetti sulle milestone superate anziché sul software funzionante e sul valore concretizzato. Quando la metrica è la percentuale di attività completate, un team può riportare novanta percento per mesi mentre il dieci percento difficile, integrante, portatore di valore resta intatto. Il rimedio non è una migliore disciplina di reporting. È cambiare ciò che si misura, affinché il progresso significhi incrementi dimostrabili, testati e utilizzabili anziché attività a fronte di un piano.

La negazione delle dipendenze. I team pianificano il proprio lavoro con cura e trattano tutto ciò che è al di fuori del proprio confine come un problema di qualcun altro che si risolverà da sé nei tempi previsti. Raramente accade. Le dipendenze che un progetto non controlla sono proprio quelle più esposte a slittare, e quelle che un team è meno in grado di accelerare quando lo fanno. Rendere esplicite le dipendenze esterne, assegnarne la titolarità e bufferizzarle realisticamente è un lavoro poco glamour che separa i programmi che tengono le loro date da quelli che non lo fanno.

L'ambiguità degli stakeholder. Molti progetti procedono per mesi senza una risposta chiara su chi decide davvero. Quando lo sponsor, gli utenti e i finanziatori vogliono cose sottilmente diverse e nessun singolo titolare responsabile le concilia, il progetto assorbe il conflitto come turbolenza, rimettendo in discussione decisioni già prese e non accontentando nessuno. La chiarezza su chi risponde dell'esito, chi deve essere consultato e chi va semplicemente informato non è burocrazia. È il meccanismo con cui un progetto può effettivamente prendere decisioni e mantenerle ferme.

La stima come impegno. Una stima è un'affermazione probabilistica su un futuro incerto. Nel momento in cui viene trattata come una promessa, smette di essere onesta, perché la stima più sicura da promettere è quella gonfiata, e il gonfiaggio distrugge l'informazione che la stima doveva veicolare. Una delivery sana tiene separate stima e impegno: le stime informano la pianificazione con franchezza, e gli impegni si prendono deliberatamente, con l'incertezza riconosciuta anziché negoziata via.

L'approccio di Nashua alla gestione dei progetti IT parte dalla diagnosi anziché dal metodo. Prima di raccomandare qualsiasi modello di delivery, lavoriamo per stabilire dove risieda effettivamente l'incertezza in un dato programma, componente per componente, perché quella lettura determina tutto ciò che segue a valle. È un lavoro deliberatamente controcorrente. Resiste all'impulso di dichiarare un'unica metodologia per l'intero panorama e accetta invece che un programma possa richiedere il rigore plan-driven per il suo nucleo stabile e ricco di dipendenze e la scoperta adattiva per le parti in cui i requisiti sono ancora in via di apprendimento. Gestiamo la giuntura tra queste modalità come una preoccupazione di prim'ordine anziché come un ripensamento.

Nell'esecuzione, ci atteniamo a un piccolo numero di discipline non negoziabili. Gli incrementi sono progettati per produrre software funzionante e testato presto e spesso, così che il rischio di integrazione sia affrontato con continuità anziché rinviato. Le dipendenze, specie quelle al di fuori del controllo del team, vengono rese esplicite, assegnate e bufferizzate sin dall'inizio. L'ambito è gestito a fronte di un obiettivo coerente, con il cambiamento accolto dove converge su quell'obiettivo e contestato dove si limita ad ampliarlo. E manteniamo la stima onesta separandola dall'impegno, affinché i piani veicolino informazione reale anziché gonfiaggio difensivo. Soprattutto, giudichiamo il progresso in base a software funzionante e dimostrabile e all'evidenza di valore concretizzato, non in base al conteggio delle milestone superate, perché il secondo è facile da falsificare e il primo no.

Prendiamo inoltre sul serio l'architettura umana di un progetto: stabilire chi risponde dell'esito, chi decide e come quelle decisioni restano ferme. Molto di ciò che sembra un fallimento di delivery è in realtà un'ambiguità irrisolta degli stakeholder espressa come turbolenza, e trattiamo la chiarificazione delle responsabilità come lavoro di delivery di prim'ordine anziché come un onere di governance da minimizzare.

La differenza che Nashua porta non è un metodo proprietario che promette di far sparire l'incertezza. Un metodo simile non esiste, e le aziende che affermano il contrario vendono conforto anziché delivery. La differenza è il giudizio applicato con coerenza: la disponibilità a diagnosticare onestamente, a scegliere la delivery plan-driven e quella adattiva in base ai loro meriti anziché alla moda, a rendere visibili dipendenze e responsabilità prima che diventino scuse, e a insistere per tutto il tempo che un progetto vale ciò che mette nelle mani degli utenti e concretizza in valore, non ciò che riporta a fronte di un piano. Quel giudizio è il frutto di aver realizzato abbastanza programmi da sapere dove vanno davvero storti.

C'è anche un corollario pratico che cambia ciò che il lavoro può presupporre. Quando un incarico richiede una capacità che ancora non esiste, non deve attendere un ciclo di approvvigionamento o la roadmap di un fornitore. La Nashua 360 Enterprise Platform è costruita per accogliere quasi ogni funzionalità a ritmo sostenuto, attraverso l'extreme vibe coding: ciò che serve viene descritto in linguaggio semplice e generato rapidamente, ma sempre entro solidi principi architetturali e sotto una rigorosa garanzia di qualità, così che la velocità non vada mai a scapito di coerenza, sicurezza o controllo. L'effetto è strategico più che meramente pratico. Sposta la linea del make-or-buy, mantiene poco costosa l'opzionalità e lascia che l'architettura segua la strategia anziché la strategia piegarsi a qualsiasi cosa capitasse di avere a scaffale.

Ciò che tiene insieme tutto questo è il rifiuto di lasciare che la delivery diventi teatro. È semplice condurre un progetto che appare ben gestito, genera un reporting rassicurante e soddisfa ogni checkpoint di governance mentre silenziosamente non produce nulla di valore. È molto più difficile, e molto più raro, condurne uno che resti onesto sulla propria incertezza, affronti presto i propri rischi, mantenga il proprio ambito in convergenza e si misuri a fronte di esiti funzionanti. Quel percorso più difficile è quello a cui Nashua si impegna, perché è l'unico che rende il cambiamento IT genuinamente prevedibile anziché semplicemente ben documentato. Le organizzazioni con cui lavoriamo arrivano a fare affidamento non sulla promessa che nulla andrà storto, ma sulla certezza che quando qualcosa va storto sarà visto presto, nominato con chiarezza e affrontato mentre è ancora poco costoso da correggere.