Quando i framework diventano una scusa

Negli ultimi vent’anni, il mercato del Project Management ha visto un’esplosione di framework, metodologie, certificazioni. Agile, Scrum, Kanban, PRINCE2, Waterfall rivisitato, SAFe, ibridi di ogni tipo. Ognuno di questi metodi project management promette di risolvere il caos, ridurre i fallimenti, migliorare la delivery. Eppure, secondo il Pulse of the Profession 2024 del PMI, il 34% dei progetti continua a fallire o a non raggiungere gli obiettivi prefissati. Un dato che, nonostante decenni di evoluzione metodologica, rimane ostinatamente stabile. La domanda non è più “quale metodo usare”, ma “perché i metodi non bastano”.

La verità è scomoda: i framework sono diventati una comfort zone. Un modo per sentirsi professionali senza affrontare il vero problema. Perché il problema non è mai stato il processo. Il problema sono le persone che lo usano, il contesto in cui lo applicano, e la capacità — o incapacità — di adattarlo alla realtà invece di adattare la realtà al metodo. I metodi project management funzionano quando chi li usa capisce che sono strumenti, non religioni. Falliscono quando diventano gabbie cognitive che impediscono di vedere cosa sta realmente accadendo nel progetto.

Questo articolo non è un attacco ai framework. È un invito a riconoscere i limiti metodologici e a smettere di nascondersi dietro processi e best practice quando il progetto va a rotoli. Perché la differenza tra un progetto che funziona e uno che fallisce non sta nel metodo scelto, ma nella capacità del project manager di capire quando il metodo serve e quando serve buttarlo via.

 

Il mito del metodo perfetto

Ogni metodo nasce da un’esigenza specifica, in un contesto specifico, per risolvere un problema specifico. Scrum è nato per team di sviluppo software che lavoravano in contesti di incertezza elevata. PRINCE2 è stato progettato per progetti governativi con requisiti rigidi e accountability forte. Waterfall funzionava — e funziona ancora — in contesti industriali dove le variabili sono note e controllabili. Eppure, nel mondo reale, questi metodi vengono applicati ovunque, spesso senza alcuna analisi di contesto. Un progetto di costruzione gestito con Scrum. Un prodotto software gestito con Waterfall. Un team distribuito su tre continenti che segue PRINCE2 come se fosse il 1996.

Il problema non è il metodo in sé. È l’illusione che esista un metodo universale, valido per ogni progetto, ogni team, ogni azienda. Secondo una ricerca di Gartner del 2023, il 58% delle organizzazioni adotta framework agili senza aver mai analizzato se il contesto fosse compatibile con l’approccio. Il risultato? Processi ibridi che non sono né agili né strutturati, ma semplicemente confusi. Riunioni Daily Scrum fatte per rispettare il rituale, non per risolvere problemi. Retrospettive che non generano azioni. Sprint planning che diventano negoziazioni infinite perché nessuno ha chiaro cosa significhi “Done”.

I limiti metodologici emergono nel momento in cui si crede che seguire il processo sia sufficiente. Un project manager che rispetta tutti i passaggi di PRINCE2 ma non capisce perché li sta facendo è pericoloso quanto uno che improvvisa senza alcun metodo. Perché il metodo non pensa. Non prende decisioni. Non gestisce conflitti. Non sente quando il team è bruciato o quando uno stakeholder sta mentendo. Il metodo è una mappa, e come tutte le mappe, funziona solo se chi la usa sa dove sta andando.

 

Quando il processo diventa una scusa

C’è un momento, in ogni progetto che sta fallendo, in cui qualcuno dice: “Abbiamo seguito il processo alla lettera”. Come se questo fosse una difesa. Come se rispettare il metodo esimesse dalla responsabilità di ottenere risultati. Ma i progetti non falliscono perché il processo è sbagliato. Falliscono perché il processo è stato seguito meccanicamente, senza capire cosa stava succedendo sotto la superficie.

Un esempio concreto. Un’azienda tech di medio-grandi dimensioni decide di adottare SAFe per coordinare dieci team di sviluppo. Formazione costosa, consulenti esterni, roadmap dettagliate, PI Planning ogni tre mesi. Tutto perfetto, almeno sulla carta. Dopo un anno, il CEO chiede: “Dove sono i risultati?”. La risposta dei team: “Abbiamo rispettato tutte le cerimonie, tutti i ruoli, tutti i passaggi del framework”. Ma i prodotti rilasciati sono ancora lenti, pieni di bug, disconnessi dalle esigenze reali degli utenti. Il motivo? Nessuno ha mai chiesto se SAFe fosse il framework giusto per quella cultura aziendale. Nessuno ha mai verificato se i team avessero le competenze per lavorare in quel modo. Nessuno ha mai osato dire: “Questo non sta funzionando, cambiamo approccio”.

Il processo era diventato una scusa per non affrontare i problemi reali: una governance troppo pesante, una cultura del controllo invece che della responsabilità, stakeholder che chiedevano prevedibilità in un contesto intrinsecamente imprevedibile. I metodi project management offrono una rete di sicurezza psicologica. Se il progetto fallisce, la colpa è del metodo, non del project manager. Ma questa mentalità è letale, perché impedisce di vedere che il problema non è mai stato il framework, ma il modo in cui è stato applicato.

 

Il ruolo del contesto: perché ogni progetto è unico

Uno degli errori più gravi nella gestione dei progetti è trattare ogni progetto come se fosse identico al precedente. Stessa metodologia, stesse cerimonie, stessi strumenti. Ma ogni progetto è un ecosistema vivo, con variabili che cambiano continuamente: le persone coinvolte, la cultura aziendale, il livello di incertezza, le aspettative degli stakeholder, i vincoli di tempo e budget. Applicare un metodo senza considerare queste variabili è come usare lo stesso antibiotico per qualsiasi infezione: funziona a volte, ma spesso peggiora la situazione.

Secondo uno studio del Project Management Institute, i progetti di successo sono quelli in cui il project manager adatta il metodo al contesto, non il contrario. Eppure, la pressione organizzativa spinge nella direzione opposta. Le aziende vogliono standardizzare, certificare, ripetere. Vogliono una metodologia unica per tutti i progetti, perché è più facile da governare, da comunicare, da vendere ai clienti. Ma questa ricerca di standardizzazione uccide la flessibilità, che è esattamente ciò che serve per gestire l’incertezza.

Un esempio. Un progetto di infrastruttura IT per una banca richiede un approccio strutturato, con fasi chiare, deliverable definiti, controllo rigoroso dei cambiamenti. Waterfall o PRINCE2 sono scelte sensate. Ma se lo stesso approccio viene applicato allo sviluppo di una nuova app per clienti, in un mercato competitivo dove le priorità cambiano ogni settimana, il risultato è disastroso. Il team passa più tempo a gestire il change management formale che a sviluppare funzionalità utili. Gli stakeholder si sentono ingannati. Il prodotto finale arriva sul mercato sei mesi dopo la concorrenza.

I limiti metodologie non sono nel metodo stesso, ma nell’incapacità di riconoscere quando il metodo è inadeguato. Un project manager esperto sa che il contesto guida la scelta del metodo, non il contrario. Sa che alcuni progetti richiedono rigore e prevedibilità, altri richiedono velocità e iterazione. E sa che, spesso, la soluzione migliore non è scegliere un metodo puro, ma costruire un approccio ibrido che prenda il meglio di più metodologie. Ma questo richiede competenza, esperienza, e soprattutto il coraggio di deviare dal manuale.

 

Le persone prima del processo

Se c’è una lezione che emerge da ogni progetto fallito, è questa: i processi non eseguono progetti, le persone lo fanno. Un team disfunzionale può distruggere anche il miglior framework. Un team allineato, motivato e competente può far funzionare anche un processo improvvisato. Eppure, la maggior parte delle aziende investe enormemente in metodologie e strumenti, e pochissimo nelle persone che dovrebbero usarli.

Un progetto Agile senza un team che capisca i principi dell’Agile Manifesto è solo teatro. Daily standup dove nessuno ascolta. Sprint review dove si mostra codice che nessuno userà mai. Retrospettive dove si ripetono sempre gli stessi problemi senza mai risolverli. Il metodo c’è, ma mancano le condizioni perché funzioni: fiducia reciproca, responsabilità distribuita, capacità di autogestione. Secondo una ricerca di McKinsey, il 70% dei progetti Agile fallisce non per problemi tecnici, ma per problemi culturali e organizzativi. I team non sono pronti a lavorare in autonomia. I manager non sanno delegare. Gli stakeholder continuano a chiedere certezze in un contesto che per definizione non può darne.

I metodi project management presuppongono competenze che spesso non ci sono. Scrum presuppone che il team sappia stimare, prioritizzare, risolvere impedimenti. PRINCE2 presuppone che ci sia una governance chiara e una separazione netta tra ruoli. Ma nella realtà, i team sono composti da persone con livelli di esperienza disomogenei, con dinamiche relazionali complesse, con priorità personali che non sempre coincidono con quelle del progetto. Un project manager che si concentra solo sul processo e ignora le persone sta costruendo un castello di carte.

La gestione dei progetti è prima di tutto gestione di esseri umani. E gli esseri umani non sono variabili controllabili. Hanno emozioni, paure, ambizioni. Si stancano. Entrano in conflitto. Hanno vite fuori dal progetto. Un buon project manager sa che il suo lavoro principale non è riempire Gantt o aggiornare board Kanban, ma capire cosa sta succedendo nelle teste delle persone con cui lavora. Sa che un team demotivato non si risolve con un processo diverso, ma con ascolto, chiarezza, riconoscimento. Sa che un progetto che va a rotoli spesso non ha problemi tecnici, ma problemi umani che nessuno vuole affrontare.

 

L’illusione del controllo

Uno dei motivi per cui i metodi project management vengono adottati in modo così rigido è che offrono un senso di controllo. In un mondo aziendale sempre più complesso e imprevedibile, i framework danno l’illusione di poter governare il caos. Ma questa illusione è pericolosa, perché porta a ignorare i segnali di allarme. Un progetto può rispettare tutti i KPI, tutti i milestone, tutti i passaggi previsti dal metodo, e comunque essere destinato al fallimento.

Perché? Perché i limiti metodologie includono l’incapacità di misurare ciò che conta davvero. Un progetto può essere on time, on budget, e completamente inutile. Può rispettare lo scope iniziale in un mercato che nel frattempo è cambiato. Può soddisfare tutti i deliverable formali, ma non risolvere il problema per cui è stato avviato. I metodi misurano ciò che è misurabile: tempi, costi, output. Ma non misurano valore, impatto, utilità reale. E spesso, proprio questa focalizzazione sul controllabile porta a perdere di vista l’essenziale.

Un caso emblematico. Un’azienda manifatturiera lancia un progetto di digital transformation seguendo un approccio PRINCE2 rigoroso. Business case solido, governance impeccabile, fasi chiaramente definite. Dopo due anni e 5 milioni di euro, il progetto viene chiuso con successo. Tutti i deliverable sono stati consegnati. Ma sei mesi dopo, nessuno usa i nuovi strumenti digitali. I dipendenti continuano a lavorare come prima. Il ROI previsto non si materializza mai. Cosa è andato storto? Il metodo è stato seguito alla perfezione, ma nessuno ha mai chiesto se gli utenti finali volessero davvero quel cambiamento. Nessuno ha mai verificato se l’organizzazione fosse pronta ad adottarlo. Nessuno ha mai messo in discussione il business case iniziale, anche quando era evidente che le premesse erano cambiate.

Il controllo è un’illusione. I progetti sono sistemi complessi, dove piccole variazioni possono generare effetti imprevedibili. Cercare di controllarli attraverso processi rigidi è come cercare di prevedere il meteo con tre mesi di anticipo: tecnicamente possibile sulla carta, praticamente inutile nella realtà. I project manager di successo non sono quelli che controllano tutto, ma quelli che sanno navigare l’incertezza, adattarsi velocemente, e prendere decisioni anche quando non hanno tutte le informazioni.

 

Quando buttare via il manuale

C’è un momento, in ogni progetto difficile, in cui il metodo diventa un ostacolo. Quando seguire il processo significa perdere tempo prezioso. Quando rispettare le cerimonie previste significa ignorare problemi urgenti. Quando il framework impedisce di fare ciò che andrebbe fatto. In questi momenti, il vero project manager sa che è il momento di buttare via il manuale.

Non significa improvvisare. Non significa abbandonare ogni disciplina. Significa riconoscere che il metodo è uno strumento, non un obiettivo. E che gli strumenti vanno usati quando servono, non per principio. Un progetto in crisi non si salva con un’ennesima retrospettiva o con un nuovo board Kanban. Si salva prendendo decisioni difficili: tagliare scope, cambiare team, rinegoziare con gli stakeholder, ammettere che le premesse iniziali erano sbagliate.

Secondo uno studio del Project Management Institute, i project manager più efficaci sono quelli che hanno una solida conoscenza dei metodi, ma sanno anche quando deviarvi. Sanno che Agile non significa “senza pianificazione”, ma pianificazione adattiva. Sanno che Waterfall non significa “rigidità”, ma struttura quando serve. Sanno che l’ibrido non è un compromesso, ma una scelta strategica. E sanno che, a volte, la cosa migliore da fare è inventare un approccio su misura, che non esiste in nessun manuale ma che risponde esattamente alle esigenze di quel progetto, in quel contesto, con quelle persone.

I metodi project management sono mappe. Ma la mappa non è il territorio. E quando il territorio cambia, serve un project manager che sappia leggere il territorio, non uno che continui a guardare la mappa sperando che la realtà si adatti ad essa. Questa capacità di deviare dal metodo quando serve è ciò che distingue un project manager mediocre da uno eccellente. Il primo segue il processo. Il secondo guida il progetto.

 

Cosa serve davvero per salvare i progetti

Se i metodi non salvano i progetti, cosa li salva? La risposta è scomoda perché non può essere standardizzata, certificata, o insegnata in un corso di due giorni. Ciò che salva i progetti è la competenza reale del project manager: la capacità di leggere il contesto, di capire le persone, di prendere decisioni sotto pressione, di adattarsi continuamente. E questa competenza non viene dal manuale, ma dall’esperienza, dalla riflessione, dal fallimento ripetuto seguito da apprendimento.

Un project manager competente sa che il metodo è solo uno degli strumenti a sua disposizione. Sa che la comunicazione conta più del Gantt. Sa che la fiducia tra i membri del team è più importante della board perfettamente aggiornata. Sa che uno stakeholder gestito bene può salvare un progetto, mentre uno stakeholder ignorato può affossare, indipendentemente dal metodo usato. Sa che i progetti si salvano con intelligenza emotiva, capacità politica, visione strategica. E sa che tutto questo non è nel PMBOK, né nello Scrum Guide, né in nessun altro framework.

Secondo Harvard Business Review, i progetti di successo hanno una caratteristica comune: un project manager che sa quando seguire il metodo e quando abbandonarlo. Che sa bilanciare rigore e flessibilità. Che sa ascoltare i segnali deboli prima che diventino crisi. Che sa dire no agli stakeholder quando è necessario. Che sa proteggere il team dalla pressione esterna. Che sa trasformare un problema tecnico in una decisione strategica. E che sa, soprattutto, che il suo lavoro non è applicare un processo, ma far accadere un risultato.

I limiti metodologie non sono un problema se il project manager li riconosce. Diventano un problema quando il metodo diventa un alibi, una scusa per non pensare, un rifugio per evitare responsabilità. I metodi non salvano i progetti. Le persone sì. E solo quando smetteremo di nasconderci dietro i framework iniziamo davvero a migliorare il tasso di successo dei nostri progetti.

 

Conclusione: i metodi sono solo l’inizio

I metodi project management hanno un ruolo. Offrono struttura, linguaggio comune, best practice consolidate. Ma non sono la soluzione. Sono l’inizio, non la fine. Un project manager che conosce Scrum, PRINCE2, Waterfall, SAFe ha una cassetta degli attrezzi ricca. Ma se non sa quando usare quale attrezzo, se non sa riconoscere che a volte l’attrezzo giusto non esiste e va inventato, se non sa che il successo del progetto dipende dalle persone più che dal processo, allora quella cassetta degli attrezzi non serve a nulla.

Il mercato del Project Management continuerà a produrre nuovi framework, nuove certificazioni, nuove mode. E va bene così. Ma il project manager che vuole fare davvero la differenza deve smettere di cercare il metodo perfetto e iniziare a costruire la competenza vera: quella che legge il contesto, gestisce le persone, prende decisioni, e sa quando è il momento di buttare via il manuale e fare ciò che serve. Perché alla fine, i progetti non si salvano con i metodi. Si salvano con l’intelligenza, il coraggio e l’esperienza di chi li guida.