C'è una riunione che mi torna in mente ogni tanto, e non perché sia stata particolarmente drammatica. Anzi, era andata benissimo. Slide curate, parole giuste, quel tono da "stavolta facciamo sul serio". Si parlava di trasformazione, di efficienza operativa, di futuro.
Tutti annuivano. Il budget era stato approvato.
Tre mesi dopo, di quel progetto non c'era più traccia.
Non è una storia rara. L'84% delle pmi italiane riscontra criticità nella realizzazione dei progetti digitali, e il 15,8% dichiara un fallimento completo. E a livello globale la musica è simile: circa l'84% delle iniziative di trasformazione digitale non raggiunge i risultati attesi, spesso per ragioni che con la tecnologia c'entrano poco.
Il punto, però, non è solo che i progetti falliscono. È che certi progetti nascono già morti. I segnali ci sono dall'inizio, solo che sono discreti, quasi educati. E se non sai dove guardare, li scambi per normale complessità.
Lo sponsor che “supporta da lontano” #
Il primo segnale è quello che sembra meno grave. Sulla carta, il progetto ha uno sponsor importante: titolare, direttore generale, qualcuno che “ci mette la faccia”.
Poi però quella faccia non la vedi mai.
Lo sponsor delega, manda un’email di endorsement, magari apre il kick-off con cinque minuti di discorso motivazionale. E dopo sparisce dalle riunioni operative, da quelle dove si sbloccano i nodi veri. Il risultato è abbastanza prevedibile: appena arriva la prima resistenza interna, vince la resistenza. Non perché sia più forte, ma perché è più paziente.
In molte PMI la resistenza non è nemmeno cattiveria. È routine, urgenza, “prima chiudiamo il mese”, “ne parliamo dopo la fiera”, “adesso non possiamo fermare il magazzino”. Se lo sponsor non è presente quando bisogna scegliere, il messaggio implicito è semplice:
Questo progetto può aspettare.
E le cose che possono aspettare, aspettano per sempre.
Non è solo una sensazione. Il 56% dei progetti di trasformazione digitale non riceve un supporto reale dalla leadership senior.
Obiettivi scritti con il copia-incolla #
“Migliorare l’efficienza”. “Ottimizzare i processi”. “Aumentare la competitività digitale”.
Quando leggo obiettivi così, mi viene sempre un dubbio: stanno descrivendo qualcosa che vogliono fare davvero, o stanno solo cercando una frase che suoni bene in un documento?
Il problema non è che siano falsi. È che non sono verificabili. Non ti aiutano a capire, tra sei mesi, se il progetto ha funzionato oppure no. E soprattutto non ti aiutano a decidere cosa fare domani mattina.
Una frase come “ridurre i tempi di evasione ordini del 30% entro sei mesi” cambia tutto. Ti costringe a scegliere un perimetro, a trovare un dato di partenza, a capire dove intervenire. “Digitalizzare i processi aziendali” invece è una nebulosa. Dentro ci sta tutto, e quindi non ci sta niente.
Non sorprende che il 64% dei progetti di digitalizzazione parta senza una roadmap chiara. Forse la causa principale è proprio questa difficoltà nel tradurre ambizioni generiche in obiettivi misurabili.
E poi c’è un effetto collaterale un po’ tossico: la vaghezza rende facile dichiarare successo senza aver combinato molto. Basta raccontarla bene.
Nessuno sa chi decide #
Questo segnale è subdolo, perché all’inizio sembra collaborazione. Tante persone coinvolte, tanti reparti invitati, tante opinioni raccolte.
Poi, quando arriva una decisione vera, nessuno sa chi ha l’ultima parola.
Chi approva le scelte tecnologiche? Chi risolve i conflitti tra commerciale e operations? Chi decide se accettare un cambio di scope proposto dal fornitore? Chi dice “ok, si fa così” quando due alternative sono entrambe scomode?
Se non c’è una risposta chiara, succede una cosa che ho visto ripetersi spesso: le decisioni non vengono negate, vengono rimandate. Si trasformano in loop di email, in riunioni che finiscono con “ci aggiorniamo”, in documenti condivisi pieni di commenti.
E il progetto non collassa in modo spettacolare. Si dissolve. Un po’ alla volta.
Anche qui, la letteratura è meno romantica di quanto vorremmo: una governance efficace richiede un referente interno capace di coordinare scelte tecnologiche, rapporti con i fornitori e monitoraggio dei risultati. Senza, il progetto resta senza direzione.
Lo stack scelto dal fornitore #
Questo è quello che mi mette più a disagio, forse perché è il più difficile da riconoscere quando sei dentro l’azienda.
Il fornitore arriva con una soluzione già pronta. Magari è anche una buona soluzione, nel suo contesto. Ma la propone come risposta naturale ai problemi dell’azienda, e l’azienda accetta perché non ha fatto un’analisi vera dei bisogni.
A volte succede per fretta. A volte perché “loro lo fanno da anni, sapranno cosa serve”. A volte perché nessuno internamente ha le competenze o il tempo per mettere in discussione la proposta.
Il risultato però tende a essere sempre lo stesso: si compra una tecnologia costosa che non si adatta ai processi esistenti, oppure li stravolge in un modo che l’organizzazione non è pronta ad assorbire.
La sequenza corretta sarebbe banale, eppure è rarissima: prima capisci cosa vuoi risolvere, poi scegli la tecnologia.
Quando lo stack è già stato deciso prima della prima riunione strategica, qualcosa non torna.
I KPI che non si possono misurare #
L’ultimo segnale spesso arriva quando ormai si è già speso tempo, energia, reputazione.
Si definiscono i KPI. Tutti sono contenti perché “almeno misuriamo”. Poi però nessuno si è chiesto una cosa molto semplice: i dati per misurarli esistono?
“Miglioramento della soddisfazione del cliente” è un KPI solo se hai un modo consistente per misurare la soddisfazione prima e dopo. “Riduzione dei costi operativi” funziona solo se sai quali costi stai guardando, e se li tracci in modo pulito.
Quando i KPI vengono definiti per rassicurare chi approva il budget, e non per guidare il progetto, diventano numeri elastici. E se un numero si può interpretare in mille modi, non dirà mai chiaramente che il progetto sta fallendo.
Sul tema c’è un punto interessante: a volte misurare diventa una specie di teatro, una pratica che sembra seria ma non cambia le decisioni.
Il PO: la figura che nessuno ha chiamato #
Se ci pensi, tutti e cinque questi segnali hanno qualcosa in comune. Non sono problemi tecnici. Sono problemi di chiarezza, responsabilità, comunicazione.
E c’è una figura che, almeno in teoria, nasce proprio per governare quel tipo di caos: il product owner.
In una PMI spesso nessuno ha tempo per fare la parte “noiosa” del progetto. Quella fatta di domande ripetute, definizioni, confini, priorità. Eppure è proprio lì che si decide se un progetto parte davvero.
Un PO non accetta “migliorare l’efficienza” come risposta. Insiste, magari anche troppo. Quale processo? Quale metrica? Da quando a quando? Chi ci mette le mani? Cosa cambia per le persone che oggi fanno quel lavoro in un certo modo?
Sul tema dello sponsor debole, il PO non può sostituire la leadership, e sarebbe ingenuo pensarlo. Però può renderla più efficace. Può preparare decisioni che costringono lo sponsor a scegliere tra opzioni concrete, invece di annuire davanti a presentazioni vaghe. In pratica riduce l’attrito cognitivo di chi dovrebbe guidare e spesso non sa da dove iniziare.
Sulla governance, il PO porta struttura quasi per definizione. Gestisce priorità, esplicita cosa è dentro e cosa è fuori, tiene traccia degli impegni. Non elimina la politica interna, ma la rende visibile, e già questo a volte cambia il gioco.
E sul tema dei fornitori, forse è la funzione più preziosa. Il PO si mette davanti al fornitore non come cliente ingenuo, ma come interlocutore che capisce cosa sta comprando. Sa distinguere una proposta costruita attorno alle esigenze dell’azienda da una costruita attorno al catalogo del fornitore.
Mi chiedo se il vero problema non sia che nelle PMI italiane questa figura venga ancora percepita come un lusso, qualcosa da grandi aziende o da startup finanziate. Io ho l’impressione opposta. Dove le risorse sono limitate e gli errori costano caro, avere qualcuno che fa le domande giuste all’inizio vale quanto non buttare via sei mesi su un progetto che, in fondo, non sarebbe partito comunque.
E forse la domanda più utile, prima ancora di scegliere un software, è questa: chi si prende la responsabilità di rendere il progetto reale, giorno dopo giorno? Se non c’è una risposta che suona credibile, forse conviene fermarsi lì. Non per cinismo, ma per rispetto del tempo di tutti.