Presumere inconsciamente il funzionamento di una determinata soluzione può portare a fallimenti disastrosi. Lo stesso accade quando non si dedica abbastanza tempo all’analisi iniziale e non si coinvolgono tutte le parti interessate dal problema che si vuole risolvere
Devo confessare una cosa: adoro i gadget e sono attratto dalla novità tipica dei nuovi prodotti tecnologici scintillanti. E sono anche noto per comprare senza pensare davvero alla praticità dell’oggetto che sto acquistando, il che significa che ho cassetti pieni di prodotti tecnologici e di gadget che uso raramente, se mai li uso. C’è stato un tempo in cui avevamo non meno di tre spremiagrumi in casa, che (per quanto mi riguarda) sono tre in più di quelli di cui avremo mai bisogno. Ognuno di questi prodotti sembrava una buona idea, ma ben presto tutti finirono relegati nelle profondità di un polveroso armadio, per non essere più riutilizzati. C’è però una cosa da dire: mentre la maggior parte dei gadget a cui mi riferisco è tutto sommato di poco conto, nelle aziende persiste un modello simile e più preoccupante. Chi ne è coinvolto spesso si innamora dell’idea di una particolare soluzione molto prima che sia stata determinata una comprensione del contesto e dei risultati desiderati. Ma se nessuno ha chiesto “perché è necessario un cambiamento” e “quali benefici e risultati stiamo cercando”, come diavolo possiamo mai sapere se la presunta soluzione migliorerà effettivamente le cose? Per giunta c’è la possibilità che, nella realtà, la presunta soluzione possa in realtà peggiorarle le cose.
L’illusione della soluzione
Questo modello di presumere inconsciamente che una particolare soluzione funzionerebbe, può portare a situazioni in cui i team finiscono per fornire esattamente ciò che è specificato solo per scoprire che non è ciò di cui le persone avevano bisogno o si aspettavano. Le diverse prospettive di chi è coinvolto rimangono inascoltate e potrebbe esserci un tacito disaccordo sul motivo per cui il cambiamento è necessario, quale ne sia l’ambito e come verrà realizzato. Chi ha lavorato a progetti di questo tipo conosce bene quanti conflitti possono emergere, spesso nei momenti meno opportuni. A questo proposito, la “soluzione” implementata non è affatto una “soluzione”: la modifica implementata potrebbe aver effettivamente peggiorato le cose, con gli utenti che si lamentano a gran voce del fatto che non fa ciò di cui hanno bisogno. Il prodotto implementato potrebbe rimanere inutilizzato, con le parti interessate che lo detestano attivamente e trovano modi per evitarlo. Diventa un errore costoso e (metaforicamente) raccoglie polvere, proprio come i luccicanti gadget tecnici inutilizzati di cui ho parlato prima. Si tratta di un esito davvero negativo: tempo e denaro vengono sprecati, ma anche le relazioni con gli stakeholder ne vengono danneggiate poiché il prodotto non soddisfa le aspettative. Potrebbe anche essere “in tempo” e “nel rispetto del budget”, ma se nessuno lo usa, non costituirà un beneficio e probabilmente sarà un errore costoso! Tuttavia, esiste un modo per sapere in anticipo come potrebbe andare a finire.
L’importanza dell’analisi dei problemi pre-progetto
Che si stia lavorando in un ambiente agile, a cascata o ibrido, o che si stia seguendo un progetto o la gestione del ciclo di vita di un prodotto, è necessario concentrarsi a sufficienza sull’analisi iniziale. Questa analisi del problema breve, nitida e pre-progetto è il tipo di lavoro che non richiede molto tempo, produce indicazioni concise e può essere svolta rapidamente. Tuttavia, garantisce che le parti chiave interessate raggiungano un accordo sul perché, cosa e come del progetto. Ci sono molte tecniche che possono aiutare a capirlo, e in questo articolo mi concentrerò solo su alcune che possono aiutare a esplorare e ottenere un accordo sul perché. In primo luogo, è importante esplorare la situazione problematica percepita dal punto di vista delle diverse parti interessate. Approccio come il modello del diagramma causa-effetto a lisca di pesce, ma anche altri, possono essere di aiuto portando a scambi di idee su quale forma assume il successo e come può essere misurato. In questa fase iniziale, una discussione sui fattori critici di successo (CSF, critical success factor) e degli indicatori chiave di prestazione (KPI, key performance indicator) può rivelarsi davvero utile.
I CSF e i KPI sono spesso discussi a livello organizzativo, ma si applicano ugualmente bene a livello di progetto o di prodotto. Un CSF è tipicamente qualitativo e non direttamente misurabile, a meno che ogni CSF sia associato a uno o più KPI. Il KPI funge da metrica o misurazione per il CSF. Si potrebbe dire, per esempio, che dopo l’avvio di un progetto verrà un “servizio clienti eccellente” (un CSF). Ciò è buono a sapersi, tuttavia saranno i KPI a darne una misura qualitativa. Si potrebbe introdurre un KPI del tipo “meno di X reclami ogni Y ordini”. Pre-progetto si potrebbe non disporre dei dati per sommare preventivamente i numeri X e Y, ma almeno è stata definita la scala di misura che può essere integrata se l’iniziativa va avanti. Può sembrare banale, ma in realtà è molto importante. Discutere le metriche per il successo è un modo per coltivare una discussione sui risultati. Molto spesso stakeholder diversi avranno visioni sottilmente o talvolta radicalmente diverse su ciò che costituisce il “successo”, e questo è meglio scoprirlo presto. Uno stakeholder delle vendite potrebbe cercare “un aumento delle vendite”, mentre un collega di produzione potrebbe cercare “previsioni di produzione migliori”. Questi due risultati potrebbero essere compatibili, ma dovrebbe esserci una discussione. Anche se questi due stakeholder potrebbero essere apparentemente d’accordo in superficie su quale “soluzione” vogliono, in realtà la vogliono per ragioni diverse. Ciò potrebbe influire sull’idoneità della “soluzione” in esame. Scoprendo tempestivamente eventuali differenze nei risultati desiderati, c’è tempo per riunire le persone attorno a un tavolo, discutere le priorità e concordare come procedere comprendendo la probabile portata dell’azione. Un progetto che mira ad aumentare le vendite avrà probabilmente uno scopo diverso da quello che mira anche a consentire migliori previsioni di produzione. Comprendere questo in anticipo contribuirà più avanti a garantire una precisione simile a quella di un laser nell’analisi dei requisiti di business, ma aiuta anche ad allontanarsi dal pensiero incentrato sulla soluzione. Anche se uno stakeholder ha in mente una soluzione particolare (del tipo “dobbiamo solo acquistare questo nuovo sistema IT”), parlare dei risultati aiuta a incoraggiare il pensiero divergente (“OK, quindi il sistema IT è un’opzione, quali altri modi potrebbero esserci per raggiungere questi risultati?”). Questo, a sua volta, può aiutare a convalidare che l’idea originale proposta è la migliore o aiuterà a trovare una soluzione più adatta. Se ne potrebbe anche trovare una più veloce da realizzare e più economica: chi non lo vorrebbe?
Analisi rapida, fluida e leggera
L’analisi dei problemi pre-progetto deve essere rapida, fluida e leggera. La descrivo spesso come una “fetta sottile” del perché, cosa e come, tenendo conto delle prospettive dei diversi stakeholder. Spesso è possibile riassumere i risultati chiave in un unico “file” (con collegamenti a informazioni più dettagliate se qualcuno lo desidera) che funge da aiuto decisionale per gli sponsor. Se il progetto va avanti, questo file unico diventa un utile strumento di tracciabilità. Un requisito che non rientra nel folder identificato molto probabilmente è fuori dall’ambito (oppure l’obiettivo si è spostato, il che di solito richiede una discussione più ampia). Questo tipo di analisi può essere eseguita rapidamente. Prendendo in prestito e adattando una frase della comunità Agile, si tratta di “lavoro di analisi quanto basta e nel tempo giusto”. Un piccolo investimento iniziale utile a sapere che si può premere forte sull’acceleratore, sapendo che si sta procedendo nella giusta direzione. Cosa ancora più importante, l’analisi pre-progetto assicura che tutti siano sullo stesso file e puntino nella stessa direzione. È uno sforzo relativamente piccolo che può fare una differenza significativa e su cui vale la pena investire.
Adrian Reed
Vero sostenitore della professione di analista, è principal consultant e director di Blackmetric Business Solutions, dove fornisce consulenza di business analysis e soluzioni di formazione per una vasta gamma di clienti in diversi settori. Past president della sezione britannica dell’IIBA, è anche speaker a livello internazionale su argomenti relativi alla business analysis e al business change. Nel 2016 ha scritto il libro “Be a Great Problem Solver… Now” e nel 2018 il libro “Business Analyst”.
Adrian Reed presenterà per Technology Transfer il seminario “Pre-Project Problem Analysis”, che si terrà online live streaming il 22-23 maggio 2023.
