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.
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…
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Redazione ZeroUno
Source link
