Anche se rispettano tempi e budget, i progetti falliscono se non soddisfano le esigenze di business. Chiedere perché aiuta a scoprire le vere necessità dietro le richieste. Ecco come evitare conflitti, errori comuni e garantire che tutti siano sulla stessa lunghezza d’onda
I progetti sono solitamente avviati in risposta a qualche sfida o a qualche opportunità. Forse c’è la necessità di aumentare l’efficienza, di sostituire un vecchio sistema IT legacy o di lanciare nuovi prodotti su nuovi mercati. Senza dubbio, chi promuove un progetto mira a ottenere una serie di risultati e benefici, ma non è un mistero che molti progetti incontrino difficoltà durante la loro realizzazione e che alcuni finiscano per fallire. In effetti, un progetto potrebbe rimanere nei tempi e nel budget previsti e comunque essere un fallimento se non soddisfa in concreto le esigenze di business e non raggiunge i benefici previsti. Una pratica chiave per prevenire tali situazioni è l’analisi dei problemi pre-progetto. Di solito, questo processo inizia prima della formalizzazione del progetto con l’obiettivo di comprendere la natura del problema da risolvere o dell’opportunità da perseguire. È fondamentale evitare soluzioni premature: aggrapparsi a una soluzione troppo presto, prima che vi sia una comprensione condivisa del problema o dell’opportunità, può portare a problemi significativi man mano che il progetto avanza.
Evitare l’illusione della soluzione
Questo potrebbe sembrare controintuitivo, perché dopotutto decidere su una “soluzione” è sicuramente una cosa buona. Nonostante questo sia parzialmente vero, troppi progetti diventano completamente incentrati sulla soluzione anziché essere focalizzati sui risultati. L’intero team lavora diligentemente per consegnare secondo il perimetro, i tempi e il budget previsti, mentre involontariamente perde di vista il beneficio che si sta cercando di ottenere. Questo può portare a una situazione in cui gli status report del progetto sono impeccabilmente “ok”, tuttavia, sorprese inattese possono attendere il team quando il progetto viene effettivamente avviato. Esiste sempre il pericolo di consegnare tutto ciò che viene richiesto solo per scoprire – tristemente troppo tardi – che non era ciò di cui si aveva realmente bisogno. Questo è altrettanto vero anche per piccole iterazioni e richieste di funzionalità. Immaginiamo che arrivi questa richiesta da uno stakeholder: “Serve un altro campo nel modulo web che si mappa al database. Dovrebbe essere una lista a discesa”. Sicuramente si avranno domande da fare su questa richiesta, e probabilmente si chiederà cosa dovrebbe esserci nella lista a discesa, quale domanda dovrebbe apparire sul sito web, e così via.
Questo è un esempio di pensiero incentrato sulla soluzione che si verifica prima che sia stata discussa la vera necessità o il risultato desiderato. È completamente comprensibile, poiché come esseri umani siamo portarti a essere naturali risolutori di problemi. C’è una parola magica che può aiutarci a uscire da questo modo di pensare: “Perché?”. Chiedere allo stakeholder perché desidera includere questo campo potrebbe rivelare che il loro intento è identificare la fonte degli ordini in arrivo. Questo consentirebbe di determinare quale percentuale del business è generata dalla pubblicità online, dai social media e da altre fonti. Ponendo ulteriori domande sul “perché”, si potrebbe scoprire che l’obiettivo finale è ottimizzare le spese di marketing. Per esempio, si potrebbe implementare immediatamente la soluzione richiesta, cioè aggiungere un nuovo campo. Tuttavia, quel nuovo campo potrebbe non garantire necessariamente il raggiungimento dell’obiettivo finale, ossia fornire dati utili per ottimizzare le spese di marketing. In effetti, potrebbero esserci molti altri modi per fornire i dati di cui lo stakeholder ha bisogno, alcuni dei quali potrebbero essere più efficienti, eleganti e veloci rispetto all’idea precedente.
Un progetto con una soluzione che arriva troppo presto
L’esempio di un campo su un database potrebbe sembrare davvero piccolo e insignificante. Tuttavia, lo stesso schema si verifica anche a livelli superiori. Ecco alcuni esempi: “Stiamo lanciando un progetto per implementare un sistema CRM” (Perché è stato scelto un sistema CRM? Quali risultati si vanno cercando? Potrebbero essere necessari anche altri cambiamenti oltre a un sistema CRM?); “Stiamo migrando dal sistema X al sistema Y” (Quali risultati si stanno cercando? Si stanno mitigando i rischi? La produttività sta aumentando? Qualcos’altro? Tutti sono d’accordo?); “Stiamo implementando, l’automazione dei processi robotici” (I processi sono già snelli? In caso contrario, c’è il pericolo di automatizzare processi difettosi? Cosa ha provocato questa decisione? Quale problema si sta cercando di risolvere?). Questi sono solo alcuni esempi ipotetici, ma il concetto è chiaro: uno dei principali rischi nel far avanzare progetti senza discutere chiaramente i risultati desiderati è che gli stakeholder manterranno una visione implicita di ciò che dovrebbe essere raggiunto. Poiché questa visione rimane implicita e non viene mai discussa apertamente, ha la tendenza a emergere più tardi, causando conflitti. Di conseguenza, l’ambito del progetto inizia a espandersi e, alla fine, il progetto rischia di fallire. Gli stakeholder potrebbero essere d’accordo, a livello superficiale, che vogliono o hanno bisogno di un nuovo sistema CRM. Tuttavia, potrebbero volerlo per motivi molto diversi e talvolta in conflitto. Senza analisi e discussione, è impossibile sapere se tutti sono sulla stessa lunghezza d’onda. In effetti, senza sapere quale problema stanno cercando di risolvere, è impossibile sapere se il nuovo sistema CRM è la soluzione adatta.
Iniziare con il perché?
Qui entra in gioco l’analisi dei problemi pre-progetto. Dedicare un po’ di tempo all’inizio per capire perché un’iniziativa viene avviata offre significativi benefici a lungo termine. Tuttavia, le cose non si fermano qui: è anche possibile approfondire il perché, il cosa e il come di un potenziale progetto. Ottenere rapidamente e concisamente una comprensione condivisa del perché (i risultati ricercati), cosa (l’ambito concettuale) e come (le possibili soluzioni che possono essere considerate). Questo può culminare in un breve e conciso documento che assicura che tutti siano sulla stessa lunghezza d’onda. Questo documento di sintesi del concetto di progetto diventa a sua volta un faro guida durante l’iniziativa. Non esiste un formato obbligato o fisso, ma potrebbe prevedere alcuni elementi come la dichiarazione con una definizione concisa e precisa del problema da risolvere, i fattori critici di successo e gli indicatori di performance per mostrare quale miglioramento si vuole raggiungere. Inoltre, la sintesi del concept potrebbe contenere anche il diagramma di scopo e la lista delle soluzioni.
Rimuovere gli ostacoli
L’analisi dei problemi pre-progetto è rilevante per tutto: iniziative piccole e grandi, approcci agili, di tipo waterfall oppure ancora ibridi. Quando eseguita correttamente, coinvolge una serie di tecniche di analisi complementari che assicurano che tutti siano sulla stessa lunghezza d’onda. Questa analisi aiuta a rimuovere gli ostacoli, permettendo al progetto di avanzare con fiducia, sapendo che gli stakeholder condividono una visione comune degli obiettivi. Inoltre, offre l’opportunità di ottenere un forte impegno iniziale nel ciclo di vita del progetto o del prodotto. Coinvolgendo attivamente gli stakeholder principali, facilita la collaborazione e la co-creazione di una visione condivisa dello scopo. Aiuta anche a prevenire situazioni in cui le persone si fissano su una soluzione specifica, guidandole invece a pensare in modo empatico e riflessivo ai problemi, alle opportunità e ai risultati desiderati. Questo investimento di tempo all’inizio del progetto può portare a significativi risparmi di tempo nel lungo termine.
Adrian Reed
Convinto sostenitore della professione di analista e attualmente 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 e speaker a livello internazionale su argomenti di Business analysis e Business change. Nel 2016 ha scritto il libro “Be a Great Problem Solver…Now” e nel 2018 ha pubblicato “Business Analyst”.
Adrian Reed presenterà per Technology Transfer il seminario “Pre-project problem analysis” che si terrà online live streaming il 21-22 ottobre 2024.
