Trasformazione digitale
Perché i progetti IT non rispettano tempi e budget nelle PMI
"Avevamo stimato sei mesi. Ne sono passati quattordici."
L'ho sentita così tante volte che a un certo punto ho smesso di sorprendermi. Quello che mi sorprende ancora è la spiegazione che accompagna quasi sempre quella frase: "Il fornitore non ha rispettato i tempi." Oppure: "Il software aveva dei problemi." Raramente qualcuno guarda dall'altra parte.

I numeri
I grandi progetti IT sforano il budget in media del 45% e consegnano il 56% di valore in meno rispetto a quanto promesso. (Fonte: McKinsey & University of Oxford, studio su 5.400 progetti IT)
Il Chaos Report dello Standish Group, che analizza i risultati di oltre 50.000 progetti IT globali, mostra che solo il 31% dei progetti viene completato con successo, consegnato nei tempi e nel budget previsti.
Questi dati riguardano prevalentemente grandi organizzazioni. Ma le PMI non sono immuni. Anzi, spesso pagano un prezzo più alto perché hanno meno risorse per assorbire gli errori e meno struttura per intercettarli in tempo.
Le cause ufficiali e quelle reali
Quando un progetto IT slitta, la diagnosi ufficiale tende a convergere su alcune spiegazioni standard: requisiti cambiati in corso d'opera, problemi tecnici imprevisti, difficoltà di integrazione con i sistemi esistenti.
Queste cose accadono. Ma sono sintomi, non cause.
Nella mia esperienza sul campo, le cause reali sono quasi sempre altre tre.
La prima: nessuno ha il mandato reale
Un progetto IT in una PMI coinvolge tipicamente l'IT, l'area business coinvolta, la direzione e il fornitore. Ognuno ha le proprie priorità, i propri tempi, il proprio linguaggio. Se non c'è una persona con mandato esplicito che tiene insieme questi mondi e prende decisioni quando le cose si inceppano, il progetto rallenta. Ogni decisione rimbalza tra funzioni diverse, le email si accumulano, i problemi restano irrisolti per settimane.
Non è incompetenza. È assenza di governance.
La seconda: i requisiti vengono scritti prima di capire il problema
Uno degli errori più costosi che vedo è la scrittura di capitolati tecnici dettagliati in una fase in cui l'azienda non ha ancora capito davvero cosa vuole ottenere. Si descrivono funzionalità, si elencano moduli, si definiscono integrazioni. Ma la domanda "quale problema stiamo risolvendo e come misuriamo il successo?" resta spesso senza risposta precisa.
Il risultato è che a metà progetto emergono esigenze che nessuno aveva considerato, i requisiti cambiano, il fornitore allunga i tempi e aumenta i costi. Non per malafede, ma perché il problema era definito male fin dall'inizio.
La terza: il progetto non viene presidiato nel quotidiano
Un progetto IT non va avanti da solo. Ha bisogno di qualcuno che segua l'avanzamento settimana per settimana, che intercetti i segnali di rallentamento prima che diventino emergenze, che tenga allineati tutti gli attori coinvolti.
Nelle PMI questa figura spesso non esiste o è part-time rispetto al progetto. Il risultato è che i problemi emergono tardi, quando il ritardo è già consolidato e recuperarlo costa molto di più che prevenirlo.
Il segnale d'allarme che si ignora sempre
C'è un momento preciso in cui quasi tutti i progetti che ho visto andare male potevano ancora essere salvati. Si chiama "primo mese di silenzio".
Nelle prime settimane dopo il kick-off c'è sempre movimento: riunioni, scambi di documenti, entusiasmo. Poi, intorno alla quarta o quinta settimana, arriva un rallentamento. Nessuna notizia dal fornitore per giorni, qualche email che resta senza risposta, una data spostata di una settimana "per allineare le agende".
Quel silenzio è il segnale. Se non viene intercettato e affrontato subito, diventa il pattern del progetto intero.
Cosa cambia nei progetti che funzionano
I progetti IT che rispettano i tempi e il budget nelle PMI non sono quelli con i fornitori migliori o le tecnologie più avanzate. Sono quelli in cui qualcuno, dall'interno, si è preso la responsabilità dell'avanzamento — non della parte tecnica, ma del fatto che le cose accadano davvero.
Tre domande da fare prima di approvare qualsiasi progetto IT:
Chi è la persona interna che presidia l'avanzamento ogni settimana, con nome e cognome?
Come misuriamo il successo tra sei mesi, in termini di business e non di funzionalità consegnate?
Qual è il processo decisionale quando emergono problemi? Chi decide, in quanto tempo, con quale mandato?
Se queste domande non hanno una risposta precisa prima che il progetto parta, la probabilità di sforare tempi e budget è molto alta — indipendentemente dalla qualità del fornitore scelto.
Hai vissuto un progetto IT che ha sforato i tempi o il budget? Qual è stata, guardando indietro, la causa reale?
Se vuoi capire dove si bloccano i tuoi progetti, [prenota una call](https://www.marco-devecchi.com/form) — nessun impegno, solo una conversazione concreta.
*Marco De Vecchi è un Fractional Executive specializzato in trasformazione digitale per PMI italiane. Ha guidato progetti digitali in contesti ad alta complessità — Ferrari, Marina Militare, ENI, Presidenza del Consiglio dei Ministri.*