Lo steering committee si apre con una dashboard rassicurante. Le attività previste risultano completate, il budget è ancora dentro la soglia approvata e il rilascio riporta la data indicata nel piano. Eppure, dietro “il verde dei semafori”, il progetto può avere già cominciato a perdere valore: una parte degli utenti continua a lavorare con procedure parallele, un’integrazione decisiva è stata rinviata, il mercato è cambiato oppure i benefici economici poggiano su ipotesi che nessuno ha più verificato.
È in questa distanza fra avanzamento e risultato che si colloca oggi il rischio più rilevante. Metodologie Agile, cloud, automazione e intelligenza artificiale hanno aumentato velocità e capacità dei team, ma nessuna tecnologia può compensare a lungo obiettivi ambigui, responsabilità senza autorità, priorità in conflitto o un cambiamento organizzativo lasciato al dopo. Per capire perché in alcune circostanze le iniziative tecnologiche continuano a deludere occorre quindi allargare la definizione di successo e osservare dove, durante l’esecuzione, si consuma la convenienza dell’investimento.
Indice degli argomenti
Perché un progetto IT può fallire anche dopo il go-live
Il fallimento più evidente è la cancellazione. Esistono però esiti meno netti e molto più frequenti: un’iniziativa che supera in modo rilevante tempi e costi, una soluzione che funziona ma viene adottata solo in parte, oppure un sistema consegnato quando il problema originario è ormai cambiato. In tutti questi casi il progetto può risultare formalmente completato e, nello stesso tempo, aver prodotto soltanto una quota del valore atteso.
Il rapporto Pulse of the Profession 2026 del Project Management Institute aiuta a dimensionare il problema senza ricorrere alla controversa affermazione secondo cui fallirebbe il 70% dei progetti IT. La ricerca, trasversale a settori e tipologie progettuali e quindi non limitata all’informatica, rileva che circa un terzo dei progetti complessi fallisce, quasi il doppio del 13% registrato sull’insieme dei progetti. Il 97% dei professionisti interpellati dichiara inoltre di avere gestito almeno un progetto complesso nell’ultimo anno.
La complessità ovviamente cresce con il numero di stakeholder, l’incertezza regolatoria, le dipendenze tecniche e organizzative e la velocità del cambiamento.
Tempi e budget non bastano a definire il successo
Il tradizionale triangolo formato da tempi, costi e perimetro resta necessario per governare la delivery. Diventa insufficiente quando viene utilizzato come misura completa del successo. Un nuovo CRM può arrivare puntuale e rispettare il capitolato, ma deludere se i commerciali lo usano solo per gli adempimenti minimi. Un sistema di automazione può superare i test e non ridurre i tempi di processo. Una data platform può entrare in esercizio senza migliorare la qualità o la rapidità delle decisioni.
La ricerca Step Up: Redefining the Path to Project Success with M.O.R.E., pubblicata nel 2025 dal Project Management Institute (PMI), organizzazione internazionale di riferimento per il project management, invita a misurare anche il valore prodotto e la percezione degli stakeholder. Il dato forse più utile per chi governa un portafoglio è che il 45% dei progetti infine riusciti era stato, in una fase precedente, a rischio di fallimento. Individuare presto i segnali critici può dunque cambiare l’esito.
Occorre distinguere tre livelli.
- La delivery riguarda ciò che è stato realizzato;
- l’adozione misura quanto la soluzione sia entrata nel lavoro quotidiano;
- la benefits realization verifica se l’uso ha generato i benefici economici, operativi o strategici indicati nel business case.
Un progetto tecnicamente riuscito diventa un investimento deludente quando questi tre piani vengono confusi.
Il business case deve continuare a governare il progetto
In molte organizzazioni il business case svolge una funzione importante ma breve: sostiene la richiesta di budget, supera il processo di approvazione e poi lascia il posto al piano di progetto. Da quel momento l’attenzione si concentra su attività, milestone e spesa. I benefici rimangono sullo sfondo, spesso espressi in termini troppo generici per essere verificati.
Un business case capace di accompagnare l’esecuzione dovrebbe indicare benefici, situazione di partenza, KPI, target, responsabile del risultato, principali ipotesi e orizzonte temporale. Se il ritorno dipende, per esempio, dalla migrazione dell’80% delle transazioni su un nuovo canale digitale entro dodici mesi, quella condizione deve restare visibile nella governance. Lo stesso vale per il costo delle licenze, la disponibilità dei dati, la risposta dei clienti, il volume delle attività o la capacità di ridurre operazioni manuali.
Ma le ipotesi, talvolta, sono destinate a cambiare in corsa. Un vincolo regolatorio può modificare lo scope, un concorrente può anticipare una funzione, il prezzo di un servizio cloud può crescere, un’acquisizione può ridisegnare i processi. Per questo il controllo dovrebbe affiancare alla domanda “siamo in linea con il piano?” una verifica diversa: “il risultato vale ancora ciò che stiamo investendo?”. È anche un modo concreto per ridurre lo scarto fra strategia ed esecuzione: ogni revisione riporta le scelte operative alla ragione per cui l’iniziativa era stata finanziata.
Dai business case ai “progetti zombie”
Quando nessuno riesamina la convenienza dell’investimento, può nascere un “progetto zombie”: continua ad assorbire budget e competenze pur avendo perso una parte sostanziale della sua utilità. A tenerlo in vita concorrono l’inerzia organizzativa, la difficoltà di ammettere che le condizioni siano cambiate, la pressione dei costi già sostenuti e dashboard concentrate sulla percentuale di completamento.
Il sunk-cost bias, cioè la tendenza a proseguire perché si è già investito molto, trasforma il passato in un argomento per spendere ancora. Dal punto di vista economico, invece, contano i costi futuri e il valore ancora ottenibile. La governance dovrebbe perciò prevedere checkpoint nei quali scegliere in modo esplicito se continuare, modificare il perimetro, sospendere o cancellare. La decisione richiede criteri stabiliti in anticipo, affinché lo stop non dipenda soltanto dalla forza politica dei diversi sponsor.
Fermare un’iniziativa che ha perso la propria giustificazione può rappresentare una buona decisione di investimento. Il vero errore è consumare altre risorse per proteggere l’apparenza di successo, sottraendole a priorità con prospettive migliori.
Chi decide cosa in un progetto IT
Molti organigrammi di progetto mostrano ruoli, comitati e linee di riporto. Meno spesso chiariscono chi risponde del valore e chi possiede l’autorità per prendere una decisione entro la scadenza richiesta. La distinzione fondamentale riguarda tre piani: ownership dei benefici, governo dell’esecuzione e presidio dei vincoli specialistici o contrattuali.
Una matrice di responsabilità RACI è utile se collega ciascuna decisione a una persona, a un tempo massimo e a un percorso di escalation. Perde efficacia quando distribuisce responsabilità generiche tra gruppi numerosi. Essere consultati, approvare una scelta e rispondere del risultato sono funzioni diverse.
Sponsor, business owner e product owner: chi risponde del valore
Lo sponsor dà mandato al progetto, ne sostiene la priorità a livello executive, assicura copertura e rimuove ostacoli organizzativi.
Il business owner risponde dei benefici, della trasformazione dei processi e dell’adozione nell’area interessata.
Il product owner, nei progetti gestiti secondo Scrum, un framework Agile basato su cicli di lavoro brevi e incrementali, traduce obiettivi e bisogni in priorità del prodotto: la Scrum Guide ufficiale in italiano gli attribuisce formalmente la responsabilità di massimizzare il valore generato dal lavoro del team e di gestire efficacemente il Product Backlog.
I tre ruoli possono talvolta ricadere sulla stessa persona, ma restano concettualmente distinti. Uno sponsor autorevole può ottenere fondi e attenzione senza presidiare l’uso quotidiano della soluzione. Un product owner può ordinare correttamente il backlog senza avere l’autorità per cambiare incentivi, processi o obiettivi di una funzione aziendale. La presenza di uno sponsor, quindi, non garantisce che esista un vero owner del beneficio.
Questo vuoto emerge soprattutto dopo il rilascio. Il team tecnico chiude le attività, il project manager completa la documentazione e il fornitore rispetta le condizioni contrattuali; se nessuno continua a seguire adozione e risultati, il valore promesso rimane privo di un responsabile.
CIO, PMO, project manager e fornitori: chi governa execution e vincoli
Il CIO deve assicurare la coerenza dell’architettura, la disponibilità delle capacità IT, la sicurezza, la governance dei dati, la sostenibilità tecnologica e la gestione delle dipendenze. Il project o program manager governa piano, rischi, milestone, problemi e coordinamento. Il Project Management Office (PMO), la funzione aziendale che coordina e supporta la gestione dei progetti, monitora il portafoglio, mette in relazione le priorità con le risorse disponibili e rende visibili i conflitti tra programmi.
Accanto a questi ruoli, enterprise architect, CISO, data owner e responsabili compliance presidiano vincoli che possono determinare la fattibilità di una scelta. Vendor e system integrator rispondono della delivery prevista dal contratto. Il loro impegno può contribuire in modo decisivo al risultato, ma la consegna contrattuale non coincide automaticamente con il beneficio aziendale.
Il project manager può portare un problema al livello corretto, quantificare l’impatto del ritardo e proporre alternative. Non può sostituirsi a chi possiede budget, rischio o processo. Quando lo fa per necessità, l’organizzazione ottiene decisioni prive del mandato adeguato e tende poi a scaricare sull’esecuzione un problema di autorità.
Governance, scope e dipendenze: dove si accumula il ritardo invisibile
Una parte dei ritardi nasce prima di apparire nel cronoprogramma. Un requisito rimane ambiguo, l’accesso a una fonte dati viene rinviato, la security review non trova uno slot, due vendor discutono l’interfaccia, il responsabile di processo non approva una scelta. Ogni attesa sembra locale; la loro somma attraversa più workstream e riduce il margine disponibile per test, migrazione e formazione.
Anche lo scope creep, l’allargamento progressivo del perimetro, è spesso un effetto della governance. Nuove richieste entrano nel backlog senza che qualcuno scelga quale attività rinviare, quanto budget aggiungere o quale beneficio ulteriore giustifichi l’estensione. Il piano continua a mostrare lo stesso obiettivo mentre, nella pratica, la squadra lavora su un progetto diverso.
Il PMI invita ad affrontare la complessità attraverso il systems thinking: osservare relazioni, effetti indiretti e retroazioni, anziché gestire ogni elemento come indipendente. Il punto critico raramente coincide con un singolo task in ritardo; spesso è una dipendenza che nessuno governa end-to-end.
Il costo delle decisioni che non vengono prese
La decision latency è il tempo che intercorre tra l’emersione di una scelta e la decisione effettiva. Può diventare un indicatore più rivelatore della percentuale di completamento, soprattutto nei programmi complessi. Tre settimane impiegate per approvare una modifica dello scope possono bloccare sviluppo, test, procurement e comunicazione; il ritardo finale emergerà più tardi e sembrerà distribuito tra diversi team.
Per le decisioni rilevanti la governance dovrebbe specificare chi decide, entro quanto tempo, chi deve essere consultato e quando scatta l’escalation. Le casistiche comprendono l’aumento del budget, il rinvio del go-live, l’accettazione di un rischio, la modifica del perimetro e il cambio di un fornitore. Non tutte richiedono il comitato più alto: delegare soglie chiare ai livelli operativi riduce le attese e conserva agli executive le scelte realmente strategiche.
Misurare la latenza aiuta anche a evitare un equivoco ricorrente. Un team può sembrare lento mentre aspetta risposte che non ha l’autorità di produrre. Rendere visibile la coda delle decisioni, con età, impatto e owner, porta il problema nel luogo in cui può essere risolto.
Quando troppi progetti competono per le stesse risorse
La capacità nominalmente assegnata raramente coincide con quella realmente disponibile. Un architect indicato al 30% su tre programmi può essere già saturo; un esperto di cybersecurity può ricevere contemporaneamente richieste di revisione; data engineer e responsabili business possono diventare il collo di bottiglia di iniziative nate in aree diverse. È la portfolio congestion: troppi lavori attivi competono per le medesime capacità critiche.
Il problema acquista peso in un Paese in cui gli specialisti ICT rappresentavano nel 2024 il 4% dell’occupazione, una quota inferiore alla media europea, come rileva il Digital Decade Country Report 2025 dedicato all’Italia. Il rapporto dell’Istat sulla diffusione dell’ICT nelle imprese italiane mostra inoltre quanto le competenze incidano sulle scelte tecnologiche: tra le aziende che hanno valutato l’AI senza poi investirvi, il 58,6% indica come ostacolo la mancanza di competenze adeguate.
Legacy, qualità dei dati, API, controlli cyber e capacità dei vendor aggiungono dipendenze tecniche alla scarsità di persone. Per questo la domanda utile è capire quanta capacità critica sarà davvero disponibile nel momento preciso in cui il programma ne avrà bisogno. Ridurre il numero di iniziative contemporanee può aumentare il valore complessivamente consegnato, perché accorcia le code e porta a termine prima i lavori prioritari.
Competenze e adozione: il go-live non conclude il cambiamento
Per realizzare una trasformazione servono competenze tecniche, ma anche project e program management, conoscenza dei processi, comprensione economica, gestione dei fornitori e capacità di guidare il cambiamento. Se una di queste componenti manca, il progetto può produrre un output corretto senza trasformarlo in risultato aziendale.
Il change management viene ancora ridotto a comunicazione e formazione organizzate vicino al rilascio. In realtà comprende il ridisegno dei processi, la ridefinizione di responsabilità e incentivi, l’ascolto delle resistenze, il supporto ai manager e la rimozione delle procedure che tengono in vita il vecchio modo di lavorare. Queste attività richiedono tempo e devono cominciare quando la soluzione è ancora modificabile.
Il business mantiene qui una responsabilità diretta. L’IT può rendere il sistema affidabile e semplice da usare, ma l’adozione dipende anche da obiettivi, comportamenti e scelte operative delle funzioni coinvolte. Attribuire al solo CIO il compito di cambiare il lavoro dell’intera organizzazione confonde la responsabilità tecnologica con quella sul beneficio.
Una soluzione utilizzata poco è un progetto incompleto
Un ERP può essere tecnicamente operativo mentre reparti e filiali continuano a utilizzare fogli Excel e procedure parallele. In questo scenario il go-live certifica la disponibilità della piattaforma, non la trasformazione. Le doppie registrazioni aumentano il lavoro, i dati divergono e i benefici economici rimangono distanti dal business case.
La misurazione deve proseguire dopo il rilascio. Utenti attivi, processi migrati, attività manuali eliminate, errori, tempi di attraversamento e KPI economici consentono di capire se l’organizzazione sta convertendo la funzionalità in valore. Le metriche vanno confrontate con una baseline: senza la situazione di partenza, anche un miglioramento reale rimane difficile da quantificare.
Formazione, supporto, revisione dei processi e incentivi devono essere progettati prima del rilascio. Anche il piano di dismissione delle procedure precedenti è fondamentale: se il vecchio strumento resta più comodo o continua a essere accettato dai manager, il nuovo sistema diventa un livello aggiuntivo anziché una semplificazione. L’owner del beneficio deve seguire questa fase fino al raggiungimento dei target, non soltanto fino all’accettazione tecnica.
L’AI accelera i progetti e può spostarne i colli di bottiglia
L’intelligenza artificiale entra nel tema in due modi distinti. Nel primo è l’oggetto dell’investimento: l’impresa vuole portare in produzione un modello o un’applicazione AI. Nel secondo diventa uno strumento usato per realizzare altri progetti, attraverso assistenti di coding, analisi automatizzate, generazione di documentazione o supporto alla pianificazione. Confondere i due casi impedisce di leggere rischi e benefici correttamente.
Quando l’AI è l’oggetto del progetto
Un caso d’uso AI ha bisogno di un business case specifico. Deve chiarire quale decisione o processo migliora, con quali dati, per quali utenti e attraverso quali indicatori. Accuratezza del modello e qualità della demo rappresentano soltanto una parte del risultato. Contano anche integrazione nei sistemi, cybersecurity, compliance, monitoraggio, accountability e costo di esercizio.
I dati possono impedire il passaggio dal pilot alla produzione: indisponibilità, qualità insufficiente, diritti di utilizzo incerti o difficoltà nel mantenere aggiornati i flussi. I costi possono cambiare con i volumi, soprattutto quando la sperimentazione usa un campione ridotto. Il monitoraggio deve rilevare degrado delle prestazioni, comportamenti inattesi e variazioni del contesto. L’accountability stabilisce chi può accettare il rischio e chi interviene quando l’output è sbagliato.
Un pilot tecnicamente riuscito dimostra che una soluzione può funzionare in condizioni definite. Una soluzione enterprise deve dimostrare di poter funzionare in modo affidabile, integrato, conforme ed economicamente sostenibile nel tempo. È nello spazio fra queste due prove che molti progetti smarriscono il valore promesso.
Quando l’AI viene utilizzata per realizzare il progetto
Coding assistant e strumenti generativi possono accelerare sviluppo, analisi e documentazione. La maggiore velocità del singolo task, però, non coincide necessariamente con una riduzione del lead time end-to-end. Gli output richiedono validazione e possono contenere errori plausibili, incoerenze o scelte poco adatte al contesto. Il controllo umano rimane quindi parte della capacità necessaria.
Se la produzione del codice accelera mentre test, code review, security review e approvazioni conservano la stessa capacità, il collo di bottiglia si sposta a valle. Il lavoro in attesa cresce e il progetto può dover impiegare più persone di quelle previste proprio nelle funzioni di verifica. Una stima che traduce automaticamente il guadagno di produttività dello sviluppo in una riduzione proporzionale di tempi e risorse rischia di essere irrealistica.
Occorre misurare rework, difetti, vulnerabilità, tempi di revisione e attraversamento complessivo. L’AI può aumentare la quantità di output senza aumentare nella stessa misura la capacità dell’organizzazione di assorbirli. La progettazione del flusso deve quindi evolvere insieme agli strumenti: soglie di revisione basate sul rischio, automazione dei test, tracciabilità e competenze adeguate diventano condizioni del beneficio.
Come capire in tempo che un progetto sta perdendo valore
Lo steering committee dispone spesso di informazioni approfondite sull’esecuzione e più deboli sulla validità delle ipotesi che giustificano l’investimento. Per correggere questa asimmetria, la dashboard dovrebbe affiancare a tempi, costi, scope e rischi alcuni indicatori di valore: andamento dei benefici, adozione, decisioni pendenti, capacità delle dipendenze critiche e variazioni delle assunzioni del business case.
Non serve moltiplicare i KPI. Serve scegliere pochi segnali capaci di anticipare il problema. Un alert deve condurre a una decisione, non soltanto a una spiegazione. Se l’adozione è inferiore al target, qualcuno deve poter cambiare formazione, processo o rilascio; se la latenza decisionale cresce, deve attivarsi un’escalation; se un’ipotesi economica decade, va rivalutato il finanziamento.
Cinque domande che il CIO dovrebbe portare allo steering committee
- Il beneficio è ancora misurabile e ha un owner? Devono essere espliciti baseline, KPI, target, tempi e responsabilità. Se il beneficio è espresso soltanto come “maggiore efficienza” o “migliore esperienza”, il progetto non dispone ancora di un criterio verificabile.
- Se il progetto partisse oggi, avrebbe ancora la stessa priorità? La risposta obbliga a riesaminare business case, strategia, mercato, regolazione e tecnologia alla luce di ciò che è cambiato dall’approvazione.
- Le decisioni arrivano alla velocità richiesta? Occorre osservare owner, scadenze, escalation e anzianità delle questioni pendenti, valutando l’impatto che ogni attesa produce sui diversi workstream.
- Le dipendenze critiche hanno davvero capacità disponibile? Persone, architettura, dati, cybersecurity, funzioni business e vendor devono essere disponibili quando servono, non soltanto presenti sulla carta.
- Stiamo misurando il rilascio o il beneficio? Ai KPI di delivery vanno affiancati indicatori di adozione e outcome dopo il go-live, mantenendo la responsabilità fino alla realizzazione del valore.
La scena finale può assomigliare a quella iniziale: milestone rispettate, budget sotto controllo, dashboard verde. Questi segnali dicono molto sulla qualità dell’esecuzione e possono dire poco sulla persistente convenienza dell’investimento. La domanda che il CIO dovrebbe lasciare sul tavolo è un’altra: “Se questo progetto dovesse essere approvato oggi, conoscendo tutto ciò che abbiamo imparato durante l’esecuzione, investiremmo ancora la stessa cifra per ottenere lo stesso risultato?”
Partecipa alla community