Oltre il 65% delle Iniziative Strategiche Non Raggiunge i Propri Obiettivi. Non Perché la Strategia Fosse Sbagliata.

Traducete ogni ambizione in blocker e success condition, e fate passare ogni success condition attraverso gli 8 domini di business prima di sequenziare qualsiasi cosa, Proposition Development, Process & Technology, Resources & Capabilities, Partners & Suppliers, Commercial Effectiveness, Value Communication, Customer Insights e Relationship & Retention. Sequenziare prima di questo passaggio produce solo un calendario plausibile ma basato su ipotesi mai confrontate con l'intero business, che è esattamente ciò che fa sgretolare le roadmap dopo pochi mesi.

Di solito è un problema di capacità, non di strategia, le roadmap sono costruite sulla capacità desiderata invece che sulla capacità reale, già impegnata, del team. Le persone che dovrebbero guidare una nuova iniziativa sono spesso le stesse che mantengono in funzione il business attuale, e una roadmap che non tiene conto di questo scontro si blocca appena il quotidiano si complica, cosa che accade quasi sempre prima del previsto.

Sequenziate per impatto, sforzo, dipendenze obbligatorie e quali azioni possono essere eseguite in parallelo nello stesso dominio, invece che per l'iniziativa con lo sponsor più vocale. Le dipendenze obbligatorie contano più di quanto riconosca di solito la maggior parte degli esercizi di prioritizzazione, un'iniziativa che sembra ad alto impatto e basso sforzo isolatamente può restare bloccata per mesi se dipende segretamente dal completamento di altre tre azioni.

Mappate le dipendenze esplicitamente durante la fase di roadmap teorica, prima di costruire qualsiasi business case, così la sequenza riflette ciò che deve davvero accadere prima e non ciò che sarebbe più comodo iniziare prima. Le dipendenze scoperte dopo che un business case è già costruito e dotato di risorse sono molto più costose da risolvere di quelle individuate quando la roadmap è ancora solo un esercizio di sequenziamento sulla carta.

Un responsabile, una scadenza, la capacità richiesta, le dipendenze e una definizione di completato per ogni singola azione, non solo un elenco di iniziative con scadenze approssimative. Una roadmap a cui manca uno qualsiasi di questi cinque elementi per azione non è davvero eseguibile; è una lista dei desideri con un design migliore, perché nessuno può essere ritenuto responsabile di consegnare qualcosa mai specificato con precisione sufficiente per verificarlo.

Assegnate un responsabile nella fase di sprint di sei settimane, quando ogni azione o cluster costruisce il proprio business case completo, non prima, quando l'azione è ancora troppo astratta perché qualcuno la possieda in modo significativo. Assegnare la proprietà troppo presto produce spesso una responsabilità vaga per un'azione vaga; aspettare la fase di business case significa che il responsabile eredita qualcosa di abbastanza concreto da doverne davvero rispondere.

Etichettate ogni azione come task, progetto o programma, aggiungete una stima di sforzo in giorni, settimane o mesi, e numerate le sequenze dove dipende da altre azioni, così la roadmap riflette scadenze realistiche invece che ottimistiche. La maggior parte dei ritardi nelle roadmap risale a stime di sforzo fatte senza questo livello di dettaglio, una riga d'azione di una sola frase può nascondere quantità di lavoro reale molto diverse a seconda della sua reale portata.

Consolidate la roadmap validata in un unico documento, dopo la revisione del consiglio, con responsabile, scadenza, capacità, dipendenze e definizione di completato per azione, così nessuno lavora con una versione leggermente diversa circolata tre settimane prima. Avere più versioni della roadmap in circolazione nell'organizzazione è una delle cause più comuni, e più evitabili, per cui i team lavorano silenziosamente verso priorità diverse.

Fate passare ogni success condition attraverso gli 8 domini di business; se un dominio ha zero azioni, o qualcosa viene trascurato o il target state è troppo ristretto in partenza. Una roadmap che non tocca mai, ad esempio, Partners & Suppliers o Customer Insights non è necessariamente sbagliata, ma vale la pena confermare esplicitamente che è una scelta di scope deliberata e non un punto cieco che nessuno ha notato.

Fissate l'ordine sequenziato della roadmap teorica, deriva dalle dipendenze, non da chi argomenta più forte quel trimestre per far salire la propria iniziativa in lista. Le priorità che cambiano costantemente di solito non rispondono a informazioni genuinamente nuove; rispondono a chi ha più capitale politico quel mese specifico, cosa a cui una sequenza basata sulle dipendenze è specificamente progettata per resistere.

Legate ogni azione a una success condition specifica, a sua volta legata a un'ambizione strategica specifica, così la catena dall'azione al risultato è tracciabile dall'inizio alla fine, e chiunque può chiedere perché esiste una data azione e ottenere una risposta diretta. Le iniziative che non possono essere tracciate così fino a un'ambizione sono di solito le prime candidate a essere eliminate silenziosamente quando la capacità scarseggia.

Probabilmente mancano business case reali, sforzo, risorse, rischio e un responsabile nominato trasformano un piano da intenzione a decisione, e una roadmap senza di essi è in realtà solo una lista di buone idee con cui nessuno si è ancora impegnato. Il divario tra una roadmap che sembra completa e una che davvero guida l'azione sta quasi sempre in questo livello di dettaglio operativo, non nella logica strategica.

Ogni sprint prende un'azione o cluster e la trasforma in un business case completo: sforzo, risorse, rischio, data di inizio, responsabile e definizione di completato, trasformando una riga della roadmap in qualcosa che un team può iniziare a eseguire dal primo giorno. Eseguire questi sprint in sequenza lungo la roadmap è ciò che trasforma la sequenza teorica basata sulle dipendenze in un insieme di pacchetti di lavoro reali, con risorse, proprietà e calendario.

Dettagliate lo sforzo esatto in tempo, denaro e persone, le risorse e competenze richieste, le condizioni di esecuzione, i rischi e le relative mitigazioni, la data di inizio, il responsabile e la definizione di completato, lo stesso rigore che un consiglio si aspetterebbe per una decisione di investimento di capitale, applicato a ogni iniziativa rilevante della roadmap e non riservato solo a una o due delle più grandi.

Eseguite un workshop di revisione della roadmap dove CEO e consiglio confrontano la roadmap teorica e quella fattibile, e adeguano la portata dei task e la priorità dei driver, l'ordine sequenziato in sé resta fisso, poiché deriva dalle dipendenze e non dalle preferenze. Ciò che il team esecutivo aggiusta davvero in questo workshop è la portata e le risorse, non la logica sottostante di cosa deve accadere prima di cosa.