PMI PMP: Leadership del team e gestione delle risorse — Guida allo studio

By Laurynas Brazys · 21 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Fa parte della PMP — Guida allo studio. Esercitati con risposte verificate nel centro esami PMI, oppure fai test cronometrati su ExamRoll.io.

Formazione del Team, Carta e Chiarezza dei Ruoli

Ogni team ad alte prestazioni inizia con un rituale di formazione deliberato, non con la prima riunione di stato di avanzamento. La carta del team è l’artefatto fondante: un documento creato congiuntamente che racchiude i valori condivisi del team, le regole decisionali, gli orari di lavoro nei vari fusi orari, la cadenza della comunicazione e i percorsi di escalation. A differenza della carta del progetto (che autorizza il progetto e nomina lo sponsor), la carta del team è redatta dal team, per il team. La sua forza risiede in questa co-autorialità: quando in seguito uno sviluppatore interrompe un collega o salta uno stand-up, il project manager non invoca la propria autorità personale, ma indica una norma che il team stesso ha stabilito.

Accanto alla carta, le regole di base rendono operativa la disciplina quotidiana: webcam accese per le revisioni del design, niente multitasking durante le retrospettive, una regola di due minuti per gli aggiornamenti verbali, decisioni documentate entro 24 ore. Le regole di base dovrebbero essere visibili (affisse nella stanza del team o fissate nel canale di collaborazione) e riesaminate all’inizio di ogni iterazione o phase gate. Una carta che risiede in una cartella di SharePoint che nessuno apre è decorativa; una carta a cui si fa riferimento settimanalmente è normativa.

La chiarezza dei ruoli chiude il triangolo della formazione. Una matrice RACI (o la sua variante RASCI) che mappa i deliverable alle parti responsabili, accountable, consultate e informate elimina la modalità di fallimento del “pensavo te ne occupassi tu”. In un nuovo team in cui un project manager eredita un gruppo che è andato alla deriva per settimane senza una guida, la prima mossa corretta non è né una ripianificazione aggressiva né un’immediata rinegoziazione della timeline con lo sponsor. È invece convocare il team, ascoltare ciò che percepiscono come bloccante e ricostruire la carta e la mappa dei ruoli. Il team si sente perso proprio perché mancano questi punti di ancoraggio.

Adattare lo Stile di Leadership alla Maturità

La leadership situazionale tratta lo stile di leadership come una variabile, non come un tratto della personalità. La classica progressione di Hersey-Blanchard mappa lo stile alla prontezza dei collaboratori:

• Bassa competenza, alto impegno (nuovo)
  • Stile raccomandato: Direttivo
  • Comportamento: Dire cosa, quando, come
• Certa competenza, impegno variabile
  • Stile raccomandato: Coaching
  • Comportamento: Spiegare, “vendere” le decisioni, invitare al dialogo
• Alta competenza, impegno variabile
  • Stile raccomandato: Di supporto
  • Comportamento: Facilitare, condividere il processo decisionale
• Alta competenza, alto impegno
  • Stile raccomandato: Delegante
  • Comportamento: Trasferire la responsabilità

Una postura di leadership di servizio — rimuovere gli impedimenti, proteggere il team dal “rumore”, dare priorità alla loro crescita — si sovrappone a questo modello ma non sostituisce il giudizio situazionale. Leadership di servizio non significa leadership permissiva. Quando un team va alla deriva, il servant leader dirige comunque; lo fa semplicemente al servizio del successo del team piuttosto che della propria visibilità.

La trappola della leadership laissez-faire in un team senza direzione è un fallimento comune. Farsi da parte “per lasciare che il team si auto-organizzi” quando il team non ha un modello di lavoro condiviso produce confusione, mancate dipendenze e demoralizzazione. L’auto-organizzazione è un risultato della maturità, non una condizione di partenza. Al contrario, fare micromanagement su ingegneri senior che hanno già consegnato lavori simili cinque volte segnala sfiducia, sopprime l’iniziativa e aumenta il tasso di abbandono. Il segnale rivelatore è quando il project manager esamina i dettagli a livello di commit del lavoro di un esperto di dominio, ignorando al contempo le conversazioni sul rischio a livello di portfolio.

Quando ci si unisce a un team con seniority mista, la mossa iniziale è un ciclo di incontri individuali combinato con un workshop per definire gli accordi di lavoro. Questo fa emergere dove si colloca ogni individuo nello spettro di prontezza, permettendo di calibrare lo stile persona per persona anziché applicarlo in modo uniforme.

Coaching, Incontri Individuali e Gestione delle Performance

Gli incontri individuali ricorrenti — tipicamente 30 minuti ogni due settimane — sono il canale principale per il coaching, l’individuazione precoce dei problemi e lo sviluppo di carriera. Non sono riunioni di stato di avanzamento. L’ordine del giorno dovrebbe essere gestito dal membro del team, con il project manager che ascolta per il 70% del tempo. Gli argomenti ruotano tra blocchi attuali, crescita delle competenze, feedback in entrambe le direzioni e morale.

I problemi di performance devono essere sollevati alla prima osservazione, non accumulati per un ciclo di revisione formale. Ritardare le conversazioni difficili è uno dei modelli più dannosi nella leadership di progetto: chi ha basse performance non impara nulla finché non è troppo tardi per correggersi, i collaboratori ad alte prestazioni osservano e si disimpegnano, e il morale si erode silenziosamente. Il feedback dovrebbe fare riferimento a indicatori misurabili — tasso di difetti sfuggiti, cycle time delle story, tempo di completamento della code review, partecipazione alle riunioni, affidabilità degli impegni presi — piuttosto che a impressioni soggettive (“sembri poco coinvolto”). Gli indicatori misurabili ancorano la conversazione a comportamenti osservabili e forniscono al membro del team un obiettivo concreto.

L’escalation ai manager funzionali, o in ultima istanza la richiesta di sostituzione della risorsa, è giustificata solo dopo che il coaching, la chiara definizione delle aspettative e un colloquio documentato per il miglioramento delle performance non hanno avuto successo. Saltare questi passaggi danneggia la fiducia e spesso viola le policy delle risorse umane.

Risoluzione dei Conflitti e Team-Building

Il conflitto interpersonale, se non viene affrontato, si aggrava. Quando un membro del team viene isolato dai colleghi in un progetto di breve durata, la risposta del project manager non è né attendere che la situazione si risolva da sola (il progetto termina prima che la dinamica si risolva) né affrontare pubblicamente il gruppo (il che umilia e irrigidisce le posizioni). L’approccio corretto combina tre azioni: avere una conversazione privata con la persona interessata per comprendere la sua esperienza, parlare individualmente con i colleghi che manifestano il comportamento di esclusione per descrivere il modello osservato e il suo impatto, e rafforzare le norme di inclusione attraverso il team charter e un’attività di team-building facilitata. La documentazione dell’intervento è essenziale nel caso in cui si renda necessaria un’escalation alle Risorse Umane (HR).

I cinque stili di gestione dei conflitti di Thomas-Kilmann — collaborazione, compromesso, accomodamento, imposizione, elusione — guidano la scelta. La collaborazione (risoluzione dei problemi per trovare una soluzione vantaggiosa per tutti) è generalmente preferita per le dispute interpersonali e tecniche in un team stabile, mentre l’imposizione può essere giustificata solo per decisioni relative alla sicurezza, all’etica o a scadenze inderogabili.

Allocazione delle Risorse, Livellamento e Pianificazione della Capacità

La gestione delle risorse è tanto una negoziazione quanto un calcolo aritmetico. Il resource leveling (livellamento delle risorse) appiattisce la sovra-allocazione estendendo la pianificazione; il resource smoothing (regolarizzazione delle risorse) mantiene fissa la data di fine e opera all’interno del “float” (margine di flessibilità). Scegliere il livellamento quando uno specialista critico è sovra-impegnato e la qualità ne risentirebbe; scegliere la regolarizzazione quando la data di fine è contrattuale.

Quando un manager funzionale riassegna un architect condiviso a metà sprint, il project manager negozia usando i dati: impegni attuali, impatto sul percorso critico (critical path) e costo del ritardo a valle (cost of delay). L’escalation allo sponsor o al comitato direttivo (steering committee) è appropriata solo dopo che un tentativo di negoziazione diretta è stato effettuato e documentato. Portare lamentele grezze ai livelli superiori senza prima tentare una risoluzione brucia capitale politico.

Trasferimento delle Conoscenze e Cross-Training

Le dipendenze da un singolo punto (single-point dependencies) sono tra i rischi di progetto più prevedibili e più frequentemente ignorati. Quando una persona è l’unica responsabile di un sottosistema e viene ricoverata in ospedale per due mesi, il fallimento non è l’incidente, ma l’assenza di una mitigazione preventiva. Le pratiche preventive includono il pair programming o il pair mentoring, la rotazione delle responsabilità di reperibilità (on-call), la documentazione obbligatoria delle conoscenze “tribali” (tribal knowledge) in runbook, sessioni registrate di trasferimento delle conoscenze e rotazioni di cross-training in cui un responsabile secondario affianca (“shadowing”) e poi esegue i compiti dello specialista. I piani di onboarding per i nuovi assunti dovrebbero assegnare esplicitamente un “buddy” (collega di supporto) e una mappa delle competenze a 30-60-90 giorni.

La pianificazione della successione a livello di team identifica chi potrebbe assumere ogni ruolo critico e quali lacune nelle competenze deve colmare. Questo viene registrato in una matrice delle competenze (skills matrix) revisionata trimestralmente.

Facilitazione delle Riunioni e Riconoscimento

Le riunioni consumano la fetta più visibile della capacità del team. La disciplina richiede uno scopo dichiarato, un ordine del giorno con tempi definiti (timeboxed) distribuito in anticipo, i partecipanti giusti (non il numero massimo), decisioni esplicite e action item registrati con responsabili e date, e un “parking lot” funzionante per le discussioni fuori tema. Le riunioni periodiche (standing meetings) che non portano a decisioni dovrebbero essere cancellate.

Infine, il riconoscimento — tempestivo, specifico e pubblico per le vittorie del team; privato per il coaching individuale — non è una gentilezza di poco conto (“soft nicety”). Le ricompense allineate ai valori del charter rafforzano i comportamenti che le hanno prodotte. Un rapido “shout-out” (menzione di merito) durante una review, uno “spot bonus” coordinato con il manager funzionale, o una nota scritta al manager diretto di una persona costano poco e hanno un effetto cumulativo significativo sul morale e sulla retention.

Problema pratico: scenario d’uso

Scenario: A Priya Kapoor è stato appena assegnato il ruolo di responsabile del progetto di modernizzazione dei pagamenti “Meridian” presso una banca regionale di medie dimensioni, con un budget di 4,2 milioni di dollari e una tempistica di 14 mesi. Il team di 11 persone si estende su tre fusi orari: cinque sviluppatori a Bangalore, tre business analyst a Londra e un responsabile QA, un architetto e Priya stessa a Toronto. Due settimane dopo l’inizio del progetto, gli sviluppatori di Bangalore hanno creato un prototipo che i BA di Londra hanno respinto perché non allineato ai requisiti di conformità che “davano per scontato che tutti avessero letto”, e l’architetto di Toronto sostiene di non essere mai stato consultato sulla decisione relativa allo stack tecnologico.

Sfida: Priya deve reimpostare le norme operative e la chiarezza dei ruoli del team prima che il progetto subisca ulteriori ritardi, senza dare l’impressione di incolpare un singolo gruppo per l’errore di comunicazione.

Approccio consigliato:

1. Sospendere lo sviluppo attivo per un workshop virtuale di due giorni sulla formazione del team, programmando ore di sovrapposizione (7:00–10:00 Toronto / 12:00–15:00 Londra / 16:30–19:30 Bangalore) in modo che tutti gli 11 membri possano creare insieme gli artefatti in tempo reale.
2. Facilitare la co-creazione di una team charter (carta del team) che copra la sovrapposizione dell’orario di lavoro condiviso, i diritti decisionali, la definizione di “consultato” rispetto a “informato”, una regola di 24 ore per la gestione delle decisioni asincrone e un percorso di escalation che termina con lo sponsor.
3. Costruire una matrice RASCI rispetto ai 18 deliverable principali della WBS, analizzando ogni riga con il team in modo che “Accountable” (Responsabile) sia sempre una singola persona nominata e “Consulted” (Consultato) nomini esplicitamente l’architetto per qualsiasi decisione sullo stack tecnologico.
4. Stabilire regole di base — videocamere accese durante le revisioni del design, decisioni registrate su Confluence entro un giorno lavorativo, un meeting di sincronizzazione settimanale di 30 minuti tra i vari fusi orari nella finestra di sovrapposizione — e fissarle nel canale Slack del team.
5. Rielaborare lo scopo del prototipo insieme ai BA e agli sviluppatori, utilizzando la matrice RASCI appena chiarita per identificare chi deve dare l’approvazione prima che il codice venga scritto.
6. Aggiungere un “controllo della charter” fisso di 10 minuti alla prima retrospettiva di ogni iterazione per rivedere le norme man mano che il team matura.

Perché funziona: La co-creazione trasforma la charter da un’imposizione a un impegno reciproco tra pari, il che conferisce al PM la legittimità per far rispettare le norme senza invocare l’autorità gerarchica. La matrice RASCI elimina il problema del “pensavo te ne occupassi tu” che ha causato la mancanza di conformità, e rivedere le norme a ogni iterazione impedisce che la charter diventi un artefatto decorativo anziché un accordo vivo e funzionale.

← Coinvolgimento degli stakeholder e comunicazione · Tutti i domini · Agile →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →