Ci sono un commerciale, un amministrativo, un responsabile IT e un software developer che parla solo un inglese sgangherato. Tutti parlano, ma nessuno si capisce. Che cos'è?
Una barzelletta? No, un caso che ho seguito e che mi ha lasciato un insegnamento prezioso che oggi voglio condividere con voi.
Nel 2023, venivo ingaggiata da una grossa società di logistica italiana per supportarli nella migrazione del database commerciale della distribuzione. La missione sembrava semplice: spostare 13.000 contratti da un software ad un altro. Analizzi la base dati, definisci delle regole di porting, sviluppi le integrazioni, esporti i contratti et voilà, les jeux sont faits.
Mai mi sarei aspettata lo scenario che emerse durante il lavoro.
Un progetto fermo da tre anni
Il progetto era sponsorizzato e coordinato dal dipartimento amministrativo, che presiedeva la correttezza delle operazioni: si preoccupavano che le tariffe girassero nel modo corretto e rimettevano in riga i commerciali dalla tariffa creativa.
I commerciali erano la memoria storica. Sapevano vita, morte e miracoli dei contratti. Come erano stati scritti, da chi, secondo quali logiche — o illogicità. Conoscevano le travagliate vicende del progetto e tutte le inefficienze del software di partenza che assolutamente non volevano vedere replicate in quello di arrivo. La loro richiesta di requisiti era: minimo sforzo, massima resa.
Poi c'era il dipartimento IT, un circolo ermetico che cercava di interpretare le arcane richieste dello SDI, facendo sì che API e integrazioni trasferissero i dati corretti al fisco italiano (per capirci, che non arrivasse una fattura da 10.000.000 invece che da 1.000).
E poi il dipartimento Processi: un team eterogeneo, che si ergeva come un baluardo di coraggio, pazienza e un certo spirito di improvvisazione tra una realtà aziendale complessa e un fornitore di Andorra dalle dubbie capacità linguistiche che non sapeva nemmeno cosa fosse lo SDI, la marca da bollo o una lettera d'intento. Una situazione a metà tra Captain America e le Wacky Races.
Il risultato: il progetto era incagliato da tre anni, i rapporti erano logorati e la speranza di vederlo realizzato era sempre più fievole.
La prima regola del consulente: chiedi e ti sarà dato
La prima cosa che ho fatto per scogliere questo intricato bandolo interdipartimentale non è stato guardare i KPI, ma fare domande.
Ho dedicato i primi mesi a chiedere, capire, studiare e interrogare qualunque stakeholder coinvolto nel progetto.
Ogni commento, ogni frase, ogni documento mi dava un pezzo della storia, di cosa era andato storto, della prospettiva di ciascuna delle parti coinvolte: qual era la visione con cui il progetto era iniziato, cosa ciascun dipartimento desiderava ottenere, cosa funzionava e cosa non funzionava secondo gli utenti che utilizzavano quello strumento tutti i giorni.
E il quadro ha cominciato a prendere forma.
Alcune richieste si sovrapponevano, altre erano contrastanti. Altre ancora erano il frutto della visione individuale di un singolo utente: legittime, ma non traducibili automaticamente per gli altri.
E una volta raccolto il mio cahier des doléances (l’inventario delle richieste degli utenti), ho semplicemente tradotto.
Le esigenze degli amministrativi e dei commerciali in logica di business. La logica di business in specifiche tecniche. Le specifiche tecniche in istruzioni che il fornitore potesse eseguire — a volte aprendo il codice insieme, riga per riga.
E come per magia, il progetto ha ricominciato a girare.
Questo non è un problema IT
A vostro parere il problema del progetto, era tecnico o di altra natura?
Spoiler: era comunicativo.
Ciascuna parte guardava il progetto dal proprio angolo, concentrandosi sul problema e sulla difesa della propria posizione con la stessa energia che avrebbe potuto impiegare per trovare soluzioni. Il commerciale contro l'amministrativo. L'IT contro il fornitore. Tutti contro tutti, con il progetto fermo nel mezzo.
E la dimostrazione sta nel fatto che i primi successi hanno cominciato ad arrivare non quando qualcuno ha vinto, ma quando tutti hanno smesso di stare uno di fronte all'altro e hanno cominciato a lavorare verso un obiettivo comune.
Come si applica alla consulenza
Questo switch mentale in consulenza è la chiave per portare a termine qualsiasi progetto, anche con i clienti più ostili.
In vendita? Voi e il cliente contro le obiezioni sul prezzo, sul “momento giusto”, sulla novità della soluzione.
Nell’erogazione del servizio? Voi e il cliente contro il problema, il bias, la disabitudine, l’inesperienza, la malainformazione, la circostanza avversa.
Nella crisi del rapporto con il cliente? Voi e il cliente contro l’incomprensione tra di voi.
Questa è intelligenza emotiva e comunicazionale applicata alla consulenza. Non è una "soft skill", è una competenza strategica, essenziale per garantire la retention del cliente e il successo di progetti complessi. Ed è esattamente quello su cui lavoro con i professionisti che seguono il Metodo LMB, aiutandoli a strutturare un’attività di consulenza stabile, longeva, riconosciuta e di successo.
Se hai un cliente che non avanza, una partnership che si è arenata o una trattativa che gira in tondo parliamone in una call.
A volte basta cambiare prospettiva per vedere cosa c'è davvero nel quadro.