PMI e Agile: quando serve pianificare e quando serve adattarsi

✍️ Auctor: Gian Luigi Venturin   🗓️ 12 Iunius 2026

Perché questo articolo

Chiunque abbia partecipato almeno una volta ad un progetto, indipendentemente dal ruolo ricoperto o dall'ambito in cui quel progetto si è sviluppato, si è probabilmente trovato, prima o poi, davanti alla stessa domanda, anche se spesso formulata con parole diverse: quali decisioni dobbiamo prendere oggi e quali, invece, possiamo permetterci di rimandare senza compromettere il risultato finale?

È una domanda sulla quale mi sono trovato anch’io a riflettere molte volte, prima come project manager, poi come consulente e infine come docente. Ho incontrato aziende molto diverse tra loro, ho partecipato a progetti che riguardavano impianti produttivi, organizzazioni, processi, servizi e prodotti, ed ogni volta, indipendentemente dal settore o dalla complessità del progetto, mi rendevo conto che la domanda era sempre la stessa, anche se nessuno la formulava esplicitamente.

Per molti anni il dibattito sul project management è stato raccontato come una scelta tra due modelli: da una parte il modello tradizionale, rappresentato dal PMI, dall'altra il modello Agile. Due approcci che, soprattutto agli inizi, sono stati spesso descritti come alternativi, quasi appartenessero a due scuole di pensiero destinate ad escludersi a vicenda.

Con il passare degli anni, però, ho smesso di chiedermi quale fosse il modello migliore e ho iniziato a pormi una domanda completamente diversa: quale problema stiamo cercando di risolvere?

È stato proprio questo cambiamento di prospettiva a farmi comprendere che il punto non è scegliere tra PMI e Agile, ma riconoscere che non tutte le decisioni hanno la stessa natura:perché i due modelli non sono in competizione, ma rispondono a decisioni di natura diversa.

Alcune decisioni devono essere prese fin dall'inizio, perché modificarle successivamente significherebbe ripensare buona parte del progetto, con costi economici, organizzativi o tecnici molto elevati; altre, invece, possono essere lasciate volutamente aperte, possono evolvere insieme al progetto, possono migliorare grazie all'esperienza, ai risultati via via ottenuti, ai suggerimenti del cliente o semplicemente perché, nel frattempo, il contesto è cambiato e sono emerse opportunità che all'inizio non era possibile prevedere.

Più una decisione è costosa da modificare, più richiede pianificazione; più una decisione è semplice da modificare, più conviene mantenerla aperta il più a lungo possibile.

A prima vista sembrerebbe un progetto da gestire esclusivamente con un approccio tradizionale: in realtà, anche in un'opera complessa come una galleria ferroviaria convivono decisioni che devono essere definite fin dall'inizio e altre che possono maturare durante l'esecuzione dei lavori. È questa distinzione, più ancora della metodologia scelta, che determina il modo corretto di governare un progetto.

Nel corso degli anni ho utilizzato questa riflessione anche durante i miei corsi, perché mi sono accorto che aiutava le persone a comprendere il motivo per cui esistono due modelli di gestione dei progetti, ancora prima di entrare nel dettaglio delle metodologie. PMI e Agile, infatti, non sono due modelli in competizione: sono due modelli che rispondono a esigenze diverse e che, proprio per questo, oggi possono convivere e completarsi a vicenda.

Con questo articolo non entreremo ancora nel dettaglio delle metodologie, dei ruoli o degli strumenti operativi, lo faremo nei prossimi approfondimenti. L'obiettivo di queste pagine è diverso: capire perché esistono due modelli di gestione dei progetti, quali problemi cercano di risolvere e perché, nella mia esperienza, la domanda più utile non è "PMI o Agile?", ma "quale tipo di decisione sto gestendo? "

Quando il mio modo di vedere i progetti iniziò a cambiare

La riunione di progetto durava oramai da parecchio tempo, così che qualcuno propose di rinviare una decisione apparentemente secondaria: sul tavolo c'erano i disegni del nuovo impianto, le prime ipotesi di layout e una domanda che, in quel momento, sembrava riguardare soltanto un dettaglio tecnico. In realtà, riguardava molto di più: stavamo cercando di capire se quella scelta fosse un vincolo del progetto da decidere subito oppure se potesse essere presa più avanti.

Momenti come questi, nelle riunioni di progetto, ne ho incontrati molti, al punto che, quasi senza accorgermene, ho iniziato a osservare i progetti con un'attenzione diversa.

Continuavo a vedere che alcune decisioni dovevano essere prese subito, mentre altre producevano risultati migliori proprio perché venivano rinviate. Fu allora che capii che il problema non era decidere in fretta o decidere lentamente, il problema era riconoscere quali decisioni appartenessero alla prima categoria e quali alla seconda.

Ripensando a quegli anni, mi resi conto che le decisioni più difficili non erano necessariamente le più importanti: erano quelle che, una volta prese, diventavano estremamente costose da modificare. Altre decisioni, invece, producevano risultati migliori proprio perché potevano essere lasciate aperte ancora per un po', consentendo al progetto di maturare insieme alle informazioni che via via emergevano.

Più una decisione è costosa da modificare, più richiede pianificazione; più una decisione è semplice da modificare, più conviene mantenerla aperta il più a lungo possibile.

Come porto oggi tutto questo in aula

Quando, durante un corso, mi viene chiesto quale metodologia sia migliore, sorrido sempre. Non perché la domanda sia sbagliata, ma perché, dopo tanti anni trascorsi a lavorare nei progetti, ho imparato che contiene un presupposto che raramente corrisponde alla realtà.

A quel punto rispondo quasi sempre con una domanda: “quale problema stiamo cercando di risolvere? ”

Immaginiamo di progettare un edificio, ci sono decisioni che riguardano la posizione dell'edificio, le fondazioni, la struttura portante, il numero dei piani: sono decisioni che, una volta prese, diventano estremamente costose da modificare, cambiarle in corso d'opera significa ripensare il progetto, sostenere costi elevati e, in molti casi, ricominciare da capo.

Accanto a queste, però, esistono molte altre decisioni che possono maturare durante il progetto: la distribuzione di alcuni ambienti, determinate soluzioni tecnologiche, alcune finiture, perfino aspetti che inizialmente sembravano importanti ma che, grazie all'esperienza maturata durante il lavoro, possono essere rivisti senza compromettere l'intera struttura del progetto.

A questo punto la domanda iniziale cambia completamente significato: non si tratta più di scegliere tra PMI e Agile, si tratta di capire quale tipo di decisione abbiamo davanti.

Se stiamo governando decisioni strutturali, che una volta prese diventano difficili e costose da modificare, il modello tradizionale del Project Management offre strumenti di pianificazione e controllo estremamente efficaci.

Se, invece, stiamo affrontando decisioni che possono evolvere grazie al confronto continuo, ai risultati via via ottenuti e al dialogo con il cliente, il modello Agile permette di adattare il progetto senza perdere di vista l'obiettivo finale.

È in quel momento che, quasi sempre, in aula succede qualcosa di interessante: le persone smettono di chiedermi quale metodologia sia migliore, cominciano a chiedersi quale sia il modo migliore per gestire quella particolare decisione.

Ed è esattamente questo il risultato che cerco di ottenere.

PMI e Agile

Per molti anni il dibattito tra PMI e Agile è stato raccontato come una contrapposizione tra due modi diversi di gestire i progetti, ma l'evoluzione delle organizzazioni, l'esperienza maturata sul campo e la stessa evoluzione delle metodologie hanno progressivamente dimostrato che quella contrapposizione aveva poco senso: oggi sappiamo che pianificazione e adattamento possono convivere e che, molto spesso, convivono all'interno dello stesso progetto.

Nei prossimi approfondimenti entreremo nel dettaglio di entrambi i modelli, dedicheremo almeno un articolo al PMI e uno all'Agile Management, cercando di comprenderne principi, strumenti e modalità operative, perché il vero punto non è scegliere un modello, il vero punto è imparare a riconoscere la natura delle decisioni che ogni progetto ci chiede di prendere.