Il progetto è finito. Il software è online. Tutti festeggiano. L’imprenditore respira: “Abbiamo fatto”. E poi, tre mesi dopo, scopre che il sistema viene usato al 30% della sua capacità. I commerciali continuano con Excel. Le integrazioni non funzionano. Nessuno sa come gestire i dati. Il vendor ha chiuso il progetto e non risponde più.
Questo è il sintomo che più ricorre nelle aziende: confondere il go-live con il traguardo. Ma il go-live non è la fine del percorso. È il momento in cui il vero lavoro comincia.
Go-live è il primo giorno di un’operazione, non l’ultimo giorno di un progetto
Questo malinteso nasce da una decisione strutturale: tutto il budget, l’attenzione e la governance si concentrano sulla costruzione del sistema. Zero su quello che succede dopo. Il vendor viene pagato per consegnare “un software funzionante”. Una volta che l’applicazione si accende, il contratto è tecnicamente chiuso. La responsabilità finisce.
Ma la realtà è questa: un software non vive perché è stato costruito bene — vive perché viene usato bene. E l’adozione non è automatica. Richiede un piano parallelo: cambiamento organizzativo, addestramento, incentivi, governance, manutenzione, evoluzione.
Approfondisci: Quando fermare un progetto digitale
La conseguenza sistemica è sempre la stessa: il costo vero del software non si vede nel primo anno — si vede nei tre anni seguenti, quando il sistema non rende, consuma risorse interne per essere mantenuto, e alla fine viene dismesso. Risultato: bruciati soldi sul deployment e nessun valore generato.
Il problema reale: il piano del progetto termina dove dovrebbe iniziare
Quando guardo un project management plan vedo quasi sempre questa struttura:
- Fase 1: Discovery e analisi → 2 mesi
- Fase 2: Design e configurazione → 3 mesi
- Fase 3: Build e testing → 4 mesi
- Fase 4: Deployment e go-live → 1 mese
- Fine.
Manca completamente la Fase 5: l’operazione sostenibile.
Cosa significa? Nel momento in cui il software si accende, non c’è:
- Un piano di adozione: chi usa il sistema quando, con quale processo, con quale competenza, con quale incentivo
- Una struttura di support: chi risponde agli utenti, chi risolve i problemi operativi, chi gestisce i dati, chi mantiene la configurazione aggiornata
- Una governance post-go-live: come e quando vengono prese decisioni su evoluzioni, manutenzione, integrazioni
- Un modello economico: come si distribuisce il costo di gestione, chi lo paga, quale è il ritorno atteso, come si misura
Risultato: il vendor se ne va il giorno del go-live. Il progettista che ha disegnato il sistema non c’è più. L’azienda resta con un sistema nuovo e nessuno che sappia come governarlo.
La decisione sbagliata: minimizzare il costo visibile ignorando il costo occulto
La decisione implicita qui è semplice e devastante: “Vogliamo il software al costo minore, nel tempo minore. Quello che succede dopo è un problema nostre o del software”.
Non è una decisione consapevole — è una decisione inconsapevole, guidata da incentivi disallineati.
- Il CFO: vuole il progetto finito, il budget chiuso, le spese ferme. Il go-live è il momento in cui il progetto scompare dal budget annuale.
- Il vendor: viene pagato per consegnare un software funzionante entro una data. Dopo quella data, non è suo problema se viene usato.
- Il CIO o il responsabile IT: è occupato a gestire l’infrastruttura e i problemi urgenti. L’adozione è un “soft skill problem” che riguarda le persone, non il tecnologico.
- L’utente finale: non è stato coinvolto nel design, non sa come il sistema cambia il suo lavoro, non ha incentivo a usarlo finché l’azienda non lo obbliga.
Questo disallineamento significa che nessuno è proprietario della sostenibilità operativa. E quando il sistema non vive, tutti dicono: “Era il software sbagliato” o “La gente non lo sa usare”.
Perché succede: tre meccanismi ricorrenti
1. Il project management scambia il go-live con il successo
Nel linguaggio del project management, “successo” significa: budget rispettato, scadenza rispettata, qualità tecnica rispettata. Consegnato e firmato. Tutto questo accade al go-live.
Ma il successo vero di un investimento digitale non è “software consegnato” — è “valore generato”. Valore significa: i processi sono più veloci, i dati sono affidabili, le persone prendono decisioni migliori. Queste cose succedono dopo il go-live.
Il project management storico non è disegnato per misurare questo. Quindi il progetto finisce e nessuno traccia cosa succede dopo.
2. L’adozione è un costo, non una responsabilità
Nel budget del progetto, l’adozione — se c’è — è una linea di “change management”: 5-10% del costo totale. Training, comunicazione, incentivi. Giusto?
No. Perché l’adozione non è una fase che finisce. È il contesto continuativo in cui il sistema vive. Se non la disegni come operazione permanente, non avviene.
3. Il vendor ha incentivi disallineati
Il vendor viene scelto e pagato per consegnare un progetto. Raramente viene retribuito per il valore generato nei 24 mesi dopo il go-live. Quindi il suo incentivo è: consegnare in tempo, chiudere il contratto, lasciare il cliente con una soluzione stabile ma non necessariamente performante.
Se il cliente vuole evolvere il sistema, toccare i dati, integrare altre applicazioni — tutti costi aggiuntivi per il vendor, fuori dal contratto originale. Il vendor ha incentivo a non facilitare questo.
Il criterio replicabile: come giudicare un piano di progetto
Ecco la domanda che dovresti fare PRIMA di iniziare un progetto:
“Nel vostro piano di progetto, cosa succede dopo il go-live? Chi è proprietario della sostenibilità? Come misurate il valore nei 12 mesi successivi?”
Se la risposta è vaga — “Vedremo”, “Quello è un problema dei gestori del sistema”, “Il vendor fornisce supporto” — non hai un piano. Hai una mezza promessa.
Un piano serio ha questa struttura:
- Go-live day: il sistema è online e affidabile
- Mesi 1-3 post go-live: supporto intenso, bug fixing, training, adozione accelerata
- Mesi 3-12: operazione stabile, KPI di utilizzo tracciati, evoluzione pianificata
- Proprietario di outcome: una persona — interna o esterna — che risponde del valore generato
- Modelo economico: chi paga il supporto, chi lo fornisce, come vengono finanziate le evoluzioni
Se il tuo piano non ha questa struttura, il progetto è già fallito. Non al go-live — ma prima.
Cosa smettere di fare
- Smettere di vedere il go-live come il traguardo: è il primo giorno di un’operazione, non l’ultimo di una costruzione.
- Smettere di progettare in isolation: il vendor disegna il sistema, l’azienda lo implementa, nessuno ne governa l’operazione. Occorre un ruolo di “regia” — interno o esterno — che rappresenti l’interesse del cliente nella fase post-go-live.
- Smettere di minimizzare l’adozione nel budget: se l’adozione è il 5-10% del progetto, il valore non accade. Deve essere il 20-30%, concentrato nei 12 mesi post-lancio.
- Smettere di usare contratti “fixed price” senza clausole di valore: il vendor dovrebbe avere un incentivo di “retention” — parte della fee dipende dall’utilizzo del sistema a 3, 6, 12 mesi.
La regola finale
Se il piano del progetto finisce al go-live, non è un piano — è una mezza promessa. Un piano vero specifica cosa accade nei 24 mesi dopo, chi ne è proprietario e come si misura il successo. Tutto il resto è costruzione, non strategia.
Leggi anche
- Quando fermare un progetto digitale
- Il progetto che cambia scope ogni mese
- Hai comprato il software sbagliato?
- Dati ovunque, informazioni da nessuna parte
Domande frequenti
Cosa succede dopo il go-live di un progetto digitale?
Il go-live è l’inizio, non la fine. Dopo il lancio servono almeno 90 giorni di monitoraggio attivo: adozione da parte degli utenti, bug fixing, formazione, e misurazione dei KPI reali.
Perché i progetti digitali falliscono dopo il lancio?
Perché nessuno ha pianificato la fase post-lancio: adozione, manutenzione, evoluzione. Il budget finisce al go-live, ma il valore si genera dopo.
Come pianificare il post go-live?
Prevedere nel budget iniziale almeno il 20-30% per i primi 6 mesi dopo il lancio. Definire KPI di adozione, assegnare un owner interno, e pianificare cicli di feedback con gli utenti.
