Il modello RAPID è stato sviluppato daBain & Companye reso noto da Paul Rogers e Marcia Blenko. Distingue cinque ruoli — Recommend, Agree, Perform, Input e Decide — e insiste in particolare sulla presenza diun solo soggetto con la D, cioè con l’autorità finale di decidere. Le indicazioni originali raccomandano inoltre di limitare fortemente gli Agree, cioè i soggetti dotati di un effettivo diritto di veto.

Quando il problema non è decidere meglio, ma riuscire a decidere

Nelle organizzazioni contemporanee il problema non è sempre prendere decisioni migliori. Molto spesso è riuscire a prendereuna decisione, capire chi abbia realmente l’autorità per farlo e impedire che venga rimessa continuamente in discussione.

La crescita delle strutture a matrice, dei team cross-funzionali e dei modelli Agile ha aumentato le interdipendenze. Prodotto, tecnologia, operations, finance, legal, marketing e commerciale partecipano sempre più spesso alla stessa scelta.

È un’evoluzione necessaria: i problemi complessi richiedono prospettive differenti.

Ma quando partecipazione e autorità decisionale vengono confuse, la collaborazione può trasformarsi in paralisi.

È in questo spazio che RAPID offre una distinzione particolarmente utile. Non è una tecnica per trovare automaticamente la decisione corretta. È un modello per chiarire idiritti decisionali: chi formula la raccomandazione, chi deve essere ascoltato, chi possiede un effettivo diritto di veto, chi decide e chi esegue.

La sua intuizione più importante può essere sintetizzata così: collaborare non significa decidere tutti insieme.

Il costo invisibile dell’ambiguità decisionale

Immaginiamo una riunione di portfolio management. Sul tavolo c’è la scelta se interrompere un progetto digitale che ha già assorbito una parte significativa del budget ma continua a mostrare scarsa adozione.

Il responsabile di prodotto propone di interromperlo. IT ritiene che manchino poche funzionalità decisive. Finance sottolinea l’investimento già sostenuto. Sales sostiene che alcuni clienti importanti lo stiano aspettando. Il responsabile della business unit chiede ulteriori dati.

Dopo novanta minuti la riunione termina con una richiesta di approfondimento.

Due settimane dopo si tiene una seconda riunione. Vengono presentati nuovi dati, ma emerge una nuova obiezione. La decisione viene nuovamente rinviata.

Il problema potrebbe sembrare analitico: non abbiamo abbastanza informazioni.

Spesso, però, il vero problema è un altro:nessuno sa esattamente chi abbia il diritto di chiudere la decisione.

Quando questo accade, ogni stakeholder tende a comportarsi come se il proprio consenso fosse necessario. La consultazione diventa approvazione implicita e l’organizzazione cerca un consenso che nessuno ha formalmente dichiarato indispensabile.

Il costo non appare necessariamente nel budget di progetto. Compare sotto forma di attesa, meeting, rework, escalation e opportunità perse.

Da RACI ai diritti decisionali

Molte organizzazioni cercano di risolvere questa ambiguità attraverso una matrice RACI.

RACI è estremamente utile per chiarire responsabilità nell’esecuzione: chi è Responsible, chi Accountable, chi Consulted e chi Informed.

Ma una decisione non è semplicemente un’attività.

Possiamo sapere perfettamente chi debba preparare un business case senza sapere chi possa autorizzare l’investimento. Possiamo conoscere chi debba implementare una nuova policy senza avere chiarito chi possa scegliere tra due alternative incompatibili.

RAPID nasce precisamente per separare queste dimensioni.

Le cinque lettere identificanoRecommend, Agree, Perform, Input e Decide. È importante non interpretarle come una sequenza: lo stesso acronimo identifica ruoli decisionali, non cinque fasi da eseguire nell’ordine R-A-P-I-D.Asana

Recommend: costruire una proposta, non convocare un referendum

Il ruoloRha la responsabilità di portare la decisione verso una conclusione.

Chi possiede la Recommend raccoglie informazioni, costruisce alternative, valuta trade-off e formula una proposta.

Questo ruolo viene spesso sottovalutato. In molte organizzazioni una decisione arriva al management sotto forma di problema:

«Abbiamo questa situazione, cosa facciamo?»

RAPID richiede invece che qualcuno trasformi il problema in una raccomandazione argomentata.

La differenza è sostanziale.

Il management non dovrebbe essere costretto ogni volta a ricostruire il problema dal principio. Il recommender dovrebbe arrivare con una posizione:

sulla base di queste informazioni, considerando questi rischi e queste alternative, raccomandiamo questa scelta.

Input: ascoltare senza distribuire il potere di veto

Il ruoloInputrappresenta uno dei passaggi più importanti del framework.

Alcune persone possiedono informazioni indispensabili per prendere una buona decisione. Devono essere ascoltate.

Ma essere ascoltati non significa necessariamente avere il diritto di bloccare la decisione.

Questa distinzione appare banale finché non osserviamo il funzionamento reale delle organizzazioni.

Molti processi rallentano perché ogni stakeholder consultato viene implicitamente trasformato in approvatore. Il risultato è una progressiva espansione del numero di persone dalle quali ci si aspetta consenso.

RAPID separa nettamenteinformazione e autorità.

Un esperto può fornire un contributo fondamentale e contemporaneamente non possedere alcun veto.

Questa distinzione protegge sia la qualità della decisione sia la sua velocità.

Agree: rendere esplicito il vero veto

Agreenon significa semplicemente essere d’accordo.

Indica chi possiede un effettivo diritto di bloccare una raccomandazione in virtù di una responsabilità specifica. Le linee guida RAPID raccomandano infatti di utilizzare questo ruolo con parsimonia, tipicamente quando esistono vincoli legali, regolatori o analoghi.Bain Media

Legal può avere questo ruolo quando una scelta viola un requisito normativo. Cybersecurity quando viene superata una soglia di rischio non accettabile. Finance rispetto a determinati vincoli finanziari.

Il punto fondamentale è che gli Agree dovrebbero essere pochi.

Se ogni funzione possiede un veto, RAPID smette di funzionare e ricostruisce esattamente il problema che dovrebbe eliminare.

Il valore del framework consiste nel trasformare i veti informali indiritti espliciti, limitati e motivati.

Decide: qualcuno deve avere la D

Il cuore di RAPID è laD.

Per ogni decisione dovrebbe esistere un soggetto chiaramente identificabile che abbia l’autorità di chiuderla e impegnare l’organizzazione all’azione. Il modello prescrive esplicitamente una sola D per ciascuna decisione.Bain Media

Non necessariamente il manager gerarchicamente più alto.

Il diritto decisionale dovrebbe essere collocato dove esistono sufficiente competenza, visibilità delle conseguenze e responsabilità rispetto all’outcome.

La presenza di una singola D non significa leadership autoritaria. Il decisore può e deve ascoltare input, comprendere obiezioni e considerare alternative.

Ma alla fine qualcuno deve poter dire:questa è la decisione.

È una differenza profonda rispetto al consenso. Il consenso cerca una posizione che tutti possano accettare. RAPID cerca una decisione informata che qualcuno sia autorizzato ad assumere.

Perform: la decisione esiste soltanto quando modifica il sistema

L’ultimo ruolo riguarda l’esecuzione.

Una decisione strategica che non produce cambiamenti operativi rimane una dichiarazione di intenzioni.

Performidentifica chi deve trasformare la decisione in attività, comportamenti e risultati.

Separare Decide e Perform è utile perché evita un errore frequente: assumere che chi prende una decisione debba necessariamente essere anche chi la implementa.

Il management può decidere di modificare il pricing. Product, IT, Sales e Finance possono essere responsabili dell’esecuzione.

La chiarezza su questa transizione è fondamentale perché molti processi decisionali formalmente efficaci falliscono precisamente nel passaggio dalla scelta all’azione.

Un caso concreto: decidere se fermare un progetto

Consideriamo un’azienda che sta sviluppando una nuova piattaforma digitale B2B.

Il progetto dura da quattordici mesi. È stato consumato circa il 70% del budget previsto, ma i test con i clienti mostrano un’adozione molto inferiore alle attese.

Il Product Manager propone di interrompere il progetto e riallocare il budget verso un servizio differente emerso durante la discovery.

La decisione coinvolge numerosi stakeholder.

Senza una struttura chiara, il processo potrebbe trasformarsi in una lunga sequenza di riunioni. IT difende l’investimento tecnologico, Sales teme la reazione dei clienti ai quali il prodotto è stato anticipato, Finance evidenzia il sunk cost e Marketing ritiene prematuro giudicare l’adozione.

Applichiamo RAPID.

Recommend:il Product Manager costruisce la raccomandazione utilizzando dati di utilizzo, interviste, costi residui e scenari alternativi.

Input:CTO, Sales Director, Marketing e Customer Success forniscono informazioni tecniche, commerciali e di mercato.

Agree:Legal possiede un diritto limitato di veto esclusivamente se l’interruzione viola obblighi contrattuali già assunti.

Decide:il responsabile della business unit possiede la D perché risponde economicamente del portfolio.

Perform:Product, Technology e Customer Success implementano la chiusura e la transizione.

La decisione non diventa automaticamente facile.

Rimane possibile che CTO e Sales siano contrari.

Ma il disaccordo non impedisce più di decidere.

Questa è la differenza tragestire il conflitto e pretendere di eliminarlo prima di agire.

RAPID e Agile: autonomia non significa assenza di confini

A prima vista RAPID potrebbe sembrare un framework distante dalla cultura Agile. In realtà affronta uno dei problemi più frequenti delle trasformazioni Agile mature: la confusione tra empowerment e indeterminatezza dell’autorità.

Dire a un team«siete autonomi»serve a poco se non viene chiarito su quali decisioni possieda realmente autonomia.

Può modificare il backlog o cambiare una tecnologia? E’ in grado di rilasciare autonomamente e modificare il pricing? Può interrompere una feature già finanziata?

L’autonomia reale nasce da confini decisionali comprensibili.

RAPID può quindi essere utilizzato non per centralizzare, ma perrendere esplicita la decentralizzazione.

Un’organizzazione può decidere che alcune D appartengano ai team, altre ai Product Owner, altre ai responsabili di portfolio e soltanto poche al top management.

Il risultato può essere una struttura più distribuita, non più gerarchica.

Decision velocity: velocità senza fretta

La velocità decisionale è diventata una capacità organizzativa importante, ma la relazione con la performance è più sofisticata del semplicefaster is better. Una meta-analisi pubblicata nel 2025 ha aggregato127 studi e 239 effect size, rilevando effetti medi positivi sulla performance per decision speed (0,21), implementation speed (0,22) e response speed (0,10).Sage Journals

Questo introduce una distinzione fondamentale.

Decidere velocemente non significa decidere in fretta.

Un processo può essere analiticamente rigoroso e contemporaneamente rapido se è chiaro chi debba contribuire e chi possa chiuderlo.

Al contrario, una decisione relativamente semplice può richiedere settimane quando l’autorità è ambigua.

Ladecision velocitydipende quindi anche dall’architettura organizzativa.

Il rischio di burocratizzare RAPID

Come molti framework, RAPID può produrre l’effetto opposto se applicato indiscriminatamente.

Non tutte le decisioni meritano una matrice.

Applicare cinque ruoli alla scelta di una licenza software da cento euro sarebbe una forma di over-governance.

Lo stesso materiale metodologico sul framework suggerisce infatti di partire da poche decisioni realmente critiche, invece di mappare indiscriminatamente ogni scelta organizzativa.Bain Media

Il modello produce valore soprattutto sulle decisioni che sono contemporaneamente importanti, ricorrenti, cross-funzionali o frequentemente bloccate.

La domanda non dovrebbe quindi essere«possiamo usare RAPID?», ma:«Quali decisioni stanno generando abbastanza attrito da richiedere diritti decisionali espliciti ?»

Mappare le decisioni prima delle responsabilità

Molte trasformazioni organizzative iniziano dall’organigramma.

Disegniamo funzioni, ruoli e reporting line e successivamente cerchiamo di capire come far funzionare il sistema.

RAPID suggerisce implicitamente un percorso differente.

Partiamo dalle decisioni critiche.

Chi decide il pricing e l’ingresso in un nuovo mercato? Quali progetti interrompere e può modificare una roadmap? Chi decide una deroga agli standard tecnologici e quando un rischio è accettabile?

Una volta rese visibili queste decisioni, l’organizzazione reale diventa molto più leggibile.

Perché il potere organizzativo non è descritto soltanto dall’organigramma.

È descritto dachi possiede il diritto di dire sì, no o adesso.

Il management come architettura delle decisioni

La conseguenza più interessante di RAPID non è la matrice in sé.

È il cambiamento di prospettiva che introduce.

Il compito del management non consiste soltanto nel prendere decisioni. Consiste nel progettare un sistema nel qualele decisioni possano essere prese al livello appropriato senza richiedere continuamente l’intervento del management.

Questo significa distinguere consultazione da consenso, competenza da autorità, responsabilità esecutiva da diritto decisionale.

Significa anche accettare che una buona organizzazione non elimina il disaccordo.

Lo rende governabile.

Chi ha la D?

Quando una decisione importante rimane aperta per settimane, tendiamo a chiedere quali informazioni manchino, quale analisi debba essere completata o quale stakeholder non sia ancora stato coinvolto.

Talvolta sono domande corrette.

Ma ce n’è una che dovrebbe venire prima:chi ha la D?

Se la risposta non è immediata, probabilmente il problema non è ancora la qualità della decisione.

È la sua governance.

RAPID ci ricorda che organizzazioni collaborative non sono organizzazioni nelle quali tutti decidono tutto. Sono sistemi nei quali le persone giuste contribuiscono alle decisioni giuste e l’autorità necessaria per chiuderle è visibile prima che emerga il conflitto.

In contesti nei quali strategia, tecnologia e mercato cambiano rapidamente, questa chiarezza non rappresenta una rinuncia alla partecipazione.

Rappresenta una delle condizioni che permettono alla partecipazione di produrre risultati.

Perché il vero opposto della leadership autoritaria non è la decisione collettiva permanente.

È un’organizzazione nella qualeil potere decisionale è distribuito con intenzione, trasparenza e responsabilità.

L’articoloRAPID: chiarire chi decide prima di accelerare l’esecuzioneproviene daManagement Expert.

L'articolo RAPID: chiarire chi decide prima di accelerare l’esecuzione proviene da neosidea consulting.

laLaw of Requisite Variety di W. Ross Ashby, nota anche come Ashby’s Law, nato nella cibernetica, sostiene in sintesi che un sistema regolatore deve disporre di una varietà di risposte sufficientemente ampia rispetto alla varietà delle perturbazioni che deve governare. La letteratura ne ha successivamente esplorato esplicitamente l’applicazione alle organizzazioni, alla pianificazione e alla leadership.

Nelle organizzazioni contemporanee la complessità viene spesso affrontata aggiungendo controllo. Più procedure, più approvazioni, più reporting, più livelli decisionali. È una reazione intuitiva: quando il sistema diventa difficile da governare, si rafforzano i meccanismi di governo.

Eppure, oltre una certa soglia, il risultato può essere opposto a quello desiderato.

L’organizzazione diventa più lenta proprio mentre l’ambiente richiede maggiore capacità di risposta. Le eccezioni aumentano, le escalation si moltiplicano e il management finisce per essere coinvolto in un numero crescente di decisioni operative.

La legge della varietà necessaria, formulata dal pioniere della ciberneticaW. Ross Ashby, offre una chiave di lettura sorprendentemente attuale: per regolare efficacemente un sistema, il regolatore deve possedere una varietà di risposte almeno adeguata alla varietà delle perturbazioni che deve affrontare.

Tradotto nel linguaggio manageriale: se il mercato, i clienti, la tecnologia e le condizioni operative possono presentarsi in cento modi diversi, un’organizzazione capace di rispondere soltanto in tre modi standardizzati sarà inevitabilmente fragile.

La complessità non si governa necessariamente con più controllo. Si governa costruendo una capacità di risposta proporzionata alla varietà del contesto.

Quando l’ambiente diventa più vario dell’organizzazione

Immaginiamo un’azienda che operi in un mercato relativamente stabile. I clienti hanno esigenze simili, i prodotti cambiano lentamente, i processi sono prevedibili e le eccezioni limitate.

In questo scenario la standardizzazione è estremamente efficace. Procedure, ruoli e responsabilità possono essere definiti con precisione perché il numero di situazioni possibili è contenuto.

Poi il contesto cambia.

I clienti iniziano a richiedere personalizzazioni. I competitor introducono nuovi modelli di servizio. Le tecnologie evolvono più rapidamente. La normativa diventa più articolata. Le supply chain diventano meno prevedibili.

La varietà esterna aumenta.

Se la struttura interna rimane invariata, si crea progressivamente uno squilibrio. Le procedure coprono sempre meno casi. Le persone incontrano situazioni che non rientrano nelle regole esistenti. Le decisioni vengono quindi spinte verso l’alto.

Il management diventa il punto nel quale convergono le eccezioni.

Nascono comitati, escalation, deroghe, nuove procedure e livelli autorizzativi.

Paradossalmente, l’organizzazione cerca di rispondere alla crescente complessitàriducendo ulteriormente il numero delle risposte possibili.

È qui che la legge di Ashby diventa particolarmente interessante.

La Law of Requisite Variety

Ashby formalizzò il principio nel contesto della cibernetica e della teoria dei sistemi. In termini essenziali, un regolatore può contenere la varietà prodotta dalle perturbazioni solo se dispone di un repertorio sufficientemente ricco di stati o risposte.Taylor & Francis Online

Il concetto viene spesso sintetizzato nell’idea secondo cuisolo la varietà può assorbire varietà.

Non significa che un’organizzazione debba diventare caotica per fronteggiare un ambiente complesso. Significa che non può governare una realtà altamente differenziata attraverso un insieme troppo limitato di risposte.

Consideriamo un customer service.

Se esistono soltanto cinque tipologie di richiesta, cinque procedure standard possono essere sufficienti.

Se le richieste diventano cento, ma gli operatori possono scegliere soltanto tra le stesse cinque procedure, aumenteranno inevitabilmente i casi non gestibili.

A quel punto esistono tre possibilità.

La prima è aumentare il numero di regole.

La seconda è trasferire le decisioni a un livello superiore.

La terza èaumentare la capacità locale di interpretazione e risposta.

Le prime due soluzioni sono quelle più frequentemente adottate. La terza è quella più interessante dal punto di vista organizzativo.

Complessità esterna e complessità interna

La legge di Ashby obbliga a distinguere tra due forme di complessità.

La prima appartiene all’ambiente: varietà di clienti, mercati, tecnologie, eventi e situazioni operative.

La seconda appartiene all’organizzazione: competenze, autonomia, strumenti, informazioni e possibilità decisionali disponibili per rispondere.

Un’organizzazione resiliente non cerca necessariamente di ridurre tutta la complessità interna. Cerca di progettarela complessità necessaria nei punti in cui serve.

Questo spiega perché alcune aziende molto standardizzate funzionano perfettamente in contesti stabili e diventano improvvisamente fragili quando il mercato cambia.

La struttura non è diventata peggiore.

È diventatainadeguata rispetto alla varietà dell’ambiente.

La risposta tradizionale: centralizzare le eccezioni

Quando una situazione non rientra nelle procedure, la risposta classica consiste nell’escalation.

L’operatore chiede al responsabile. Il responsabile coinvolge il manager. Il manager interpella la direzione.

La logica sembra corretta: le decisioni più difficili vengono prese da chi possiede maggiore esperienza e autorità.

Ma se il numero delle eccezioni cresce, il modello non scala.

La capacità decisionale del vertice rimane finita mentre la varietà dell’ambiente aumenta.

Il management diventa quindi uncollo di bottiglia informativo e decisionale.

Le persone attendono decisioni. I tempi si allungano. Le informazioni perdono qualità salendo lungo la gerarchia. Decisioni che richiederebbero conoscenza contestuale vengono prese lontano dal punto nel quale il problema è emerso.

La centralizzazione riduce apparentemente la complessità organizzativa, ma può ridurre anche la varietà delle risposte disponibili.

Autonomia come moltiplicatore della varietà

Da questa prospettiva, l’autonomia non è soltanto un principio culturale.

È un meccanismo di regolazione della complessità.

Quando una persona o un team può scegliere tra più risposte appropriate, la capacità complessiva del sistema aumenta.

Naturalmente autonomia non significa assenza di vincoli.

Un’organizzazione nella quale ogni individuo può fare qualsiasi cosa possiede una varietà enorme, ma non necessariamente utile.

La questione manageriale diventa quindi più precisa:

come aumentare la varietà delle risposte senza perdere coerenza?

La risposta passa spesso attraverso guardrail, principi, piattaforme e confini decisionali chiari.

Non più procedure capaci di descrivere ogni situazione possibile, ma sistemi che definiscono entro quali limiti le persone possono decidere autonomamente.

È una differenza fondamentale.

La procedura dice cosa fare.

Il guardrail definisce cosa non deve essere violato.

Nel primo caso la varietà della risposta è progettata centralmente. Nel secondo viene generata localmente entro un perimetro condiviso.

Il legame con Agile

Molti principi Agilepossono essere riletti attraverso la legge di Ashby.

Unteam cross-funzionalepossiede maggiore varietà rispetto a un gruppo nel quale ogni decisione richiede il coinvolgimento di funzioni esterne.

Un Product Owner vicino al cliente può reagire più rapidamente a variazioni di priorità rispetto a un sistema nel quale ogni cambiamento deve attraversare una catena gerarchica.

Iterazioni brevi aumentano la frequenza con cui il sistema può modificare il proprio comportamento.

Feedback continui aumentano la capacità di percepire le variazioni dell’ambiente.

Agile, da questa prospettiva, non è soltanto un metodo per sviluppare software più velocemente.

Èun modo per aumentare la varietà adattiva dell’organizzazione.

Ma anche qui esiste un rischio.

Se aumentiamo autonomia senza fornire competenze, informazioni o strumenti adeguati, la varietà teoricamente disponibile non diventa capacità reale.

Un team può essere formalmente autonomo e continuare a dipendere dal management per ogni decisione importante.

La varietà non nasce dall’organigramma.

Nasce dal repertorio effettivamente utilizzabile.

Team Topologies e varietà necessaria

Il collegamento conTeam Topologiesè particolarmente evidente.

Gli stream-aligned team vengono progettati per poter gestire una porzione significativa del flusso di valore senza dipendere continuamente da altre unità.

Gli enabling team aumentano la varietà degli altri team trasferendo competenze e capacità.

I platform team riducono invece parte della complessità che i team devono gestire direttamente.

Ed è proprio qui che il modello di Ashby diventa ancora più utile.

Esistono infatti due strategie complementari.

Possiamo aumentare la varietà del regolatore.

Oppure possiamo ridurre la varietà delle perturbazioni che raggiungono il regolatore.

Le piattaforme interne fanno precisamente questo: assorbono complessità tecnica e offrono interfacce più semplici.

Un developer non deve conoscere ogni dettaglio dell’infrastruttura cloud se una piattaforma interna gli fornisce un servizio standardizzato di deployment.

La complessità non è scomparsa.

È stataspostata e assorbita nel punto più appropriato del sistema.

Un caso concreto: l’assistenza tecnica di un’azienda industriale

Immaginiamo un produttore di macchinari industriali con clienti distribuiti in diversi Paesi.

Per anni il modello di assistenza tecnica ha funzionato bene. I prodotti erano relativamente standardizzati e la maggior parte dei problemi rientrava in categorie note.

L’azienda cresce e introduce macchine sempre più digitali, configurabili e integrate con i sistemi dei clienti.

La varietà delle situazioni aumenta rapidamente.

Un guasto può dipendere dalla meccanica, dal software, dalla configurazione della rete, da un’integrazione ERP o da condizioni specifiche del processo produttivo del cliente.

L’organizzazione dell’assistenza rimane però invariata.

Gli operatori di primo livello seguono procedure rigide. Quando il problema non rientra nello script, aprono un ticket al secondo livello. Il secondo livello coinvolge gli specialisti. Gli specialisti, quando necessario, coinvolgono engineering.

Nel giro di pochi mesi il tempo medio di risoluzione cresce significativamente.

Il management interpreta il problema come una mancanza di disciplina e risponde introducendo procedure più dettagliate.

Il manuale operativo passa da cento a quasi trecento pagine.

Il risultato peggiora.

Gli operatori impiegano più tempo a individuare la procedura corretta e continuano comunque a incontrare situazioni non previste.

L’azienda decide allora di leggere il problema attraverso la varietà necessaria.

La diagnosi cambia.

Il problema non è che esistano troppo poche procedure.

È chela varietà delle situazioni affrontate dagli operatori è diventata superiore alla varietà delle risposte che sono autorizzati a utilizzare.

Il nuovo modello interviene su tre livelli.

Innanzitutto vengono create squadre cross-funzionali per tipologia di prodotto, nelle quali competenze meccaniche, software e di processo sono più vicine.

In secondo luogo, agli operatori vengono forniti nuovi strumenti diagnostici e maggiore visibilità sui dati delle macchine.

Infine, le procedure vengono progressivamente sostituite da principi decisionali e guardrail: quali condizioni richiedono escalation, quali possono essere gestite localmente, quali rischi non devono mai essere accettati.

Dopo alcuni mesi diminuisce il numero delle escalation e aumenta la percentuale di casi risolti al primo livello.

La differenza non deriva da maggiore controllo.

Deriva dauna maggiore varietà di risposte disponibili nel punto in cui nasce il problema.

Il ruolo dell’informazione

La capacità di risposta non dipende soltanto dall’autorità.

Dipende anche dall’informazione.

Un team può avere piena autonomia decisionale ma essere incapace di utilizzarla se non dispone dei dati necessari.

Da questa prospettiva, dashboard, analytics e strumenti di osservabilità non sono soltanto supporti al reporting.

Sono componenti della capacità regolatoria del sistema.

Aumentano il numero di stati dell’ambiente che l’organizzazione riesce a distinguere.

Se non percepiamo una variazione, non possiamo reagire.

La varietà necessaria riguarda quindi tantoil repertorio delle azioni quanto la qualità della percezione.

Leadership e varietà di risposta

La stessa logica può essere applicata alla leadership.

Un manager che utilizza sempre lo stesso stile possiede un repertorio limitato.

Può essere direttivo, partecipativo, delegante o orientato al coaching, ma se utilizza una sola modalità indipendentemente dal contesto la sua varietà di risposta rimane inferiore alla varietà delle situazioni che deve affrontare.

La ricerca sulla leadership del cambiamento ha esplicitamente collegato l’efficacia alla requisite variety: contesti differenti richiedono repertori differenti di comportamenti e funzioni di leadership.DOI

Questo conduce a una definizione interessante della maturità manageriale.

Non consiste nell’avere trovato il proprio stile.

Consiste nelpossedere un repertorio sufficientemente ampio da poter scegliere lo stile appropriato alla situazione.

Ridurre la varietà è altrettanto importante

Aumentare la capacità di risposta non è però l’unica strategia.

In alcuni casi la soluzione migliore consiste nel ridurre la varietà inutile che raggiunge il sistema.

Standardizzare formati, costruire API comuni, eliminare varianti di prodotto prive di valore, consolidare fornitori o creare piattaforme condivise sono tutti modi per diminuire la complessità che le persone devono gestire.

Questa distinzione è cruciale.

Non tutta la varietà genera valore.

Un’organizzazione matura distingue travarietà necessaria per rispondere al mercato e varietà accidentale prodotta dalla propria storia.

Dieci sistemi diversi per gestire lo stesso processo non aumentano necessariamente l’adattabilità.

Possono semplicemente aumentare il carico cognitivo.

La progettazione organizzativa consiste quindi in un doppio movimento:

ridurre la varietà inutile e aumentare la varietà utile.

La trappola della standardizzazione

La standardizzazione rimane uno degli strumenti più potenti del management.

Permette di ridurre errori, aumentare qualità e creare economie di scala.

Il problema nasce quando viene utilizzata per eliminare varietà che invece è strutturale nel contesto.

Un processo estremamente standardizzato può funzionare perfettamente fino al momento in cui l’ambiente cambia.

In quel momento la sua efficienza diventa fragilità.

È una dinamica particolarmente evidente nelle trasformazioni digitali.

Molte organizzazioni digitalizzano processi progettati in epoche nelle quali la varietà era minore. Il risultato è spesso un’automazione della rigidità.

La tecnologia rende il processo più veloce, ma non necessariamente più adattabile.

Una domanda fondamentale dovrebbe quindi precedere ogni iniziativa di automazione:

quanta varietà deve essere preservata affinché il sistema continui a rispondere alle eccezioni rilevanti?

Governance come progettazione della varietà

La legge di Ashby cambia anche il modo di interpretare la governance.

Governare non significa necessariamente concentrare decisioni.

Significa progettare un sistema nel quale le decisioni possano essere prese nel punto più adatto, con informazioni, competenze e limiti coerenti con il rischio.

Alcune decisioni devono essere centralizzate perché richiedono coerenza globale.

Altre devono essere decentralizzate perché richiedono conoscenza locale e rapidità.

La buona governance non sceglie ideologicamente tra centralizzazione e autonomia.

Distribuisce varietà decisionale dove produce maggiore capacità di regolazione.

Una domanda diversa per il management

Quando un’organizzazione incontra complessità crescente, la domanda abituale è:

come possiamo controllarla meglio?

Ashby suggerisce una domanda più utile:

abbiamo abbastanza modi per rispondere alle situazioni che possono verificarsi?

Da qui derivano immediatamente altre domande.

Le persone possiedono le competenze necessarie?

Dispongono delle informazioni giuste?

Sono autorizzate a decidere?

Esistono piattaforme capaci di assorbire complessità inutile?

Quali variazioni del contesto possiamo standardizzare e quali dobbiamo invece saper gestire?

Queste domande spostano il management dalla supervisione delle attività allaprogettazione della capacità adattiva.

Governare la complessità senza inseguirla

La complessità non è necessariamente un difetto del sistema.

Spesso è una caratteristica inevitabile dell’ambiente nel quale il sistema opera.

La sfida non consiste quindi nell’eliminarla, ma nel costruire organizzazioni capaci di assorbirla senza trasferirla continuamente verso il vertice.

La Law of Requisite Variety offre una prospettiva sorprendentemente moderna proprio perché mette in discussione una delle reazioni più radicate del management:aggiungere controllo quando aumenta l’incertezza.

In molti casi serve l’opposto.

Serve distribuire capacità decisionale, aumentare competenze, migliorare informazione e costruire infrastrutture che consentano alle persone di gestire localmente una maggiore varietà di situazioni.

Il management non deve conoscere in anticipo ogni possibile risposta.

Deve progettare un sistema capace di produrre risposte appropriate quando il contesto cambia.

È una distinzione fondamentale.

Perché in ambienti complessi il vantaggio competitivo non appartiene necessariamente all’organizzazione che possiede il piano più dettagliato.

Appartiene a quella che possiedeil repertorio più ampio di risposte efficaci.

Ed è forse questo il contributo più attuale di Ashby al management contemporaneo: ricordarci che, quando il mondo aumenta la propria varietà, un’organizzazione non può continuare a governarlo restringendo la propria.

L’articoloAshby’s Law: governare la complessità senza moltiplicare il controlloproviene daManagement Expert.

L'articolo Ashby’s Law: governare la complessità senza moltiplicare il controllo proviene da neosidea consulting.

Nelle organizzazioni si parla molto di decisionidata-driven. L’espressione suggerisce un processo quasi lineare: osserviamo i fatti, li analizziamo e scegliamo la soluzione migliore. La realtà manageriale è molto meno ordinata. Tra ciò che accade e ciò che decidiamo esiste uno spazio invisibile popolato da selezione, interpretazioni, esperienze pregresse, convinzioni e bias.

È in questo spazio che nasce una parte significativa dei conflitti organizzativi e degli errori decisionali.

La Ladder of Inference offre una rappresentazione semplice di questo processo. La sua forza non consiste nel suggerire che i manager debbano eliminare le inferenze: sarebbe impossibile. Il valore sta nelrenderle visibili, così da distinguere ciò che sappiamo da ciò che abbiamo concluso.

Il problema non sono i dati, ma il percorso che facciamo a partire dai dati

Immaginiamo una riunione di avanzamento. Il responsabile di una business unit arriva quindici minuti in ritardo, interviene poco e durante la presentazione guarda più volte il telefono. Il project manager conclude che non considera il progetto prioritario.

Il comportamento osservato è reale. La conclusione, però, non è un fatto: è il risultato di un percorso mentale.

Avremmo potuto osservare che il manager era in ritardo, ha parlato poco e ha guardato il telefono. Abbiamo selezionato questi elementi tra molti altri. Abbiamo attribuito loro un significato — disinteresse — e formulato un’assunzione: il progetto non è importante per lui. Da quell’assunzione traiamo una conclusione e, se il processo si ripete, costruiamo una convinzione stabile: «il business non supporta il progetto».

Da quel momento iniziamo inevitabilmente ad agire sulla base di quella convinzione. Coinvolgiamo meno il manager, smettiamo di chiedergli feedback, interpretiamo ogni sua assenza come conferma.

La convinzione contribuisce così a produrre la realtà che sembrava soltanto descrivere.

I gradini della scala

Alla base esiste la realtà osservabile: eventi, comportamenti, numeri, conversazioni. Nessuno, tuttavia, elabora tutta l’informazione disponibile.Selezioniamo alcuni dati e ne ignoriamo altri.

A ciò che selezioniamo attribuiamo un significato, spesso influenzato dal contesto e dalle nostre esperienze. Su quel significato costruiamo assunzioni; dalle assunzioni traiamo conclusioni; le conclusioni consolidate diventano convinzioni e le convinzioni orientano le nostre azioni.

Il processo è rapidissimo e in larga parte automatico. Il problema nasce quando arriviamo in cima alla scala dimenticando di averla percorsa. Una conclusione ci appare allora come un fatto.

«Il cliente vuole questa funzionalità.»

«Il team non è abbastanza autonomo.»

«Quella persona resiste al cambiamento.»

«Agile qui non funziona.»

«Il progetto è in ritardo perché IT è lento.»

Sono tutte affermazioni che possono essere vere. Ma possono anche rappresentare conclusioni costruite selezionando solo una parte della realtà.

Quando le inferenze diventano problemi organizzativi

In un’organizzazione il fenomeno non riguarda soltanto il singolo individuo. Le inferenze possono diventare collettive.

Una funzione commerciale può sviluppare la convinzione che IT sia burocratica. IT può convincersi che il business cambi continuamente idea. Il management può ritenere che i team abbiano bisogno di maggiore controllo, mentre i team possono interpretare lo stesso controllo come mancanza di fiducia.

Ogni gruppo seleziona eventi coerenti con la propria interpretazione e finisce per rafforzarla.

Si crea così un circuito auto-rinforzante nel quale due letture parziali della realtà diventano progressivamenteidentità organizzative.

Il conflitto smette di riguardare un problema concreto e diventa una storia: «noi siamo fatti così, loro sono fatti cosà».

A quel punto cambiare processo o organigramma serve relativamente poco. Prima occorre rendere discutibili le convinzioni che governano il comportamento.

Scendere la scala prima di decidere

La Ladder of Inference diventa uno strumento manageriale quando impariamo a percorrerla anche nella direzione opposta.

Davanti a una conclusione forte possiamo chiederci quali dati osservabili la sostengano, quali informazioni abbiamo selezionato e quali potremmo avere escluso. Possiamo interrogarci sul significato attribuito ai dati, sulle assunzioni formulate e soprattutto domandarciquale evidenza ci convincerebbe che la nostra conclusione è sbagliata.

Queste domande non impongono relativismo. Un manager deve comunque decidere.

Introducono però una distinzione fondamentale travelocità decisionale e fretta cognitiva.

Decidere rapidamente può essere necessario. Trasformare rapidamente un’interpretazione in certezza è molto più pericoloso.

Advocacy e inquiry: rendere visibile il ragionamento

Una delle applicazioni più interessanti consiste nel modificare il modo in cui le persone discutono.

Nelle riunioni manageriali utilizziamo spesso l’advocacy: sosteniamo una posizione e cerchiamo argomenti che la rafforzino. È utile, ma se tutti fanno soltanto advocacy la conversazione diventa una competizione tra conclusioni.

L’alternativa non è rinunciare alle proprie idee, ma combinareadvocacy e inquiry: spiegare come siamo arrivati a una conclusione e contemporaneamente investigare il ragionamento degli altri.

Invece di dire:

«Il cliente non vuole questa soluzione.»

possiamo ragionare in modo differente:

«Nelle ultime tre interviste nessun cliente ha utilizzato spontaneamente questa funzione; da questo sto inferendo che il valore percepito sia basso. Voi vedete dati che portano a una conclusione diversa?»

La seconda formulazione non è più debole.

Èpiù verificabile.

Una buona discussione manageriale non dovrebbe quindi mettere a confronto soltanto opinioni, ma rendere visibili i percorsi che hanno prodotto quelle opinioni.

Il caso concreto: una trasformazione Agile che sembra non funzionare

Immaginiamo un’azienda industriale che abbia introdotto team Agile per accelerare lo sviluppo di servizi digitali.

Dopo nove mesi il management è insoddisfatto. I rilasci non sono aumentati quanto previsto e alcune iniziative accumulano ritardi.

Durante uno steering committee emerge una conclusione apparentemente condivisa:

«I team non sono ancora abbastanza maturi per lavorare in autonomia.»

La risposta proposta è aumentare il controllo: reporting settimanale, approvazione preventiva delle stime, nuovi checkpoint e coinvolgimento diretto dei responsabili funzionali nella pianificazione degli sprint.

Prima di procedere, il facilitatore utilizza la Ladder of Inference.

Quali sono i dati osservabili?

Tre release hanno subito ritardi. Alcuni sprint non hanno raggiunto lo Sprint Goal. Due team hanno chiesto frequentemente decisioni al management.

Da questi dati il management ha attribuito un significato: difficoltà nella gestione autonoma. L’assunzione successiva è che la causa risieda nella maturità dei team. La conclusione diventa quindi che serva maggiore supervisione.

Scendendo la scala emergono però dati rimasti fuori dalla narrazione iniziale.

I team dipendono da una funzione infrastrutturale esterna per ogni rilascio. Il Product Owner di uno dei prodotti dedica al ruolo meno del 30% del proprio tempo. Cinque decisioni architetturali richiedono l’approvazione di un comitato che si riunisce ogni due settimane. Inoltre, le priorità sono state modificate dal management quattro volte in tre mesi.

La stessa realtà produce ora un’interpretazione differente.

Forse il problema non è la mancanza di autonomia dei team, maun sistema organizzativo che dichiara autonomia senza trasferire realmente le condizioni necessarie per esercitarla.

La decisione cambia.

Invece di introdurre ulteriore reporting, l’azienda riduce le dipendenze infrastrutturali, assegna Product Owner dedicati e delega alcune decisioni architetturali entro guardrail condivisi.

Tre mesi dopo il lead time migliora senza aumentare i livelli di controllo.

La Ladder of Inference non ha fornito la soluzione. Ha impedito cheuna conclusione plausibile diventasse prematuramente una diagnosi.

Il legame con Agile e le retrospettive

Il modello è particolarmente utile nei contesti Agile perché molte pratiche Agile dipendono dalla capacità di trasformare esperienza in apprendimento.

Una retrospective che produce frasi come «la comunicazione non funziona» o «il business cambia sempre priorità» è ancora in cima alla scala.

Il lavoro interessante comincia quando il team torna ai dati osservabili.

Che cosa è accaduto concretamente? Quante priorità sono cambiate? Chi le ha cambiate? In quale momento? Quale effetto hanno prodotto? Quale assunzione avevamo fatto sulla stabilità del backlog?

Questa disciplina evita che la retrospective diventi uno spazio nel quale si consolidano narrazioni organizzative invece di metterle alla prova.

Agile richiede feedback, ma il feedback produce apprendimento soltanto quando siamo capaci di distinguere osservazione e interpretazione.

Leadership e certezza

Per un leader la Ladder of Inference introduce una tensione particolarmente importante.

L’organizzazione chiede al management chiarezza e decisione. Questo può creare l’idea che un buon leader debba mostrare certezza.

Ma certezza e chiarezza non sono la stessa cosa.

Un leader può essere estremamente chiaro dichiarando: «questa è la decisione che prendo sulla base dei dati disponibili e di queste tre assunzioni».

Una formulazione di questo tipo mantiene l’accountability senza trasformare il ragionamento in dogma.

In contesti complessi questa capacità diventa decisiva. Più aumenta l’incertezza, più le decisioni dipendono da ipotesi. Nascondere quelle ipotesi dietro una comunicazione assertiva non rende la strategia più robusta:la rende soltanto meno falsificabile.

La leadership matura non consiste quindi nel rinunciare alle convinzioni, ma nel possedere convinzioni sufficientemente solide da orientare l’azione e sufficientemente aperte da poter essere corrette dall’evidenza.

Ladder of Inference e change management

Nei programmi di cambiamento il modello offre una seconda applicazione rilevante: comprendere la resistenza.

Quando una persona contesta una trasformazione, il management può salire rapidamente la propria scala:

«Non comprende il progetto.»

«Ha paura di perdere potere.»

«È resistente al cambiamento.»

Sono spiegazioni possibili, ma rimangono inferenze.

Se vengono trattate come fatti, orientano immediatamente le azioni: più comunicazione, formazione, pressione o escalation.

Se la diagnosi è sbagliata, queste azioni possono aumentare proprio la resistenza che intendono ridurre.

Scendere la scala significa invece tornare ai comportamenti osservabili e investigarne il significato. Una persona che contesta il nuovo processo potrebbe non opporsi al cambiamento; potrebbe possedere informazioni operative che il progetto non ha considerato.

Il dissenso diventa cosìuna fonte potenziale di informazione, non automaticamente un problema da correggere.

Dalle decisioni data-driven alle decisioni assumption-aware

Le organizzazioni contemporanee investono enormemente nei dati. Dashboard, KPI, analytics e intelligenza artificiale aumentano continuamente la quantità di informazione disponibile.

Ma più dati non eliminano automaticamente le inferenze.

Possiamo costruire una dashboard perfetta e interpretarla attraverso una convinzione sbagliata e possiamo selezionare KPI coerenti con ciò che vogliamo dimostrare. Possiamo, anche, confondere correlazione e causalità ed ignorare segnali che contraddicono la strategia.

La vera evoluzione non consiste quindi soltanto nel diventaredata-driven, ma nel diventareassumption-aware: consapevoli delle ipotesi che collegano i dati alle decisioni.

Ogni decisione strategica significativa potrebbe essere accompagnata da una domanda semplice:

Quali assunzioni devono essere vere perché questa decisione sia corretta?

Da questa domanda discende immediatamente la successiva:

Come possiamo verificarle?

Rendere il pensiero osservabile

La Ladder of Inference non elimina bias, conflitti o errori. Offre qualcosa di più pragmatico:un linguaggio per discuterli.

Il suo valore manageriale nasce dalla possibilità di interrompere, anche solo per qualche minuto, l’automatismo con cui trasformiamo osservazioni in certezze.

Nelle organizzazioni complesse molte decisioni sbagliate non derivano dalla mancanza di competenza. Nascono da persone competenti che osservano porzioni differenti della realtà, attribuiscono significati differenti agli stessi eventi e successivamente discutono le proprie conclusioni come se fossero fatti.

Rendere visibile la scala significa rendere visibile il ragionamento.

E quando il ragionamento diventa osservabile può essere discusso, verificato e migliorato.

Per un manager questa è una competenza meno appariscente della capacità di decidere velocemente, ma probabilmente più importante:sapere quando fidarsi della propria esperienza e quando fermarsi un gradino più in basso per chiedersi se ciò che appare evidente sia davvero un fatto o soltanto una conclusione diventata familiare.

Perché nelle organizzazioni il problema raramente è avere delle convinzioni.

Il problema nasce quando dimentichiamo il percorso attraverso il quale le abbiamo costruite.

L’articoloLadder of Inference: quando i fatti diventano convinzioni e le convinzioni guidano le decisioniproviene daManagement Expert.

L'articolo Ladder of Inference: quando i fatti diventano convinzioni e le convinzioni guidano le decisioni proviene da neosidea consulting.

IlPremortem di Gary Kleindescrive il metodo come un esercizio da svolgere dopo che il team ha compreso un piano: si assume che il progetto sia già fallito e si ricostruiscono le possibili ragioni del fallimento.

La maggior parte dei progetti non fallisce perché nessuno aveva intuito i rischi. Più spesso fallisce perché quei rischi erano stati percepiti, ma non sono riusciti a entrare davvero nella conversazione decisionale. Qualcuno aveva un dubbio sull’integrazione tecnologica, qualcun altro sapeva che la scadenza era irrealistica, un responsabile commerciale intuiva che il cliente non avrebbe adottato la soluzione come previsto. Eppure il piano è partito ugualmente.

Il problema, quindi, non è soltanto la capacità di prevedere. È la capacità dell’organizzazione direndere dicibile ciò che contraddice il piano.

Il Premortem, tecnica sviluppata dallo psicologo cognitivo Gary Klein e resa nota nel management attraversoPerforming a Project Premortem, pubblicato dalla Harvard Business Review nel settembre 2007, interviene precisamente su questo punto. Invece di chiedere a un team «che cosa potrebbe andare storto?», propone un cambio radicale di prospettiva: immaginare che il progetto sia già fallito e chiedersi perché.

Una differenza linguistica apparentemente minima produce un cambiamento sostanziale nel modo in cui le persone ragionano. Il rischio non è più una possibilità da contrapporre all’ottimismo del piano. Il fallimento diventa temporaneamente un fatto acquisito e il compito del gruppo consiste nel ricostruirne le cause.

È un esercizio diprospective hindsight: guardare al futuro come se fosse già passato. Ed è proprio questa inversione temporale a rendere il Premortem particolarmente interessante per project manager, leadership team e organizzazioni chiamate a prendere decisioni in condizioni di elevata incertezza. La ricerca richiamata da Klein associa il prospective hindsight a una maggiore capacità di generare spiegazioni sulle cause di un possibile esito futuro.

Il paradosso della pianificazione: quando un buon piano diventa difficile da criticare

Ogni progetto importante nasce da un atto di fiducia. Si costruisce un business case, si definiscono obiettivi, si stimano costi e tempi, si assegnano responsabilità. Progressivamente il piano smette di essere soltanto un’ipotesi e acquisisce uno status organizzativo: diventail progetto.

Da quel momento criticarlo diventa più difficile.

Entrano in gioco dinamiche cognitive e sociali note: l’optimism bias porta a sottostimare gli eventi negativi; il confirmation bias induce a privilegiare informazioni coerenti con la decisione già presa; i costi già sostenuti possono rendere psicologicamente e politicamente più difficile rimettere in discussione un’iniziativa.

A questi fenomeni individuali si aggiunge una dimensione organizzativa ancora più rilevante:il dissenso ha un costo.

In un kickoff nel quale sponsor e management presentano con entusiasmo una nuova iniziativa, affermare che l’architettura potrebbe non scalare, che il cliente probabilmente non cambierà comportamento o che il team non dispone delle competenze necessarie significa assumersi implicitamente il ruolo di oppositore.

Non è necessario che esista una cultura autoritaria. È sufficiente che le persone percepiscano che l’organizzazione preferisce l’allineamento alla contraddizione.

Il risultato è un fenomeno frequente:i rischi esistono nella conoscenza distribuita del gruppo, ma non nel piano.

Il Premortem prova a colmare precisamente questa distanza. Klein sottolinea infatti che uno dei problemi della pianificazione è la riluttanza delle persone a esprimere le proprie riserve; assumere preventivamente il fallimento rende più semplice portarle alla luce.

Dal postmortem al Premortem

Il termine richiama deliberatamente l’autopsia. Nel postmortem si analizza un evento dopo che è accaduto per comprenderne le cause e apprendere dall’esperienza. È una pratica preziosa, ma presenta un limite evidente: quando la lezione emerge, il danno è già avvenuto.

Klein rovescia il paradigma.

Il team conosce il piano. Prima di iniziare l’esecuzione, il facilitatore propone uno scenario molto preciso: immaginiamo di trovarci tra sei o dodici mesi. Il progetto è terminato ed è stato un fallimento evidente. Non ha semplicemente incontrato qualche difficoltà:non ha raggiunto gli obiettivi per cui era stato avviato.

A questo punto ogni partecipante deve rispondere individualmente a una domanda:

Che cosa è successo?

Non «che cosa potrebbe succedere?», quindi, ma «che cosa è successo?».

La distinzione è centrale. Ma l’effetto forse più interessante in azienda è sociale: il Premortemlegittima il pessimismo temporaneo.

Il partecipante che identifica una debolezza non sta più opponendosi al progetto. Sta svolgendo esattamente il compito che gli è stato assegnato.

Il dissenso passa da comportamento potenzialmente disfunzionale a contributo richiesto.

Il Premortem non è una riunione sui rischi

A prima vista la tecnica può sembrare una variante creativa del risk assessment tradizionale. In realtà agisce su un livello differente.

Un registro dei rischi chiede normalmente di identificare eventi incerti, valutarne probabilità e impatto, definire mitigazioni e assegnare ownership. È uno strumento di governo indispensabile, ma la sua qualità dipende dalla qualità dei rischi che il gruppo riesce a far emergere.

Il Premortem lavora un passo prima:modifica il contesto cognitivo nel quale quei rischi vengono prodotti.

Se chiediamo «quali sono i rischi del progetto?», il gruppo tende facilmente verso categorie note: ritardi, budget, fornitori, risorse, tecnologia. Se invece diciamo «il progetto è fallito: raccontatemi perché», diventano più accessibili anche spiegazioni scomode e specifiche.

Il responsabile tecnico potrebbe dire: «Abbiamo scoperto troppo tardi che il sistema legacy non esponeva i dati con la qualità necessaria».

Il commerciale: «I clienti hanno continuato a utilizzare Excel perché il nuovo processo richiedeva più passaggi».

L’HR manager: «Abbiamo formato le persone sul software, ma non abbiamo cambiato gli obiettivi con cui venivano valutate».

Il project manager: «Abbiamo mantenuto la data di rilascio anche quando tre milestone consecutive indicavano che non era più realistica».

Queste non sono categorie astratte di rischio. Sononarrazioni causali. E una narrazione causale è molto più facile da trasformare in una contromisura concreta.

Come condurre un Premortem

Un Premortem efficace può essere relativamente breve, ma deve essere strutturato con attenzione. Klein lo colloca tipicamente dopo che il gruppo è stato informato sul piano, proprio perché le persone devono possedere sufficiente conoscenza dell’iniziativa per immaginarne concretamente le modalità di fallimento.

Il momento ideale è spesso dopo la costruzione di una prima versione credibile del piano eprima che le decisioni diventino difficili o costose da modificare.

Il facilitatore presenta quindi lo scenario futuro: «Siamo a un anno da oggi. Il progetto è fallito e non ha generato il risultato atteso. Che cosa è successo?».

Segue una fase individuale e silenziosa. È un passaggio essenziale. Se la discussione iniziasse immediatamente, le prime opinioni espresse creerebbero ancoraggio e i partecipanti con maggiore status potrebbero influenzare inevitabilmente gli altri. La scrittura individuale permette invece di preservare la diversità delle prospettive.

Solo successivamente le ipotesi vengono condivise. Il facilitatore le raccoglie senza discuterle immediatamente. In questa fase l’obiettivo non è difendere il piano né dimostrare perché una determinata eventualità sia improbabile. Èampliare il campo di osservazione.

Le cause vengono poi raggruppate per affinità e analizzate. Alcune saranno già coperte dal piano; altre risulteranno marginali; altre ancora metteranno in luce assunzioni che nessuno aveva esplicitato.

Il passaggio conclusivo è quello che trasforma l’esercizio da conversazione interessante a strumento manageriale:ogni rischio significativo deve produrre una decisione.

Può trattarsi di modificare il piano, introdurre una verifica anticipata, costruire un prototipo, cambiare una milestone, nominare un owner, definire una metrica o stabilire un trigger che richieda una rivalutazione.

Il Premortem non dovrebbe quindi terminare con una parete piena di post-it.Dovrebbe terminare con un piano diverso da quello con cui la sessione è iniziata.

Dal rischio al segnale debole

Uno degli sviluppi più interessanti consiste nel collegare ogni causa di fallimento a un indicatore anticipatore.

Supponiamo che il gruppo individui questo scenario: «Il progetto è fallito perché gli utenti non hanno adottato il nuovo processo».

La mitigazione classica potrebbe essere prevedere formazione e comunicazione. Ma il Premortem può spingersi oltre chiedendo:quale segnale, osservabile tra due mesi, ci direbbe che stiamo andando precisamente in quella direzione?

Potrebbero emergere indicatori come la percentuale di utenti che continua a utilizzare strumenti alternativi, il numero di processi completati fuori piattaforma, il tasso di partecipazione ai test o il tempo necessario per eseguire le attività principali.

Il rischio smette così di essere una frase statica in un registro e diventaun’ipotesi monitorabile.

Questo passaggio è particolarmente coerente con la logica Agile. In un contesto adattivo non è realistico pretendere di prevedere tutto. È invece possibile progettare sistemi capaci di riconoscere rapidamente quando le ipotesi iniziali stanno diventando false.

Il Premortem non elimina l’incertezza:aumenta la sensibilità dell’organizzazione ai segnali che la rendono visibile.

Premortem e Agile: anticipare senza tornare alla pianificazione predittiva

Potrebbe sembrare che immaginare preventivamente il fallimento sia in contrasto con il principio Agiledi accogliere il cambiamento. Non è così.

Agile non significa rinunciare alla previsione. Significa evitare di confondereprevisione e certezza.

Un Premortem applicato a un prodotto digitale non dovrebbe produrre un piano più rigido, ma domande migliori da verificare durante discovery e delivery.

Se una possibile causa di fallimento è «abbiamo costruito una funzionalità che gli utenti non consideravano importante», la risposta non dovrebbe essere aggiungere sei mesi di analisi iniziale. Potrebbe essere anticipare un test con gli utenti, costruire un prototipo o definire una metrica di comportamento.

Se il rischio è «l’integrazione con il sistema legacy ha richiesto quattro volte il previsto», la mitigazione potrebbe consistere in unospike tecniconelle prime iterazioni.

Se emerge «il business non era realmente disponibile a dedicare tempo al Product Owner», il team può trasformare quell’assunzione in una condizione esplicita di governance prima di partire.

Il Premortem diventa così complementare ai modelli Agile:non cerca di predire dettagliatamente il futuro, ma identifica le ipotesi la cui falsificazione avrebbe le conseguenze più importanti.

Un caso concreto: la digitalizzazione del processo commerciale

Immaginiamo un’azienda B2B di medie dimensioni che decida di introdurre una nuova piattaforma CRM con l’obiettivo di rendere più affidabile la pipeline commerciale, standardizzare il processo e fornire al management forecast più attendibili.

Il progetto appare ben impostato. Il software è stato selezionato, il budget approvato, il partner tecnologico individuato e il piano prevede sei mesi per configurazione, migrazione, formazione e go-live.

Prima dell’avvio viene organizzato un Premortem con direzione commerciale, IT, marketing, amministrazione, alcuni sales account e il partner di implementazione.

La domanda giusta …

Lo scenario è semplice: «Siamo a dodici mesi da oggi. Il CRM è formalmente operativo, ma il progetto viene considerato un fallimento. Perché?».

Durante la fase individuale emergono ipotesi molto diverse.

Gli account commerciali scrivono che il CRM richiede troppi dati e che, sotto pressione, le persone tornano ai propri fogli Excel.

L’IT ipotizza che la qualità dell’anagrafica clienti renda la migrazione molto più complessa del previsto.

Il marketing segnala che nessuno ha definito con precisione la proprietà dei lead tra marketing e vendite.

Il CFO immagina che il forecast continui a essere inattendibile perché ogni commerciale interpreta diversamente le probabilità associate alle opportunità.

Un area manager introduce il rischio più scomodo: «Il progetto fallisce perché i responsabili commerciali chiedono di usare il CRM, ma continuano a richiedere i report settimanali nei vecchi Excel».

Quest’ultima osservazione cambia la natura del problema.

Il rischio principale non è tecnologico. È la possibilità che l’organizzazione introduca un nuovo strumento mantenendo intatti i comportamenti che il nuovo strumento dovrebbe sostituire.

Il gruppo trasforma quindi le ipotesi in azioni.

Dalla comprensione all’azione

Prima della migrazione completa viene realizzato un test sulla qualità dei dati. Il processo lead-to-opportunity viene definito con responsabilità esplicite. Le probabilità della pipeline vengono associate a criteri osservabili anziché alla percezione del singolo venditore. Un gruppo pilota utilizza il CRM per quattro settimane prima del rollout generale.

Soprattutto, la direzione decide che dopo il go-live il forecast ufficiale verrà prodotto esclusivamente dal CRM. Nessun report parallelo sarà richiesto.

Vengono inoltre definiti tre leading indicator: percentuale di opportunità aggiornate negli ultimi sette giorni, utilizzo di file paralleli e differenza tra forecast e consuntivo.

Il Premortem non ha previsto il futuro. Ha fatto qualcosa di più utile:ha reso visibili le condizioni che avrebbero potuto produrre il fallimento e le ha trasformate in scelte di progetto.

La qualità del dissenso come competenza organizzativa

Il valore del Premortem va oltre il risk management. La tecnica offre infatti una misura indiretta della qualità del sistema sociale nel quale viene utilizzata.

Se durante l’esercizio emergono soltanto rischi generici e impersonali, potrebbe non significare che il progetto sia particolarmente solido. Potrebbe significare che le persone non si sentono ancora autorizzate a mettere in discussione assunzioni, decisioni o comportamenti della leadership.

Per questo il ruolo del facilitatore è delicato.

Una risposta difensiva dello sponsor — «questo problema lo abbiamo già risolto» — può essere sufficiente a ridurre immediatamente la qualità dei contributi successivi. Al contrario, ringraziare chi porta una prospettiva scomoda segnala che l’obiettivo non è proteggere il piano, ma migliorarlo.

In questa prospettiva, il Premortem è anche un piccolo esercizio dipsychological safety. Non perché elimini gerarchie e conflitti, ma perché crea temporaneamente una regola diversa: vedere ciò che gli altri non vedono è un contributo al gruppo, non una minaccia alla coesione.

Le organizzazioni mature non sono quelle nelle quali tutti concordano rapidamente. Sono quelle capaci ditrasformare il dissenso competente in informazione utile prima che sia la realtà a imporlo.

Quando utilizzare il Premortem

La tecnica è particolarmente efficace nei momenti di commitment: prima dell’avvio di un progetto strategico, di un go-live, di un investimento importante, di una trasformazione organizzativa, di una scelta make-or-buy o del lancio di un nuovo prodotto.

Può essere ripetuta anche durante il progetto quando cambiano significativamente contesto o assunzioni.

È meno utile quando viene trasformata in un rituale burocratico o quando le decisioni sono già irreversibili. Se il gruppo sa che nessuna evidenza potrà modificare scope, data, budget o soluzione, il Premortem rischia di diventare una simulazione di apertura senza reale capacità decisionale.

La condizione essenziale è quindi l’esistenza di uno spazio di manovra.

Identificare un rischio senza essere disposti a cambiare nulla non è gestione del rischio. È semplice documentazione dell’impotenza.

Dal Premortem alla governance adattiva

In contesti complessi, la governance non può limitarsi a controllare che il progetto proceda secondo il piano. Deve verificare continuamente seil piano continua a essere sensato.

Qui il Premortem può assumere un ruolo più ampio.

Le principali cause di fallimento immaginate dal team possono diventare oggetto delle review di governance. Non soltanto «siamo nei tempi e nel budget?», ma anche «quali delle condizioni che avevamo identificato come precursori del fallimento stanno iniziando a manifestarsi?».

È un cambiamento significativo.

Le metriche tradizionali misurano spesso lo scostamento dal piano. Gli indicatori derivati dal Premortem misurano invecelo scostamento dalle assunzioni che rendono il piano valido.

Un progetto può essere perfettamente nei tempi e contemporaneamente diretto verso un risultato inutile. Può rispettare il budget mentre l’adozione degli utenti sta crollando. Può completare tutte le milestone mentre il mercato cambia.

La governance adattiva deve saper distinguereperformance di esecuzione e validità strategica.

Immaginare il fallimento per aumentare la capacità di riuscire

Il Premortem contiene un paradosso manageriale interessante: per proteggere un progetto dall’eccesso di pessimismo, spesso le organizzazioni finiscono per proteggerlo dalle informazioni di cui avrebbe bisogno.

Pensare al fallimento non significa essere contrari al progetto. Significa riconoscere cheogni piano è una teoria sul futuroe che una teoria migliora quando viene sottoposta a tentativi seri di falsificazione.

Il valore del metodo non consiste nella costruzione di scenari catastrofici, ma nella creazione di uno spazio nel quale esperienza, intuizioni e dubbi distribuiti nel team possano emergere prima che diventino incidenti.

Per il project manager significa spostare parte dell’attenzione dalla gestione dei problemi alla progettazione delle condizioni che permettono di intercettarli prima, mentre per la leadership significa accettare che il dissenso non indebolisce necessariamente una decisione: se governato correttamente, può renderla più robusta.

Per l’organizzazione significa sviluppare una competenza sempre più importante: non quella di prevedere perfettamente il futuro, ma quella dimettere in discussione le proprie convinzioni abbastanza presto da poter ancora cambiare direzione.

Il postmortem produce conoscenza dopo il fallimento. Il Premortem prova a utilizzare quella stessa conoscenza quando è ancora possibile farne qualcosa.

Ed è forse questa la sua intuizione più potente:una buona organizzazione non aspetta che la realtà dimostri che aveva torto. Costruisce deliberatamente occasioni per scoprirlo prima.

L’articoloPremortem: immaginare il fallimento per progettare decisioni miglioriproviene daManagement Expert.

L'articolo Premortem: immaginare il fallimento per progettare decisioni migliori proviene da neosidea consulting.

L’articolo introduce il concetto diAmbidextrous Organizationcome risposta a una delle tensioni più complesse per le aziende mature: continuare a sfruttare ciò che oggi genera valore senza perdere la capacità di esplorare nuove opportunità.

Un’organizzazione ambidestra non abbandona il presente: lo usa come piattaforma per costruire il futuro.

Il dilemma delle organizzazioni che devono crescere e cambiare allo stesso tempo

Ogni organizzazione matura vive prima o poi una tensione difficile da risolvere.

Da un lato deve continuare a far funzionare ciò che già genera valore. Deve servire i clienti attuali, mantenere margini, ottimizzare processi, rispettare budget, proteggere la qualità e garantire continuità operativa. Dall’altro deve prepararsi a un futuro che potrebbe richiedere competenze, modelli di business, tecnologie, prodotti e modalità di relazione completamente diverse.

È una tensione naturale, ma spesso viene gestita male.

Le aziende chiedono alle stesse strutture di essere contemporaneamente efficienti e sperimentali, prudenti e radicali, stabili e adattive, focalizzate sul risultato trimestrale e orientate alla costruzione del futuro. Il problema è che queste due logiche non funzionano con le stesse regole.

Il business esistente richiede controllo, affidabilità, standardizzazione e miglioramento continuo. L’innovazione richiede esplorazione, incertezza, tolleranza dell’errore e apprendimento rapido.

Quando queste due esigenze vengono confuse, nascono conflitti interni.

Le iniziative innovative vengono giudicate con metriche troppo tradizionali. I team operativi percepiscono l’innovazione come una distrazione. I progetti esplorativi si sentono soffocati dalla burocrazia. Il management oscilla tra entusiasmo per il nuovo e protezione dell’esistente.

È in questo contesto che il concetto diAmbidextrous Organizationdiventa particolarmente utile.

Un’organizzazione ambidestra è un’organizzazione capace di fare due cose apparentemente opposte:sfruttare l’esistente ed esplorare il nuovo.

Non sceglie tra efficienza e innovazione.
Progetta un sistema in grado di farle convivere.

Exploitation ed exploration: due logiche diverse

Per comprendere il significato di ambidestria organizzativa è necessario partire da una distinzione fondamentale:exploitationedexploration.

L’exploitation riguarda lo sfruttamento di ciò che l’organizzazione già conosce. Significa migliorare prodotti esistenti, ottimizzare processi, aumentare efficienza, ridurre costi, consolidare competenze, servire meglio clienti già acquisiti e rafforzare il modello di business attuale.

È il dominio della performance.

L’exploration, invece, riguarda la ricerca di nuove possibilità. Significa sperimentare tecnologie emergenti, esplorare mercati non ancora maturi, validare nuovi modelli di business, costruire competenze non presenti, testare ipotesi, osservare segnali deboli e accettare che molte iniziative non produrranno risultati immediati.

È il dominio dell’apprendimento.

Entrambe sono necessarie.

Un’organizzazione che investe solo in exploitation diventa progressivamente più efficiente nel fare ciò che sa già fare, ma rischia di perdere contatto con il futuro. Un’organizzazione che investe solo in exploration può generare molte idee, ma fatica a trasformarle in valore economico sostenibile.

Il problema strategico non è scegliere tra exploitation ed exploration, ma costruire un equilibrio dinamico tra le due.

Questa è la vera sfida dell’ambidextrous organization.

Perché il conflitto nasce quasi sempre dalle metriche

Molti conflitti tra business esistente e innovazione non nascono da cattiva volontà, ma da metriche incompatibili.

Il core business viene misurato su ricavi, margini, produttività, qualità, efficienza, saturazione delle risorse, rispetto dei budget e riduzione degli sprechi. Queste metriche sono corrette per attività mature, ripetibili e già validate.

L’innovazione, invece, soprattutto nelle sue fasi iniziali, non può essere valutata con gli stessi parametri. Un’iniziativa esplorativa potrebbe non generare ricavi nel breve periodo, avere margini incerti, richiedere investimenti non immediatamente recuperabili e produrre risultati prevalentemente sotto forma di apprendimento.

Se viene giudicata con le metriche del core business, apparirà inevitabilmente inefficiente.

È qui che molte aziende commettono un errore: chiedono all’innovazione di comportarsi come un business maturo prima ancora che abbia avuto il tempo di diventarlo.

Il risultato è prevedibile.

Le iniziative nuove vengono interrotte troppo presto. I team innovativi vengono costretti a giustificare ogni scelta con business case prematuri. I manager del core business le percepiscono come sprechi di risorse. Le persone più orientate alla sperimentazione si frustrano. L’organizzazione conclude che “l’innovazione non funziona”.

Ma spesso non è l’innovazione a non funzionare.

È il sistema di valutazione a essere sbagliato.

Non si può misurare una fase di apprendimento con gli stessi criteri utilizzati per una fase di ottimizzazione.

Un’organizzazione ambidestra comprende questa differenza e costruisce metriche, governance e aspettative coerenti con la natura delle diverse iniziative.

La trappola del “tutto dentro la stessa organizzazione”

Una delle difficoltà principali dell’ambidexterity riguarda la struttura.

Molte aziende cercano di far convivere exploitation ed exploration dentro gli stessi team, con le stesse regole, gli stessi processi decisionali, gli stessi obiettivi e gli stessi sistemi premianti. Apparentemente è una scelta efficiente: si usano risorse già disponibili, si evita duplicazione, si mantiene controllo centrale.

Ma nella pratica può diventare una trappola.

I team che gestiscono il business esistente sono già assorbiti da priorità operative, richieste dei clienti, manutenzione, compliance, efficienza e continuità. Chiedere loro di dedicarsi anche a innovazioni radicali significa spesso aggiungere complessità senza togliere responsabilità.

L’innovazione diventa un’attività residuale, da fare quando c’è tempo. Ma il tempo, nel core business, raramente avanza.

Allo stesso modo, imporre a un team esplorativo le regole del business maturo può soffocare la sperimentazione. Ogni esperimento richiede autorizzazioni, ogni errore diventa un problema, ogni deviazione dal piano viene interpretata come inefficienza.

L’organizzazione ambidestra non nega il conflitto tra le due logiche. Lo riconosce e lo progetta.

La convivenza tra presente e futuro non si ottiene semplicemente mettendoli nella stessa stanza. Si ottiene disegnando interfacce, responsabilità e regole di ingaggio adeguate.

Ambidestria strutturale e ambidestria contestuale

Esistono diversi modi per costruire un’organizzazione ambidestra.

Una prima possibilità è l’ambidestria strutturale. In questo caso l’organizzazione separa fisicamente o organizzativamente le unità dedicate all’exploitation da quelle dedicate all’exploration. Il core business continua a operare con logiche di efficienza, mentre team, innovation lab, venture unit o business unit dedicate lavorano su nuove opportunità con maggiore autonomia.

Questo approccio è utile quando l’innovazione richiede regole molto diverse da quelle del business esistente. Separare permette di proteggere l’esplorazione dalla pressione dell’operatività quotidiana.

Ma la separazione comporta un rischio: creare distanza.

Se l’unità innovativa diventa troppo autonoma, può perdere connessione con le competenze, i clienti, i canali, le operations e le capacità industriali dell’organizzazione madre. In quel caso produce idee interessanti, ma difficili da integrare o scalare.

Una seconda possibilità è l’ambidestria contestuale. In questo caso non si separano necessariamente le strutture, ma si costruisce un contesto organizzativo in cui le persone e i team possono alternare comportamenti orientati all’efficienza e comportamenti orientati all’esplorazione.

Questo approccio richiede una cultura più matura, leadership distribuita, chiarezza strategica, autonomia e sistemi di priorità ben progettati. È più difficile, ma può essere molto potente, soprattutto quando l’innovazione è vicina al core business.

Non esiste una soluzione universalmente migliore.

La scelta tra separare e integrare dipende dalla distanza tra il business attuale e il futuro che si vuole esplorare.

Più l’innovazione è radicale, più può essere utile proteggerla con una struttura separata. Più l’innovazione è adiacente al core business, più può essere efficace integrarla nei team esistenti con regole chiare.

Il ruolo della leadership: tenere insieme logiche incompatibili

L’ambidextrous organization richiede una leadership particolarmente sofisticata.

Non basta promuovere l’innovazione nei discorsi o difendere il core business nei piani economici. Serve una capacità più rara:gestire simultaneamente logiche organizzative diverse senza farle distruggere a vicenda.

I leader devono proteggere il presente, perché senza il presente non esistono risorse per costruire il futuro. Ma devono anche proteggere il futuro, perché senza esplorazione il presente rischia di diventare progressivamente irrilevante.

Questa duplice responsabilità genera tensioni continue.

Quando le risorse sono limitate, il core business tenderà a chiedere più budget per ottimizzare ciò che già funziona. L’innovazione chiederà tempo e investimenti per esplorare ciò che ancora non produce risultati. Entrambe le richieste saranno legittime.

Il compito della leadership non è eliminare la tensione. È renderla produttiva.

Questo significa chiarire quali iniziative appartengono al core, quali sono adiacenti e quali sono esplorative ed evitare che tutte competano nello stesso modo per le stesse risorse. Significa assegnare aspettative diverse a iniziative diverse. Significa costruire momenti di connessione tra chi gestisce l’esistente e chi esplora il nuovo.

La leadership ambidestra non sceglie semplicemente dove investire. Disegna il sistema in cui investimenti diversi possono convivere senza delegittimarsi.

Il caso concreto: la trasformazione di FoodService Italia

Immaginiamo un’azienda ipotetica ma realistica, che chiameremoFoodService Italia.

FoodService Italia è un’impresa consolidata nella distribuzione alimentare per ristoranti, mense aziendali, hotel e piccole catene locali. Il suo successo si è costruito su una rete logistica affidabile, relazioni commerciali solide, capacità di gestire prodotti freschi e un servizio clienti molto vicino al territorio.

Per anni il modello ha funzionato bene.

I clienti ordinano attraverso agenti commerciali, telefonate, email e, in alcuni casi, un portale B2B di base. La forza dell’azienda è la relazione: i clienti conoscono i referenti, gli agenti conoscono le abitudini di acquisto, la logistica riesce a rispondere con flessibilità.

Negli ultimi anni, però, il mercato cambia.

Crescono le piattaforme digitali di procurement. I ristoratori più giovani vogliono ordinare fuori orario. Alcuni clienti chiedono tracciabilità, suggerimenti automatici, disponibilità in tempo reale, prodotti alternativi in caso di stock-out. La concorrenza introduce modelli più digitali, con prezzi dinamici e promozioni personalizzate.

Il core business di FoodService Italia resta solido, ma il management percepisce una domanda strategica: il modello relazionale che ha garantito crescita negli ultimi vent’anni sarà sufficiente anche nei prossimi dieci?

L’azienda decide quindi di costruire una strategia ambidestra.

Sfruttare l’esistente: rafforzare il core business

Nel dominio dell’exploitation, FoodService Italia lavora per migliorare il modello attuale.

Non lo abbandona. Non lo considera superato. Al contrario, riconosce che la rete commerciale, la logistica e la conoscenza dei clienti sono asset fondamentali.

L’azienda investe nell’ottimizzazione delle rotte, nella riduzione degli errori d’ordine, nel miglioramento del customer service e nell’integrazione dei dati tra agenti, magazzini e amministrazione. Introduce strumenti digitali per supportare la forza vendita, consentendo agli agenti di avere visibilità più precisa su storico acquisti, disponibilità, marginalità e promozioni.

Queste iniziative hanno metriche chiare: riduzione dei costi logistici, aumento del livello di servizio, miglioramento della puntualità, riduzione degli errori, incremento del margine per cliente.

Sono interventi di Horizon 1, legati alla performance del business esistente.

L’azienda non sacrifica il presente sull’altare dell’innovazione. Lo rende più forte.

Questo passaggio è essenziale perché spesso l’innovazione viene percepita come una minaccia proprio quando sembra disconoscere il valore di ciò che già funziona. FoodService Italia evita questo errore: parte dal core, lo migliora e lo usa come piattaforma per esplorare il nuovo.

Esplorare il nuovo: una unità digitale protetta

Parallelamente, l’azienda crea una piccola unità dedicata all’esplorazione di nuovi modelli digitali.

Non si tratta semplicemente del reparto IT. Il team include competenze di prodotto, marketing, operations, customer experience, data analysis e alcuni agenti commerciali particolarmente aperti all’innovazione.

Il mandato non è sostituire il canale commerciale tradizionale, ma esplorare una nuova modalità di relazione con alcuni segmenti di clientela.

Il team lavora su una piattaforma digitale più evoluta, pensata inizialmente per piccoli ristoratori urbani, chef indipendenti e locali con forte rotazione del menu. Il nuovo servizio consente di visualizzare disponibilità aggiornate, ricevere suggerimenti di prodotti alternativi, riordinare rapidamente, accedere a offerte personalizzate e pianificare consegne ricorrenti.

Questa iniziativa non viene valutata subito con le metriche del core business.

Nei primi mesi, il management osserva soprattutto il livello di adozione, la frequenza di utilizzo, la qualità degli insight raccolti, la riduzione delle telefonate operative, la capacità di intercettare clienti non serviti efficacemente dal modello tradizionale.

Il team esplorativo può sperimentare, ma non è isolato. Mantiene contatto con logistica, agenti, customer service e direzione commerciale.

L’innovazione viene protetta, ma non separata dalla realtà operativa.

Il conflitto con la rete commerciale

Nonostante le buone intenzioni, il conflitto emerge.

Alcuni agenti percepiscono la piattaforma digitale come una minaccia al proprio ruolo. Temono che il cliente, ordinando in autonomia, riduca il valore della relazione commerciale. Altri considerano il nuovo canale poco adatto al settore, sostenendo che “i clienti vogliono parlare con una persona”.

Il team digitale, dal canto suo, percepisce la rete commerciale come un freno. Ogni proposta viene discussa, rallentata, messa in dubbio. Alcuni esperimenti vengono ostacolati perché non coerenti con le abitudini consolidate.

Questo è il punto critico di ogni organizzazione ambidestra.

Il conflitto non nasce perché qualcuno ha torto. Nasce perché due logiche diverse stanno cercando di convivere.

La rete commerciale protegge un modello che funziona.
Il team digitale esplora un modello che potrebbe funzionare domani.

Se il management lasciasse la tensione irrisolta, l’organizzazione si dividerebbe. Da un lato i difensori del core business, dall’altro i promotori dell’innovazione.

FoodService Italia decide quindi di intervenire non sul conflitto superficiale, ma sul disegno organizzativo.

Disegnare l’interfaccia tra presente e futuro

Il management chiarisce tre elementi.

Il primo riguarda il ruolo della piattaforma digitale. Non nasce per sostituire gli agenti, ma per ridurre attività operative a basso valore e liberare tempo commerciale per consulenza, sviluppo clienti e gestione di opportunità complesse.

Il secondo riguarda le metriche. La rete commerciale non viene penalizzata se un cliente utilizza il canale digitale. Al contrario, l’adozione digitale viene integrata tra gli indicatori di qualità del presidio commerciale, perché un cliente che ordina meglio, con meno errori e più continuità, genera valore per tutto il sistema.

Il terzo riguarda la collaborazione. Alcuni agenti vengono coinvolti nella discovery con i clienti, contribuendo a identificare bisogni reali, ostacoli, linguaggi e funzionalità utili. In questo modo non subiscono l’innovazione, ma partecipano alla sua costruzione.

Questa scelta modifica la percezione interna.

La piattaforma non è più “il progetto del digitale”. Diventa uno strumento per evolvere la relazione con il cliente.

Il conflitto diminuisce quando l’innovazione smette di apparire come alternativa al core business e diventa un’estensione della sua capacità di generare valore.

I risultati della trasformazione ambidestra

Dopo alcuni mesi, FoodService Italia osserva risultati interessanti.

Il core business migliora grazie all’ottimizzazione operativa. Gli errori d’ordine diminuiscono, la disponibilità delle informazioni aumenta, la rete vendita lavora con dati più affidabili.

Nel frattempo, la piattaforma digitale mostra segnali promettenti su segmenti specifici. Non tutti i clienti la adottano, ma quelli più dinamici iniziano a usarla con frequenza. Le richieste ripetitive al customer service diminuiscono. Gli agenti più coinvolti iniziano a usare la piattaforma come supporto alla relazione, non come minaccia.

L’iniziativa esplorativa non ha ancora sostituito il modello tradizionale. Ma ha costruito una nuova capacità organizzativa: servire alcuni clienti attraverso un mix più evoluto di relazione umana, dati e autonomia digitale.

Questo è il vero valore dell’ambidexterity.

Non produrre innovazione come oggetto separato, ma trasformare progressivamente la capacità dell’organizzazione di evolvere.

FoodService Italia non sceglie tra agente e piattaforma. Impara a progettare una relazione cliente più ampia, in cui entrambi possono generare valore.

Gli errori più comuni nelle organizzazioni ambidestre

Il primo errore è creare unità innovative completamente scollegate dal core business. Possono produrre idee interessanti, ma faticano a scalare perché non hanno accesso alle capacità operative dell’organizzazione.

Il secondo errore è non proteggerle abbastanza. Se le nuove iniziative vengono immerse troppo presto nelle logiche del business esistente, vengono soffocate prima di maturare.

Il terzo errore è usare le stesse metriche per tutto. Un progetto di efficienza operativa, una nuova linea di business e un esperimento radicale non possono essere valutati nello stesso modo.

Il quarto errore è sottovalutare la dimensione politica del cambiamento. L’innovazione modifica ruoli, potere, identità professionali e sistemi di riconoscimento. Se questi elementi non vengono gestiti, il conflitto emergerà comunque.

Il quinto errore è parlare di innovazione senza modificare realmente governance, budget, responsabilità e processi decisionali.

L’ambidestria non è una dichiarazione strategica. È un disegno organizzativo.

Il rapporto con Agile e Innovation Management

L’ambidextrous organization ha un rapporto molto forte con Agile e Innovation Management.

Gli approcci Agileaiutano a gestire exploration attraverso cicli brevi, feedback continui, sperimentazione e apprendimento iterativo. Le logiche di Innovation Management aiutano a costruire portafogli di iniziative, distinguere livelli di incertezza, proteggere idee immature e trasformare opportunità in modelli scalabili.

Ma l’ambidexterity aggiunge una dimensione ulteriore: il rapporto tra innovazione e organizzazione esistente.

Non basta avere team Agile.
Né avere innovation lab.
Non basta generare idee.

Serve capire come il nuovo dialoga con l’esistente. Come viene finanziato, misurato, integrato, protetto e scalato. Come evita di essere percepito come minaccia.

In questo senso, l’ambidextrous organization è una delle forme più mature di gestione dell’innovazione, perché riconosce che il problema non è solo trovare nuove idee, ma creare le condizioni perché possano convivere con il sistema che oggi genera valore.

Il futuro non deve distruggere il presente

La lezione più importante dell’ambidextrous organization è che l’innovazione non deve necessariamente nascere contro il core business.

Può nascere accanto, dialogando.
Emergere protetta, ma connessa.
Può utilizzare le risorse del presente per costruire possibilità future.

Allo stesso tempo, il core business non deve diventare una forza di conservazione cieca. Deve riconoscere che ciò che oggi produce valore potrebbe non bastare domani. Deve accettare che una parte dell’organizzazione lavori con logiche diverse, metriche diverse e livelli di incertezza diversi.

Questo equilibrio è difficile, ma necessario.

Un’azienda che sa solo sfruttare ciò che esiste diventa efficiente, ma vulnerabile. Un’azienda che sa solo esplorare il nuovo diventa creativa, ma fragile. Un’organizzazione ambidestra prova a tenere insieme entrambe le capacità.

Il caso FoodService Italia mostra che il conflitto tra presente e futuro non si elimina con una dichiarazione di intenti. Si riduce attraverso un disegno organizzativo coerente: ruoli chiari, metriche adeguate, interfacce ben progettate, leadership capace di proteggere sia il core business sia l’esplorazione.

In ultima analisi, l’ambidestria organizzativa non è la capacità di fare tutto.

È la capacità difare cose diverse con logiche diverse, senza perdere coerenza strategica.

Perché il vero vantaggio competitivo non nasce solo dal difendere ciò che funziona oggi, né solo dall’inseguire ciò che potrebbe funzionare domani.

Nasce dalla capacità di trasformare il presente in una piattaforma per costruire il futuro.

L’articoloAmbidextrous Organization: sfruttare l’esistente ed esplorare il nuovo senza creare conflitto internoproviene daManagement Expert.

L'articolo Ambidextrous Organization: sfruttare l’esistente ed esplorare il nuovo senza creare conflitto interno proviene da neosidea consulting.

L’articolo presenta ilRolling Wave Planningcome approccio utile per pianificare progetti complessi quando il futuro non è ancora completamente chiaro.
Il punto di partenza è il limite della pianificazione tradizionale: pretendere troppo dettaglio all’inizio può generare una falsa sensazione di controllo.
Nei contesti incerti, molte informazioni emergono solo avanzando nel progetto, attraverso analisi, feedback, vincoli e decisioni progressive.
Il Rolling Wave Planning propone quindi di pianificare in dettaglio ciò che è vicino e mantenere più generale ciò che è ancora lontano o incerto.
Questo permette di unire direzione strategica e capacità di adattamento.
Il modello si collega bene agli approcci Agile e iterativo-incrementali, perché considera la pianificazione come un processo continuo.
Attraverso il caso LogiFarm, l’articolo mostra come un programma di trasformazione digitale possa essere gestito per onde successive.
Ogni onda consente di produrre risultati, ridurre incertezza e rendere più chiara la pianificazione della fase successiva.
Il ruolo del Project Manager diventa quello di facilitare apprendimento, riallineamento e governance progressiva.
Il valore del metodo sta nel proteggere l’obiettivo senza irrigidire il percorso.
Pianificare, nei progetti complessi, significa rendere il futuro progressivamente governabile.

Il paradosso della pianificazione nei progetti complessi

Ogni progetto nasce con un’esigenza di chiarezza.

Il management vuole sapere tempi, costi, obiettivi, milestone, rischi, dipendenze e risultati attesi. Gli stakeholder chiedono previsioni affidabili. I team hanno bisogno di orientamento. I clienti vogliono comprendere quando vedranno valore. I fornitori devono coordinarsi. La governance richiede piani, responsabilità e criteri di controllo.

Tutto questo è legittimo.

Un progetto senza pianificazione rischia di trasformarsi in improvvisazione. Ma un progetto pianificato troppo in dettaglio quando le informazioni sono ancora immature rischia di produrre un’altra forma di errore:l’illusione del controllo.

È uno dei paradossi più frequenti nella gestione progettuale. Si chiede precisione proprio nel momento in cui il contesto non consente ancora precisione, si costruiscono piani dettagliati su elementi ancora incerti. Si definiscono date, effort e sequenze operative per attività che, nella realtà, diventeranno chiare solo dopo aver completato le prime fasi di lavoro.

Il risultato è un piano apparentemente solido, ma fragile nella sostanza.

Appena il progetto incontra la realtà, emergono informazioni nuove. Alcune ipotesi si rivelano incomplete. Le dipendenze cambiano. I vincoli tecnici si chiariscono. Gli stakeholder modificano priorità. I rischi iniziali assumono forme diverse. Il team comprende meglio il lavoro solo dopo aver iniziato a svolgerlo.

A quel punto l’organizzazione può reagire in due modi.

Può continuare a difendere il piano iniziale, trattando ogni deviazione come un problema. Oppure può riconoscere che, nei progetti complessi, la pianificazione non è un atto unico da completare all’inizio, ma un processo continuo di progressiva comprensione.

È qui che entra in gioco ilRolling Wave Planning.

Il suo principio è semplice:pianificare in dettaglio ciò che è vicino e mantenere a un livello più alto ciò che è ancora lontano o incerto. Secondo la definizione riportata da ProjectManagement.com, il Rolling Wave Planning consiste nel pianificare “a onde” man mano che il progetto procede e i dettagli successivi diventano più chiari; il PMI lo descrive come un approccio in cui il piano si sviluppa progressivamente per il futuro prevedibile e viene rivalutato periodicamente in termini di tempi e costi.

Questa logica non elimina la pianificazione. La rende più intelligente.

Pianificare non significa prevedere tutto

Nella cultura manageriale tradizionale, pianificare è spesso associato all’idea di anticipare. Più un piano è dettagliato, più viene percepito come serio. Più contiene date, attività, responsabilità, deliverable e dipendenze, più sembra offrire controllo.

Ma questa associazione non è sempre corretta.

Nei progetti ad alta incertezza, il dettaglio prematuro può generare falsa sicurezza. Il piano diventa una rappresentazione elegante di ipotesi non ancora verificate. Le persone iniziano a discutere scostamenti rispetto a una previsione che non aveva basi sufficientemente solide. Il progetto viene misurato contro una mappa disegnata prima di conoscere davvero il territorio.

Il problema non è pianificare. Il problema è confondere la pianificazione con la previsione totale del futuro.

Rolling Wave Planning aiuta a superare questa confusione. Non chiede di rinunciare alla visione complessiva. Al contrario, richiede di mantenerla. Ma distingue tra ciò che può essere pianificato in modo dettagliato e ciò che deve restare volutamente più generale fino a quando emergeranno informazioni migliori.

È una forma di disciplina, non di approssimazione.

Pianificare a onde significa accettare che la conoscenza del progetto non sia uniforme lungo tutta la sua durata. Le attività più vicine sono più comprensibili, più stimabili e più controllabili. Le attività più lontane sono più esposte a incertezza, cambiamento e apprendimento.

Pretendere lo stesso livello di dettaglio su entrambe le dimensioni non aumenta il controllo. Aumenta solo il rischio di costruire piani che dovranno essere continuamente riscritti.

Che cos’è il Rolling Wave Planning

Il Rolling Wave Planning è una tecnica di pianificazione progressiva utilizzata nel project management per gestire contesti in cui il progetto è noto a livello generale, ma non ancora completamente definibile nei dettagli.

La logica è quella dell’elaborazione progressiva: il piano viene costruito e aggiornato man mano che il progetto avanza, le informazioni aumentano e le incertezze si riducono. PMI descrive il metodo come un approccio capace di soddisfare l’esigenza degli sponsor di avere visibilità a lungo termine, mantenendo al tempo stesso la possibilità per il team di cambiare rotta quando emergono nuove informazioni o feedback.

In pratica, si lavora su due livelli.

Il primo livello riguarda la visione complessiva del progetto: obiettivi, macro-fasi, milestone principali, vincoli rilevanti, budget indicativo, risultati attesi e sequenza logica generale.

Il secondo livello riguarda il dettaglio operativo delle attività più vicine: task, responsabilità, effort, dipendenze, deliverable, criteri di completamento, rischi specifici e modalità di controllo.

Quando una “onda” di lavoro si avvicina, viene pianificata con maggiore precisione. Quando viene completata, ciò che è stato appreso viene utilizzato per dettagliare l’onda successiva.

Il progetto viene quindi governato attraverso una combinazione di direzione stabile e dettaglio progressivo.

Questa è la differenza più importante rispetto a una pianificazione predittiva rigida. Non si tratta di decidere tutto all’inizio, ma nemmeno di procedere senza una struttura. Si tratta di costruire un piano che evolve con la conoscenza.

Il rapporto con Agile e approcci iterativo-incrementali

Rolling Wave Planning viene spesso associato ai contesti predittivi, ma il suo spirito è profondamente compatibile con gli approcci Agile e iterativo-incrementali.

In Agile, infatti, non si pianifica tutto il prodotto nel dettaglio fin dal primo giorno. Esiste una visione di prodotto, una roadmap, un backlog, priorità evolutive e cicli brevi di lavoro. Il team dettaglia ciò che è prossimo alla realizzazione, mentre gli elementi più lontani restano a un livello più alto fino a quando non diventano abbastanza maturi.

In questo senso, il Rolling Wave Planning rappresenta un ponte tra due mondi che spesso vengono contrapposti inutilmente: pianificazione e adattamento.

Nei contesti Agile, la pianificazione non scompare. Si distribuisce nel tempo. La roadmap fornisce direzione, il release planning offre una visione intermedia, lo sprint planning dettaglia il lavoro immediato. Un articolo del PMI sul ciclo di vita Agile descrive proprio questa logica: mantenere una visione complessiva del perimetro e della timeline, pianificando però nel dettaglio solo il periodo immediatamente davanti al team.

Questa distinzione è essenziale.

Molte organizzazioni pensano che Agile significhi assenza di piano, mentreAgilesignifica pianificazione continua. Allo stesso modo, molte organizzazioni pensano che project management significhi piano fisso, mentre una buona gestione progettuale richiede capacità di adattamento.

Rolling Wave Planning dimostra che pianificare e adattarsi non sono opposti. Sono due dimensioni della stessa maturità manageriale.

Il valore della prossimità

Il Rolling Wave Planning si fonda su un principio spesso trascurato: la qualità della pianificazione dipende dalla prossimità.

Ciò che è vicino è più leggibile.
Ciò che è lontano è più incerto.

Questa affermazione sembra intuitiva, ma molte organizzazioni continuano a comportarsi come se non fosse vera. Chiedono lo stesso livello di dettaglio per attività che inizieranno la settimana successiva e per attività previste tra otto mesi. Pretendono stime simili per deliverable già compresi e per deliverable ancora dipendenti da decisioni future.

Questa simmetria artificiale produce distorsioni.

Il team è costretto a stimare ciò che non conosce. Gli stakeholder assumono quelle stime come impegni. Il piano diventa una promessa. Quando la realtà cambia, il progetto viene percepito come in ritardo, anche se il vero errore era stato chiedere precisione troppo presto.

Rolling Wave Planning introduce invece una forma più onesta di pianificazione.

Accetta che il dettaglio abbia valore solo quando è sostenuto da informazioni sufficienti. E riconosce che l’incertezza non va mascherata, ma gestita.

La maturità di un piano non si misura dalla quantità di dettagli che contiene, ma dalla coerenza tra dettaglio e conoscenza disponibile.

Questa frase dovrebbe guidare molte decisioni di project management.

La differenza tra incertezza e disordine

Un aspetto importante del Rolling Wave Planning è la distinzione tra incertezza e disordine.

L’incertezza è fisiologica. Esiste quando non tutte le informazioni sono ancora disponibili, ma il progetto ha una direzione, una struttura e un metodo per apprendere progressivamente.

Il disordine, invece, nasce quando non esiste una logica chiara di avanzamento. Le decisioni sono casuali, le priorità cambiano senza criterio, i deliverable non sono definiti, le responsabilità restano ambigue e il team lavora in modo reattivo.

Rolling Wave Planning non giustifica il disordine. Al contrario, lo contrasta.

Permette di dire: non conosciamo ancora tutto, ma sappiamo come gestire ciò che non conosciamo. Sappiamo quali parti del progetto sono già dettagliabili e quali devono restare a livello macro, sappiamo quando rivedremo il piano. Sappiamo quali informazioni servono per dettagliare la prossima onda.

Questa distinzione è fondamentale anche nella relazione con gli stakeholder.

Dire “non possiamo pianificare tutto ora” può essere percepito come debolezza. Dire “pianificheremo in dettaglio per onde successive, sulla base di decision point espliciti e informazioni progressivamente validate” comunica invece un approccio strutturato.

L’incertezza governata è molto diversa dall’improvvisazione.

Rolling Wave Planning serve proprio a rendere questa differenza visibile.

Il ruolo del Project Manager

Nel Rolling Wave Planning, il ruolo del Project Manager cambia profondamente.

Non è più soltanto il custode del piano iniziale. Diventa il facilitatore di un processo continuo di pianificazione, apprendimento e riallineamento.

Questo richiede competenze diverse.

Il Project Manager deve saper costruire una visione complessiva abbastanza chiara da orientare gli stakeholder, ma abbastanza flessibile da accogliere nuove informazioni. Deve saper distinguere tra cambiamenti che rappresentano rumore e cambiamenti che derivano da apprendimento reale. Deve proteggere il team dall’illusione di una precisione prematura e, al tempo stesso, proteggere il management dal rischio di perdere visibilità.

È un ruolo di equilibrio.

Da un lato, il Project Manager deve evitare che l’organizzazione usi l’incertezza come alibi per non pianificare. Dall’altro, deve evitare che la governance imponga una pianificazione dettagliata dove il contesto non la consente ancora.

Il Project Manager maturo non difende il piano a ogni costo. Difende la qualità del processo di pianificazione.

Questo significa aggiornare il piano in modo disciplinato, documentare le ipotesi, rendere visibili le decisioni, esplicitare i livelli di confidenza delle stime, chiarire quando e perché un dettaglio verrà elaborato più avanti.

Il ruolo degli stakeholder

Rolling Wave Planning richiede anche una diversa maturità da parte degli stakeholder.

In molte organizzazioni, gli stakeholder vogliono contemporaneamente due cose: certezza iniziale e massima flessibilità successiva, vogliono un piano dettagliato, ma anche la possibilità di cambiare priorità, vogliono date certe, ma anche adattamento continuo. Vogliono controllo, ma non sempre accettano il costo della complessità.

Il Rolling Wave Planning aiuta a rendere esplicito questo compromesso.

Il piano iniziale offre visibilità, non certezza assoluta. Le onde successive offrono progressivo dettaglio, non libertà illimitata. Ogni revisione del piano deve essere collegata a nuove informazioni, decisioni consapevoli o cambiamenti reali di contesto.

Questo approccio migliora la relazione con gli stakeholder perché sposta la conversazione dal “perché il piano è cambiato?” al “quali informazioni nuove giustificano l’evoluzione del piano?”.

La differenza è sostanziale.

Nel primo caso, il cambiamento viene vissuto come deviazione.
Nel secondo, viene trattato come apprendimento.

Rolling Wave Planning trasforma il piano da promessa immobile a strumento vivo di governo del progetto.

Quando utilizzare il Rolling Wave Planning

Il Rolling Wave Planning è particolarmente utile quando il progetto ha una direzione generale chiara, ma non dispone ancora di tutte le informazioni necessarie per pianificare ogni dettaglio.

È adatto a progetti complessi, programmi di trasformazione, iniziative digitali, progetti di innovazione, implementazioni software, cambiamenti organizzativi, programmi con molte dipendenze, contesti in cui gli stakeholder apprendono lungo il percorso o in cui la soluzione finale richiede progressiva elaborazione.

Non è invece necessario quando il lavoro è completamente noto, ripetitivo, stabile e altamente prevedibile. In quei casi, una pianificazione dettagliata iniziale può essere efficace e più efficiente.

Il punto non è usare Rolling Wave Planning sempre.
Il punto è usarlo quando il livello di incertezza lo rende appropriato.

Ogni metodo di pianificazione dovrebbe essere coerente con il grado di conoscenza disponibile e con la natura del contesto.

Questa è una regola fondamentale del project management moderno.

Il caso concreto: la trasformazione digitale di LogiFarm

Immaginiamo un’azienda ipotetica, ma realistica, che chiameremoLogiFarm.

LogiFarm è un’impresa italiana attiva nella distribuzione di prodotti agroalimentari freschi verso supermercati, ristorazione e piccoli rivenditori. Il suo business dipende da tempi rapidi, tracciabilità, controllo della qualità, gestione delle scadenze e coordinamento tra magazzini, trasportatori, clienti e fornitori.

Negli ultimi anni l’azienda è cresciuta rapidamente, ma i processi interni sono rimasti in parte frammentati. Alcune attività sono gestite tramite ERP, altre con fogli Excel, altre ancora attraverso comunicazioni informali tra magazzini e ufficio commerciale.

Il management decide quindi di avviare un programma di trasformazione digitale per creare una piattaforma integrata di gestione ordini, disponibilità, tracciabilità, consegne e monitoraggio qualità.

L’obiettivo è chiaro.
La soluzione, però, non lo è ancora del tutto.

Fin dall’inizio emergono molte incertezze. I processi non sono uniformi tra i magazzini. Alcune regole operative sono implicite. La qualità dei dati non è nota. I fornitori hanno livelli diversi di digitalizzazione. I clienti chiedono funzionalità differenti. Le integrazioni con l’ERP esistente devono essere analizzate.

In un approccio tradizionale, l’organizzazione potrebbe tentare di costruire un piano completo di dodici mesi, con tutte le funzionalità dettagliate, le date di rilascio e le dipendenze definite. Ma sarebbe un piano fragile, perché poggerebbe su troppe assunzioni.

LogiFarm decide quindi di adottare il Rolling Wave Planning.

La prima onda: comprendere e stabilizzare

La prima onda viene pianificata in dettaglio per i primi tre mesi.

L’obiettivo non è costruire subito l’intera piattaforma, ma comprendere e stabilizzare le fondamenta del progetto. Il team lavora sulla mappatura dei processi principali, sull’analisi della qualità dei dati, sull’identificazione delle integrazioni critiche, sulla definizione del modello informativo e sulla realizzazione di un primo modulo pilota per la gestione disponibilità in un solo magazzino.

Questa onda è pianificata con precisione: attività, responsabilità, deliverable, incontri con gli stakeholder, criteri di validazione, rischi e milestone.

Il resto del progetto, invece, resta pianificato a un livello più alto. Sono note le macro-aree future: estensione agli altri magazzini, gestione ordini avanzata, tracciabilità lotti, monitoraggio consegne, dashboard qualità, portale clienti. Ma non vengono ancora dettagliate tutte le attività.

Durante la prima onda emergono informazioni decisive. Alcuni dati di disponibilità non sono affidabili. Le regole di prenotazione prodotto variano tra clienti. L’integrazione con il sistema di trasporto è più complessa del previsto. Alcuni magazzini utilizzano codifiche differenti.

Queste scoperte non vengono trattate come deviazioni dal piano. Sono il motivo stesso per cui si è scelto il Rolling Wave Planning.

La prima onda non serve solo a produrre deliverable. Serve a rendere pianificabile la seconda.

La seconda onda: estendere con maggiore consapevolezza

Terminata la prima onda, LogiFarm aggiorna il piano.

La seconda onda viene ora dettagliata con informazioni migliori. L’obiettivo diventa estendere il modulo disponibilità a tre magazzini, uniformare le regole di prenotazione prodotto, costruire le prime integrazioni con ERP e trasportatori, e avviare una dashboard operativa per il customer service.

Grazie all’apprendimento precedente, le stime sono più realistiche. Alcune attività previste inizialmente vengono anticipate, altre posticipate, altre eliminate. Il team comprende che il portale clienti, inizialmente considerato prioritario, avrebbe poco valore senza dati affidabili sulla disponibilità e sulle consegne. Viene quindi spostato in una fase successiva.

Questa scelta produce una conversazione importante con il management.

Non si tratta di ridurre l’ambizione del progetto, ma di modificare la sequenza per aumentare la probabilità di successo.

Rolling Wave Planning permette di proteggere l’obiettivo cambiando il percorso.

Questa è una delle sue caratteristiche più importanti. Il piano non viene aggiornato perché il team non ha rispettato gli impegni. Viene aggiornato perché l’organizzazione ha imparato qualcosa che rende possibile una pianificazione migliore.

La terza onda: consolidare e scalare

Nella terza onda, LogiFarm può finalmente pianificare con maggiore precisione le funzionalità più visibili per il cliente.

La piattaforma inizia a includere tracciabilità lotti, stato delle consegne, notifiche, report qualità e prime funzionalità self-service per i clienti più strutturati.

A questo punto molte incertezze iniziali sono state ridotte. I processi sono più chiari, i dati più affidabili, le integrazioni principali validate, le regole operative più uniformi. La pianificazione può quindi diventare più dettagliata anche su attività che, all’inizio del progetto, sarebbero state troppo speculative.

Il management percepisce maggiore controllo, non perché tutto fosse stato deciso all’inizio, ma perché il progetto ha costruito progressivamente le condizioni per decidere meglio.

Il team, a sua volta, lavora con meno ambiguità. Gli stakeholder comprendono meglio la logica delle sequenze. Le aspettative diventano più realistiche.

Il controllo non nasce dalla rigidità del piano iniziale, ma dalla qualità del riallineamento continuo.

I benefici per la governance progettuale

Nel caso LogiFarm, il Rolling Wave Planning produce diversi benefici.

Il primo è la riduzione della falsa precisione. L’azienda evita di dettagliare in anticipo attività che non sarebbe stata in grado di stimare correttamente.

Il secondo è il miglioramento della qualità delle decisioni. Ogni onda produce informazioni che alimentano la successiva, rendendo il piano progressivamente più affidabile.

Il terzo è una maggiore trasparenza verso gli stakeholder. Le aree incerte non vengono nascoste, ma collocate consapevolmente nelle onde future.

Il quarto è una migliore gestione del rischio. Le incertezze più critiche vengono affrontate prima, così da evitare che esplodano quando il progetto è già troppo avanzato.

Il quinto è una maggiore adattabilità. Il progetto resta orientato agli obiettivi, ma può modificare il percorso sulla base dell’apprendimento.

In sintesi, Rolling Wave Planning aiuta a costruire una governance progettuale più matura, perché distingue tra ciò che deve essere deciso ora e ciò che sarà più responsabile decidere dopo.

Gli errori più comuni

Il primo errore è usare il Rolling Wave Planning come scusa per non pianificare. Alcuni team interpretano l’incertezza come autorizzazione a procedere in modo vago. Ma il modello richiede esattamente il contrario: pianificare molto bene ciò che è prossimo e mantenere ordinato ciò che è futuro.

Il secondo errore è non definire chiaramente la durata delle onde e i momenti di revisione. Senza cadence, il piano rischia di aggiornarsi in modo casuale.

Il terzo errore è non esplicitare le ipotesi. Se le ipotesi restano implicite, diventa difficile capire perché il piano debba essere aggiornato.

Il quarto errore è trattare ogni revisione come una crisi. In un approccio rolling wave, il piano deve evolvere. La revisione non è un fallimento, ma una parte integrante del metodo.

Il quinto errore è non coinvolgere gli stakeholder. Se la logica delle onde non viene condivisa, gli stakeholder continueranno a interpretare il piano iniziale come un impegno rigido su tutto il perimetro.

Rolling Wave Planning funziona solo se l’organizzazione comprende che il dettaglio progressivo non è mancanza di controllo, ma controllo proporzionato alla conoscenza disponibile.

Rolling Wave Planning e cultura manageriale

Applicare Rolling Wave Planning richiede anche un cambiamento culturale.

Significa accettare che non tutte le risposte siano disponibili all’inizio, significa riconoscere che l’apprendimento non è una deviazione dalla pianificazione, ma una sua componente, significa distinguere tra impegno sugli obiettivi e flessibilità sul percorso.

Questa cultura non è sempre facile da costruire.

Molti manager sono stati abituati a interpretare il piano come una promessa. Ogni modifica sembra una perdita di controllo, ogni incertezza sembra un rischio da nascondere, ogni revisione sembra una giustificazione.

Rolling Wave Planning propone invece una visione più adulta della pianificazione:un piano non è il tentativo di congelare il futuro, ma uno strumento per prendere decisioni migliori mentre il futuro si chiarisce.

Questa prospettiva è particolarmente importante nei contesti di trasformazione digitale, innovazione e cambiamento organizzativo, dove il livello di conoscenza aumenta proprio attraverso l’azione.

Pianificare ciò che si conosce, governare ciò che ancora non si conosce

Rolling Wave Planning offre una risposta concreta a una delle tensioni più difficili del project management: la necessità di pianificare anche quando il futuro non è ancora abbastanza chiaro.

Non propone di rinunciare alla pianificazione, di procedere per tentativi casuali.
Non propone di sostituire il piano con l’improvvisazione.

Propone qualcosa di più maturo: adattare il livello di dettaglio al livello di conoscenza disponibile.

In un mondo stabile, forse sarebbe possibile definire tutto all’inizio. Ma nei progetti complessi, digitali, organizzativi o innovativi, questa aspettativa è spesso irrealistica. Ciò che serve non è un piano perfetto, ma un sistema di pianificazione capace di evolvere.

Il caso LogiFarm mostra come questo approccio consenta di mantenere direzione, controllo e governance senza sacrificare l’apprendimento. Le prime onde chiariscono il contesto. Le successive trasformano quella conoscenza in pianificazione più precisa. Il progetto avanza non perché tutto era noto fin dall’inizio, ma perché l’organizzazione ha costruito un metodo per conoscere meglio lungo il percorso.

Questa è la vera forza del Rolling Wave Planning.

Aiuta a proteggere l’obiettivo senza irrigidire il percorso e a dare visibilità senza promettere falsa certezza.
Aiuta a governare il progetto mentre il progetto rivela progressivamente la propria realtà.

Perché pianificare, nei contesti complessi, non significa fingere che il futuro sia già chiaro.

Significa costruire il modo migliore per renderlo progressivamente governabile.

L’articoloRolling Wave Planning: pianificare quando il futuro non è ancora abbastanza chiaroproviene daManagement Expert.

L'articolo Rolling Wave Planning: pianificare quando il futuro non è ancora abbastanza chiaro proviene da neosidea consulting.