Perché, cosa e come ovvero l’analisi delle esigenze, delle soluzioni e delle scelte nel ciclo di vita del progetto per evitare di spostare il problema in un altro punto dell’organizzazione. Una sfida comune per i professionisti del cambiamento e gli stakeholder
Decidere in anticipo una soluzione? Non c’è nulla di intrinsecamente sbagliato in questo: il problema sorge quando la soluzione viene presa prima di avere una chiara comprensione dei risultati che vengono cercati e delle opportunità o dei problemi che vengono affrontati. In tale situazione, può esserci il pericolo reale che ogni stakeholder abbia aspettative leggermente diverse su ciò che farà la “soluzione” scelta e su come ne trarrà beneficio. Se queste aspettative non sono chiaramente articolate, possono emergere situazioni in cui le persone sono d’accordo a livello superficiale ma hanno punti di vista di fondo molto diversi. In altri casi, la presunta “soluzione” può peggiorare le cose o semplicemente spostare il problema da qualche altra parte nell’organizzazione.
La trappola della prima soluzione
Immaginiamo un gruppo di stakeholder che hanno deciso di volere un nuovo sistema CRM. Sarebbe possibile avviare un progetto per implementare esattamente ciò che hanno chiesto (e migrare i dati esistenti), ma se non venissero poste domande sul motivo per cui in primo luogo volevano il nuovo sistema, potremmo scoprire di non avere l’effetto sperato. Per esempio, se uno stakeholder dicesse: «Ah, mi fa piacere che tu me l’abbia chiesto! Il motivo per cui desideriamo un nuovo CRM è perché il nostro team di vendita sul campo non utilizza quello esistente. Abbiamo sentito che quel “CRM System” è molto utilizzato, quindi abbiamo pensato di provarlo”. Si tratta chiaramente di una ipotesi provocatoria ma che dimostra l’errore di andare avanti senza capire “il perché”. In effetti, sarebbe sicuramente il caso di andare a fondo, chiedendosi perché il team di vendita non utilizza il sistema esistente. Forse, è perché i dati sono scarsi? Forse, non funzionano bene sui dispositivi mobili? O forse, è solo perché non vedono il valore nell’usarlo (se è così, è improbabile che un nuovo sistema risolva il problema!). Senza capire meglio queste cose si corre il rischio di fornire un nuovo sistema IT che peggiora le cose. Dobbiamo anche tenere a mente che la soluzione che è stata suggerita (una soluzione IT) è probabilmente solo una parte di una situazione molto più ampia che coinvolge processi, policy, persone e molto altro ancora. La migliore tecnologia al mondo è un investimento sprecato se le persone scelgono di non usarla e sviluppano invece le proprie soluzioni alternative (tipo le macro di Excel, per dire).
Rallentare prima di accelerare ovvero capire “il perché”
È qui che professionisti del cambiamento come sono i business analyst possono aggiungere un valore significativo nelle fasi di pre-progetto e di discovery. È utile dedicare un po’ di tempo alla comprensione delle prospettive sulla situazione dei diversi stakeholder. Tecniche come i “cinque perché”, diagrammi a lisca di pesce o diagrammi a cause multiple possono aiutare a ottenere una comprensione più ampia e più ricca, e soprattutto una comprensione condivisa della situazione. Un metodo che funziona è la tecnica della descrizione del problema (problem statement). Molto spesso gli stakeholder vedono le cose in modo molto diverso, ma questo non viene alla luce finché non iniziano ad articolare la loro visione del problema. Ci saranno spesso discussioni su parole particolari, e questa è in realtà una buona cosa, in quanto si stanno mettendo presto sul tavolo diversi punti di vista e prospettive. Un possibile formato da utilizzare per esprimere la dichiarazione del problema comprende la descrizione sintetica di ciò che è considerato più problematico; l’indicazione dei soggetti coinvolti; la descrizione del tipo di impatto; l’elenco delle caratteristiche che la soluzione dovrebbe avere. Sebbene la dichiarazione del problema sia semplice, non è affatto semplicistica. Spesso è difficile da creare e richiede iterazioni e discussioni. Questo può essere fatto in tempi relativamente brevi quando gli stakeholder sono coinvolti. La corretta dichiarazione del problema agisce quindi come un sistema di tracciabilità che aiuta a gestire l’ambito della questione.
Un assaggio
Il lavoro iniziale di pre-progetto benché cruciale non può richiedere troppo tempo o essere oneroso. Si tratta di ottenere un “assaggio” del perché, del cosa e del come. Una dichiarazione del problema, magari con alcuni fattori critici di successo (CSF) e indicatori chiave di prestazione (KPI), fornisce un’indicazione del motivo per cui il cambiamento è necessario, e dei risultati che si stanno cercando. Per creare un ambito iniziale di ciò che potrebbe essere necessario modificare, è possibile utilizzare qualcosa come un diagramma di use case di business o un diagramma di contesto. Quindi, ovviamente, le discussioni possono essere incentrate su come implementare il cambiamento. Naturalmente, la vita non è mai così semplice come si vorrebbe pensare, e in realtà il “perché”, il “cosa” e il “come” sono sfocati nella mente delle persone. Come professionisti, si andrà su e giù in quella gerarchia per ottenere un “assaggio” iniziale in grado di condensare una comprensione unificata. Questo “assaggio” in genere può essere presentato in modo molto conciso, per esempio, in un documento molto leggero con tutte le persone coinvolte sulla stessa pagina. E questo fornisce la certezza necessaria per premere l’acceleratore con sicurezza. Se viene utilizzato un approccio Agile, il team avrà una solida base su cui formare un backlog. Se si tratta di un approccio più predittivo o a cascata, allora c’è la base per un documento di avvio del progetto. Se si considera che l’analisi dei problemi pre-progetto può avere un impatto positivo fin dall’inizio del business change lifecycle, è paradossale che a volte siano proprio alcuni stakeholder a essere meno disposti a coinvolgere i professionisti del cambiamento. L’analisi dei problemi pre-progetto è un modo per assicurarsi che il progetto inizi sulla strada giusta!
Adrian Reed
Sempre dalla parte dei business analyst, nel suo ruolo di principal consultant e director di Blackmetric Business Solutions fornisce consulenza di analisi aziendale e soluzioni di formazione a una vasta gamma di clienti in diversi settori. Già presidente della sezione britannica dell’IIBA, è speaker a livello internazionale su argomenti relativi alla business analysis e al business change. Autore di “Be a Great Problem Solver – Now!” (Pearson, 2016) e di “Business Analyst” (BCS, 2018).
Adrian Reed presenterà per Technology Transfer il seminario “Pre-Project Problem Analysis” che si terrà online live streaming il 6-7 giugno 2022.
