La telefonata arriva un mercoledì pomeriggio, a metà trimestre.
Il titolare di un’azienda di componentistica industriale in Veneto — 22 milioni di fatturato, seconda generazione, sessanta dipendenti — mi chiama perché “il gestionale nuovo non funziona come dovrebbe”.
Scavo un po’. Scopro che il progetto di migrazione ERP è partito 8 mesi prima. Il budget iniziale era 95.000 euro. Siamo a 187.000 e il sistema non è ancora in produzione.
Il fornitore ha chiesto “altri due mesi e una fase di personalizzazione aggiuntiva.” Il responsabile amministrativo, che doveva essere l’owner interno del progetto, ha smesso di partecipare alle riunioni da tre mesi perché “tanto non mi ascoltano.”
Il figlio del fondatore, che aveva voluto il cambio gestionale, non ne parla più in riunione — perché parlarne significherebbe ammettere che la scelta è stata sbagliata.
E il fondatore, 68 anni, ha una frase che ripete ogni volta che qualcuno accenna al problema: “Ormai abbiamo speso troppo per fermarci adesso.”
Quella frase è la più costosa che un imprenditore possa pronunciare. E la sento in media una volta al mese.
In questo articolo trovi: perché i progetti digitali nelle aziende familiari diventano immortali anche quando sono clinicamente morti, i cinque segnali concreti che il tuo progetto ha superato il punto di non ritorno, il meccanismo psicologico e organizzativo che impedisce di fermare, e soprattutto i criteri per decidere — prima di partire e quando sei in mezzo — se continuare o tagliare. Criteri che puoi usare lunedì mattina.
Perché le aziende familiari non riescono a fermare un progetto digitale fallito
In finanza comportamentale si chiama sunk cost fallacy: la tendenza a continuare a investire in qualcosa perché “abbiamo già speso troppo per fermarci.” È un errore cognitivo (bias) studiato e documentato. Ma nelle aziende familiari diventa qualcosa di più potente e pericoloso — diventa un fatto personale e una questione di Leadership.
Il progetto ERP lo ha voluto il figlio. Il CRM lo ha scelto il fondatore su consiglio del suo amico imprenditore.
L’eCommerce B2B lo ha spinto il direttore commerciale che si è esposto in riunione davanti a tutta la famiglia. In un’azienda familiare, ogni decisione tecnologica porta il nome e la faccia di qualcuno. Fermarlo non significa “chiudere un progetto che non funziona” — significa dire a quella persona, in quel sistema di relazioni familiari e aziendali, che ha sbagliato.
Ed è esattamente qui che il meccanismo si inceppa.
Il fondatore non ferma il progetto del figlio perché non vuole delegittimarlo davanti al team. Il figlio non ferma il progetto del padre perché non vuole sembrare quello che critica. Il direttore non alza la mano perché il suo contratto si rinnova tra sei mesi. Il fornitore non dice “fermiamoci” perché ogni mese in più è fatturato. E il commercialista, che vede i numeri e capisce che qualcosa non va, non ha gli strumenti tecnici per dire cosa esattamente.
Risultato: il progetto continua. Non perché qualcuno ha analizzato i dati e ha deciso che vale la pena andare avanti. Ma perché nessuno ha il potere, il coraggio o i criteri per dire “basta.”
Ho visto questo schema ripetersi in aziende di manifattura, distribuzione, servizi, food & beverage. Settori diversi, dimensioni diverse, stesso meccanismo: l’assenza di criteri di stop-go predefiniti, combinata con le dinamiche relazionali delle aziende familiari, produce progetti con tempistiche indefinite.
Progetti che nessuno usa, che nessuno difende, ma che nessuno uccide.
Il costo nascosto di un progetto digitale che non muore
Prima di parlare di come fermare, parliamo di quanto costa non fermare. Perché il danno di un progetto zombie non è solo il budget che brucia — è tutto quello che quel budget avrebbe potuto fare.
Il costo diretto è il più visibile: i soldi che continui a versare al fornitore, le ore del team interno dedicate a un sistema che non andrà in produzione, le personalizzazioni aggiuntive che vengono richieste ogni trimestre. Nell’esempio del mio cliente in Veneto, i 92.000 euro aggiuntivi rispetto al budget non erano il vero problema.
Il vero problema era il costo-opportunità. Quattordici mesi in cui l’azienda non ha lavorato su: l’integrazione dei dati commerciali che il direttore vendite chiedeva da due anni, l’automazione dei processi di magazzino che avrebbe liberato tre persone da attività manuali, la business intelligence minima che avrebbe permesso di vedere i margini per cliente. Quattordici mesi in cui l’attenzione del management era assorbita da un progetto che non produceva valore.
C’è poi un costo ancora più subdolo: l’erosione della fiducia.
Quando un progetto digitale fallisce — o peggio, quando continua a zoppicare senza che nessuno lo fermi — l’intera organizzazione impara una lezione tossica: “Il digitale qui non funziona.”
Questo crea una resistenza passiva che avvelena qualsiasi iniziativa futura.
Il prossimo progetto, anche se ben pensato, partirà con il peso di quello che è andato storto prima.
Le persone penseranno “ecco, un altro progetto che finirà come l’ERP” — e avranno ragione di pensarlo, perché l’azienda non ha mai dimostrato la capacità di fermare ciò che non funziona.
Nell’era dell’AI, questo costo nascosto diventa ancora più grave.
Le aziende che oggi hanno progetti digitali zombie — ERP incompiuti, CRM mai adottati, eCommerce che non convertono — sono le stesse che domani dovranno decidere su progetti AI. E lo faranno con la stessa assenza di criteri, le stesse dinamiche relazionali, lo stesso terrore di fermare. Solo che i progetti AI si muovono più velocemente, costano di più in fase esplorativa, e producono risultati ancora più difficili da misurare per chi non ha governance.
I cinque segnali che il tuo progetto digitale è morto (anche se nessuno lo ammette)
Dopo oltre cento interventi in azienda, ho identificato cinque segnali ricorrenti. Non ne basta uno — ma se ne riconosci almeno due, il progetto è in terapia intensiva e serve una decisione urgente.
1. Nessuno sa dire a che punto siamo — davvero
Fai questa prova: chiedi al fornitore e al referente interno, separatamente, “a che percentuale di completamento siamo?” Se le risposte differiscono di più del 20%, il progetto non ha milestone condivise. E senza milestone condivise non esiste progresso misurabile — esiste solo l’opinione del fornitore che dice “siamo quasi a posto” e la sensazione interna che “qualcosa non torna.”
Il meccanismo è semplice: quando un progetto ha obiettivi chiari e misurabili, tutti sanno dove siamo. Quando non li ha, il fornitore può spostare il traguardo ogni volta che lo raggiunge quasi. “Abbiamo completato la migrazione dati” diventa “abbiamo completato la migrazione dati, ma serve una fase di pulizia.” Che diventa “la pulizia è fatta, ma servono personalizzazioni per il vostro caso specifico.” Ogni traguardo genera il successivo, e il progetto non finisce mai.
2. Il perimetro è cambiato e nessuno ha formalizzato il cambiamento
Il progetto ERP doveva coprire amministrazione e magazzino. Adesso include anche la gestione commesse, il portale clienti e “un pezzo di CRM perché tanto è integrato.” Il budget non è stato ricalcolato. I tempi non sono stati ridefiniti. Nessun documento aggiorna il perimetro approvato.
Questo si chiama scope creep — ed è la prima causa di morte dei progetti digitali nelle PMI. Non perché il perimetro si allarghi, che è fisiologico, ma perché si allarga senza una decisione formale. Ogni aggiunta sembra piccola. “Aggiungiamo anche questo, tanto ci siamo.” Ma dieci aggiunte piccole sommano un progetto completamente diverso da quello approvato, con costi e tempi che nessuno ha stimato.
3. Il fornitore chiede tempo, non offre piani
“Ci servono ancora due mesi.” Se questa frase arriva senza un piano dettagliato — cosa faranno in quei due mesi, con quali risorse, verso quale risultato verificabile — non è una richiesta di tempo. È una richiesta di fiducia cieca. E la fiducia cieca, nel rapporto con i fornitori digitali, è il primo passo verso il disastro.
Un fornitore serio, quando il progetto è in difficoltà, arriva con un documento: ecco cosa non ha funzionato, ecco cosa proponiamo, ecco il piano rivisto con date e deliverable verificabili, ecco cosa chiediamo da voi. Un fornitore che ha perso il controllo arriva con: “Dateci ancora un po’ di tempo.” La differenza tra i due non è la competenza tecnica — è l’accountability.
4. Le persone interne hanno smesso di partecipare
Il responsabile amministrativo non viene più alle riunioni di avanzamento. I commerciali non testano il modulo vendite. Il magazziniere a cui hanno chiesto di validare i flussi dice che “lui fa il suo lavoro e basta.” Quando le persone che dovrebbero usare il sistema si disimpegnano, il progetto ha perso la sua ragione d’essere.
E il meccanismo è circolare: le persone si disimpegnano perché vedono che il progetto non funziona. Il progetto non funziona perché le persone si disimpegnano. Nessuno rompe il cerchio perché rompere il cerchio significherebbe escalare il problema — e nelle aziende familiari escalare significa parlare con il titolare, che è quello che ha voluto il progetto.
5. Non esiste un owner del risultato
Chiedi: “Chi è responsabile del successo di questo progetto?” Se la risposta è “il fornitore”, hai un problema. Se la risposta è “il team IT”, hai un problema. Se la risposta è un silenzio imbarazzato, hai la conferma.
Un progetto digitale senza un owner interno — non un project manager di processo, ma una persona dell’azienda che risponde del risultato e ha l’autorità per prendere decisioni — è un progetto orfano. E i progetti orfani non finiscono mai: diventano terra di nessuno dove il fornitore decide la direzione e l’azienda paga il conto.
Il vero problema: l’assenza di criteri decisionali prima di partire
Ecco il punto su cui prendo una posizione netta, scomoda, e che ripeto in ogni intervento.
Il progetto in Veneto non è fallito quando il budget ha superato il 100% del previsto. Non è fallito quando il responsabile amministrativo ha smesso di partecipare. È fallito il giorno in cui è partito — perché è partito senza criteri di stop-go, senza un owner del risultato, senza un perimetro scritto e firmato, senza una cadenza decisionale che prevedesse il momento in cui qualcuno dice “i numeri non tornano, fermiamoci e rivalutiamo.”
Questo è il meccanismo che vedo ripetersi ovunque: le aziende investono settimane nella scelta del fornitore e zero minuti nella definizione delle regole del gioco. Scelgono il software, firmano il contratto, partono — e poi si trovano senza strumenti quando le cose vanno storte. Non hanno definito i KPI di avanzamento. Non hanno stabilito le soglie oltre le quali si attiva una revisione. Non hanno nominato qualcuno con l’autorità di dire “fermiamo tutto.”
Il fornitore non ha nessun incentivo a proporre queste regole. Ogni criterio di stop-go è un potenziale ostacolo al suo fatturato. Non per malafede — per struttura. Il modello di business di una software house o di un system integrator prevede che il progetto duri il più possibile, che ogni criticità generi un’estensione, che ogni problema diventi un’opportunità di upsell. Non servono cattive intenzioni: bastano gli incentivi sbagliati.
E l’imprenditore non ha le competenze interne per costruire queste regole da solo. Sa governare la produzione, sa leggere un bilancio, sa gestire clienti e fornitori nel suo settore. Ma su tecnologia e digitale opera in un’asimmetria informativa strutturale — il fornitore sa più di lui, e nessuno gli ha mai dato i criteri per valutare.
Ecco perché il problema non è mai il progetto in sé. È il sistema decisionale dell’azienda su Digital e AI. Un’azienda che sa decidere — che ha criteri, governance, owner, cadenza — può fermare un progetto fallito a tre mesi e ripartire con regole diverse. Un’azienda che non sa decidere si ritrova a quattordici mesi con il doppio del budget e nessuno che alza la mano.
Come fermare un progetto digitale senza distruggere valore
Fermare non significa buttare. Questo è il primo errore concettuale che blocca gli imprenditori. “Se fermiamo abbiamo buttato tutto” è falso — ma sembra vero quando non hai criteri per separare ciò che è recuperabile da ciò che non lo è.
Congela prima di tagliare
La prima azione non è chiudere il contratto. È congelare: sospendere le attività, fermare la fatturazione, e prendersi 2-3 settimane per una valutazione a freddo. Il congelamento toglie la pressione emotiva — nessuno sta “uccidendo” niente, si sta solo facendo una pausa strutturata.
In queste 2-3 settimane fai tre cose: un inventario di ciò che è stato prodotto e funziona, un’analisi di ciò che è stato personalizzato e non è portabile, e una stima di quanto costerebbe completare rispetto a quanto costerebbe ripartire. Spesso la risposta sorprende: completare costa più di ripartire, perché il debito tecnico accumulato da mesi di sviluppo senza direzione rende il codice esistente più un ostacolo che un asset.
Separa la decisione di fermare dalla decisione di cosa fare dopo
Questo è cruciale. L’errore più comune è trasformare la discussione “dobbiamo fermare?” nella discussione “e poi cosa facciamo?” — che è un modo elegante per non fermare mai, perché finché non hai un’alternativa chiara, continuare sembra l’unica opzione.
Prima ferma. Poi, con calma e con i dati in mano, decidi se ripartire con lo stesso fornitore e regole diverse, con un fornitore nuovo, con un approccio completamente diverso, o se il progetto in sé non serviva.
Costruisci le regole per il prossimo progetto
Il valore più grande che puoi estrarre da un progetto fallito non è il codice o le personalizzazioni — è l’esperienza di cosa è andato storto. Ogni progetto fermato deve produrre un documento di due pagine: cosa non ha funzionato, perché, e quali regole servono per evitare che succeda di nuovo.
Queste regole diventano il protocollo per il progetto successivo: perimetro scritto e firmato, owner nominato con autorità decisionale, KPI di avanzamento misurabili mensilmente, soglie di stop-go predefinite (budget +30%, tempi +60 giorni, adozione interna <40%), cadenza decisionale con date fisse in cui si guarda lo stato e si decide se continuare.
Nell’era AI, i criteri di stop-go sono ancora più urgenti
Tutto quello che ho descritto sui progetti ERP, CRM, eCommerce vale il doppio per i progetti AI. L’AI aggiunge tre complicazioni: i risultati sono più difficili da misurare, i fornitori vendono aspettative ancora più inflazionate, e il costo di un progetto AI che deraglia è spesso invisibile perché si distribuisce su licenze mensili, ore di data engineering e consulenze di “AI strategy” che non producono niente di operativo.
Un imprenditore che oggi lancia un progetto AI senza criteri di stop-go è nella stessa identica situazione del mio cliente veneto con l’ERP — solo che il ciclo sarà più veloce e più costoso. L’AI amplifica ciò che c’è: se c’è governance, amplifica il valore. Se c’è caos decisionale, amplifica il caos.
Il criterio che do ai miei clienti è semplice: prima di firmare qualsiasi contratto per un progetto AI, rispondi a queste domande. Qual è il risultato misurabile atteso entro 90 giorni? Chi è l’owner interno con autorità di stop? Quali dati servono e sono pronti oggi? Qual è la soglia oltre la quale fermiamo e rivalutiamo? Se non sai rispondere a tutte e quattro, non sei pronto a partire — non importa quanto il fornitore sia convincente o quanto l’AI sembri urgente.
Il criterio che puoi usare lunedì mattina
Prendi il progetto digitale più grande che hai in corso adesso. Quello che ti preoccupa, quello che costa più del previsto, quello di cui si parla meno in riunione. E rispondi a queste cinque domande:
- Chi è l’owner del risultato — nome e cognome?
- Le milestone dei prossimi 90 giorni sono scritte e condivise con il fornitore?
- Il budget attuale è entro il 30% del budget approvato?
- Il team interno sta usando attivamente il sistema o partecipando ai test?
- Il fornitore ha un piano scritto con date e deliverable verificabili?
Se hai risposto “no” a due o più domande, hai un progetto in terapia intensiva.
Non significa che devi fermarlo domani — significa che devi prendere una decisione, e hai bisogno di criteri per farlo. Quei criteri non te li darà il fornitore, perché non è nel suo interesse. Non te li darà il team interno, perché non ha gli strumenti. Li devi costruire tu — o trovare qualcuno che non vende niente e ti aiuti a vederci chiaro.
La capacità di fermare un progetto che non funziona è più importante della capacità di avviarne uno nuovo. Perché avviare è facile — tutti sanno firmare un contratto. Fermare richiede criteri, coraggio e governance. E sono le aziende che sanno fermare quelle che alla fine vanno più veloci.
Domande frequenti
Quando è il momento giusto per fermare un progetto digitale?
Il momento giusto è quando almeno due dei cinque segnali descritti in questo articolo sono presenti contemporaneamente: assenza di milestone misurabili, perimetro cambiato senza decisione formale, fornitore che chiede tempo senza piano, disimpegno del team interno, mancanza di un owner del risultato. La regola pratica: se non riesci a spiegare in tre frasi a che punto è il progetto e qual è il prossimo traguardo verificabile, sei già in ritardo nel prendere una decisione.
Come si definiscono i criteri di stop-go prima di iniziare un progetto?
I criteri di stop-go si stabiliscono in fase contrattuale, prima di firmare con il fornitore. Includono quattro elementi: soglia di budget (tipicamente +30% rispetto al previsto), soglia di tempo (tipicamente +60 giorni rispetto al cronoprogramma), soglia di adozione interna (il team deve raggiungere almeno il 40% di utilizzo entro la fase pilota), e cadenza di revisione (una data fissa, mensile o bimestrale, in cui si guardano i numeri e si decide formalmente se continuare). Questi criteri vanno scritti, firmati da entrambe le parti, e rivisti a ogni milestone.
Il fornitore può opporsi alla decisione di fermare il progetto?
Il fornitore non ha il diritto di opporsi se i criteri di stop-go sono stati definiti contrattualmente. Se non lo sono — e nella maggior parte dei progetti nelle PMI non lo sono — la situazione è più complessa. Il fornitore ha un legittimo interesse economico a continuare, e senza criteri predefiniti ogni discussione diventa una negoziazione al buio. Per questo è fondamentale definire le regole prima di partire: non per diffidenza verso il fornitore, ma per avere un linguaggio comune quando le cose si complicano.
Come si recupera il valore da un progetto fermato?
Un progetto fermato produce tre tipi di valore recuperabile: gli asset tecnici utilizzabili (dati migrati, configurazioni completate, integrazioni funzionanti), la conoscenza acquisita dal team interno (che ha imparato cosa non funziona e perché), e il documento di lezioni apprese che diventa il protocollo per il progetto successivo. La fase di congelamento — 2-3 settimane di pausa strutturata — serve proprio a catalogare questi asset prima di prendere qualsiasi decisione su come procedere.
