Enrico Pacassoni 
Indice dei contenuti:
- Fallimento di progetto: cosa significa
- Motivi del fallimento del progetto
- Fallimento di progetto: punti chiave
Fallimento di progetto: cosa significa
Un progetto è considerato un fallimento quando, una volta completato, non fornisce ciò che era richiesto dai requisiti di progetto e non è in linea con le aspettative degli stakeholder.
Dunque, per avere successo, come prima cosa un progetto deve offrire bilanciamento dei costi, qualità e puntualità; oltre ovviamente ad offrire i vantaggi presentati nel business case. Non finisce qui: la seconda parte della nostra definizione è che il progetto deve essere realizzato "in linea con le aspettative degli stakeholder".
Se le principali parti interessate concordano sul fatto che un progetto dovesse superare il budget iniziale, il progetto potrebbe comunque essere considerato un successo. Allo stesso modo, se un progetto ha fornito tutto ciò che era nei disegni dettagliati del progetto, potrebbe comunque essere considerato un fallimento se non includesse elementi vitali di cui le parti interessate chiave avevano bisogno.
Ciò non sembra giusto, ma il successo e il fallimento del progetto non riguardano solo i fatti, né semplicemente ciò che è stato consegnato. Riguarda, soprattutto, come viene percepito il progetto.
Motivi del fallimento del progetto
Ecco alcuni dei motivi principali per cui i progetti falliscono:
Sono stati risolti i requisiti aziendali errati
Se il tuo progetto è impostato per fornire la "cosa sbagliata", potrebbe essere considerato un fallimento anche se tutto viene consegnato in tempo, nel rispetto del budget e della qualità richiesta.
Questo potrebbe sembrare ingiusto, tuttavia se il tuo progetto non offre ciò di cui l'organizzazione ha veramente bisogno, ciò influirà inevitabilmente sul modo in cui viene percepito. Ecco perché è così importante condurre un'analisi approfondita dei requisiti aziendali.
Non è possibile consegnare il business case
Se il business case non può essere consegnato, sei di fronte ad un compito impossibile. Le cose peggiorano se il progetto genera subito delle dipendenze, ovvero se l’organizzazione aspetta il completamento del progetto per fare altre cose. Ciò rende più difficile modificare le scadenze, i budget e le aspettative del progetto.
Ad esempio, una volta che hai promesso di consegnare un nuovo sistema di gestione dei bagagli in aeroporto, le compagnie aeree possono programmare voli aggiuntivi poco dopo il lancio del sistema, in modo da poter sfruttare la nuova capacità. Se il sistema di bagaglio non funziona, o se presenta gravi problemi durante i test, potrebbe essere difficile convincere i senior manager a consentire il ritardo del progetto, perché dovranno rinunciare alle entrate promesse.
Quando scrivi il tuo business case, assicurati di riflettere dettagliatamente sui requisiti del progetto e di identificare ciò che è necessario per assicurarti di poter soddisfare tali requisiti. Non limitarti ad elencare le assumption: assicurati di esplorare ogni requisito a fondo.
Esamina altri progetti simili, in modo da non dimenticare gli elementi principali. Se stai offrendo un nuovo sistema, rivedi i requisiti hardware e di interfaccia. Se si hanno rischi importanti, assicurati di includere risorse di emergenza sufficienti (persone, budget e tempo) per gestirli in modo appropriato.
Sii realistico e preparati ad avere conversazioni difficili. Ad esempio, qualcuno potrebbe essere deluso dal fatto che non potrà avere ciò che vuole prima della fine dell'anno, oppure gli utenti chiave potrebbero dire che hanno bisogno di un prodotto completo alla fine della prima fase. Tuttavia, sarà molto più difficile avere queste conversazioni in una data futura, quando il tuo progetto è nei guai!
In molti casi, la documentazione relativa al business case viene scritta prima dell'assegnazione del project manager. Se sei il project manager in arrivo, assicurati di non accettare semplicemente questi documenti come sono! Sei responsabile della consegna del progetto, assicurati di rivedere il business case. Convalida i presupposti e identifica eventuali lacune o aree che richiedono maggiori dettagli.
Se sono necessarie conversazioni difficili, falle ora. Una volta stabilite scadenze, requisiti e budget, le aspettative sono molto più difficili da cambiare!
La governance è scarsa
Pochi progetti iniziano senza uno sponsor. Questa è la persona che ha identificato la necessità di un cambiamento in un'area aziendale e che si impegna a far sì che quel cambiamento avvenga. Questa persona gioca un ruolo vitale nel garantire il successo del progetto. Un buon sponsor può rendere fantastico un progetto mediocre e un cattivo sponsor può ritardare e frustrare un fantastico team di progetto.
Lo sponsor del progetto è supportato dagli organi di governance del progetto, generalmente sotto forma di un gruppo direttivo. Questi ruoli di governance sono essenziali: forniscono direzione, orientamento e revisione critica del progetto e dei suoi progressi.
Come project manager, sei coinvolto nella gestione quotidiana del progetto, ma i gruppi di governance possono fare un passo indietro e guardare il progetto da una prospettiva diversa. Possono porre domande difficili su progressi e prestazioni, potrebbero vedere cose che hai trascurato.
Tuttavia, possono anche supportarti fornendo contatti e approfondimenti che ti aiutano a fare le cose e possono addirittura coprirti le spalle se e quando ne hai bisogno.
I project manager di solito non hanno alcuna influenza su chi sia il loro sponsor del progetto. Gli sponsor si auto-selezionano o vengono scelti a causa della loro posizione nell'organizzazione.
Tuttavia, spesso hai più influenza su chi è nel tuo gruppo direttivo. Se ad esempio sai che al tuo sponsor manca la passione per il progetto o se invece dice sempre sì alle persone che cercano di espanderne l'ambito, assicurati di includere nel gruppo direttivo persone capaci di bilanciare questi atteggiamenti.
L'implementazione è scarsa
Se consegni il tuo progetto senza alcuna sbavatura, eviterai una cattiva implementazione - giusto? Sfortunatamente, non è così.
La consegna può essere complessa: è necessario gestire rischi, problemi e ambito di applicazione, senza contare la necessità di gestire un team più o meno numeroso e di comunicare con tutte le parti interessate.
Consegnare il cambiamento è difficile e non tutto è sotto il tuo controllo. Pertanto, essere competenti non è sufficiente per una buona implementazione, ma è un buon inizio!
Le persone perdono attenzione sui benefici del progetto
I progetti si basano su un elenco di vantaggi che devono essere erogati. Ad esempio, potrebbe essere necessario un processo di assistenza clienti più veloce, potrebbe essere necessario produrre prodotti a basso costo o potrebbe essere necessario migliorare la qualità del servizio. Questi obiettivi dovrebbero essere perfezionati in modo da essere chiare, concise e quantificate (noti delle analogie con gli obiettivi SMART?)
Da questi obiettivi viene generato un insieme di "cose da fare". Ad esempio, potrebbe essere necessario consultare i clienti, riprogettare i prodotti o implementare un nuovo sistema. Il risultato di questo è un documento di business requirements che analizza il progetto in termini di costi e dei vantaggi che verranno erogati.
Il team di progetto si concentra quindi sulla pianificazione dettagliata delle attività e sulla consegna degli elementi inclusi nel piano di progetto: in questa fase, il team potrebbe dimenticare i benefici del progetto.
Ciò si traduce spesso in un risultato del progetto ben costruito, ma che non offre i benefici necessari. Ad esempio, se il piano del progetto si concentra sulla progettazione e costruzione di un sistema, è possibile ottenere un sistema fantastico, ma non utilizzato dall'azienda.
Per evitare questo problema, occorre adottare un approccio di gestione dei benefici per tutta la durata del progetto e ricordare la necessità di offrire i benefici richiesti durante la pianificazione e la consegna del progetto.
L'ambiente cambia
Questa è probabilmente l'area più complicata. Se le esigenze dell'azienda cambiano, il tuo business case può diventare obsoleto prima che tu abbia effettivamente completato il progetto.
Potrebbe essere necessario rivedere i requisiti e gli obiettivi originali durante il progetto per decidere come procedere, e ciò può comportare la modifica dell'ambito del progetto o addirittura la sua cancellazione totale!
Se lavori in un ambiente che sta cambiando rapidamente, puoi cercare di ridurre i rischi nel modo seguente:
- Prendere decisioni tempestive - se il progetto non sarà in grado di soddisfare i requisiti modificati, non puoi ignorarlo. Prima lo comprendi e lo comunichio, e prima prendi una decisione sul futuro del progetto, meglio è.
- Considerare i progetti più piccoli - è più difficile cambiare direzione in una grande nave da crociera che in un piccolo rimorchiatore. Dunque, considera se l'ambito del progetto proposto e le tempistiche di consegna ti consentono di suddividere il progetto in sotto-progetti più piccoli. Consegnare progetti in pezzi più piccoli non è sempre appropriato, ma vale la pena considerarlo.
- Gestire le aspettative - Solo perché annulli un progetto non significa automaticamente che il progetto sia considerato un fallimento. Ciò dipende da molti fattori, incluso il modo in cui gestisci il coinvolgimento delle principali parti interessate del progetto nel processo decisionale.
Fallimento di progetto: punti chiave
Perché un progetto abbia successo, non è sufficiente semplicemente gestire il progetto con competenza e fornire un prodotto di buona qualità.
Per evitare il fallimento, assicurati di:
- identificare i giusti requisiti aziendali
- creare un business case realizzabile
- mettere in atto una solida governance del progetto
- gestire un'implementazione di alta qualità
- rimanere focalizzato sui benefici
- monitorare il tuo ambiente in evoluzione
Soprattutto, assicurati di gestire le aspettative dei tuoi stakeholder, in modo che rimangano solidali. Dopotutto, sono queste le persone che dichiareranno il successo del tuo progetto - o il suo fallimento.
