Cos’è un project manager e cosa fa concretamente in azienda
Il project manager è la figura professionale che supervisiona un team incaricato di portare a termine un singolo progetto, ed è responsabile della sua esecuzione dall’inizio alla fine (fonte: atlassian.com). Non è un ruolo di rappresentanza. È il punto di convergenza tra obiettivi, risorse, tempo e persone: quando qualcosa va storto, il project manager risponde.
In azienda questo si traduce in attività concrete e quotidiane. Il project manager definisce il perimetro del progetto, assegna i compiti al team, monitora l’avanzamento rispetto al piano, gestisce i rischi prima che diventino problemi e comunica lo stato dei lavori agli stakeholder. Tutto insieme, spesso nello stesso giorno.
Pianificazione, esecuzione, controllo. Poi si ricomincia.
Tra i candidati che ho seguito nel percorso verso la certificazione PMP, molti arrivavano con anni di esperienza operativa ma faticavano a descrivere con precisione cosa facessero davvero. Gestivano progetti, certo. Ma non avevano mai messo a fuoco la struttura del ruolo. Ed è esattamente questo il problema: fare il project manager senza sapere cosa sia un project manager porta a lacune che si pagano, prima o poi.
Definizione del ruolo secondo le fonti ufficiali
Atlassian, in una delle guide di riferimento più citate sul tema, definisce il project manager come il responsabile di un singolo progetto dall’inizio alla fine. La parola chiave è “singolo”: il ruolo ha un confine preciso, che è anche il suo punto di forza. Chi fa il project manager si occupa di un progetto alla volta, con obiettivi specifici, risorse definite e una data di consegna.
Il PMI, l’ente che rilascia la certificazione PMP, aggiunge una dimensione importante: il project manager non è solo un coordinatore operativo, ma un professionista che esercita competenze tecniche, di leadership e di gestione strategica e di business. In soldoni, non basta saper usare un diagramma di Gantt. Serve saper leggere le dinamiche del team, negoziare con gli sponsor, prendere decisioni sotto pressione.
Ma c’è di più. Il ruolo del project manager cambia forma a seconda del contesto metodologico in cui opera. In un progetto waterfall, il project manager pianifica tutto in anticipo e gestisce le variazioni rispetto al piano. In un contesto Agile, il ruolo si trasforma: la pianificazione è iterativa, il team è auto-organizzato, e il project manager si concentra sulla rimozione degli ostacoli e sulla facilitazione. In un approccio ibrido, che oggi è il più diffuso nelle medie e grandi aziende italiane, convivono entrambe le logiche. E il project manager deve sapersi muovere tra le due senza perdere il filo.
La differenza tra project manager e program manager
La distinzione è meno ovvia di quanto sembri, e vale la pena chiarirla subito.
Secondo Atlassian, il project management riguarda un singolo progetto. Il program management riguarda invece un portafoglio di progetti correlati, gestiti in modo coordinato per ottenere benefici che i singoli progetti, da soli, non potrebbero produrre. Il program manager non segue l’esecuzione quotidiana di ogni progetto: supervisiona le interdipendenze, gestisce le priorità tra progetti diversi e risponde dei risultati complessivi del programma.
A mio avviso, questa differenza è spesso sottovalutata nelle offerte di lavoro italiane, dove i due ruoli vengono mescolati con disinvoltura. Ho visto annunci che cercavano “program manager” per gestire un singolo progetto da tre mesi. E viceversa: project manager a cui veniva chiesto di coordinare cinque iniziative parallele senza né il titolo né la retribuzione corrispondente.
In pratica, la distinzione funziona così:
- Il project manager guida un team verso un obiettivo specifico, con inizio e fine definiti.
- Il program manager coordina più project manager e più progetti correlati, ottimizzando le risorse condivise e garantendo la coerenza strategica tra le iniziative.
Quindi, se stai valutando una carriera nella gestione dei progetti, capire dove ti collochi tra queste due figure non è un dettaglio accademico. È la base per scegliere il percorso formativo giusto, negoziare il ruolo corretto e costruire una progressione professionale che abbia senso.
Perché oggi il ruolo del project manager è sotto pressione
La pressione sul project manager nasce da una tensione precisa: i progetti devono consegnare valore frequente, ma i requisiti cambiano in corso d’opera. Non è una novità degli ultimi mesi. È una tensione strutturale che si è cristallizzata nel tempo, e che oggi si manifesta in modo molto concreto su chi coordina team, stakeholder e deliverable ogni giorno.
Progetti più brevi, requisiti che cambiano
Il Manifesto Agile lo dice esplicitamente dal 2001: i cambiamenti di requisiti sono benvenuti anche nelle fasi avanzate dello sviluppo. Non nelle prime settimane, quando è ancora tutto abbozzato. Anche quando il progetto è già in corsa.
Per un project manager abituato a lavorare su piani costruiti con mesi di anticipo, questo principio è destabilizzante. Il piano tradizionale presuppone che i requisiti siano stabili abbastanza a lungo da poter essere pianificati, stimati, assegnati. Ma se il cliente può cambiare idea a metà sviluppo, e il processo non solo lo tollera ma lo incoraggia, allora il valore del piano decade velocemente. E con lui parte del ruolo classico di chi quel piano lo costruisce e lo presidia.
In soldoni: il project manager non può più fare affidamento sulla stabilità come condizione di lavoro. Deve imparare a gestire l’incertezza come stato normale, non come eccezione da correggere.
L’impatto dei framework Agile sul ruolo tradizionale
Scrum è oggi uno dei framework più adottati nei team di sviluppo software, e porta con sé una conseguenza radicale per chi si chiede cosa fa un project manager in questo contesto. La risposta, nella Scrum Guide, è scomoda: il ruolo formale di Project Manager non esiste. Lo Scrum Team si compone di tre figure: Product Owner, Scrum Master e Developers. Punto.
Lo Scrum Master rimuove impedimenti, serve il team, aiuta a comprendere teoria e pratica del framework. È un leader al servizio, non un controllore di task e milestone. Nei miei anni a lavorare con team in transizione Agile ho visto project manager bravissimi ritrovarsi disorientati non perché fossero incompetenti, ma perché il framework non aveva un cassetto in cui metterli. Quella sensazione di “dove sto io in tutto questo?” è più diffusa di quanto si ammetta nelle aule di formazione.
E poi c’è il tema della comunicazione. Il Manifesto Agile indica la conversazione faccia a faccia come il metodo più efficace per trasmettere informazioni all’interno di un team. Ma i team oggi sono spesso distribuiti su più città, a volte su più fusi orari. La conversazione faccia a faccia diventa una videochiamata, poi una serie di messaggi asincroni, poi un documento condiviso che nessuno legge con la stessa attenzione.
Il project manager si trova a dover tenere insieme persone che non si incontrano mai fisicamente, coordinare feedback rapidi al termine di ogni iterazione, garantire che la collaborazione quotidiana tra chi sviluppa e chi commissiona sia reale e non solo dichiarata. È un lavoro di facilitazione continua, non di controllo. Ma molti professionisti non sono stati formati per questo tipo di ruolo, e la distanza tra le competenze che hanno e quelle che servono cresce ogni anno.
Quindi la pressione non è passeggera. È strutturale, ed è fatta di tre cose insieme: requisiti instabili per definizione, framework che ridisegnano le responsabilità, team che lavorano a distanza. Chi vuole restare rilevante deve capire come il proprio ruolo si ridefinisce in questo contesto, e dotarsi degli strumenti per farlo.
Quali sono le 7 responsabilità quotidiane di un project manager?
Le responsabilità del project manager si articolano in sette aree operative che ricorrono in qualsiasi metodologia, da waterfall ad Agile. Non sono astrazioni da manuale: sono attività concrete che si ripetono ogni giorno, a volte in parallelo, spesso sotto pressione. Nei miei anni di formazione su questi temi ho visto candidati PMP sorprendersi di quanto il ruolo sia più operativo di quanto immaginassero leggendo solo la teoria.
Le sette aree sono: definire obiettivi e scope, pianificare milestone e criteri di accettazione, allocare le risorse, gestire il team, rimuovere gli impedimenti, monitorare costi e tempi, comunicare lo stato del progetto. Alcune si concentrano nelle fasi iniziali. Altre non finiscono mai.
Pianificazione e definizione dello scope
Tutto parte qui. Il project manager definisce cosa il progetto deve produrre, entro quali confini e con quali criteri si stabilisce che il lavoro è finito. Senza scope chiaro, ogni decisione successiva diventa negoziazione aperta.
In concreto si tratta di costruire la WBS (Work Breakdown Structure), fissare le milestone principali e concordare con il cliente i criteri di accettazione del deliverable finale. Questi criteri non sono dettagli: sono il metro con cui sponsor e stakeholder giudicano il successo del progetto, e quindi il metro con cui giudicano il project manager. Un criterio vago (“il sistema deve essere veloce”) genera contestazioni. Un criterio misurabile (“il sistema deve rispondere entro 2 secondi per il 95% delle richieste”) chiude le discussioni.
Anche in Agile questa responsabilità esiste, cambia solo la forma. Il Manifesto Agile afferma esplicitamente che i cambiamenti di requisiti sono benvenuti anche nelle fasi avanzate dello sviluppo. Il project manager non definisce tutto a monte, ma deve comunque tenere chiaro il perimetro di ogni iterazione.
Gestione del team e degli stakeholder
Il project manager non esegue il lavoro tecnico. Fa sì che chi lo esegue abbia le condizioni per farlo bene.
In pratica questo significa allocare le persone giuste alle attività giuste, risolvere i conflitti interni prima che blocchino il progresso, e costruire con gli stakeholder una relazione basata su aspettative realistiche. La Scrum Guide descrive questa funzione in modo preciso quando parla dello Scrum Master: il suo compito è rimuovere gli impedimenti al progresso del team. Il principio vale anche fuori da Scrum. Un team bloccato su un’approvazione, su un accesso a sistema o su un conflitto di priorità tra reparti non avanza, indipendentemente dalla metodologia usata.
E poi c’è la gestione degli stakeholder, che è un lavoro a sé. Sponsor, clienti, responsabili di funzione, utenti finali: ognuno ha aspettative diverse e spesso non allineate. Il project manager deve capire chi decide, chi influenza e chi può bloccare. Tutto sommato, questa è la parte del ruolo che richiede più intelligenza politica.
Il Manifesto Agile valorizza la collaborazione quotidiana tra business e sviluppatori durante tutto il progetto, non solo nelle fasi di avvio e chiusura. Ma quella collaborazione non avviene da sola: qualcuno deve creare le condizioni, facilitare gli incontri, gestire le frizioni. Quel qualcuno è il project manager.
Controllo di tempi, costi e rischi
Monitorare non è guardare. È misurare, interpretare e intervenire.
Il project manager confronta con cadenza regolare l’avanzamento reale del progetto con il piano di riferimento: tempi previsti contro tempi effettivi, budget consumato contro budget pianificato, qualità dei deliverable contro i criteri stabiliti. Quando si individua uno scostamento, il lavoro è capire se è recuperabile, a quale costo e con quali implicazioni sulle altre variabili.
I rischi meritano un discorso separato. Un project manager efficace non aspetta che i problemi emergano: identifica in anticipo gli eventi che potrebbero impattare il progetto, li valuta per probabilità e impatto, e prepara una risposta. Questo non è pessimismo, è metodo. Anzi, è proprio la differenza tra chi gestisce un progetto e chi subisce gli eventi.
In contesti Agile il controllo assume forme diverse, come i burndown chart e le retrospective, ma la sostanza non cambia: il project manager deve sapere in ogni momento se il progetto sta andando nella direzione giusta.
Comunicazione e reporting
La comunicazione è l’ultima area, ma non la meno importante. Personalmente la considero quella più sottovalutata dai project manager in fase di formazione.
Il project manager comunica verso l’alto (sponsor, clienti, direzione), verso il basso (team operativo) e lateralmente (altri reparti, fornitori, partner). Ogni livello richiede un registro diverso, una frequenza diversa e un livello di dettaglio diverso. Uno status report per il board esecutivo non ha la stessa struttura di un aggiornamento al team di sviluppo.
Il Manifesto Agile è netto su questo: il metodo più efficace per trasmettere informazioni all’interno di un team è la conversazione faccia a faccia. Ma anche il reporting formale ha un ruolo preciso. Non si tratta di scegliere tra i due: si tratta di usare lo strumento giusto nel contesto giusto.
Ma alla fine della fiera, il vero obiettivo della comunicazione è uno solo: che le persone che devono prendere decisioni abbiano le informazioni giuste, nel momento giusto, nella forma giusta. Tutto il resto è ornamento.
Quali competenze tecniche e trasversali servono davvero?
Le competenze di un project manager si dividono in due famiglie: hard skill tecniche e soft skill relazionali, entrambe richieste nei ruoli senior. Non basta saper costruire un piano di progetto in Microsoft Project se poi non si riesce a tenere insieme un team sotto pressione. E non basta essere bravi a motivare le persone se i costi vanno fuori controllo alla terza settimana.
Hard skill: pianificazione, budgeting, risk management
Le competenze tecniche di un project manager ruotano attorno a tre aree principali. Pianificazione, controllo economico e gestione dei rischi. In termini pratici, questo vuol dire saper costruire una WBS (Work Breakdown Structure) che scomponga il progetto in attività misurabili, schedulare con metodi come il Critical Path o le tecniche Agile, e impostare un budget con baseline chiare da cui misurare gli scostamenti.
Il risk management è forse l’area più sottovalutata dai project manager alle prime armi. Nei miei anni di formazione PMP ho visto candidati solidissimi sulla schedulazione che si bloccavano non appena chiedevo: “Come gestiresti un rischio di secondo livello che si materializza a progetto avanzato?” La risposta richiede metodo, non improvvisazione: registro dei rischi, probabilità, impatto, piano di risposta. Tutto documentato prima che il rischio si verifichi.
Sul lato budgeting, un project manager che sa leggere un report di Earned Value Management (EVM) ha un vantaggio concreto: capisce in tempo reale se il progetto sta consumando più risorse del previsto e può intervenire prima che il problema diventi irreversibile.
Soft skill: leadership, negoziazione, comunicazione
Le soft skill pesano almeno quanto le tecniche. Anzi, nei ruoli senior spesso pesano di più.
Un project manager gestisce persone che non dipendono gerarchicamente da lui. Il team di sviluppo risponde al suo responsabile tecnico, il fornitore ha i suoi obiettivi commerciali, il cliente cambia idea ogni due sprint. In questo contesto, la leadership non è un titolo ma una pratica quotidiana: si tratta di creare condizioni in cui le persone vogliono collaborare, non solo di dare compiti e aspettare risultati. Secondo la Scrum Guide, anche lo Scrum Master opera come leader al servizio del team, non come gestore di risorse dall’alto.
La negoziazione è una competenza che si usa ogni giorno. Con gli stakeholder che vogliono più funzionalità a parità di tempo. Con i fornitori che chiedono varianti economiche. Con il management che spinge per anticipare la data di consegna. Chi non sa negoziare finisce per dire sempre sì, e a quel punto il progetto non è più gestibile.
La comunicazione, però, è il differenziatore che in pochi nominano esplicitamente. Il Manifesto Agile è diretto su questo punto: la conversazione faccia a faccia è il metodo più efficace di trasmissione di informazioni all’interno di un team. Non la mail. Non il documento di specifiche lungo trenta pagine. La conversazione diretta, in cui si capisce al volo se c’è un malinteso prima che quel malinteso costi una settimana di lavoro sbagliato.
I team Agile descritti da Smartsheet sono piccoli, auto-organizzati e interfunzionali: strutture in cui la comunicazione orizzontale non è un’opzione, è la norma. Un project manager che facilita queste conversazioni, che crea i contesti in cui le informazioni circolano senza filtri burocratici, produce risultati diversi da chi si limita ad aggiornare un Gantt. A conti fatti, è questa capacità a fare la differenza tra un PM operativo e un PM strategico.
Tutto sommato, le due famiglie di competenze non si escludono e non si sostituiscono. Ma se devo indicare dove investire per crescere davvero nel ruolo, personalmente punterei prima sulla comunicazione e sulla negoziazione, e solo dopo sullo strumento tecnico successivo. Gli strumenti si imparano. La capacità di leggere una stanza piena di stakeholder in conflitto, quella richiede pratica vera.
Project manager in contesti Agile: come cambia il ruolo?
In contesti Agile il project manager non scompare: il suo ruolo si trasforma in coordinatore di team auto-organizzati, con confini diversi rispetto al modello waterfall. Non è una perdita di potere. È una redistribuzione delle responsabilità, spesso più efficace di quanto si pensi.
Tra i candidati che ho seguito nel percorso verso la certificazione, la domanda che torna più spesso è questa: “Ma in Agile il project manager esiste ancora?” La risposta è sì, ma devi capire perché cambia forma prima di capire cosa fa davvero.
Project manager, Scrum Master e Product Owner: ruoli a confronto
La Scrum Guide definisce tre accountability all’interno dello Scrum Team: Product Owner, Scrum Master e Developers. Tre ruoli distinti, con responsabilità che non si sovrappongono per design. Il project manager tradizionale non rientra in nessuna di queste tre categorie. E questo crea confusione.
Il Product Owner decide cosa costruire e in quale ordine: gestisce il Product Backlog, stabilisce le priorità, risponde al business. Lo Scrum Master, invece, non gestisce il team nel senso classico del termine: secondo la Scrum Guide, serve il team rimuovendo gli impedimenti al progresso e aiutando il gruppo a comprendere la teoria e la pratica di Scrum. È un leader al servizio, non un supervisore gerarchico. I Developers, infine, si auto-organizzano per completare il lavoro ad ogni Sprint.
Quindi cosa fa il project manager in tutto questo? Dipende dall’organizzazione. In molte aziende assume responsabilità di coordinamento cross-team: gestisce dipendenze tra più squad Agile, tiene i rapporti con gli stakeholder, garantisce che i vari team non si blocchino a vicenda. È un ruolo di raccordo. Meno comando, più facilitazione.
A mio avviso, chi arriva da un contesto waterfall tende a sottovalutare quanto questa transizione sia concreta. Non basta cambiare terminologia. Cambia il modo in cui si esercita l’influenza sul progetto.
Approccio waterfall vs approccio iterativo
Nel modello waterfall il lavoro si pianifica tutto all’inizio e si esegue in sequenza: requisiti, progettazione, sviluppo, test, rilascio. Ogni fase chiusa prima di aprire la successiva. Il project manager coordina questa sequenza, controlla i milestone, gestisce il piano.
L’Agile Project Management, come descritto da Management Academy, è un approccio iterativo in cui il lavoro viene suddiviso in piccole parti completate una alla volta. Ogni iterazione produce qualcosa di funzionante e consegnabile. Poi si raccoglie feedback. Poi si riparte.
La differenza pratica è enorme. Nel waterfall un cambio di requisiti a metà progetto è un problema, spesso costoso. In Agile, il Manifesto Agile considera i cambiamenti di requisiti benvenuti anche nelle fasi avanzate dello sviluppo, perché il punto è consegnare valore al cliente, non rispettare un piano scritto mesi prima.
I team Agile sono descritti da Smartsheet come piccoli, auto-organizzati e interfunzionali. Il feedback rapido al termine di ogni iterazione supporta il miglioramento continuo. E qui sta il punto per il project manager: in waterfall pianifica e controlla. In Agile facilita, sblocca, coordina.
Però attenzione. Waterfall non è sbagliato in assoluto. Certi progetti, con requisiti stabili e vincoli normativi rigidi, si gestiscono meglio in modo sequenziale. Alla fine della fiera, il project manager efficace è quello che sa leggere il contesto e scegliere l’approccio giusto, non quello che applica sempre lo stesso schema.
In soldoni: Agile non elimina la figura del project manager, la ridisegna. E chi vuole lavorare su progetti complessi oggi non può ignorare questa trasformazione.
Quanto guadagna un project manager in Italia nel 2026?
Lo stipendio di un project manager in Italia nel 2026 dipende da tre variabili: seniority, settore e certificazioni in portafoglio. Non esiste una cifra unica. Un project manager junior in una PMI manifatturiera del Nord-Est guadagna qualcosa di molto diverso da un senior che gestisce programmi IT in una multinazionale milanese. Questo va detto subito, perché le medie aggregate ingannano.
Range salariali per livello di seniority
Secondo i dati di mercato elaborati da fonti come Adecco e 24 Ore Business School, la forbice retributiva in Italia si estende indicativamente da 28.000-35.000 euro lordi annui per un profilo junior fino a 65.000-80.000 euro per un senior con consolidata esperienza su progetti complessi. I profili mid-level si attestano in una fascia intermedia, intorno a 42.000-55.000 euro, con variazioni significative in base al settore.
IT, farmaceutico e infrastrutture sono storicamente i settori che pagano di più. La dimensione aziendale conta quanto il settore: le grandi aziende strutturate hanno griglie retributive più alte e budget di progetto più ampi, il che si traduce in responsabilità maggiori e compensi superiori. Nei miei anni di lavoro nel campo della formazione professionale ho visto molti project manager sottovalutare proprio questo aspetto, accettando ruoli in aziende piccole con la promessa di “più autonomia”, per poi scoprire che l’autonomia senza risorse ha un costo.
Ma non è solo una questione di azienda. Conta anche la geografia. Milano, Roma e le aree con forte concentrazione industriale nel Nord-Est garantiscono retribuzioni mediamente superiori del 15-20% rispetto al Centro-Sud, a parità di ruolo e seniority.
L’impatto delle certificazioni sullo stipendio
Le certificazioni non sono un optional. Sono, a conti fatti, uno dei pochi strumenti con cui un project manager può misurare e dimostrare il proprio valore in modo oggettivo.
La certificazione UNI 11648, standard italiano specifico per la figura del project manager, è un riferimento riconosciuto dal mercato nazionale e costituisce oggi il benchmark ufficiale per chi vuole posizionarsi con credibilità sul territorio italiano. Non è una certificazione accademica generica: attesta competenze precise, misurate su criteri definiti da UNI, l’ente di normazione italiano. Chi la ottiene segnala alle aziende una preparazione verificata da terzi, non autodichiarata.
La PMP (Project Management Professional) del PMI è invece lo standard internazionale più riconosciuto a livello globale. I dati PMI mostrano che i professionisti certificati PMP dichiarano stipendi mediani superiori del 16% rispetto ai colleghi non certificati, con variazioni in base al paese. In Italia questo differenziale esiste e si traduce spesso nell’accesso diretto a fasce retributive senior o nella possibilità di negoziare aumenti in sede di rinnovo contrattuale. Anche PRINCE2 mantiene un peso specifico, soprattutto nei contesti con legami al mercato anglosassone o nei progetti europei.
Personalmente ritengo che il ROI di una certificazione si misuri su due livelli distinti: il primo è l’aumento retributivo diretto, che può arrivare a coprire il costo del percorso formativo in 12-18 mesi. Il secondo, spesso sottovalutato, è l’accesso a ruoli che senza certificazione semplicemente non si aprono: program manager, portfolio manager, responsabile PMO. Ruoli dove la retribuzione supera stabilmente i 70.000 euro lordi annui.
Quindi, per andare al sodo: se sei un project manager senza certificazioni riconosciute e ti chiedi perché il tuo stipendio è bloccato, la risposta è probabilmente lì. Non nella congiuntura, non nel settore. Nel fatto che il mercato non ha ancora uno strumento per distinguerti dagli altri.
Studio autodidatta o percorso strutturato: cosa accelera davvero la carriera?
La scelta tra studio autodidatta e percorso strutturato non è una questione di budget: è una questione di tempo e credibilità sul mercato. Un project manager cosa fa, in concreto, dipende molto da come ha costruito le sue competenze. E il mercato, oggi, distingue bene chi ha una certificazione riconosciuta da chi ha semplicemente letto qualche manuale.
I limiti dell’autoformazione su PMBOK e Scrum Guide
Studiare da soli il PMBOK o la Scrum Guide è possibile. Gratuito, anche. Ma nei miei anni di formazione project management ho visto decine di candidati che arrivavano all’esame PMP convinti di essere pronti, e poi si bloccavano sul timing. Non sui contenuti: sul ritmo.
Il motivo è semplice. L’esame PMP consiste in 180 domande in 3 ore, un formato che richiede un allenamento specifico sul tempo di risposta, non solo sulla conoscenza teorica. Leggere il PMBOK non allena il timing. Non simula la pressione. Non riproduce la struttura delle domande situazionali che PMI usa per valutare il ragionamento, non la memoria.
E c’è un secondo problema. L’autoformazione richiede mediamente tra 6 e 12 mesi per arrivare a un livello sufficiente, senza nessuna garanzia di ottenere una credenziale riconosciuta a fine percorso. Si studia, si investe tempo, e poi si scopre che mancano le ore di formazione certificate richieste da PMI per fare domanda. O che il programma auto-costruito ha tralasciato proprio gli ambiti su cui l’esame pesa di più.
Tutto sommato, l’autodidattica ha senso per aggiornarsi, per curiosità professionale, per capire un framework che si usa già in azienda. Ma per costruire credenziali spendibili, è un percorso che rallenta invece di accelerare.
Cosa offre un percorso certificato Management Academy
Un percorso strutturato affronta esattamente le lacune che l’autoformazione lascia aperte. In soldoni: accorcia i tempi, fornisce le ore di formazione documentate che PMI richiede, e include simulazioni d’esame costruite sul formato reale.
I corsi Management Academy preparano alle principali certificazioni che un project manager può conseguire in Italia: la PMP, la UNI 11648 (norma italiana di riferimento per la qualificazione del project manager, riconosciuta a livello nazionale) e le certificazioni Agile. I docenti sono certificati e attivi sul campo. Non si tratta di formatori che spiegano il PMBOK pagina per pagina: lavorano su scenari reali, su casi in cui il project manager deve scegliere tra opzioni tutte plausibili, esattamente come accade in esame e, prima ancora, in progetto.
Ma la differenza più concreta, a mio avviso, è nelle simulazioni. Fare pratica su domande costruite con la stessa logica dell’esame ufficiale cambia completamente l’approccio. Si smette di cercare la risposta “giusta” in assoluto e si impara a ragionare secondo il framework PMI o Agile, che è esattamente ciò che la commissione valuta. Anzi, è l’unica cosa che valuta.
Un percorso certificato fornisce anche la struttura che l’autodidattica non dà: scadenze, feedback sui progressi, un programma calibrato sulla certificazione target. Per chi lavora già in azienda e ha poco tempo, questa struttura non è un lusso. È la condizione che rende il percorso sostenibile senza trascinarlo per un anno intero.
Chi vuole capire meglio come funziona il ruolo prima di scegliere quale certificazione prendere può partire dall’articolo su Agile project management nel nostro magazine, oppure approfondire direttamente l’offerta formativa di Management Academy per trovare il percorso allineato al proprio obiettivo professionale.
Domande frequenti su cosa fa un project manager
Le domande più frequenti su cosa fa un project manager riguardano routine quotidiana, formazione necessaria, differenze con altri ruoli e scelta della certificazione. Le risposte qui sotto sono pensate per essere dirette e utilizzabili subito, non per fare il giro del mondo.
Cosa fa esattamente un project manager in una giornata tipo?
Una giornata tipo non esiste davvero, e questo è uno dei motivi per cui il ruolo è difficile da spiegare a chi viene da fuori. Tra i professionisti che ho seguito nel tempo, la mattina inizia quasi sempre con una revisione dello stato avanzamento lavori: task completate, blocchi segnalati, scadenze che si avvicinano. Poi ci sono le riunioni con il team, i confronti con gli stakeholder, la gestione dei rischi che diventano problemi reali.
In soldoni: pianifica, coordina, monitora e comunica. Ogni giorno, su fronti diversi, spesso in parallelo. Il project manager non esegue il lavoro tecnico, ma è responsabile che il lavoro arrivi a destinazione nei tempi, nei costi e con la qualità attesa.
Serve una laurea per diventare project manager?
No. La laurea non è un requisito obbligatorio per lavorare come project manager, anche se può accelerare l’accesso ad alcuni contesti aziendali strutturati. Quello che conta davvero è la combinazione tra esperienza documentata nella gestione di progetti e una certificazione riconosciuta.
La certificazione PMP del PMI, per esempio, richiede un diploma di scuola superiore con 60 mesi di esperienza nella guida di progetti, oppure una laurea con 36 mesi. Ma la laurea da sola, senza esperienza e senza certificazione, vale poco sul mercato del lavoro specialistico. A conti fatti, conta più un curriculum con progetti reali gestiti che un titolo accademico in materie generali.
Qual è la differenza tra project manager e Scrum Master?
I due ruoli non sono intercambiabili, anche se in molte aziende italiane si tende a confonderli.
Il project manager ha responsabilità su ambito, tempi, costi e qualità dell’intero progetto. Risponde agli stakeholder, gestisce il budget, prende decisioni operative. Lo Scrum Master, secondo la Scrum Guide, è responsabile dell’efficacia dello Scrum Team e funge da leader al servizio del team: rimuove gli impedimenti al progresso, aiuta il team a comprendere la teoria e la pratica di Scrum, facilita gli eventi. Non gestisce persone e non ha autorità di budget.
E c’è un dettaglio che vale la pena ricordare: la Scrum Guide non prevede il ruolo formale di project manager tra le tre accountability dello Scrum Team, che sono Product Owner, Scrum Master e Developers. Questo non significa che il project manager sparisca in un contesto Agile, ma che il suo ruolo si trasforma, spesso verso la gestione di programma o portfolio.
Quale certificazione conviene scegliere nel 2026: PMP o UNI 11648?
Dipende dal mercato in cui vuoi lavorare. Però, se devo dare un’opinione netta: per chi punta a un profilo internazionale o a settori come IT, costruzioni e consulenza, il PMP rimane lo standard più riconosciuto a livello globale.
La norma UNI 11648 è la certificazione di project manager definita a livello italiano da ACCREDIA. Ha senso soprattutto per chi opera in contesti pubblici italiani o in settori dove la certificazione secondo norma nazionale è richiesta esplicitamente nei bandi. Ma i due percorsi non si escludono: si può avere entrambe, e in certi profili la combinazione è un vantaggio concreto. Il percorso di preparazione al PMP di Management Academy copre i contenuti rilevanti per entrambi gli standard, proprio perché le competenze di base si sovrappongono in modo significativo.
Il project manager può lavorare in remoto?
Sì, e la cosa non è nuova come sembra. Il ruolo si basa su comunicazione, coordinamento e gestione delle informazioni: tutte attività che si fanno bene anche a distanza, a patto di avere gli strumenti giusti e un metodo strutturato.
Ma attenzione. Il Manifesto Agile considera la conversazione faccia a faccia il metodo più efficace per trasmettere informazioni all’interno di un team. Il lavoro in remoto funziona, ma richiede una disciplina maggiore nella gestione delle riunioni, nella documentazione delle decisioni e nella visibilità dello stato avanzamento. I project manager che lavorano bene in remoto sono quelli che hanno già interiorizzato questi processi, non quelli che li imparano per la prima volta in videochiamata.


