Il progetto era previsto per 6 mesi. Sono quasi 13. Il budget originale era 60 mila. Sei a 95. Il fornitore dice che siamo “molto vicini”. Tu aspetti. Ogni call aggiunge una complicazione nuova: dati da pulire, integrazioni che non conversano, feature che improvvisamente servono.
Nel frattempo, il vecchio sistema continua a funzionare. Non è bellissimo, ma funziona. Allora perché questo nuovo progetto te lo sta paralizzando?
Perché non lo fermi.
E non lo fermi per una ragione semplice: non hai mai definito, all’inizio, a quale condizione potrebbe arrivar il momento in cui dici “basta, non vale più la pena.” Quindi adesso stai in una nuvola grigia di “speriamo che finisca presto” e niente di più concreto.
Approfondisci: Il progetto che cambia scope ogni mese
Il sintomo: l’infinito burocratico
Il progetto diventa uno status quo invisibile. Esiste, consuma risorsa, ma non è più una decisione — è una circostanza.
Ogni week c’è un update. “La prossima settimana avremo il primo modulo live.” Non succede. “Fine mese, senza dubbio.” Fine mese arriva, c’è sempre una variabile non prevista. Dopo un po’, smetti persino di farci domande. È diventato normale.
Intanto accadono cose subdole: le persone che hanno iniziato il progetto se ne sono andate (turnover durante i 13 mesi). Il fornitore ha cambiato account manager. Non è chiaro più chi ha responsabilità di cosa. I numeri si sono persi. Se qualcuno chiedesse “quanto abbiamo speso finora e quanto ci serve ancora?” la risposta varierebbe a seconda di chi chiedi.
Nel frattempo, quello che doveva essere un miglioramento operativo (velocità, automazione, insight) è diventato un drenaggio di attenzione. Perché il vecchio sistema non muore mai del tutto. Devi mantenere entrambi.
Quando finalmente arriva il momento di prendere una decisione — fermare o continuare — scopri che non hai dati per deciderlo. Non hai un baseline. Non hai KPI. Non hai niente di misurabile su cui fondare il giudizio.
Il problema: assenza di stop-go criteria
Qui il meccanismo è nudo.
Avresti dovuto dire, il giorno 0, “Se accadono X condizioni, fermiamo. Se i numeri sono Y, continuiamo. Il checkpoint è ogni Z settimane e se non abbiamo fatto progresso visibile, riconsideriamo.”
Non l’hai detto. Nessuno l’ha detto. È implicito che “il progetto continua finché non è finito” — come se “finito” fosse una condizione certa, solo spostata nel tempo.
Ma il digitale non è così. I progetti digitali sono soggetti a scoperta progressiva. Man mano che costruisci, capisci che serve altro. Scope creep è quasi impossibile da evitare se non hai una struttura che lo contiene.
Senza stop-go criteria, il progetto ha inerzia infinita. Non per negligenza. Perché nessuno ha il diritto di fermare qualcosa che non ha criteri di arresto definiti.
5 segnali che dovrebbero scattare il campanello
Qui sotto i 5 rossi.
1. Timeline estesa di più del 50% dal piano originale.
Se era 6 mesi, sei a 9? È un giallo. Sei a 13? È un rosso. Chiedi: perché? E soprattutto, qual è la stima nuova di fine? Se il fornitore non riesce a darvi una data plausibile (non “speriamo di finire a giugno”, ma “abbiamo scoperto X, che aggiunge 8 settimane, quindi live il 20 giugno”), significa che non sa dove sta il traguardo.
2. Budget bruciato oltre il 20% in più senza nuova stima di completamento.
Se partite con 60 e siete a 75 senza una roadmap chiara, c’è un problema. Il fornitore o non sapeva quanto costava il lavoro all’inizio (incompetenza), o ha un incentivo a dilatare il progetto (conflitto). Entrambi richiedono una revisione seria della relazione.
3. Scope è aumentato di “poche piccole cose” non tracciabili.
“Abbiamo aggiunto questa integrazione, questo report, questa validazione di dati.” Piccole cose. Ma sommate fanno il 30% di lavoro extra. Se non è tracciato e non è documentato, è scope creep incontrollato. Il primo segnale è “non riconosco il perimetro che abbiamo firmato”.
4. Le persone iniziali sono cambiate e nessuno può spiegare il piano.
Il project manager che ha iniziato non c’è più. L’account manager è diverso. Il technical lead ha altri progetti. Quando non c’è continuità di responsabilità, il progetto è orphan. E i progetti orphan finiscono nelle sabbie mobili. Il test è semplice: fai una riunione con il vecchio e il nuovo team. Se le storie cambiano, hai un problema.
5. Il progetto è “quasi finito” da più di 3 mesi.
“La prossima spinta, live la prossima settimana” — ripetuto 8 volte. È il sintomo più chiaro che il perimetro è rotto e nessuno ha il controllo. Se senti questa frase due volte in fila, è time to escalate.
Decisione che non è stata presa: il diritto di fermare
Ecco cosa avresti dovuto decidere che non hai deciso.
“Se, al checkpoint X, il progetto non soddisfa questi criteri, abbiamo il diritto di fermare senza penalità (o con penalità minima definita).”
Questa non è una minaccia. È un sistema di governo. Fa bene sia a te che al fornitore: a te dà il diritto di arresto, a lui dà chiarezza su cosa lo salva.
Senza questa decisione, sei paralizzato dal sunk cost fallacy: “Abbiamo già speso 80, fermarsi ora significa perderli. Se continuiamo, almeno avremo un sistema nuovo.”
Ma non è vero. Continuare a spendere su un progetto che non ha perimetro non recupera i 80. Brucia altri 30.
Meccanismo: sunk cost + assenza di governance
Il sunk cost fallacy è psicologia umana: gli soldi già spesi diventano una ragione per spendere ancora. Logica economica: gli soldi spesi sono irrecuperabili, non dovrebbero influenzare la decisione su quello che faccio adesso.
La psicologia vince sempre sulla logica se non hai un sistema che la interrompe.
Un sistema che interrompe è una cadenza di revisione (ogni 4 settimane) con criteri chiari (scope, timeline, budget) e il diritto di escalare senza conseguenze per il decision maker che dice “stop”.
Senza questo, il progetto diventa una conversazione senza fine tra il fornitore che dice “quasi fatto” e te che dici “va bene, continua”.
Criterio: il business case a ogni checkpoint
A ogni revisione (che dovrebbe essere mensile, non trimestrale), fatti questo aggiornamento:
- Quanto è costato finora (numero preciso)
- Quanto costerà per finire (stima del fornitore)
- Qual è il valore atteso (ha un numero? Se è vago, è un segnale)
- Quanto sarebbe costato non fare il progetto (continuare col vecchio sistema)
- Qual è il ROI della situazione nuova rispetto a baseline
Se non riesci a rispondere a tre di queste cinque domande con numeri concreti, non hai il controllo del progetto.
E se il ROI è inferiore a quello del vecchio sistema, fermi.
È brutale, ma economicamente giusto.
Taglio: cosa smettere di fare
Smetti di ascoltare “quasi finito” come update. Finito o non finito, live o non live. Una cosa è quasi finita per 3 mesi, poi è indefinitamente in progress. Non è un numero che racconta la verità.
Smetti di negoziare tempo quando il scope è rotto. Se la roadmap non è chiara, estendere tempo è una pezza su un buco. Usa il tempo per capire il perimetro, non per continuare nel caos.
Smetti di avere riunioni di status su progetti senza decision rights definiti. Le riunioni di status senza la possibilità di decidere “fermiamo” o “rivediamo” sono solo performance di trasparenza. Non risolvono nulla.
Smetti di pensare che “il fornitore è bravo, gli diamo fiducia” sia governance. La fiducia è bene. Ma non è un sostituto della responsabilità. Anche i bravi fornitori, senza criteri e senza peso di conseguenze, tendono a dilatare i progetti.
La domanda finale
Se oggi dovessi fare una call con il tuo board e giustificare perché il progetto continua, quale sarebbe il numero che lo giustifica? Se non hai un numero, non hai una ragione. Hai inerzia.
Se il numero non è buono, non aspettare. Ferma. Il costo della decisione ora è minore del costo dell’attesa infinita.
Leggi anche
- Il progetto che cambia scope ogni mese
- Perché il go-live non è mai la fine
- Hai comprato il software sbagliato?
- Dati ovunque, informazioni da nessuna parte
Domande frequenti
Quando è il momento giusto per fermare un progetto digitale?
Quando il budget ha superato il 40% del previsto senza che il perimetro sia stato ridotto, quando il team non sa più qual è l’obiettivo originale, o quando nessuno riesce a dire cosa cambierà per il cliente finale.
Quali sono i segnali che un progetto digitale va fermato?
I 5 segnali principali: budget sforato senza revisione, scope che si allarga a ogni riunione, assenza di owner chiaro, fornitore che guida le decisioni, e nessun KPI di successo definito.
Come si ferma un progetto digitale senza perdere tutto?
Con uno stop-go formale: si congela il perimetro, si fa un assessment indipendente, si decide cosa tenere e cosa tagliare. Meglio perdere il 30% che bruciare il 100%.
