Convertire l’incertezza in valore tangibile, ovvero fare del cambiamento la vera stabilità

L’impossibilità di pianificare tutto nei progetti di innovazione digitale ha portato a un cambio di paradigma nella gestione progettuale. Oggi, la metodologia Agile ha sostituito in gran parte l’approccio Waterfall per diversi motivi: 

• Adattabilità ai cambiamenti: l’Agile abbraccia il cambiamento come parte integrante del processo. I piani sono definiti a breve termine, concentrandosi su piccole iterazioni incrementali. Questo consente di apportare modifiche in modo rapido e flessibile, evitando di compromettere l'intero progetto. 
• Approccio centrato sull’utente: l’Agile enfatizza il coinvolgimento continuo degli utenti finali e degli stakeholder. Il prodotto evolve in base ai loro feedback, garantendo che le risorse siano utilizzate per creare valore reale. 
• Riduzione del rischio: poiché i team rilasciano incrementi funzionanti del prodotto a intervalli regolari, si identificano e si risolvono eventuali problemi prima che diventino troppo costosi o complessi da affrontare. 
• Cultura del miglioramento continuo: l’Agile promuove una mentalità di apprendimento iterativo, dove gli errori non sono visti come fallimenti, ma come opportunità per migliorare il prodotto e il processo. 
  
  Ecco perché ogni manager oggi comprende come sia importante seguire approcci agili. 
  Tuttavia, nella pratica, resta radicata nella cultura manageriale l’eredità dell’approccio tradizionale e di qui il senso di perdita della sensazione psicologicamente rassicurante di dover seguire un piano dettagliato. Cambiare questa mentalità non è per nulla semplice e richiede un’evoluzione di mindset: accettare che l’incertezza sia intrinseca nei progetti di innovazione digitale e che il controllo non deriva dalla rigidità, ma dalla capacità di adattarsi e dalla verifica continua del valore generato.

Quando si lavora in contesti che richiedono frequenti revisioni dei piani, come nei progetti di innovazione digitale, il timore di destabilizzare gli stakeholder è un aspetto centrale. Questo timore può essere attribuito a diversi motivi: 

1. Fiducia nella leadership 
Gli stakeholder, siano essi investitori, clienti o membri del comitato esecutivo, si aspettano che i leader abbiano una visione chiara e che il progetto proceda senza intoppi. Frequenti revisioni dei piani possono dare l'impressione che manchi una direzione strategica o che il team non abbia fatto un’analisi accurata all'inizio del progetto. Questo rischia di erodere la fiducia nella leadership, soprattutto se la comunicazione delle motivazioni dietro ai cambiamenti non è gestita in modo trasparente e convincente.

3. Comunicazione frammentata 
Il modo in cui vengono comunicate le modifiche è cruciale. Se gli stakeholder non comprendono appieno il razionale dietro i cambiamenti o se ricevono informazioni contraddittorie, possono sentirsi esclusi dal processo decisionale. Questo non solo destabilizza gli stakeholder, ma può anche generare resistenze interne al progetto, rallentandone ulteriormente l’esecuzione.

5. Limitata collaborazione fra Direzione IT e Linee di Business 
La limitata collaborazione fra Direzione IT e Linee di Business nelle aziende è spesso il risultato di una separazione culturale e organizzativa. La Direzione IT tende a focalizzarsi su aspetti tecnici e operativi, mentre le Linee di Business si concentrano sui risultati economici. Questa mancata integrazione porta a una visione frammentata dei progetti di innovazione digitale, rendendo difficile adattare rapidamente i piani iniziali in risposta ai cambiamenti. 

In un contesto Agile, dove la revisione continua delle priorità è fondamentale, questa mancanza di collaborazione può alimentare il timore dei C-Level di destabilizzare gli stakeholder, poiché ogni cambiamento rischia di sembrare una mancanza di controllo o di pianificazione.

Superare il timore del cambiamento e rivedere i piani con fiducia richiede un approccio che affronti sia le preoccupazioni degli stakeholder sia il cambiamento culturale necessario per abbracciare metodologie iterative come l’Agile. Ecco alcuni suggerimenti che possono aiutare a gestire questo passaggio in modo efficace.

1. Promuovere la trasparenza 

La trasparenza è fondamentale per mitigare il timore del cambiamento. Ogni revisione del piano concepito in prima istanza dovrebbe essere comunicata chiaramente agli stakeholder, spiegando non solo le motivazioni dietro le modifiche ma anche i benefici attesi. Questo richiede un cambiamento nel modo in cui la leadership si relaziona con gli stakeholder, adottando un approccio più aperto e collaborativo. 

Organizzare dei meeting con gli stakeholder nei momenti chiave del progetto, permette loro di toccare con mano lo stato attuale e di comprendere il razionale dietro ogni decisione. Ciò aiuta a trasformare la percezione dei cambiamenti da segno di incertezza a risposte proattive a nuove opportunità o sfide. 

2. Dimostrare valore incrementale 

Una delle maggiori preoccupazioni degli stakeholder è l’incertezza riguardo al ritorno sull’investimento. Rilasciare versioni funzionanti del prodotto in modo iterativo aiuta a dissipare questi timori, mostrando progressi tangibili a ogni ciclo. Questo approccio non solo rafforza la fiducia, ma dimostra che i team sono in grado di generare valore fin dalle prime fasi del progetto. 

Impatto sugli stakeholder: vedere progressi concreti riduce l’ansia associata ai cambiamenti, poiché il valore prodotto è visibile e misurabile. Per esempio, se un progetto di sviluppo software prevede il rilascio incrementale di funzionalità, gli utenti finali possono iniziare a trarre beneficio dal prodotto anche prima che sia completamente terminato, aumentando il loro supporto al progetto. 

3. Creare una cultura del miglioramento continuo 

Un aspetto chiave per affrontare il timore del cambiamento è aiutare gli stakeholder ad entrare nel merito della natura dinamica dei progetti di innovazione digitale. Questo richiede di costruire una cultura che veda l’adattabilità come un punto di forza e non come una debolezza. Le tecnologie evolvono rapidamente, le esigenze dei clienti cambiano in modo imprevedibile, e i vincoli di mercato, come nuove regolamentazioni o pressioni competitive, possono influenzare la direzione del progetto. Far capire che queste variabili non sono ostacoli, ma opportunità per migliorare il prodotto finale, è un passo essenziale per ridurre la resistenza al cambiamento.  

Questo approccio permette di trasformare l'incertezza in un elemento positivo, promuovendo un atteggiamento più aperto e proattivo da parte degli stakeholder. Un modo efficace per raggiungere questo obiettivo è organizzare workshop sintetici e dedicati per gli stakeholder. Durante questi incontri, è possibile illustrare i benefici di un approccio iterativo, come quello offerto dalla metodologia Agile, presentare casi studio concreti di successo tratti da altre organizzazioni e rivedere in modo collaborativo il piano del progetto in corso di esecuzione. 

4. Favorire la collaborazione 

In progetti complessi da realizzare in ambienti mutevoli, la collaborazione tra tutti gli attori è cruciale. Direzioni IT, Linee di Business, utenti e stakeholder, pur con ruoli e compiti molto diversi, devono impegnarsi ad agire in sinergia. 

In questo scenario, le tecniche di Co-design e il ricorso ai Minimum Viable Product (MVP) offrono strumenti pratici per migliorare la collaborazione fra IT, linee di business e utenti. Più precisamente, il Co-design consente alle parti interessate di lavorare insieme fin dalle prime fasi del progetto, favorendo una visione condivisa e prevenendo incomprensioni. Questo approccio non solo promuove la trasparenza, ma aumenta anche la fiducia degli stakeholder, che si sentono parte del processo decisionale e vedono riflessi i propri bisogni nei risultati. 

L’uso di MVP si integra perfettamente con queste dinamiche, permettendo di consegnare risultati tangibili in tempi brevi. Gli stakeholder possono valutare e utilizzare versioni iniziali del prodotto, riducendo il rischio di investire in funzionalità non necessarie o non allineate agli obiettivi di business. Inoltre, ogni iterazione consente di incorporare feedback e di adattare il progetto ai cambiamenti di mercato o alle esigenze emergenti, offrendo un senso di controllo e affidabilità. 

5.Utilizzare strumenti di pianificazione iterativa 

Le metodologie agili mettono a disposizione strumenti potenti per affrontare la complessità dei progetti e garantire una comunicazione efficace con tutti gli attori coinvolti, dagli sviluppatori agli stakeholder. Due strumenti chiave in questo contesto sono le roadmap flessibili e il backlog di prodotto, ciascuno con un ruolo specifico nel promuovere chiarezza, trasparenza e adattabilità. 

Le roadmap flessibili in Agile non sono semplici piani statici, ma rappresentano una visione strategica del progetto, organizzata in base a obiettivi di alto livello e milestones temporali. A differenza delle roadmap tradizionali, che dettagliano ogni fase in modo rigido e sequenziale, una roadmap flessibile si adatta costantemente ai cambiamenti di priorità e contesto, mantenendo al contempo un focus chiaro sugli obiettivi principali. Questo approccio permette di bilanciare la necessità di pianificazione con la capacità di rispondere rapidamente a nuovi requisiti, evoluzioni tecnologiche o opportunità di mercato. 

Il backlog di prodotto, invece, è una lista dinamica e ordinata di tutte le attività, funzionalità e miglioramenti necessari per il progetto. Mentre il backlog è fondamentale per il lavoro quotidiano dei team, è spesso troppo dettagliato e tecnico per gli stakeholder, i quali potrebbero trovare complesso analizzare ogni elemento. Per questo motivo, è essenziale tradurre il backlog in una visione più comprensibile e sintetica, come un insieme di macro-funzionalità o epic, per aiutare gli stakeholder a ragionare in termini di priorità strategiche. 

Questo approccio duale — roadmap flessibile per la visione d'insieme e backlog operativo per il dettaglio — garantisce che ogni attore abbia accesso al livello di informazione più adatto al suo ruolo. Gli stakeholder possono così concentrarsi sulle priorità e sulle decisioni strategiche, mentre il team operativo si dedica all'esecuzione pratica. 

La combinazione di questi strumenti non solo favorisce un adattamento continuo alle esigenze del progetto, ma permette anche di mantenere una comunicazione trasparente e coerente. Gli stakeholder, vedendo come le modifiche si inseriscono armoniosamente nella roadmap e come ogni macro-funzionalità risponde alle priorità aziendali, sviluppano una maggiore fiducia nel processo e nella leadership del progetto. Questo riduce la percezione di instabilità, trasformando i cambiamenti da ostacoli a opportunità di miglioramento continuo. 

6.Rinforzare la fiducia attraverso i risultati  
Alla fine, la fiducia degli stakeholder si basa essenzialmente sui risultati concreti e sul valore percepito del progetto. Questo valore è senza dubbio evidenziato dai progressi tangibili, visionabili ad ogni rilascio, e dalla chiarezza con cui vengono comunicate le finalità e i benefici di ogni cambiamento apportato. Gli stakeholder, se opportunamente gestiti, sono disposti a rivedere le decisioni iniziali, purché sia loro evidente che gli aggiustamenti incrementano il valore complessivo o riducono i rischi. La trasparenza e la capacità di mostrare il legame tra le modifiche e gli obiettivi strategici sono quindi essenziali per mantenere il loro supporto. 

Un’ottima modalità per comunicare con gli stakeholder è quella di ricorre a delle metriche, a partire da quelle di business (aumento di ricavi, risparmi di risorse, nuovi modelli di business, etc), di governance (costi sostenuti, tempi di realizzazione, …), a quelle di qualità del software (tasso dei difetti, copertura dei test, performance e affidabilità, …), a metriche operative (velocità di realizzazione, lead time, stabilità dei team, clima organizzativo, …). 

In questo scenario, per rassicurare gli stakeholder, è fondamentale collegare ogni modifica del progetto a metriche significative che dimostrino il progresso raggiunto o da raggiungere. Quando gli stakeholder vedono progressi tangibili, supportati da dati chiari e metriche pertinenti, la loro percezione del progetto cambia in positivo. Si rafforza la fiducia nella leadership, nella metodologia Agile e nella capacità dei team di adattarsi ai cambiamenti per raggiungere gli obiettivi. Questo approccio trasparente non solo dissipa paure e resistenze, ma consolida il supporto degli stakeholder come parte attiva del processo decisionale.

La tradizione della pianificazione costruita a priori rimane presente nel mindset manageriale a causa della sua associazione storica con controllo, prevedibilità e stabilità. Tuttavia, i contesti di innovazione digitale odierni richiedono flessibilità e capacità di adattamento, rendendo questa mentalità obsoleta in molti casi. Il timore di destabilizzare gli stakeholder rivedendo i piani può essere superato solo con un’evoluzione culturale che promuova un attento e prezioso coinvolgimento degli stakeholder basato su trasparenza e attenzione ai loro bisogni. La metodologia Agile rappresenta uno strumento fondamentale per affrontare questa sfida, trasformando la revisione dei piani da fonte di destabilizzazione a punto di forza per il successo del progetto.

Beck, K., Beedle, M., van Bennekum, A., et al. (2001). Manifesto for Agile Software Development. Disponibile al link https://agilemanifesto.org/ 

Boehm, B., & Turner, R. (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley Professional. 

Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional. 

Conforto, E. C., Salum, F., Amaral, D. C., da Silva, S. L., & de Almeida, L. F. M. (2014). Can Agile Project Management be adopted by industries other than software development? Project Management Journal, 45(3), 21-34. 

Denning, S. (2016). Agile's ten implementation challenges. Strategy & Leadership, 44(5), 15-20. 

Denning, S. (2018). The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done. AMACOM. 

Mainetti, S. (2024). Come non cadere nella trappola della Velocity, disponibile al link https://tinyurl.com/ycyjad7c 

Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005). Challenges of migrating to Agile methodologies. Communications of the ACM, 48(5), 72-78. 

Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). Embracing Agile. Harvard Business Review, 94(5), 40-50. 

Royce, W. W. (1970). Managing the development of large software systems. Proceedings of IEEE WESCON, 26(8), 1-9.