Gestire il conflitto nei progetti

C’è una scena che chiunque abbia guidato un team di progetto conosce a memoria. Riunione di stato avanzamento lavori. Tutti seduti, o in call. Si parla di un task in ritardo, di una dipendenza mal gestita, di una stima errata. E poi, in modo quasi impercettibile, qualcosa cambia nell’aria. I toni si alzano di mezzo grado. Qualcuno diventa improvvisamente molto preciso nel ricordare cosa aveva detto tre settimane prima. Un altro inizia a rispondere con monosillabi. Non c’è ancora un litigio dichiarato. C’è qualcosa di peggio: un conflitto che si cristallizza nel silenzio, che cresce sotto la superficie del progetto e che, se ignorato, diventa più costoso di qualsiasi ritardo tecnico.

La gestione del conflitto nei progetti è uno dei temi su cui si gioca realmente la differenza tra un Project Manager bravo sulla carta e uno che ottiene risultati nel mondo reale. Non è una competenza soft nel senso riduttivo del termine. È una competenza strategica, che richiede consapevolezza psicologica, metodo e, sì, anche coraggio. Perché affrontare un conflitto in modo diretto — quando tutti intorno a te stanno cercando di farlo sparire sotto al tavolo — richiede una scelta precisa su chi sei come manager.

Secondo il PMI Pulse of the Profession 2023, oltre il 65% dei progetti che falliscono non fallisce per motivi tecnici o di budget: fallisce per dinamiche interpersonali non gestite. Il conflitto ingestito non è un effetto collaterale del lavoro di progetto — è una delle sue cause di morte più frequenti. Eppure nelle organizzazioni si continua a trattarlo come un’anomalia da silenziare, non come una variabile da governare. Questo articolo serve esattamente a cambiare quella prospettiva.

 

Il conflitto nei team di progetto: perché è inevitabile e perché è utile

La natura strutturale del conflitto in un progetto

Un progetto per definizione concentra in uno spazio temporale limitato persone con competenze diverse, priorità diverse e spesso linee gerarchiche diverse. Il Business Analyst risponde a una direzione, lo sviluppatore a un’altra, il referente del cliente a una terza. Il Project Manager non ha autorità gerarchica diretta su gran parte delle persone con cui lavora, eppure deve produrre risultati che dipendono da tutti loro. Questa è una condizione strutturalmente generatrice di conflitto. Non perché le persone siano difficili — ma perché il sistema è costruito in modo da creare attrito.

A questo si aggiunge la pressione tipica di qualsiasi contesto progettuale: scadenze compresse, scope che cambia, risorse che non bastano mai, stakeholder con aspettative divergenti. In questo ambiente, il conflitto non è un’eccezione. È la norma. Chi lo tratta come un’anomalia da evitare sta fondamentalmente rifiutando di fare il proprio lavoro. Chi invece lo riconosce come una variabile del sistema, e si attrezza per gestirla, ha già una marcia in più rispetto alla media.

Il conflitto funzionale esiste — e va cercato

C’è una distinzione che pochi manager fanno davvero in modo consapevole: quella tra conflitto disfunzionale e conflitto funzionale. Il primo è quello che tutti conoscono: scontri personali, difese di territorio, comunicazione aggressiva o passivo-aggressiva, boicottaggio silenzioso. È costoso, paralizzante, tossico per il clima del team. Va gestito, contenuto, risolto. Il secondo, invece, è quello che Patrick Lencioni ha descritto con precisione nella sua ricerca sui team ad alta performance: il disaccordo produttivo, la tensione creativa tra punti di vista diversi, il confronto diretto sulle idee. Questo tipo di conflitto, se canalizzato correttamente, produce decisioni migliori, soluzioni più robuste, team più coesi nel lungo periodo.

Il problema è che la maggior parte delle organizzazioni — e dei manager — tende a reprimere entrambi i tipi. Si crea una cultura della finta armonia in cui nessuno dice davvero quello che pensa, i problemi reali non emergono mai nelle riunioni formali, e le decisioni vengono prese fuori dalle stanze deputate a farle. Questo è l’ambiente più pericoloso in cui far crescere un progetto. Quando non c’è conflitto apparente, non significa che non ci sia conflitto. Significa che è andato sottoterra — e lì fa danni molto più grandi.

 

Le cause reali del conflitto nei team di progetto

Priorità divergenti tra stakeholder e team

Una delle fonti più comuni di conflitto nei progetti — e spesso quella meno riconosciuta — è la divergenza di priorità tra chi definisce gli obiettivi e chi li deve eseguire. Il cliente vuole tutto, subito, al minimo costo. Il team tecnico vuole fare le cose bene, con il tempo necessario. Il management vuole i numeri per il board. Il Project Manager sta nel mezzo, cercando di tenere insieme un sistema di aspettative che per definizione non può essere soddisfatto nella sua totalità. Quando questa tensione non viene resa esplicita — quando non si ha il coraggio di mettere sul tavolo i trade-off reali — la pressione si scarica sulle persone, e il conflitto esplode dove non ci si aspetta: in una riunione tecnica, in uno scambio di email, in un’escalation improvvisa.

Ambiguità di ruoli e responsabilità

L’altra causa strutturale del conflitto — quella che i Project Manager esperti imparano a riconoscere quasi a istinto — è l’ambiguità di ruolo. Chi decide cosa? Chi ha l’ultima parola su un’architettura tecnica? Il PM può bloccare un rilascio o deve passare per il team lead? Ogni zona grigia nelle responsabilità è un territorio fertile per il conflitto. Non perché le persone vogliano litigare, ma perché in assenza di confini chiari, ognuno agisce in base alla propria interpretazione del proprio ruolo — e quelle interpretazioni, quasi inevitabilmente, si sovrappongono e si scontrano.

Secondo una ricerca del Politecnico di Milano sui contesti di progetto complessi, la mancanza di chiarezza nei ruoli è citata come causa primaria di conflitto nel 48% dei casi analizzati. Non è un dato sorprendente per chi lavora sul campo. È invece sorprendente quante organizzazioni continuino a non investire tempo nella definizione esplicita delle responsabilità, affidandosi all’assunzione ottimistica che “le persone di buonsenso capiscano da soli”.

Differenze di stile e cultura

I team di progetto contemporanei sono spesso team multidisciplinari, multigenerazionali, e sempre più spesso multiculturali. Un professionista cresciuto in una cultura gerarchica forte tende a evitare il disaccordo diretto con chi percepisce come superiore. Un professionista abituato a contesti flat e agili interpreta quella stessa reticenza come mancanza di commitment. Entrambi hanno ragione nel loro modello del mondo. Nessuno dei due sta facendo qualcosa di sbagliato. Ma il conflitto latente che si genera da questo fraintendimento culturale può diventare rapidamente un problema reale se non viene nominato e gestito in modo consapevole.

 

I cinque approcci alla gestione del conflitto nei progetti: quando usarli davvero

Il modello Thomas-Kilmann applicato al project management 

Il modello di Thomas e Kilmann — che classifica gli approcci al conflitto lungo due assi, assertività e cooperazione — è probabilmente il framework più citato in letteratura sulla gestione del conflitto. Cinque stili: competizione, collaborazione, compromesso, evitamento, accomodamento. È un modello utile, a patto di non usarlo come un test della personalità ma come una bussola situazionale. Il punto non è capire “che tipo sei” quando ti trovi di fronte a un conflitto. Il punto è capire quale approccio è più efficace in quella specifica situazione, con quelle specifiche persone, in quel contesto di progetto.

La competizione — imporre la propria posizione — è appropriata quando c’è un’emergenza che richiede una decisione rapida e univoca, quando sono in gioco valori non negoziabili, o quando si è certi di avere ragione su un punto tecnico critico. Usarla come default, come fanno molti manager che confondono la fermezza con l’autorità, è una ricetta per demoralizzare il team e perdere i talenti migliori — che di solito sono anche i più insofferenti all’autoritarismo gratuito.

La collaborazione — lavorare insieme per trovare una soluzione che soddisfi entrambe le parti — è l’approccio ideale quando il problema è complesso, quando entrambe le parti hanno informazioni rilevanti, e quando la relazione a lungo termine vale l’investimento di tempo. Non è però l’approccio giusto per ogni conflitto: applicare la collaborazione a un disaccordo su un dettaglio operativo minore significa sprecare energia che potrebbe andare su decisioni che contano davvero.

Il compromesso è spesso sopravvalutato come soluzione di default. “Troviamo un punto di incontro” suona ragionevole, ma spesso produce soluzioni che non soddisfano nessuno davvero — e che rimandano il problema invece di risolverlo. È utile come meccanismo temporaneo quando le parti hanno pari potere e la posta in gioco è media. Non è utile quando si tratta di scelte architetturali, di budget, o di obiettivi di progetto: lì il compromesso produce mediocrità.

L’accomodamento — cedere per mantenere la relazione — ha senso quando l’altra parte ha più esperienza su quel dominio specifico, o quando il tema non è prioritario e la relazione lo è. Usarlo per evitare il disagio del confronto, però, è un errore che si paga caro nel tempo: accumula risentimento, comunica debolezza, e premia i comportamenti più aggressivi.

L’evitamento, infine, è lo stile più usato e meno efficace. Ha una sua razionalità in casi specifici — quando le emozioni sono troppo alte per un confronto produttivo, o quando il problema potrebbe risolversi da solo — ma nella maggior parte dei casi è semplicemente procrastinazione vestita da diplomazia.

 

Come un Project Manager gestisce il conflitto nei progetti: strumenti pratici

Nominarlo prima che esploda

La prima competenza del Project Manager nella gestione del conflitto nei progetti non è risolvere il conflitto. È riconoscerlo prima che diventi una crisi. Questo richiede una cosa sola: attenzione alle persone. Non alle slide di stato avanzamento, non alle metriche di burndown. Alle persone. Un cambio di tono in una email. Un silenzio insolito in una riunione. Una risposta sbrigativa da qualcuno che di solito è preciso. Questi sono i segnali precoci del conflitto che si sta formando sotto la superficie. Un Project Manager che li coglie e li nomina — “ho notato che c’è tensione su questo punto, ne parliamo?” — interrompe il ciclo prima che si consolidi in qualcosa di molto più costoso da gestire.

La capacità di nominare il conflitto richiede coraggio, ma anche un’abilità comunicativa specifica: quella di separare il comportamento dall’identità della persona. Non “sei sempre in ritardo con questo”, ma “noto che nelle ultime tre settimane le consegne sono arrivate in ritardo — cosa sta succedendo?”. La differenza non è solo di tono: è di efficacia. La prima formulazione genera difensività e chiude la conversazione. La seconda apre uno spazio in cui il problema può essere esplorato.

La conversazione diretta come strumento primario

Quando il conflitto tra due persone del team è già esplicito, la risposta più frequente dei manager è convocare un incontro a tre e fare da moderatori. È spesso la risposta sbagliata. Prima di portare la questione in un contesto formale, il PM dovrebbe avere conversazioni individuali con ciascuna delle parti — non per raccogliere “prove”, ma per capire quale è la percezione di ciascuno, quale è il bisogno sottostante che non viene detto esplicitamente, e quale è la storia che ciascuno si racconta su quello che è successo.

Solo dopo queste conversazioni ha senso portare le parti allo stesso tavolo. E anche lì, il ruolo del PM non è giudicare chi ha ragione. È facilitare la comprensione reciproca e guidare verso un accordo su come procedere. Sun Tzu scriveva che il generale più abile non è quello che vince ogni battaglia, ma quello che ottiene il risultato senza combattere. Nel conflitto di progetto, la vittoria non è “chi ha ragione”. La vittoria è un team che torna a funzionare.

Distinguere il problema percepito da quello reale

Quasi sempre, nei conflitti di progetto, ciò di cui le persone litigano esplicitamente non è la causa reale del conflitto. Il frontender e il backender discutono animatamente di quale sia la specifica corretta per un’API. In realtà, il frontender si sente scavalcato nelle decisioni architetturali da settimane. Due stakeholder si scontrano su una funzionalità del prodotto. In realtà, uno dei due non si è mai sentito ascoltato nelle fasi di discovery. Capire questo livello — quello dei bisogni non detti — è il lavoro più importante che un PM può fare in una situazione conflittuale, ed è quello che separa un manager ordinario da uno che lascia traccia nelle organizzazioni in cui lavora.

Questa è la dimensione psicologica del management che troppo spesso viene delegata alle HR o ignorata del tutto. Le emozioni non sono rumore nel sistema. Sono informazioni. Un team che litiga su questioni tecniche di superficie sta comunicando qualcosa di molto più importante sullo stato della sua salute organizzativa.

 

Conflitto e cultura del team: la prevenzione sistemica

Costruire un ambiente in cui il disaccordo sia sicuro

Il modo migliore per gestire conflitto nei progetti è non arrivare al punto in cui è disfunzionale. Questo si ottiene costruendo, fin dall’inizio del progetto, una cultura esplicita del disaccordo produttivo. Non basta dirlo in un kick-off meeting. Bisogna modellarlo con il proprio comportamento: fare domande invece di dare risposte, accogliere le obiezioni invece di difendersi, riconoscere pubblicamente quando si è sbagliato. Il team si calibra sul comportamento del suo leader molto più che sulle sue dichiarazioni di intenti.

Un framework operativo che funziona in questo senso è quello delle norme esplicite del team — un documento semplice, scritto insieme all’inizio del progetto, che definisce come ci si aspetta che il team gestisca i disaccordi, come si prendono le decisioni, cosa succede quando una scadenza è a rischio. Non è un documento giuridico: è un contratto sociale. La sua funzione non è prescrittiva ma conversazionale — serve a creare uno spazio in cui nominare i problemi è normale, non eccezionale.

Il ruolo dello steering committee nella prevenzione del conflitto nei progetti

A livello di governance di progetto, una delle cause più sottovalutate di conflitto nei progetti è l’assenza di un meccanismo di escalation chiaro e funzionante. Quando un PM non sa a chi rivolgersi per risolvere un impasse decisionale, o quando le escalation vengono percepite come segnali di debolezza invece che come strumenti di governance, i problemi restano irrisolti a livello operativo fino a quando non esplodono. Uno steering committee che si riunisce regolarmente, che ha mandato reale sulle decisioni, e che tratta le escalation come feedback utili sul progetto — non come problemi del PM — è uno degli investimenti più redditizi che un’organizzazione possa fare nella salute dei suoi progetti.

Secondo una ricerca di Gartner sul portfolio management nelle grandi organizzazioni, i progetti con una governance attiva dello steering committee hanno una probabilità del 35% più alta di concludersi entro budget e nei tempi previsti. La governance non è burocrazia: è il sistema immunitario del progetto.

Errori classici nella gestione del conflitto nei progetti nei team 

Aspettare che si risolva da solo

È l’errore più comune e più costoso nel conflitto nei progetti. Il conflitto non gestito non si risolve: si sedimenta. Ogni settimana che passa senza un intervento esplicito, la distanza tra le parti aumenta, le posizioni si irrigidiscono, e il costo dell’intervento cresce. Un PM che adotta una posizione di “lascio che le cose si sistemino” non sta praticando la saggezza del non intervento. Sta evitando il disagio del confronto diretto a spese del team e del progetto.

Schierarsi

Il PM che prende esplicitamente le parti di uno dei contendenti in un conflitto di team perde immediatamente la capacità di agire da facilitatore neutrale — che è l’unico ruolo che gli consente di essere efficace. Questo non significa essere neutrali su tutto: ci sono situazioni in cui il PM deve prendere una posizione netta, soprattutto quando il conflitto riguarda comportamenti che violano gli accordi del team o i valori dell’organizzazione. Ma in un conflitto interpersonale su contenuti e priorità, schierarsi è quasi sempre controproducente.

Confondere il sintomo con la causa

Intervenire sul conflitto visible senza capire cosa lo genera a monte è come prendere antidolorifici per un’appendicite. La riunione di chiarimento, l’accordo di facciata, il “da oggi ci rispettiamo tutti” — queste sono soluzioni cosmetiche. La gestione del conflitto nei team di progetto che funziona davvero è quella che va a rimuovere le condizioni che lo generano: ambiguità di ruolo, priorità non allineate, processi che mettono le persone in competizione invece di collaborazione.

 

Conclusione: il conflitto come specchio dell’organizzazione

Il conflitto nel team di progetto non è un problema di persone difficili. È un problema di sistemi che producono le condizioni per il conflitto e di manager che non hanno gli strumenti — o il coraggio — per intervenire prima che diventi una crisi. Ogni conflitto irrisolto è una radiografia dell’organizzazione: mostra dove ci sono ambiguità, dove mancano processi, dove la comunicazione si è interrotta, dove le aspettative non sono mai state rese esplicite.

Un Project Manager che sa leggere quei segnali e intervenire con metodo — non con la speranza che le cose si sistemino, non con l’autoritarismo di chi vuole imporre la propria volontà, ma con la competenza di chi capisce le persone e sa guidarle verso un risultato condiviso — è quello che le organizzazioni cercano davvero. Non il PM che sa fare i Gantt. Quello che sa fare le conversazioni difficili.

Il conflitto non si elimina. Si governa. E governarlo bene è uno dei lavori più importanti che un manager possa fare.