Come Evitare il Fallimento di un Progetto in 3 Passi + 4 Casi di Studio
Ci sono molte ragioni per cui i progetti falliscono, ma alla fine quasi tutte si riducono a due cose (a volte entrambe):
- C'era un rischio che nessuno aveva riconosciuto, e/o
- Non abbiamo reagito adeguatamente quando si è presentato un problema
In questo articolo voglio concentrarmi sulla visione d’insieme per aiutare ad affrontare la causa principale del fallimento dei progetti—e spesso anche della gestione dei progetti.
Ecco come evitare il fallimento di un progetto e cosa fare se si verifica quell’evento catastrofico che non avevi previsto (puoi ancora riuscirci se agisci rapidamente e con attenzione!).
Sblocca Gratis
Crea un account gratuito per terminare la lettura di questo articolo e unirti a una community di leader innovativi che accedono a strumenti, playbook e approfondimenti per prosperare nell’era dell’AI.
Have an account? Log In
Cos'è il fallimento di un progetto?
Esattamente ciò che sembra—ogni volta che un progetto non raggiunge gli obiettivi fissati all'inizio dal team, non soddisfa le aspettative del cliente o degli stakeholder chiave, oppure non rispetta tempi, budget o ambito.
Perché i progetti falliscono?
Come anticipato nell’introduzione, ci sono ragioni comuni per cui i progetti possono fallire. Di solito ciò avviene a causa di un rischio che non è stato valutato correttamente e/o il team (incluso il project manager) non ha risposto adeguatamente al rischio.
Altre cause comuni di fallimento sono una comunicazione poco efficace sullo stato, sui problemi o sui rischi; membri del team che non rispettano (o non capiscono bene) l’ambito del progetto, gli output previsti (cioè scope creep) o la tempistica; mancanza di risorse, o mancato rispetto dei processi o delle metodologie previste.
Come evitare il fallimento di un progetto: 3 passi
La gestione dei rischi è un’attività chiave nella gestione dei progetti. È così importante che la mancata gestione dei rischi spesso equivale al fallimento nella gestione del progetto. La gestione dei rischi comprende tre componenti fondamentali:
- Individuare i rischi.
- Valutare i rischi identificati: Quanto è probabile che si verifichino e quanto possono essere gravi le conseguenze? Qual è la probabilità e l’impatto?
- Preparare piani di mitigazione e contingenza per quei rischi che potrebbero compromettere il tuo progetto di successo. I registri dei rischi sono utili per tenere traccia di ciò che hai fatto.
1. Individuare i rischi
Per prima cosa, individua i rischi. Farlo bene aumenterà notevolmente le tue probabilità di successo. E, anche se è difficile identificarli tutti, se esamini il progetto in modo sistematico puoi generalmente individuare quelli maggiori. Questo di solito fa parte del processo di creazione di un piano di progetto.
La mia esperienza riguarda lo sviluppo software, sia di prodotto sia IT, e i processi correlati. I progetti software sono complessi, fragili e, tranne in pochi rari casi, non dispongono dei meccanismi di sicurezza e delle ispezioni integrati presenti in settori come l’edilizia o la produzione di dispositivi medici.
Dovresti avere obiettivi per ciascuno dei quattro parametri principali:
- Programma
- Contenuto
- Costo
- Qualità
Se non sai quali sono, questo è il punto di partenza. Trovo che, in genere, due dei quattro parametri cambieranno nel tempo, ma più conosci dove vuoi arrivare, più facile sarà individuare gli ostacoli.
Capire quale dei quattro parametri è prioritario ti aiuterà a ridurre i rischi facendo compromessi appropriati nei dettagli.
È facile concentrarsi solo sul programma del progetto e non vedere rischi che potrebbero mettere in pericolo gli altri parametri, ma sono tutti interconnessi e tutti importanti da identificare.
Rispettare le scadenze con un prodotto difettoso di solito non è una buona opzione—anche se viene rilasciato, finirai per dover fare aggiornamenti correttivi che ritarderanno ancora di più il rilascio di una versione adeguata rispetto a risolvere il problema iniziale.
Oltre i 4 parametri
Oltre ai quattro parametri, hai tre aspetti del progetto da bilanciare:
- Prodotto, che di solito è coperto dai parametri
- Processi
- Persone
I rischi di processo si presentano in due modalità: un processo esistente inadeguato che non soddisfa le necessità del progetto e l’assenza di un processo per qualcosa di fondamentale per il team. I rischi di processo sono piuttosto facili da mitigare, creando o sistemando il processo.
La parte delle persone viene spesso trascurata, ma il tuo team e i team con cui interagiscono possono determinare il successo o il fallimento del progetto. Stakeholder difficili o poco coinvolti renderanno difficile ottenere ciò che serve per andare avanti.
Membri del team sovraccarichi, stressati o insoddisfatti non porteranno a termine il lavoro. Alcuni dei potenziali problemi legati alle persone possono essere affrontati pubblicamente, altri è meglio discuterli in privato, ma non commettere l’errore di ignorarli.
2. Valuta i Rischi che Hai Identificato
Dopo aver identificato i rischi, determina quanto è probabile che si verifichino. Di solito uso una percentuale—100% significa che sono certo che accadrà. È anche importante valutare quanto sarà grave se il rischio si concretizza. Il modo più semplice per farlo è classificare i rischi in rischi alti, medi o bassi.
Una volta terminata questa analisi, è il momento di coinvolgere il tuo team. Chiedi a ciascun membro del team di progetto o collaboratore cosa li preoccupa, aggiungi questi punti all’elenco dei rischi, e sottoponili a revisione:
- Il team riesce a pensare ad altri rischi che non hai considerato?
- Cosa pensano dell’analisi di probabilità e impatto?
Sulla base di questo incontro, puoi fare aggiustamenti al tuo piano di gestione dei rischi. Le parti uno e due sono completate—per ora. Dovrai rivedere i rischi almeno settimanalmente per vedere se ci sono rischi nuovi, se ce ne sono alcuni che non sono più applicabili e se sono cambiate probabilità o impatto.
3. Prepara Piani di Mitigazione e Contingenza
Infine, se la combinazione di probabilità e impatto di alcuni rischi potrebbe far deragliare il tuo progetto, lavora con il tuo team per sviluppare piani documentati di mitigazione e contingenza.
La mitigazione consiste nel rendere il rischio meno probabile o ridurne l’impatto qualora si verificasse. La contingenza si concentra sui passaggi che metterai in atto se il rischio è inevitabile e si verifica.
Assicurati che i piani siano documentati e che tutti ne siano a conoscenza. È anche una buona idea pianificare possibili problemi legati alle persone oltre ai 4 "quadranti" e al processo, ma probabilmente vorrai fare questa analisi da solo e mantenerla riservata.
Come Sopravvivere al Fallimento di un Progetto
La seconda causa di fallimento nella gestione di un progetto è una risposta inadeguata al verificarsi di un rischio di progetto, previsto o meno. Tutto questo dipende da te come project manager. Prima di eseguire uno dei passi qui sotto, inizia con questi 2 suggerimenti:
- Non andare in panico. Ricordati di respirare.
- Non puntare il dito e non permettere a nessun altro di cercare colpevoli.
1. Fai Riferimento al Tuo Piano di Contingenza
Se hai un piano di contingenza stabilito, convoca subito una riunione o almeno invia un’email per dare il via al piano di contingenza. Ricorda a tutti qual è il piano e comunica quando e come dovranno aggiornarti sullo stato.
Se salti o ritardi questo passaggio, troverai persone desiderose di aiutare che interverranno in modalità panico; quando ciò avviene si perde il controllo su ciò che è stato fatto e spesso il problema peggiora.
Se non hai un piano di contingenza, raduna immediatamente tutti con una convocazione e istruzioni rigide: NON FARE NULLA fino alla riunione.
Altrimenti, tutti cercheranno di aiutare e non avrai idea di cosa sia stato fatto. Durante la riunione, esponi chiaramente il problema—è sempre sorprendente quante idee differenti abbiano le persone su quale sia il vero problema.
Esegui un’analisi delle cause radice per arrivare fino in fondo alla questione e sviluppa il piano—chi fa cosa e come—per il recupero. Durante questa analisi bisogna capire chi ha fatto cosa prima del problema, ma mantieni la discussione su questo livello.
In altre parole, solo i fatti. Non assegnare colpe, perché il puntare il dito distrae. Se il tuo team non riesce a trovare la soluzione, hai delle opzioni.
La prima è coinvolgere qualcuno che conosce la materia generale ma non fa parte di questo specifico progetto—ad esempio, se il problema riguarda il database, coinvolgi un database administrator non attualmente sul progetto per ottenere una diversa prospettiva.
Un’altra tecnica è coinvolgere qualcuno che non conosce affatto il progetto. A volte il dover spiegare ogni passaggio esplicitamente fa emergere assunzioni errate o qualcosa che le persone avevano trascurato.
2. Risolvi il Problema
Coinvolgi tutti nella linea d’azione e assegna i compiti. Chiedi alle persone di comunicarti lo stato di avanzamento e indica con quale frequenza devono aggiornarti—di ora in ora, al termine di ogni task, a fine giornata, o come è più opportuno nella situazione.
I report possono sembrarti ovvi, ma non sarà così per tutti. Aggiornamenti regolari aiutano a mantenere il team con i piedi per terra. Trasmetti regolarmente a tutto il team lo stato consolidato dei progressi.
Coloro che non hanno compiti immediati nel team potrebbero sentirsi inutili e infine cercheranno di intervenire se non li tieni aggiornati con informazioni e progressi.
È molto importante anche tenere informata la direzione. Usa il tuo giudizio per capire chi aggiornare e quando, ma comunica lo stato consolidato dei progressi a tutto il team regolarmente.
3. Chiudi la Fase
Quando il problema è davvero risolto. Redigi un rapporto finale e passa allo step successivo. Concedi al team la possibilità di riprendersi un po’.
4. Organizza un Post-Mortem o una Retrospettiva
È importante completare una valutazione del progetto per raccogliere le lezioni apprese. Ecco come strutturarla:
- Esporre il problema in modo che tutti sappiano di cosa si sta parlando
- Inizia da ciò che è andato bene. Anche nella situazione più difficile, qualcosa è comunque andato nel verso giusto. Così la riunione parte con un tono completamente diverso.
- Parla di cosa deve essere migliorato. Se c'è tempo, fate brainstorming su come attuare i miglioramenti; altrimenti, assegnate compiti e scadenze e fate un follow-up alle date stabilite.
Se la colpa è effettivamente di qualcuno, affrontala direttamente con quella persona, in privato. Se lo fai in pubblico, tutta la squadra si chiederà chi sarà il prossimo a essere messo in imbarazzo di fronte a tutti.
Se lo salti completamente, il tuo team sentirà che qualcuno l’ha fatta franca e che il problema non è stato risolto. Sii oggettivo e verifica qualsiasi cambiamento personale ai processi che qualcuno deve adottare. Si tratta di responsabilità e miglioramento, non di trovare un colpevole.
3 esempi reali di fallimenti di progetto
Ho avuto la mia quota di insuccessi nei progetti IT, anche se fortunatamente—ma dolorosamente—si sono ripresi.
Ecco alcuni esempi di progetti IT e progetti di sviluppo che non sono andati a buon fine, oltre a un esempio famoso di progetto fallito.
Questi esempi di progetti falliti e casi di studio dovrebbero anche darti un’idea concreta dei motivi per cui i progetti possono fallire e di come si possa affrontare la situazione.
1. Il Sistema Contabile
All'inizio della mia carriera ho lavorato in IBM. Il mio primo vero incarico era prendere in mano un sistema piuttosto piccolo che si integrava nei sistemi contabili aziendali. Qualcuno in IBM lo aveva sviluppato in un linguaggio di programmazione non comune chiamato RPG su un sistema minore.
Non solo ho gestito il progetto, ma ho seguito l’intero sistema (anche se c’era un amministratore) inclusi raccolta dei requisiti di progetto, troubleshooting e programmazione.
Un giorno ho installato un nuovo programma, l’ho eseguito e ho trovato un errore. Ho corretto l’errore e rieseguito il programma. La mattina dopo ho ricevuto una chiamata dal reparto Contabilità perché c’erano delle doppie registrazioni (una pessima notizia nel mondo contabile).
Primo, nessuno aveva revisionato il mio lavoro. Secondo, non avevo coinvolto le persone dei sistemi collegati a valle per controllare le registrazioni prima che passassero per tutto il sistema. Terzo, non avevo dedicato tempo ad analizzare alcuni vecchi programmi ancora in funzione e che stavano generando doppie registrazioni. Non c’era neppure un processo, se non quello che mi inventavo sul momento.
E poi la mia reazione—panico. Appena uscito dall’università, stavo rovinando il sistema contabile di IBM. Non avevo coinvolto le persone giuste—l’amministratore non sapeva cosa stesse succedendo—e lui ha generato un altro set di registrazioni senza rendersene conto. Alla fine, ho lavorato 48 ore di seguito per risalire alla causa radice, correggerla, scrivere e eseguire programmi per sistemare gli errori contabili.
Ho imparato la lezione: osservare attentamente, sottoporre a revisione, pensare a cosa potrebbe andare storto e fermarsi a riflettere prima di intervenire (tutte cose che i software di project management contabile possono aiutare a fare). Ora immagina se avessi avuto un team di 10 persone e ognuno cercava di risolvere il problema nello stesso modo. Sarebbe stato davvero irrecuperabile senza dover sospendere i sistemi contabili di IBM per capire dove stava il problema.
2. Il Nuovo Prodotto Interno
Come consulente, gestivo un nuovo grande progetto con molte persone coinvolte nella definizione dei requisiti, il che rendeva le priorità funzionali in continua evoluzione. Stavamo lavorando con un processo di project management agile, che l’azienda non aveva mai usato prima. Il team QA era molto efficiente nei test ma non aveva ancora acquisito la mentalità e il flusso di lavoro dell’utente finale.
Ero consapevole di tutti questi aspetti e li avevo anche esposti di tanto in tanto, ma non avevo un registro dei rischi, nessuna valutazione di impatto/probabilità, nessun piano di emergenza o di mitigazione. Inoltre, non ero io il canale principale di informazioni per lo sponsor del progetto, anche se ogni tanto mi incontravo con lei.
Abbiamo aggiunto uno sprint. Poi un altro. Quando è divenuto chiaro che non eravamo ancora pronti per effettuare il beta test, ne abbiamo aggiunto un terzo.
Poiché non ero io a trasmettere le informazioni allo sponsor, non avevo idea che lei non sapesse nulla di tutto questo. La persona responsabile ha commesso l’errore critico di non informare lo sponsor, sperando che ce la saremmo cavata.
E a dire il vero, anche se parlavo dei rischi, non gli avevo fornito un elenco concreto di rischi da illustrare per preparare lo sponsor alla possibilità di un rinvio della scadenza.
Nel mezzo di tutto questo ho incontrato lo sponsor e ho fatto un riferimento casuale all’ultimo sprint che avremmo dovuto aggiungere. Lei mi ha fermato. Non ne sapeva nulla ed era molto contrariata.
Alla fine, si è rivelata più irritata per la sorpresa che per il ritardo. Ci sono state conseguenze pubbliche ed infine la persona responsabile del progetto è stata trasferita altrove nell’azienda perché la fiducia era venuta a mancare.
Ancora una volta, ho imparato lezioni importanti dal fallimento. Conoscere i rischi non basta, bisogna metterli insieme, valutarli, avere piani di mitigazione e di contingenza, e renderli pubblici e costantemente visibili.
Non sono mai stato uno che nasconde rischi e problemi, ma l'importanza della trasparenza nei progetti mi è diventata chiarissima.
3. Ricordi OS2?
No, nessuno lo ricorda. È uno dei tanti progetti falliti di sviluppo di sistemi. Lavoravo in IBM quando uscì il primo OS2—un concorrente di Windows. Io nemmeno provai quella prima versione, perché in IBM sapevamo tutti che era davvero piena di bug. Il resto del mondo lo scoprì subito: aveva troppi problemi per valere la pena provarlo.
Era abbastanza difettoso che il team di progetto non poteva davvero pensare fosse pronto, ma in qualche modo non fecero la scelta giusta e non bloccarono il rilascio. Trascurare l’elemento umano, sia del proprio team che dei clienti, può rovinare rapidamente anche il piano più bello.
Nel software ci sono molte alternative a questa situazione—rilasciare una versione limitata a chi tollera i bug pur di avere software all'avanguardia, rendere pubblico che si sta aspettando di portare l'affidabilità agli alti standard richiesti, ecc.
Era ancora abbastanza presto nella mia carriera da poter trarre lezioni preziose dal fatto che un prodotto che amavo era già arrivato a un vicolo cieco al secondo rilascio.
Sii chiaro sulle tue priorità—ci sono pochi casi in cui rilasciare in una certa data è più importante della qualità del prodotto, ma non sono molti.
Usa i tuoi 4 indicatori, ammetti i tuoi errori e rendi visibili le correzioni così che le persone si fidino che hai capito il problema e non commetterai lo stesso errore due volte.
Prendi in considerazione la componente umana—è tanto critica quanto la tecnologia. Da allora, ho portato queste lezioni nei progetti software e IT, e si sono rivelate preziose.
In conclusione
In generale, ricorda che anche se alla fine la responsabilità è tua, non devi fare tutto il lavoro. In realtà, assolutamente non dovresti provarci da solo. Puoi beneficiare dell’ampia gamma di esperienze e conoscenze del tuo team. Sei il leader, ma non devi essere l’intero team.
Il software di gestione dei progetti e altri strumenti di gestione dei progetti possono aiutarti a monitorare rischi, traguardi, allocazione delle risorse e altri indicatori critici per capire se sei sulla buona strada per un progetto di successo.
