Perché i progetti falliscono anche con buoni PM

Conosco project manager con certificazioni PMP, PRINCE2, esperienza decennale, che hanno visto i loro progetti naufragare. Non per incompetenza tecnica. Non per mancanza di metodo. Ma perché nessuno gli aveva mai detto che un progetto non fallisce mai per un solo motivo. E soprattutto, che i motivi reali non sono quasi mai quelli che finiscono nei report finali.

Prendiamo un caso che ho visto ripetersi in aziende diverse, settori diversi, dimensioni diverse. Un PM competente viene chiamato su un progetto in ritardo. Budget già sforato del 30%. Stakeholder nervosi. Il PM fa tutto giusto: riorganizza il team, riscrive il piano, stabilisce nuove milestone, comunica con disciplina. Tre mesi dopo, il progetto è ancora più in ritardo. Altri sei mesi dopo, viene chiuso con perdite del 150% sul budget iniziale. Nei meeting post-mortem, tutti concordano: “sottovalutazione della complessità tecnica”. Fine della storia.

Falso. Quella non era la causa. Era il sintomo di un organismo malato da molto prima che il PM arrivasse. Il progetto era fallito il giorno in cui qualcuno aveva promesso una data impossibile per vincere una gara. Era fallito quando il CFO aveva tagliato il 20% del budget “per sicurezza”. Era fallito quando il team aveva capito che dire la verità era più pericoloso che mentire. Il PM è arrivato a gestire un cadavere che ancora respirava.

Questo articolo non è per chi cerca le solite liste di “errori comuni”. È per chi vuole capire perché i progetti fallisconoanche quando tutto sembra fatto bene. Perché le best practice non bastano. Perché le certificazioni non proteggono dal disastro. E soprattutto, cosa può fare un PM quando il sistema è progettato per il fallimento.

 

L’illusione del controllo: quando il metodo non basta

Partiamo da una verità scomoda: la maggior parte dei progetti fallisce prima ancora di iniziare. Secondo il Chaos Report di Standish Group, solo il 29% dei progetti viene completato nei tempi, nel budget e con tutte le funzionalità previste. Il 52% viene completato con ritardi, sforamenti di budget o riduzione di scope. Il 19% viene cancellato. Questi dati sono sostanzialmente invariati da vent’anni, nonostante l’esplosione di metodologie, strumenti, certificazioni e “best practice”.

Perché? Perché continuiamo a curare i sintomi invece delle cause. Un PM formato sa fare tutto: WBS, Gantt, risk register, stakeholder analysis, comunicazione strutturata. Applica PMBOK o PRINCE2 con disciplina. Usa tool sofisticati. Eppure il progetto va a rotoli. Non perché il metodo è sbagliato, ma perché il metodo presuppone un sistema razionale che non esiste.

Prendiamo la gestione del rischio. Ogni PM sa che deve identificare i rischi, valutarli, pianificare mitigazioni. Ma cosa succede quando il rischio più grande è il comportamento irrazionale del CEO che cambia idea ogni settimana? O quando il vero rischio è che il cliente ha promesso funzionalità che la tecnologia non può ancora fornire, ma nessuno può dirlo ad alta voce? O quando il rischio è che metà del team ha già capito che il progetto è condannato e sta cercando altro lavoro? I risk register non contemplano “il sistema è strutturalmente disfunzionale”.

 

La dittatura degli ottimisti

Uno studio McKinsey su progetti IT di grande scala ha rilevato che il 17% fallisce così gravemente da mettere a rischio l’esistenza stessa dell’azienda. Non sono errori di calcolo. Sono progetti dove qualcuno ha mentito consapevolmente sulla fattibilità, perché dire la verità significava non partire. E in molte organizzazioni, non partire è peggio che fallire.

Ho visto business case costruiti su assunzioni che chiunque con esperienza sapeva essere false. Ma il sistema premia chi dice “si può fare” e punisce chi dice “ci vorranno sei mesi in più e il doppio delle persone”. Il PM viene chiamato dopo che le promesse sono state fatte. Gli viene dato un piano che non sta in piedi. E gli viene detto di farlo funzionare. Non perché qualcuno creda davvero sia possibile, ma perché ammettere l’errore a quel punto costerebbe troppo in termini politici.

 

Il paradosso della visibilità

Più il PM è bravo a rendere visibili i problemi, più il sistema lo percepisce come problema. Un PM che segnala rischi viene visto come “negativo”. Un PM che dice “non ce la facciamo con queste risorse” viene visto come “non abbastanza proattivo”. Un PM che documenta con precisione i ritardi causati da decisioni del management viene visto come “uno che cerca scuse”. Il sistema non vuole verità, vuole rassicurazioni.

Risultato: i PM imparano a mentire per omissione. I semafori dei report diventano arancioni quando dovrebbero essere rossi. I ritardi vengono presentati come “slittamenti tecnici recuperabili” quando in realtà sono sintomi di problemi strutturali. E quando il progetto crolla, tutti possono dire “ma nel report di due mesi fa era tutto sotto controllo”. Era sotto controllo perché il PM aveva imparato che dire la verità costa più caro che mentire.

 

Gli errori invisibili: quello che il post-mortem non dice mai

Quando un progetto fallisce, l’analisi post-mortem segue un copione standard. Si identificano cause tecniche, si parla di “lessons learned”, si aggiornano le procedure. Quello che non si dice mai è che il fallimento era sistemico e le persone che lo hanno causato sono quelle che conducono l’analisi.

Un report Gartner del 2023 ha analizzato 500 progetti falliti in organizzazioni enterprise. Nel 78% dei casi, le cause dichiarate nei post-mortem erano tecniche o legate all’esecuzione. Ma quando i ricercatori hanno intervistato i team in forma anonima, nel 89% dei casi le cause reali erano organizzative, politiche o legate a decisioni del management prese prima dell’avvio del progetto. La distanza tra verità dichiarata e verità reale è il vero problema.

 

L’architettura del fallimento

I progetti falliscono perché sono costruiti su fondamenta marce. Un cliente che non sa cosa vuole ma pretende una data fissa. Un budget calcolato non sui costi reali ma su “quanto siamo disposti a spendere”. Un team assemblato non per competenze ma per disponibilità politica. Uno sponsor che ha promesso risultati senza capire cosa stava promettendo. È un PM che viene inserito in questo sistema con il mandato implicito di “far sembrare che funzioni”.

Ho visto progetti dove il vero obiettivo non era mai quello dichiarato. Un progetto di “digital transformation” il cui vero scopo era giustificare l’acquisto di una piattaforma che il CTO voleva per altri motivi. Un progetto di “miglioramento del processo” il cui vero scopo era dimostrare che un certo dipartimento era inefficiente per giustificarne il ridimensionamento. Quando gli obiettivi reali e quelli dichiarati non coincidono, il progetto può solo fallire.

 

Il gioco delle sedie

Un fenomeno ricorrente: nei progetti lunghi, le persone chiave cambiano. Lo sponsor iniziale viene promosso e il suo successore ha priorità diverse. Il cliente cambia il responsabile e il nuovo non si sente vincolato dagli accordi del predecessore. Il CTO che aveva approvato l’architettura se ne va e il nuovo vuole rifare tutto. Ogni cambio azzera parte della memoria e della commitment, ma il piano resta lo stesso.

Secondo una ricerca del Project Management Institute, il 43% dei progetti subisce cambiamenti significativi negli stakeholder chiave durante l’esecuzione. Ogni cambio introduce nuove aspettative, nuove priorità, nuove interpretazioni del successo. Ma il contratto resta quello iniziale. Il budget resta quello iniziale. E quando il progetto fallisce, si dà la colpa al PM per “scarsa gestione degli stakeholder”.

 

L’economia dell’escalation

Più un progetto è in difficoltà, più diventa difficile fermarlo. Questo perché fermare un progetto significa ammettere che tutti i soldi spesi finora sono persi. È il principio del “sunk cost fallacy” applicato a livello organizzativo. Meglio buttare altri due milioni sperando in un miracolo che ammettere che i cinque già spesi sono andati in fumo.

Ho visto progetti zombie andare avanti per anni. Tutti sapevano che non sarebbero mai andati in produzione. Ma ogni trimestre qualcuno trovava una ragione per “dargli ancora un po’ di tempo”. Perché chiuderli significava scrivere nel bilancio “abbiamo bruciato X milioni per niente”. Molto più politicamente conveniente tenerli in vita a bassa intensità, sperando che con un cambio di management o una ristrutturazione possano essere silenziosamente archiviati senza troppo rumore.

 

Il PM come capro espiatorio del sistema

Una dinamica che ho visto decine di volte: un progetto nasce con difetti strutturali. Qualcuno vende al cliente o al management una soluzione impossibile. I tempi sono irrealistici. Il budget è sottostimato del 40%. Il team ha metà delle competenze necessarie. Il PM viene messo a capo di questa bomba a orologeria e gli viene detto “fai accadere le cose”.

Nei primi mesi, il PM fa miracoli. Ottimizza, negozia, recupera. Ma i difetti strutturali non si possono compensare con l’execution. Arriva il punto in cui il PM deve dire la verità: “non ce la facciamo, servono più tempo e più risorse”. E qui scatta la trappola. Il sistema non vuole sentire che il piano era sbagliato. Vuole sentire che il PM non è all’altezza.

 

La narrazione del fallimento

Quando un progetto fallisce, serve una storia. Una storia semplice, che identifichi un colpevole, che rassicuri sul fatto che “se avessimo fatto X diversamente, sarebbe andato tutto bene”. Il PM è il colpevole perfetto. Non è abbastanza senior da essere intoccabile. Non è abbastanza esterno da poter essere ignorato. Ed è l’unico che ha responsabilità formale sul risultato. Anche se tutti gli altri hanno creato le condizioni del fallimento, è il PM che “non ha gestito bene”.

Ho visto PM eccellenti bruciati da progetti impossibili. La narrazione era sempre la stessa: “non ha saputo gestire la complessità”, “non ha comunicato efficacemente con gli stakeholder”, “non ha identificato i rischi in tempo”. Tutto tecnicamente vero, ma completamente fuorviante. Come dire che un chirurgo ha fallito l’operazione perché “non ha gestito bene l’emorragia”, quando il paziente era dissanguato prima ancora di entrare in sala operatoria.

 

Il costo nascosto della colpa

Secondo uno studio del PMI, il 62% dei project manager ha vissuto almeno un progetto fallito che ha avuto un impatto negativo sulla propria carriera. Non perché fossero incompetenti, ma perché il sistema aveva bisogno di un colpevole. Questo crea un effetto perverso: i PM bravi evitano i progetti rischiosi. E i progetti rischiosi finiscono gestiti da chi non ha le competenze per identificare i problemi in tempo.

Inoltre, questa dinamica uccide l’apprendimento organizzativo. Se ogni fallimento viene attribuito a un individuo, l’organizzazione non impara mai. Non affronta i problemi strutturali. Non cambia i processi che generano progetti destinati a fallire. Si limita a cambiare PM, sperando che il prossimo sia “migliore”. È un sistema che si autodistrugge lentamente.

 

Quando l’organizzazione sabota il progetto

Esiste una categoria di fallimenti particolarmente insidiosa: quelli causati dall’organizzazione stessa. Non per incompetenza, ma per conflitti di interesse, dinamiche politiche o semplicemente perché il successo del progetto danneggerebbe qualcuno con potere sufficiente per sabotarlo.

Prendiamo un progetto di digital transformation. Obiettivo dichiarato: efficientare i processi, ridurre i costi operativi, migliorare l’esperienza cliente. Obiettivo reale non dichiarato: ridurre il potere di certi dipartimenti che gestiscono i processi attuali. Cosa succede? Quei dipartimenti non collaborano. Forniscono dati incompleti. Sollevano obiezioni continue. Trovano ragioni tecniche per cui “non si può fare”. E il progetto affonda. Non perché il PM è incapace, ma perché metà dell’organizzazione ha interesse che fallisca.

 

La guerra silenziosa

Ho visto progetti bloccati da atti di sabotaggio sottile. Nessuno dice apertamente “no”. Ma le riunioni vengono rimandate. Le decisioni vengono differite “per approfondimenti”. Le risorse promesse non arrivano mai. I test rivelano “criticità impreviste” a due giorni dal go-live. E quando chiedi spiegazioni, tutti hanno ragioni plausibili. “Siamo oberati”, “non ci avevano detto che serviva anche questo”, “abbiamo scoperto un rischio di compliance”. Tutto vero. Tutto usato strategicamente per affondare il progetto.

Un report di Harvard Business Review su progetti di change management ha rilevato che nel 70% dei casi, la resistenza al cambiamento non è culturale o emotiva. È razionale. Le persone resistono perché il cambiamento danneggia i loro interessi. Riduce il loro potere. Rende obsolete le loro competenze. Espone le loro inefficienze. E quando queste persone hanno abbastanza peso organizzativo, possono uccidere qualunque progetto. Il PM può essere bravissimo, ma non può vincere una guerra dove non sa nemmeno chi sono i nemici.

 

L’illusione del supporto

Altra dinamica tossica: il progetto ha un executive sponsor che “supporta pienamente l’iniziativa”. Nei kickoff meeting parla di quanto il progetto sia strategico. Nei comitati direttivi annuisce. Ma quando serve prendere decisioni difficili, non è mai disponibile. Quando serve sbloccare budget aggiuntivo, ci sono “vincoli di bilancio”. Quando serve mediare conflitti tra dipartimenti, “deve valutare tutte le posizioni”. Il supporto è puramente nominale.

Il PM si ritrova con un mandato formale ma senza potere reale. Deve ottenere risultati senza autorità. Deve coordinare persone che non ha il potere di influenzare. Deve prendere decisioni che richiedono approvazioni che non arrivano mai. E quando il progetto fallisce, lo sponsor dice “ho dato tutto il supporto possibile, evidentemente il PM non era all’altezza”. Il supporto è misurato dalle parole, non dai fatti.

 

Le variabili nascoste che nessuno controlla

Oltre alle dinamiche politiche e organizzative, esistono variabili strutturali che sfuggono completamente al controllo del PM ma che determinano il destino del progetto. Variabili che nei manuali di project management non vengono quasi mai discusse perché presuppongono che il progetto nasca in condizioni ideali. Cosa che non accade mai.

 

La qualità del team come vincolo non negoziabile

Un PM riceve un team. Non lo sceglie quasi mai. Il team è composto da “chi era disponibile”. Metà delle persone non hanno le competenze necessarie ma “impareranno on the job”. Un quarto sono consulenti esterni che hanno motivazioni economiche a far durare il progetto il più possibile. Un altro quarto sono risorse interne che il loro dipartimento voleva togliersi di torno. E il PM deve “fare il meglio possibile con quello che ha”.

Secondo Gartner, il 55% dei progetti software utilizza team con almeno il 30% di risorse che non hanno esperienza diretta sulla tecnologia utilizzata. Ma i piani di progetto sono scritti come se tutti fossero senior. Le stime sono fatte assumendo produttività da team esperto. E quando i tempi si allungano perché “bisogna formare le persone”, la colpa è del PM che “non ha gestito bene le competenze”. Come se potesse crearle dal nulla.

 

Il debito tecnico come eredità maledetta

I progetti non nascono nel vuoto. Nascono in un contesto tecnologico esistente. E quel contesto è spesso un disastro. Codice scritto dieci anni fa da persone che non lavorano più in azienda. Sistemi legacy senza documentazione. Integrazioni fatte con workaround che nessuno capisce più. Database con strutture dati che violano qualunque principio di buon design. Il debito tecnico accumulato negli anni diventa il vero nemico.

Ho visto progetti dove il 70% del tempo veniva speso non a sviluppare nuove funzionalità, ma a capire perché il sistema esistente si comportava in un certo modo. Ogni modifica richiedeva settimane di reverse engineering. Ogni test rivelava side effects imprevisti. E quando il progetto sforava, la spiegazione ufficiale era “complessità sottovalutata”. Ma la complessità non era tecnica. Era archeologica. Era il risultato di anni di scelte sbagliate che nessuno aveva mai sanato.

 

La dipendenza da vendor esterni

Molti progetti dipendono da fornitori esterni. Software house, system integrator, vendor di piattaforme. E qui si apre un mondo di conflitti di interesse nascosti. Il vendor ha interesse a vendere change request. Ha interesse a prolungare il progetto. Ha interesse a rendere il cliente dipendente dalla sua tecnologia proprietaria. E quando le cose vanno male, ha anche ottimi avvocati e contratti scritti in modo da scaricare ogni responsabilità sul cliente.

Il PM si trova a gestire un partner che è anche un avversario. Deve negoziare ogni variazione. Deve difendere il budget da richieste di extra non giustificati. Deve verificare che il lavoro fatturato sia stato effettivamente svolto. Ma non ha visibilità diretta sul lavoro del vendor. Non può entrare nei loro uffici e verificare. Deve fidarsi di quanto gli viene detto. E quando scopre che gli hanno mentito, scopre anche che contrattualmente non può fare nulla. Il progetto è ostaggio di dinamiche che non può controllare.

 

Quello che i PM dovrebbero fare ma non possono

Ogni PM sa cosa dovrebbe fare. Dovrebbe dire “no” a richieste impossibili. Dovrebbe pretendere requisiti chiari prima di partire. Dovrebbe avere buffer adeguati nel piano. Dovrebbe poter sostituire risorse inadeguate. Dovrebbe avere potere decisionale. Dovrebbe avere accesso diretto agli stakeholder chiave. Dovrebbe operare in un sistema razionale. Ma non lo fa. Perché se lo facesse, non avrebbe mai un progetto da gestire.

 

Il compromesso inevitabile

Un PM pragmatico sa che deve accettare compromessi. Parte con un piano che sa essere sottostimato, sperando di recuperare in corso d’opera. Accetta un team inadeguato, sperando di poterlo migliorare strada facendo. Accetta obiettivi vaghi, sperando di poterli chiarire durante l’esecuzione. Accetta rischi non mitigabili, sperando che non si materializzino. Non perché è ottimista, ma perché l’alternativa è non partire.

Questo crea una cultura della speranza invece che della pianificazione. I progetti iniziano con assunzioni che tutti sanno essere false, ma nessuno vuole essere quello che “blocca le cose”. E quando le assunzioni si rivelano false, sorpresa: il progetto è in crisi. Ma a quel punto ci sono già soldi spesi, commitment presi, aspettative create. E il PM deve gestire il disastro con gli stessi vincoli che lo hanno causato.

 

L’isolamento del PM

Una dinamica che uccide molti progetti: il PM è isolato. Non ha pari con cui confrontarsi. Non ha mentori che capiscono davvero le sue sfide. Ha sopra di sé manager che vogliono solo sentirsi dire che “tutto procede bene”. Ha sotto di sé un team che spesso lo vede come “quello che rompe le palle con i report”. E ha intorno stakeholder che lo vedono come “quello che dice sempre di no”.

Secondo il PMI, il 48% dei project manager segnala alti livelli di stress lavorativo. Non per il lavoro in sé, ma per l’isolamento decisionale. Devono prendere decisioni continue senza avere tutte le informazioni. Devono mediare conflitti senza avere autorità. Devono proteggere il team dalla pressione del management senza potersi lamentare. Devono sembrare sempre in controllo, anche quando tutto sta crollando.

 

Come un PM può sopravvivere in un sistema malato

Allora che fa un PM che si trova in un progetto destinato a fallire? Non può scappare. Non può dire apertamente “questo progetto è una merda”. Ma può scegliere come affrontare la situazione. Non per salvare il progetto, che forse non è salvabile, ma per salvare sé stesso e il team dal diventare capri espiatori.

 

Documentare la verità, sempre

Prima regola: tutto per iscritto. Ogni decisione presa dal management che crea rischi. Ogni volta che segnali un problema e ti dicono di “andare avanti comunque”. Ogni volta che chiedi risorse e ti vengono negate. Ogni volta che uno stakeholder cambia idea. Non per parare il culo, anche se serve anche a quello. Ma per creare una memoria oggettiva di cosa è successo veramente.

Non report formali che nessuno legge. Email. Riassunti di meeting con i punti critici evidenziati e le decisioni esplicitate. “Come da nostra conversazione di oggi, procediamo con l’approccio X pur riconoscendo il rischio Y, in quanto il management ritiene che…”. Metti le persone di fronte alle loro decisioni. Non in modo aggressivo. In modo neutro, fattuale. Ma documentato. Quando poi il progetto fallisce e inizia il gioco dello scaricabarile, avrai una timeline precisa di chi ha deciso cosa.

 

Gestire le aspettative realisticamente

Seconda regola: non mentire sullo stato del progetto. Non rendere verde un semaforo che è rosso. Non dire “ce la facciamo” quando sai che non ce la farete. Ma impara a dire la verità in modo che venga ascoltata. Non “siamo fottuti”. Ma “con le risorse attuali, possiamo consegnare X entro la data Y, oppure Y+2 mesi con le funzionalità complete, o X ridotto entro Y. Cosa scegliamo?”.

Metti il management di fronte a scelte concrete. Non dire “serve più tempo”. Dì: “Serve più tempo, oppure riduciamo lo scope, oppure aumentiamo il team, oppure accettiamo un debito tecnico che ci costerà il doppio nei prossimi due anni. Quale rischio preferiamo prendere?” Rendi visibile il costo di ogni scelta. E documentala. Così quando sceglieranno l’opzione peggiore per ragioni politiche, sarà esplicito che è stata una loro scelta.

 

Proteggere il team dalla follia organizzativa

Terza regola: il team non deve pagare per l’incompetenza del sistema. Se il progetto va male per ragioni strutturali, il team non deve essere quello che fa notti e weekend per compensare. Tua responsabilità come PM è assorbire la pressione e redistribuirla dove serve. Se il management vuole risultati impossibili, è il management che deve sentirsi dire di no. Non il team che deve essere spremuto.

Ho visto PM che proteggevano il team facendosi odiare dal management. Dicevano “no, non faccio lavorare le persone il weekend per recuperare un ritardo causato da vostre decisioni”. Ovviamente questo li rendeva “difficili” e “non collaborativi”. Ma il team li seguiva ovunque. Perché sapevano che quel PM li avrebbe protetti. E nei progetti impossibili, avere un team che ti segue è l’unica risorsa che conta davvero.

 

Sapere quando mollare

Quarta regola, la più difficile: devi sapere quando un progetto è talmente malato che rimanerci danneggia solo te. Non parlo di mollare al primo problema. Parlo di riconoscere quando il sistema non vuole che il progetto riesca. Quando sei lì solo per prendere la colpa quando crollerà. Quando il tuo mandato reale è “fallo sembrare sotto controllo finché qualcuno decide di chiuderlo”.

In quei casi, o negozi un’uscita dignitosa (“questo progetto richiede competenze più senior delle mie, serve qualcuno con più esperienza in contesti politici complessi”), oppure te ne vai. Perché rimanere su un progetto zombie che devasterà la tua reputazione è la cosa peggiore che puoi fare alla tua carriera. Meglio essere quello che se n’è andato prima del disastro che quello che ha gestito il disastro.

 

La verità che nessuno vuole sentire

Eccoci al punto. I progetti falliscono non perché i PM sono incapaci, ma perché il sistema è progettato per farli fallire. Processi di vendita che promettono impossibili pur di chiudere il contratto. Budget definiti da CFO che non capiscono quanto costa davvero fare le cose. Management che vuole risultati da startup con burocrazia da multinazionale. Organizzazioni dove dire la verità è più pericoloso che mentire.

Il PM arriva in mezzo a questo disastro e gli viene dato il compito di “far funzionare le cose”. Non gli viene dato potere. Non gli vengono date risorse adeguate. Non gli viene dato tempo per fare le cose bene. Gli viene dato un piano scritto da persone che non hanno mai gestito un progetto, un team assemblato con gli scarti degli altri dipartimenti, e la responsabilità formale quando tutto va male. È il capro espiatorio perfetto.

E il sistema si autoalimenta. Ogni progetto fallito viene attribuito al PM. Così l’organizzazione non impara mai. Non cambia i processi. Non smette di promettere impossibili. Non inizia a fare piani realistici. Si limita a cambiare PM, convinta che il prossimo sarà “migliore”. E il ciclo ricomincia.

Secondo uno studio del World Economic Forum sul project management nelle organizzazioni complesse, il fattore predittivo più forte del successo di un progetto non è la competenza del PM. Non è la metodologia utilizzata. Non è nemmeno il budget o il tempo disponibile. È la maturità organizzativa. Cioè quanto l’organizzazione ha processi decisionali razionali, quanto premia la trasparenza invece della politica, quanto sa gestire l’incertezza senza scaricarla sul PM.

Un PM eccellente in un’organizzazione immatura fallirà. Un PM mediocre in un’organizzazione matura avrà successo. Perché il progetto non è un’entità isolata gestita da un individuo. È un organismo che vive nell’ecosistema organizzativo. Se l’ecosistema è tossico, qualunque organismo si ammala.

 

Cosa fare veramente

Quindi, se sei un PM in un progetto che senti andare male, cosa fai? Intanto, smetti di incolpare te stesso. Smetti di pensare “se fossi più bravo”. Inizia a guardare il sistema. Identifica quali sono i difetti strutturali. Documentali. Rendili visibili. Non per lamentarmi. Per creare consapevolezza.

Parla con altri PM nella tua organizzazione. Confronta le esperienze. Vedrai pattern. Vedrai che i problemi si ripetono. Vedrai che non sei tu. E quando avrai questa visione sistemica, puoi iniziare a fare advocacy. Non come PM isolato che si lamenta. Ma come gruppo professionale che dice “questi sono i problemi ricorrenti, queste sono le cause, questi sono gli interventi strutturali necessari”.

Non aspettarti che l’organizzazione cambi rapidamente. Ma almeno non sarai più solo. E quando il prossimo progetto fallisce, potrai dire “vi avevamo avvertito che questo processo genera problemi, ecco la terza volta che succede”. A un certo punto, o l’organizzazione inizia ad ascoltare, o diventa chiaro che non vuole cambiare. E in quel caso, sai che devi cercare un posto migliore dove far crescere la tua carriera.

Perché i progetti falliscono anche con buoni PM? Perché il PM è l’ultima linea di difesa di un sistema che genera progetti destinati a fallire. E nessuna competenza individuale può compensare un’incompetenza sistemica. La soluzione non è diventare PM migliori. È costruire organizzazioni che meritano PMI competenti. Fino ad allora, tutto quello che puoi fare è sopravvivere, documentare, proteggere il team, e sapere quando è il momento di andartene.