Quando come software engineer / consulente / tecnico avrai interiorizzato che il tuo lavoro NON è quello di scrivere codice, ma di portare benefici di business, allora avrai fatto un passo avanti nella tua carriera.
Tu sai portare benefici a un business scrivendo codice / facendo architetture software (e questo è fondamentale per te), ma al cliente, in fondo… che gliene frega? Il cliente vuole benefici di business.
Dal libro “Selling to Big Companies” ho estratto la lista dei benefici di business da spulciare e usare come checklist quando si presenta un progetto (scegliendo quelle rilevanti, ovviamente):
- Aumento dei ricavi o della redditività
- Riduzione del time-to-market
- Riduzione dei costi
- Miglioramento dell’efficienza operativa
- Integrazione delle operazioni a livello globale
- Rivitalizzazione dell’organizzazione
- Rafforzamento della fedeltà dei clienti
- Riduzione del turnover dei dipendenti
- Miglioramento della fidelizzazione dei clienti
- Aumento della differenziazione competitiva
- Riduzione del tempo di risposta
- Riduzione delle spese operative
- Aumento delle vendite per cliente
- Miglioramento dell’utilizzo degli asset
- Accelerazione della riscossione dei crediti
- Riduzione del costo del venduto
- Minimizzazione del rischio
- Flussi di ricavo aggiuntivi
- Aumento della quota di mercato
- Miglioramento del time-to-profitability
- Aumento delle ore fatturabili
- Riduzione del tempo di ciclo
- Aumento della rotazione dell’inventario
- Accelerazione dei cicli di vendita
- Riduzione dei costi di manodopera diretta
That’s it. Non ne esistono altri. Tutto il resto è rumore. Tutto il resto è “cose tecniche” che non interessano al cliente.
Prendi questa lista, copia-incollala, metti questa pagina nei preferiti e ogni volta che devi presentare un progetto, prima di farlo, spunta le voci che il tuo progetto porterà come benefici di business. E se non ne trovi nemmeno una, allora forse il progetto non vale la pena di essere fatto.