Perché i progetti falliscono nella realtà

Project Management Reale: Perché i Progetti Falliscono Davvero

Perché i progetti falliscono nella realtà? Non è quando il budget finisce. Non è quando la deadline slitta per la terza volta. Un progetto muore molto prima: muore quando il team smette di parlare. Quando il responsabile tecnico evita le riunioni con il business. Quando gli stakeholder iniziano a mandare email in CC a mezza azienda per coprirsi le spalle.

Il project management reale vive in quello spazio grigio tra il Gantt chart perfetto e la realtà di esseri umani che lavorano sotto pressione, con agende politiche nascoste e paure mai dichiarate.

Secondo il Project Management Institute, il 70% dei progetti fallisce o viene consegnato con compromessi significativi su scope, tempi o budget. Ma questo dato maschera una verità più scomoda: la maggior parte dei project manager sa che il progetto sta fallendo settimane o mesi prima che il fallimento diventi ufficiale. Lo sanno perché vedono i segnali. Il problema è che quegli stessi project manager non hanno gli strumenti per intervenire sulla causa reale del fallimento dei progetti: la dinamica umana che sta sotto la superficie dei deliverable e dei milestone.

La letteratura sul project management è piena di framework, metodologie, tool. Waterfall, Agile, Hybrid. PRINCE2, PMBOK, Scrum. Tutti utili, tutti necessari. Ma nessuno ti dice cosa fare quando il tuo sponsor è politicamente debole e sta per essere esautorato. Nessuno ti spiega come gestire il conflitto latente tra due responsabili di area che si odiano da anni. Nessuno ti insegna a riconoscere quando un team sta mentendo sui progressi perché ha paura di ammettere di essere in ritardo.

Questo articolo non è un’introduzione al project management. È un’analisi di ciò che succede quando i progetti entrano in contatto con la realtà organizzativa. È scritto per chi ha già gestito progetti, per chi ha già visto un progetto crollare nonostante tutto fosse “formalmente corretto”, e si è chiesto: cosa è andato storto davvero?

La Distanza Tra Project Management Teorico e Realtà Organizzativa

Il gap tra teoria e pratica nel project management reale non è un problema di competenza tecnica. È un problema di modello mentale. I framework tradizionali assumono che le organizzazioni siano sistemi razionali dove le decisioni seguono logiche di ottimizzazione delle risorse. La realtà è che le organizzazioni sono organismi politici dove le decisioni seguono logiche di sopravvivenza individuale e di gruppo.

Quando un project manager pianifica un progetto usando il PMBOK, sta creando un artefatto razionale: WBS, schedule, risk register, stakeholder matrix. Tutto corretto, tutto necessario. Ma quel documento esiste in un universo parallelo rispetto a quello in cui il progetto dovrà essere eseguito. Nell’universo reale, il responsabile IT che dovrebbe fornire tre risorse per sei mesi sa che quelle risorse sono già sovrallocate su altri quattro progetti. Ma non lo dice in kick-off, perché ammettere che il suo dipartimento è cronicamente sottofinanziato lo renderebbe politicamente vulnerabile. Così firma il project charter e promette le risorse, sapendo che tra due mesi inizierà a negoziare riduzioni di scope o estensioni di timeline.

Secondo uno studio McKinsey del 2023, il 45% dei progetti IT supera il budget del 200% o più, e il 60% consegna il 50% o meno delle funzionalità previste. Ma il dato più interessante è un altro: l’87% dei project manager intervistati ha dichiarato di aver identificato segnali di allarme critici nei primi tre mesi del progetto, ma solo il 23% ha scalato formalmente il problema al governance board. Perché? Perché scalare significa ammettere che il progetto è fuori controllo. E ammettere questo troppo presto significa essere etichettato come “il PM che non sa gestire i progetti”. Meglio aspettare, meglio provare a recuperare, meglio sperare che qualcosa cambi.

Questa distanza tra teoria e pratica si manifesta in tre aree critiche: la governance, la comunicazione e la gestione del cambiamento. Sul piano della governance, i progetti hanno strutture decisionali formali — steering committee, PMO, sponsor — ma le decisioni vere vengono prese altrove. In riunioni informali, in telefonate one-to-one, in email che non vengono verbalizzate. Sul piano della comunicazione, esistono status report settimanali e dashboard colorati, ma le informazioni critiche circolano attraverso canali back-channel: il coffee break dove qualcuno ti dice “guarda che quello non ti darà mai quelle risorse”, o la cena dove scopri che il tuo sponsor principale sta per essere trasferito. Sul piano della gestione del cambiamento, i progetti hanno un change management plan che descrive training, comunicazione, engagement. Ma nessuno di questi documenti cattura la resistenza viscerale di un middle manager che sa che il nuovo sistema renderà obsoleto il suo ruolo.

 

Le Cinque Cause Reali di Fallimento dei Progetti

Il fallimento dei progetti ha sempre una narrativa ufficiale: ritardi imprevisti, requisiti cambiati, risorse non disponibili, problemi tecnici. Sono tutte vere, ma sono sintomi. Le cause reali sono più profonde e riguardano sempre dinamiche umane e organizzative che i framework non catturano.

 

Causa 1: Sponsor Debole o Assente

Uno sponsor debole non è uno sponsor che non partecipa alle riunioni. È uno sponsor che non ha capitale politico sufficiente per proteggere il progetto quando qualcosa va storto. Può essere il responsabile più presente del mondo, può fare tutte le riunioni settimanali, può approvare tutti i documenti. Ma se nell’organizzazione non ha il peso per dire “no” a un altro direttore che vuole sottrarre risorse al progetto, il progetto è vulnerabile.

La debolezza dello sponsor si manifesta in modi sottili. Non ti dice mai apertamente “non ho potere”. Ti dice “vediamo come si evolve la situazione”, “dobbiamo essere flessibili”, “cerchiamo di non creare tensioni con le altre direzioni”. Sono tutte frasi che traducono la stessa cosa: non ho la forza per difendere questo progetto contro altri interessi organizzativi. Uno studio di Harvard Business Review del 2022 ha analizzato 250 progetti enterprise e ha identificato che il 62% dei progetti falliti aveva uno sponsor con anzianità organizzativa inferiore ai tre anni, mentre solo il 18% dei progetti di successo aveva sponsor con meno di tre anni di tenure. Non è una questione di competenza: è una questione di network interno, di debiti e crediti politici accumulati, di capacità di chiamare in causa favori quando serve.

Un project manager esperto riconosce uno sponsor debole dai segnali indiretti. Quando proponi di escalare un problema critico e lo sponsor ti risponde “vediamo se riusciamo a risolverlo internamente prima”, quello è un segnale. Quando chiedi di avere un confronto diretto con un altro direttore che sta bloccando il progetto e lo sponsor ti dice “lascia fare a me”, ma poi non succede niente, quello è un altro segnale. Quando i verbali dello steering committee sono pieni di “si prende atto” e “si monitorerà”, ma non ci sono mai decisioni chiare con responsabili e deadline, quello è il segnale definitivo.

 

Causa 2: Conflitto Non Gestito Tra Stakeholder Chiave

Il conflitto tra stakeholder è fisiologico. Anzi, un progetto senza conflitto è sospetto: significa che qualcuno non sta dicendo quello che pensa davvero. Il problema non è il conflitto in sé, è il conflitto non dichiarato e non gestito. Quello che rimane sotto traccia, che si manifesta come “resistenza passiva”, “mancata disponibilità”, “ritardi inspiegabili”.

Il conflitto non gestito distrugge i progetti perché li trasforma in campi di battaglia per proxy. Il vero conflitto è tra il Direttore Operations e il Direttore IT su chi deve controllare il budget tecnologico. Ma questo conflitto non può essere dichiarato apertamente perché entrambi rispondono allo stesso CEO e devono mantenere un’apparenza di collaborazione. Quindi il conflitto viene combattuto attraverso il progetto: il Direttore Operations chiede cambi di requisiti continui per dimostrare che l’IT non capisce il business. Il Direttore IT risponde con analisi di impatto che fanno sembrare ogni richiesta proibitivamente costosa. Il progetto diventa il terreno dove si gioca una partita completamente diversa.

Secondo Gartner, il 58% dei progetti enterprise coinvolge almeno due stakeholder con agende contrapposte non risolte. E il 73% dei project manager dichiara di non avere mandato formale per mediare conflitti tra pari grado o superiori. Risultato: il project manager si trova a gestire un conflitto che non può gestire, perché non ha l’autorità per farlo e perché le parti in conflitto non hanno interesse a risolverlo. L’unica soluzione reale sarebbe che lo sponsor intervenga e impone una decisione. Ma se lo sponsor è debole — vedi punto precedente — questo non succederà.

 

Causa 3: Team Che Non Si Fida

Un team di progetto assemblato da persone che non si conoscono, che provengono da dipartimenti diversi, che hanno culture di lavoro diverse, non diventa automaticamente un team funzionale solo perché è scritto in un RACI chart. La fiducia si costruisce nel tempo, attraverso interazioni ripetute, attraverso la dimostrazione che gli altri fanno quello che dicono di fare. In un progetto, spesso non c’è questo tempo.

Il problema è che senza fiducia, il team non condivide informazioni reali. Nessuno vuole essere il primo a dire “ho un problema”. Perché ammettere un problema significa esporsi. Meglio aspettare, meglio nascondere, meglio sperare che qualcun altro abbia un problema più grande che distragga l’attenzione. Così i problemi reali emergono quando è troppo tardi per risolverli. Il PMI riporta che il 44% dei progetti che sforano i tempi ha avuto ritardi iniziali non comunicati per più di quattro settimane prima dell’escalation ufficiale.

La mancanza di fiducia si vede in riunioni dove tutti dicono che “va tutto bene” ma le milestone slittano settimana dopo settimana. Si vede nei report di avanzamento dove tutto è sempre “green” tranne una o due voci in “amber”, e niente è mai in “red” fino al momento esatto in cui diventa impossibile negare il problema. Si vede nel linguaggio: frasi come “stiamo monitorando”, “abbiamo identificato alcuni challenge”, “siamo fiduciosi di recuperare” sono tutte traduzioni di “siamo nei guai ma non vogliamo dirlo”.

 

Causa 4: Requisiti Politici Mascherati da Requisiti Funzionali

I requisiti funzionali sono razionali: descrivono cosa il sistema deve fare per risolvere un problema di business. I requisiti politici sono irrazionali: descrivono cosa il sistema deve fare per soddisfare l’agenda di qualcuno. Il problema è che i requisiti politici non vengono mai dichiarati come tali. Vengono mascherati da requisiti funzionali, e questo rende impossibile gestirli razionalmente.

Un esempio classico: il responsabile di un dipartimento chiede che il nuovo sistema generi un report specifico con una logica di calcolo particolare. La giustificazione ufficiale è “serve per il controllo di gestione”. La vera ragione è che quel report usa una metrica che fa sembrare il suo dipartimento più performante di quanto sia realmente, e lui vuole istituzionalizzare quella metrica prima che qualcuno se ne accorga. Il project manager implementa il requisito perché è formalmente giustificato. Ma sei mesi dopo, quando un altro direttore scopre che il report distorce i dati, inizia un conflitto che blocca il go-live.

Un altro esempio: una funzionalità viene richiesta non perché serve al business, ma perché il responsabile IT vuole sperimentare una tecnologia specifica per aggiornare il suo CV. Anche qui, la giustificazione ufficiale è tecnica: “dobbiamo modernizzare l’architettura”, “è importante essere allineati alle best practice”. La vera ragione è personale. E quando quella tecnologia si rivela troppo complessa e fa esplodere i tempi, il progetto paga il prezzo di un requisito che non aveva senso di business.

 

Causa 5: Organizzazione Non Pronta al Cambiamento

Il change management è la parte del progetto che tutti sottovalutano perché non è tangibile. Non è codice, non è infrastruttura, non è un deliverable che puoi mostrare. È lavorare con le persone perché accettino e adottino il cambiamento. E questo richiede tempo, energia e una profonda comprensione delle dinamiche psicologiche e organizzative.

Un’organizzazione non pronta al cambiamento non è un’organizzazione che “resiste per principio”. È un’organizzazione dove le persone hanno paura. Paura di perdere competenza, paura di perdere status, paura di dover imparare qualcosa di nuovo a 50 anni, paura che il nuovo sistema riveli che il loro lavoro è meno critico di quanto pensassero. E quando le persone hanno paura, si difendono. Non apertamente — dire “ho paura” è vulnerabile. Si difendono con resistenza passiva, con richieste impossibili, con critiche continue al nuovo sistema.

Secondo il World Economic Forum, il 67% dei progetti di trasformazione digitale fallisce non per ragioni tecniche ma per incapacità dell’organizzazione di adottare i nuovi processi. E la causa principale di questa incapacità è la mancanza di un vero change management, che non significa “fare training” o “mandare newsletter”. Significa lavorare con i middle manager che hanno più da perdere, significa identificare chi sono i resistenti chiave e capire cosa li spaventa davvero, significa costruire alleanze con chi ha interesse al successo del progetto e dargli strumenti per influenzare i loro pari.

 

Cosa fa davvero un project manager efficace nella realtà

Il project management reale richiede competenze che nessun framework insegna esplicitamente. Un project manager efficace nella realtà non è quello che segue pedissequamente il PMBOK. È quello che capisce le dinamiche umane e organizzative, e usa il framework come strumento per navigare.

La prima competenza è leggere le persone. Non in senso mistico. Leggere le persone significa osservare i comportamenti, identificare i pattern, riconoscere quando qualcuno sta dicendo una cosa ma ne pensa un’altra. Significa notare che lo stakeholder X partecipa alle riunioni ma non interviene mai, e poi scoprire che sta facendo lobby contro il progetto in altri contesti. Significa ascoltare il tono oltre alle parole: quando qualcuno dice “sì, certo, nessun problema” ma il tono è piatto e senza energia, quello non è un vero “sì”. È un “non ho voglia di discutere ora, ma non farò quello che mi stai chiedendo”.

La seconda competenza è costruire alleanze politiche. Un progetto senza alleati interni è un progetto destinato a fallire alla prima crisi. Le alleanze si costruiscono identificando chi ha interesse al successo del progetto — non interesse dichiarato, interesse reale — e investendo tempo per costruire relazioni con quelle persone. Non è networking superficiale. È capire cosa vogliono, cosa li preoccupa e trovare modi per allineare il successo del progetto al loro successo personale.

La terza competenza è gestire il conflitto senza distruggerlo. Il conflitto è informazione. Quando due stakeholder sono in disaccordo, stanno esplicitando due visioni diverse del problema o della soluzione. Sopprimere il conflitto significa perdere quell’informazione. Ma lasciare che il conflitto degeneri significa paralizzare il progetto. La gestione efficace del conflitto significa portarlo in superficie in contesti controllati, facilitare la discussione e guidare verso una decisione anche quando non c’è consenso totale. Significa dire “capisco che non siamo d’accordo, ma dobbiamo prendere una decisione entro venerdì. Propongo X, se avete alternative presentatele entro mercoledì con un’analisi di impatto”.

La quarta competenza è comunicare rischio e status senza filtri ma con intelligenza. I project manager che comunicano solo buone notizie perdono credibilità. Quelli che comunicano solo cattive notizie vengono etichettati come pessimisti e sostituiti. La comunicazione efficace significa essere onesti sui problemi ma proporre sempre opzioni. Non “siamo in ritardo di tre settimane”, ma “siamo in ritardo di tre settimane, abbiamo tre opzioni: ridurre scope su feature Y, aggiungere due risorse per un mese, o spostare il go-live. Vi presento l’analisi di impatto di ciascuna opzione e vi chiedo una decisione entro due giorni”.

La quinta competenza è proteggere il team dalla politica senza nascondere la realtà. Il team deve essere schermato dalle dinamiche politiche che non può controllare, altrimenti perde focus e motivazione. Ma non può essere completamente isolato dalla realtà, altrimenti non capisce perché certe decisioni vengono prese. Il bilanciamento è delicato: condividere il contesto necessario per capire le priorità, ma non trasformare il team in spettatore passivo dei conflitti tra director.

 

I segnali di allarme che i framework non catturano

Esistono segnali di allarme che precedono il fallimento di progetti di settimane o mesi. Sono segnali sottili, che non compaiono nei risk register o nei dashboard, ma che un project manager esperto riconosce. Il primo segnale è lo sponsor che smette di rispondere rapidamente. Non parliamo di ritardi di giorni, parliamo di pattern. Quando uno sponsor che normalmente risponde alle email in 2-3 ore inizia sistematicamente a impiegare 24-48 ore, o a rispondere con frasi vaghe tipo “vediamo”, quello è un segnale. Significa che il progetto ha smesso di essere la sua priorità. E se ha smesso di essere la priorità dello sponsor, significa che sta succedendo qualcosa di più importante nell’organizzazione che sta attirando la sua attenzione — o che lo sponsor ha capito che il progetto è problematico e sta prendendo distanza per non esserne compromesso.

Il secondo segnale è il linguaggio evasivo nelle riunioni. Quando le persone iniziano a usare frasi come “ci stiamo lavorando”, “stiamo valutando”, “stiamo monitorando”, senza mai dare date specifiche o commitment concreti, quello è un segnale. Il linguaggio evasivo è un meccanismo di difesa: le persone lo usano quando non vogliono prendersi la responsabilità per qualcosa che sanno di non poter consegnare. Un team che funziona usa linguaggio preciso: “avremo pronto il mock-up per giovedì alle 15”, “abbiamo completato il 60% dei test case”, “ci mancano ancora 15 giorni/uomo per chiudere la fase”. L’emissività è il contrario della precisione e segnala sempre un problema.

Il terzo segnale è la resistenza ad aggiornare piani o stime. Quando chiedi al team di rivedere il piano perché qualcosa è cambiato e ottieni resistenza — “il piano è quello”, “abbiamo già pianificato tutto”, “non possiamo cambiare ora” — quello è un segnale. Un team che funziona sa che i piani si volgono con la realtà. Un team in difficoltà si aggrappa al piano originale perché ammettere che serve cambiarlo significa ammettere che il progetto è fuori controllo. È un meccanismo psicologico di negazione, e quando lo vedi significa che qualcuno nel team ha già capito che non ce la farete con i tempi o le risorse attuali ma non vuole dirlo.

Il quarto segnale è l’assenza di escalation. Può sembrare controintuitivo: se nessuno scala problemi, dovrebbe essere un segnale positivo. In realtà è il contrario. Un progetto complesso genera sempre problemi. Se non ne vedi emergere, significa che qualcuno li sta nascondendo. I progetti di successo hanno un flusso costante di issue minori che vengono gestiti rapidamente. I progetti che falliscono hanno lunghi periodi di silenzio apparente, seguiti da esplosioni improvvise di crisi quando il problema nascosto diventa impossibile da ignorare.

Il quinto segnale è l’aumento delle riunioni one-to-one. Quando noti che gli stakeholder o i membri del team iniziano a chiederti riunioni bilaterali invece di portare i temi nelle riunioni plenarie, quello è un segnale. Le riunioni one-to-one aumentano quando le persone non si fidano più del gruppo. Hanno agende private, vogliono influenzare separatamente, o vogliono comunicare qualcosa che non possono dire davanti agli altri. Non è necessariamente negativo — a volte è l’unico modo per far emergere informazioni critiche — ma è sempre un sintomo di disfunzione nella dinamica di gruppo.

 

Come Intervenire Quando il Progetto Sta Fallendo

Riconoscere che un progetto sta fallendo è difficile. Intervenire efficacemente è ancora più difficile, perché richiede azioni che i framework non prescrivono e che spesso mettono il project manager in posizione vulnerabile. La prima azione è forzare la conversazione onesta con lo sponsor. Non in una riunione di status normale. In una conversazione privata, preparata, dove porti dati concreti sui segnali di allarme e chiedi allo sponsor di schierarsi. “Ho identificato questi cinque segnali che indicano che il progetto è a rischio critico. Ho bisogno che tu mi dica se hai il mandato e la volontà di intervenire, perché se non ce l’hai dobbiamo riposizionare il progetto o ridurre gli obiettivi ora, prima che diventi un fallimento pubblico”. È una conversazione rischiosa, ma è l’unica che funziona. Uno sponsor che risponde con azioni concrete è uno sponsor che può salvare il progetto. Uno sponsor che risponde con vaghe rassicurazioni non lo farà.

La seconda azione è portare i conflitti in superficie in modo strutturato. Se hai identificato un conflitto latente tra stakeholder, l’istinto è evitarlo o gestirlo informalmente. Non funziona. I conflitti latenti peggiorano col tempo. L’approccio strutturato significa convocare una riunione specifica con le parti in conflitto e lo sponsor, con un’agenda esplicita: “abbiamo un disallineamento su X, dobbiamo risolverlo oggi, le opzioni sono A, B, C, decidiamo quale e andiamo avanti”. È scomodo, ma è l’unico modo per sbloccare situazioni dove il conflitto sta paralizzando il progetto. E la presenza dello sponsor è fondamentale: è lui che deve imporre la decisione se le parti non convergono.

La terza azione è ridurre lo scope radicalmente e rapidamente. Quando un progetto è in crisi, la tendenza è provare a recuperare. Lavorare di più, pressare il team, sperare in qualche miracolo. Non funziona. Un progetto in crisi deve prima stabilizzarsi, e si stabilizza solo riducendo il carico. Significa identificare il 20% delle feature che danno l’80% del valore e consegnare quelle. Il resto va in fase 2, o viene cancellato. Questa è la decisione più difficile perché significa ammettere che non consegnerai tutto quello che avevi promesso. Ma è l’unica decisione che può salvare il progetto da un fallimento totale.

La quarta azione è sostituire persone che non funzionano. Sembra brutale, ma in un progetto in crisi non c’è tempo per recuperare chi non sta performando. Se un membro del team non sta consegnando nonostante supporto e coaching, va sostituito. Se uno stakeholder chiave sta attivamente sabotando il progetto, va rimosso dal governance o ridotto a ruolo consultivo. Queste decisioni richiedono il supporto dello sponsor, ma sono necessarie. Un progetto in crisi non può permettersi dead weight o sabotatori attivi.

La quinta azione è comunicare la crisi in modo controllato prima che esploda in modo incontrollato. Se il progetto sta fallendo, la notizia uscirà comunque. È meglio che esca attraverso una comunicazione gestita, dove tu controlli il framing, piuttosto che attraverso rumor o escalation da parte di qualcuno che vuole usare il fallimento per i propri scopi politici. La comunicazione controllata significa: un documento che spiega lo stato attuale, le cause, le azioni correttive e una nuova baseline realistica. Va presentato al governance board con il supporto dello sponsor. Non è una giustificazione, è un reframing: da “il progetto sta fallendo” a “il progetto ha incontrato ostacoli significativi, abbiamo identificato le cause, abbiamo un piano per consegnare valore ridotto ma reale entro una nuova timeline”.

 

Il Mindset del Project Manager che Sopravvive alla Realtà Organizzativa

Il project management reale richiede un mindset specifico che non viene insegnato nelle certificazioni. Il primo elemento di questo mindset è accettare che il controllo sia un’illusione. I framework vendono l’idea che se fai il piano giusto, se gestisci i rischi correttamente, se monitori i KPI, avrai il controllo del progetto. È falso. In un progetto complesso dentro un’organizzazione complessa, ci sono troppe variabili fuori dal tuo controllo: decisioni prese tre livelli sopra di te, tagli di budget decisi dal CFO, riorganizzazioni improvvise, turnover di persone chiave. Non puoi controllare queste cose. Puoi solo costruire resilienza: piani flessibili, opzioni multiple, alleanze solide.

Il secondo elemento è trattare il progetto come un organismo vivente, non come una macchina. Le macchine funzionano in modo deterministico: se metti input X, ottieni output Y. Gli organismi sono non-lineari: lo stesso input può produrre output diversi a seconda del contesto. Un progetto è fatto di persone, e le persone non sono deterministiche. Cambiano idea, si demotivano, entrano in conflitto, hanno giornate buone e giornate pessime. Un project manager efficace osserva questi pattern, si adatta, modifica l’approccio. Non cerca di imporre la macchina sull’organismo.

Il terzo elemento è separare il progetto dalla propria identità. Molti project manager si identificano col progetto: se il progetto ha successo, loro hanno valore; se il progetto fallisce, loro non valgono niente. Questa identificazione è tossica perché distorce il giudizio. Ti impedisce di vedere i problemi reali perché ammettere che il progetto è in crisi significa ammettere che tu hai fallito. Un project manager maturo sa che un progetto può fallire per motivi fuori dal suo controllo, e che la sua responsabilità non è consegnare il successo a ogni costo, ma gestire il progetto nel modo più professionale possibile date le condizioni reali.

Il quarto elemento è accettare che la politica non è il male, è parte del gioco. Molti project manager vedono la politica organizzativa come qualcosa di negativo, una distorsione che impedisce al progetto di procedere razionalmente. Ma la politica è semplicemente il modo in cui le organizzazioni collocano potere e risorse quando non c’è un algoritmo oggettivo per farlo. Non puoi evitare la politica. Puoi solo decidere se giocherà attivamente o lo subirai passivamente. I project manager che sopravvivono sono quelli che la giocano attivamente: costruiscono relazioni, capiscono le agende, trovano win-win, negoziano, influenzano. Non è sporco, è parte del lavoro.

Il quinto elemento è sapere quando lasciare andare. Ci sono progetti che non possono essere salvati. Progetti dove lo sponsor è troppo debole, dove i conflitti sono troppo radicati, dove l’organizzazione non è pronta e non lo sarà. In questi casi, la cosa più professionale che un project manager può fare è identificare chiaramente la situazione, comunicarla e raccomandare di terminare il progetto o metterlo in stand-by invece di continuare a bruciare budget e credibilità. Questa raccomandazione è raramente accettata — le organizzazioni odiano ammettere il fallimento — ma va fatta comunque. E se non viene accettata, va documentata, perché quando il progetto fallirà, quella documentazione proteggerà la tua reputazione professionale.

Il project management reale è una disciplina che si impara sul campo, attraverso progetti che falliscono e progetti che hanno successo. I framework sono utili come linguaggio comune e come checklist di completezza. Ma non sono sufficienti. La differenza tra un project manager medio e uno eccellente non sta nella conoscenza del PMBOK o di Scrum. Sta nella capacità di leggere le dinamiche umane e organizzative, di costruire alleanze, di gestire conflitti, di comunicare verità scomode, di prendere decisioni difficili quando serve. Queste competenze non si imparano studiando. Si imparano facendo, sbagliando, osservando, riflettendo. E soprattutto, si imparano accettando che un progetto è sempre, prima di tutto, un sistema di esseri umani che lavorano insieme sotto pressione. E gli esseri umani non seguono mai perfettamente i piani.