Piano di progetto: come si fa in 7 step (guida 2026)

Cos’è un piano di progetto e perché serve davvero?

Un piano di progetto è il documento che descrive come e quando saranno raggiunti gli obiettivi, includendo prodotti, attività, risorse e criteri di successo. Non è una formalità da compilare per soddisfare lo sponsor. È la differenza tra un’esecuzione guidata e un team che improvvisa settimana per settimana sperando che i pezzi si incastrino da soli.

Atlassian lo definisce la tabella di marcia per tutte le parti interessate: chiunque lavori al progetto, lo finanzi o lo riceva come output deve poter aprire quel documento e capire dove si è, dove si va e chi fa cosa. In soldoni: senza piano, ognuno ha la propria versione del progetto in testa.

Definizione operativa

Nel quadro PRINCE2, come specifica Smartsheet, il piano delinea esattamente come e quando saranno raggiunti gli obiettivi, con prodotti, attività e risorse necessari tutti documentati nello stesso posto. Ma al di là delle metodologie, la struttura di base è abbastanza stabile tra i settori.

Un piano operativo contiene almeno questi elementi:

• Riepilogo esecutivo con il problema che il progetto intende risolvere
• Obiettivi specifici e criteri di successo misurabili
• Timeline con milestone e sprint, ognuno con un punto di ingresso e un output atteso
• Lista delle attività, grande o piccola che sia, con priorità, tempi e assegnazione delle risorse
• Ambito: presupposti, vincoli, il cosa e il come del lavoro
• Budget di base e piano di controllo dei costi
• Piano di gestione dei rischi e piano di comunicazione

Nei miei anni di formazione in project management ho visto team saltare direttamente al Gantt senza aver mai scritto i criteri di accettazione. Risultato: a progetto concluso, il cliente considerava il lavoro incompleto mentre il team festeggiava la consegna. Tutto perché nessuno aveva documentato il confine tra “fatto” e “non fatto”.

Asana raccomanda di integrare nel piano gli obiettivi che derivano dalle finalità principali, usandoli come bussola durante la definizione dell’ambito. L’idea è verificare che ogni attività contribuisca a quegli obiettivi, e scartare tutto il resto. È un filtro brutale, ma funziona.

E la lista delle attività non va compilata una volta sola. Teamleader è esplicito su questo: la pianificazione va rivisitata più volte per mantenere una visione realistica del progetto in corso. Chi la tratta come un documento statico si ritrova, a metà esecuzione, con un piano che descrive un progetto diverso da quello reale.

Piano di progetto vs project charter

La confusione tra questi due documenti è comune. Spesso si usano come sinonimi, ma non lo sono.

Asana distingue con chiarezza: il project charter viene creato prima, contiene solo obiettivi, ambito e responsabilità, ed è un documento di alto livello che serve ad autorizzare il progetto. Il piano di progetto arriva dopo, è l’approfondimento operativo, e traduce quelle indicazioni in attività concrete, tempi e risorse assegnate.

Pensala così. Il charter dice cosa si vuole ottenere e chi ha l’autorità per farlo. Il piano dice come ci si arriva e quando. Sono due strumenti che si passano il testimone, non uno la copia dell’altro.

Ma c’è un passaggio che molti saltano. Il piano deve essere approvato formalmente dallo sponsor prima che l’esecuzione cominci. Senza quella firma, il team parte cieco: nessuno ha validato che le risorse ci siano davvero, che il budget regga, che le priorità siano quelle giuste. Asana è diretta anche su questo: stabilire il budget durante la fase di pianificazione, prima di iniziare a spendere, è necessario per ottenere l’approvazione delle parti interessate e prendere decisioni informate durante l’esecuzione.

Però, a conti fatti, il valore reale del piano non è nel documento in sé. È nel processo che lo produce: le conversazioni che forza, i vincoli che porta a galla, le aspettative che allinea prima che diventino conflitti.

Perché molti piani di progetto falliscono in fase di esecuzione?

Un piano di progetto fallisce quando viene trattato come adempimento burocratico anziché come strumento di governo dell’esecuzione. Lo si redige una volta, si archivia nella cartella condivisa e non lo si tocca più. Poi arriva la prima milestone e il team scopre che metà delle attività necessarie non erano state mappate, il budget è già consumato al 60% e nessuno sa con precisione quali siano i criteri per dichiarare un deliverable accettato. A quel punto non si sta più gestendo un progetto: si sta gestendo un’emergenza.

Errori ricorrenti nella pianificazione

Il primo errore, e il più sottovalutato, è l’ambito indefinito. Impresoft Engage lo indica come il punto di partenza obbligato di qualsiasi pianificazione efficace: definire risultati, attività, requisiti tecnici e criteri di accettazione, in modo che ogni membro del team sappia esattamente cosa comporta il progetto. Senza questa base, ogni stima successiva è costruita sull’aria.

Ma l’ambito vago non è l’unico problema. Nei progetti che ho seguito negli anni, ho visto ripetersi quasi sempre la stessa sequenza: l’ambito è generico, la lista delle attività è incompleta, il budget viene stimato a lavori già avviati. Tre errori distinti che si alimentano a vicenda.

Sulla lista attività vale la pena essere precisi. Teamleader è esplicito: la lista deve includere ogni singolo impegno, grande o piccolo, necessario a completare il progetto. Non solo le macro-fasi. Quei piccoli impegni dimenticati, una validazione tecnica, un’approvazione legale, un test di integrazione, sono esattamente quelli che bloccano le milestone nei momenti peggiori. E quando una milestone slitta, scivola tutto il resto.

Poi c’è il budget. Asana raccomanda di stabilire il budget durante la fase di pianificazione, prima di iniziare a spendere, per ottenere l’approvazione degli stakeholder e poter prendere decisioni informate durante l’esecuzione. Sembra ovvio. Eppure in molti progetti il budget viene “affinato” mentre i lavori sono già in corso, trasformando ogni decisione operativa in una negoziazione continua su risorse che non si sa bene se ci siano o meno.

Infine: il piano scritto una volta e mai rivisitato. Questo è forse l’errore più comune perché sembra il meno grave. In soldoni, si pensa che aggiornare il piano sia un lusso, non una necessità. Ma Teamleader chiarisce che la pianificazione va rivisitata più volte durante l’avanzamento del progetto, per mantenere una visione realistica di ciò che sta succedendo davvero. Un piano statico fotografa le intenzioni iniziali, non la realtà corrente.

Il costo di un piano superficiale

Il costo non è solo economico. È anche organizzativo e relazionale.

Quando l’ambito non è documentato con requisiti tecnici e criteri di accettazione chiari, il team passa settimane a rinegoziare cosa è “dentro” e cosa è “fuori” dal progetto. Ogni conversazione su un deliverable diventa un piccolo conflitto. Gli stakeholder credono di aver approvato una cosa, il team ne ha realizzata un’altra. E alla fine nessuno ha torto, semplicemente nessuno aveva scritto la stessa cosa nello stesso documento.

Un budget stimato a lavori iniziati porta a una conseguenza precisa: le decisioni operative vengono prese senza sapere se le risorse ci sono. Si compra tempo, si aggiungono persone, si cambiano fornitori. Ogni aggiustamento costa più del necessario perché avviene in emergenza, non in pianificazione. Asana è chiara su questo: il budget serve prima di spendere, non dopo, proprio perché le decisioni prese con dati certi costano strutturalmente meno di quelle prese sotto pressione.

Ma il danno più duraturo è sulla fiducia interna. Quando il piano non viene aggiornato e la realtà del progetto si discosta sempre di più da ciò che è scritto, il documento smette di essere un riferimento. Il team smette di consultarlo. Si lavora a memoria, per priorità percepite, per urgenze del momento. A quel punto il piano di progetto esiste ancora tecnicamente, però non governa più nulla. Ed è precisamente lì che l’esecuzione va fuori controllo: non in un singolo momento di crisi, ma in modo graduale, attività dopo attività, finché recuperare diventa quasi impossibile senza rimettere mano all’intera impostazione.

Tutto sommato, un piano superficiale non risparmia tempo nella fase iniziale: lo sposta in avanti, con gli interessi.

Quali sono gli elementi indispensabili di un piano di progetto?

Gli elementi indispensabili di un piano di progetto sono dieci componenti standard che coprono ambito, tempo, costo, qualità, risorse, rischi e comunicazione. Non è una lista arbitraria: secondo Smartsheet, questi dieci elementi ricorrono nei piani di progetto professionali indipendentemente dal settore o dalla metodologia adottata. Mancarne anche uno solo crea punti ciechi che, a progetto avanzato, diventano problemi concreti.

I 10 componenti standard

Il primo elemento è l’executive summary. Riassume il progetto in poche righe: cosa si fa, perché, entro quando. Serve al committente per capire tutto in trenta secondi, e al team per non perdere il filo nelle settimane di lavoro intenso. Secondo Bitrix24, è il punto di partenza logico di qualsiasi piano.

Poi viene l’ambito. Canva lo descrive come l’insieme dei presupposti, delle informazioni disponibili e dei vincoli, e afferma che definisce il cosa, il come e il perché di un pacchetto di lavoro. In soldoni: l’ambito dice cosa rientra nel progetto e, altrettanto importante, cosa non ci rientra. Impresoft Engage aggiunge che un ambito ben definito deve includere risultati attesi, requisiti tecnici e criteri di accettazione, così ogni membro del team sa esattamente cosa comporta il lavoro.

Terzo elemento: gli obiettivi. Asana raccomanda di usarli come bussola durante l’intera fase di pianificazione, verificando che ogni singola attività contribuisca agli obiettivi principali. Un obiettivo che non si collega ad almeno un’attività concreta è decorativo. E un’attività che non si ricollega a nessun obiettivo è spreco di tempo.

La timeline con le milestone è il quarto componente. Canva descrive la pianificazione come una sequenza temporale suddivisa in pietre miliari o sprint, ognuno con punto di ingresso, uscita, attività iniziale e output finale. Ogni milestone deve avere un impatto misurabile: non “completare la fase di analisi”, ma “documento di analisi approvato dal cliente entro il 15 marzo”.

Quinto: ruoli e responsabilità. Senza questo elemento il piano è solo una lista di cose da fare. Atlassian è esplicito su questo punto: ogni task deve avere un responsabile nominato, una data di inizio, una data di completamento e le dipendenze con gli altri task. Chi fa cosa, quando, e cosa deve essere già pronto prima di poter partire.

Sesto e settimo: la baseline dei costi e il piano di controllo dei costi. Sono due sezioni distinte nel framework di Smartsheet, e la distinzione ha senso. La baseline dice quanto si prevede di spendere. Il piano di controllo dice come si monitoreranno gli scostamenti. Asana raccomanda di stabilire il budget prima di iniziare a spendere, non durante l’esecuzione, proprio per poter prendere decisioni informate quando qualcosa va storto.

Ottavo: la gestione dei rischi. Non un elenco di paure vaghe, ma una valutazione concreta di probabilità e impatto per ciascun rischio identificato, con le contromisure previste. Atlassian la cita esplicitamente tra i componenti obbligatori di qualsiasi piano.

Nono: il piano di comunicazione. Chi riceve quali aggiornamenti, con quale frequenza, attraverso quale canale. Nei miei anni di lavoro su progetti complessi ho visto fallire piani tecnicamente impeccabili perché il committente scopriva i problemi in ritardo, quando le soluzioni erano già più costose. Il piano di comunicazione non è burocrazia: è gestione delle aspettative.

Decimo e ultimo: la valutazione del progetto e i parametri di successo. Come si misurerà il risultato finale? Quali metriche determineranno se il progetto ha centrato o mancato gli obiettivi? Questo componente chiude il cerchio aperto dall’executive summary.

Cosa NON può mancare

Tra i dieci elementi, tre sono assolutamente non negoziabili.

Il primo è la struttura delle attività con responsabile, data di inizio, data di completamento e dipendenze. Twproject descrive questa granularità come componente tipico di qualsiasi piano di project management professionale: ogni attività deve avere stato, priorità, tempo e assegnazione a una risorsa specifica. Teamleader è ancora più diretto: la lista di attività deve includere ogni singolo impegno, grande o piccolo, necessario a completare il progetto.

Il secondo elemento non negoziabile è l’ambito definito per iscritto. Senza un documento che dica esplicitamente cosa è incluso e cosa non lo è, il progetto si espande. Sempre. È una legge empirica, non una previsione pessimistica.

Il terzo è la baseline dei costi approvata prima dell’avvio. Non un’idea di massima, non una stima a voce. Un numero scritto, approvato dalle parti interessate, che diventa il riferimento per tutte le decisioni di spesa successive.

Ma c’è un principio trasversale che vale per tutti e dieci i componenti. Teamleader afferma che il piano va rivisitato più volte durante il progetto per mantenere una visione realistica di ciò che sta accadendo. Anzi, un piano che non viene aggiornato smette di essere uno strumento di lavoro e diventa un documento storico. A quel punto serve solo per capire dove si è sbagliato, non per correggere il tiro in tempo.

Come si fa un piano di progetto in 7 step concreti?

Costruire un piano di progetto richiede 7 step sequenziali che vanno dalla definizione dell’ambito alla creazione dei canali di comunicazione. Non è un documento che si compila una volta sola e si mette nel cassetto: secondo Teamleader, la pianificazione va rivisitata più volte per mantenere una visione realistica del progetto in corso. In soldoni, un piano che non si aggiorna è già vecchio il giorno dopo la firma.

Nei progetti che ho seguito negli anni, l’errore più comune non era tecnico. Era di sequenza: i team saltavano step o li affrontavano nell’ordine sbagliato, e il risultato era un piano che sembrava completo ma si sgretolava alla prima variazione di scope. Per questo conviene seguire un ordine preciso, almeno la prima volta.

Step 1: definire ambito e deliverable

L’ambito è il confine del progetto. Canva lo descrive come l’insieme dei presupposti, delle informazioni disponibili e dei vincoli, e afferma che definisce il cosa, il come e il perché di un pacchetto di lavoro. Definire l’ambito significa scrivere nero su bianco tre cose: cosa è incluso, cosa è esplicitamente escluso, e su quali presupposti si lavora.

Impresoft Engage indica la definizione dell’ambito come primo passaggio obbligatorio, e raccomanda di includere risultati attesi, attività previste, requisiti tecnici e criteri di accettazione. Quest’ultimo punto è sottovalutato: senza criteri di accettazione, il deliverable non è mai davvero “fatto”. Ma poi arriva sempre qualcuno a dire che non era quello che si aspettava.

Scrivi una lista di tre colonne: IN SCOPE, OUT OF SCOPE, ASSUNZIONI. Trenta minuti di lavoro che risparmiano settimane di negoziazione.

Step 2: identificare stakeholder e obiettivi

Prima di costruire qualsiasi timeline, bisogna sapere per chi si lavora e verso cosa. Asana raccomanda di integrare nel piano gli obiettivi che derivano dalle finalità principali del progetto, usandoli come bussola durante tutta la fase di pianificazione per verificare che ogni attività contribuisca davvero agli obiettivi dichiarati.

Mappare gli stakeholder non vuol dire elencare nomi. Vuol dire capire chi approva, chi blocca, chi subisce gli effetti del progetto senza essere nel team. Bitrix24 suggerisce di aprire il piano con un riepilogo esecutivo che riassuma il progetto, seguito da obiettivi e incarichi, metodologia e criteri di successo. È una struttura che funziona perché forza a rispondere alle domande degli stakeholder prima che le facciano.

Step 3: costruire la WBS

La Work Breakdown Structure è la spina dorsale del piano. FlexiProject la descrive come un elenco organizzato dei compiti necessari al raggiungimento dei deliverable: non attività generiche, ma compiti eseguibili, assegnabili, misurabili.

La logica è gerarchica. Si parte dal deliverable finale e si scompone verso il basso fino ad arrivare a unità di lavoro che una persona può effettivamente completare. Un deliverable come “sito web rilasciato” diventa “wireframe approvati”, poi “homepage sviluppata”, poi “test su browser completato”. Ogni livello aggiunge precisione. E ogni compito senza un responsabile assegnato è un compito che non verrà fatto.

Quindi, prima di passare alla timeline: la WBS deve essere completa. Non perfetta, ma completa. Aggiungere compiti a piano avviato è una delle cause principali di slittamento.

Step 4: costruire la timeline con milestone

Con la WBS in mano, si costruisce la sequenza temporale. Canva descrive la pianificazione di progetto come una sequenza dettagliata che va dall’avvio alla chiusura, suddivisa in pietre miliari o sprint, ognuna con punto di ingresso, punto di uscita, attività iniziale e output finale.

Una timeline senza milestone è una lista di attività. Le milestone servono a creare punti di verifica reali: il team sa cosa deve essere consegnato entro quando, e il cliente o lo sponsor può approvare prima di procedere. In un progetto di durata superiore a quattro settimane, avere una milestone ogni due settimane è il minimo ragionevole.

Personalmente trovo che il Gantt funzioni bene per comunicare la timeline agli stakeholder, ma la costruzione interna si fa meglio con una lista di dipendenze: attività A prima di B, B prima di C. Solo dopo si traduce in grafico.

Step 5: allocare risorse e budget

Allocare risorse significa assegnare persone, strumenti e costi a ogni attività della WBS. Twproject descrive questa fase come la definizione delle attività con stato, priorità, tempo e assegnazioni di risorse umane. Non basta sapere chi fa cosa: serve sapere per quanto tempo e con quale priorità rispetto ad altri progetti in corso.

Asana raccomanda di stabilire il budget durante la fase di pianificazione, prima di iniziare a spendere, per ottenere l’approvazione degli stakeholder e poter prendere decisioni informate durante l’esecuzione. Un budget definito a posteriori non è un budget: è una giustificazione.

Smartsheet elenca la linea di base dei costi e il piano di controllo dei costi come elementi distinti di un piano di progetto ben strutturato. La distinzione è importante: la baseline dice quanto si prevede di spendere, il piano di controllo dice come si monitorerà lo scostamento.

Step 6: mappare rischi e mitigazioni

Il piano di gestione dei rischi non è una formalità. È il documento che distingue un piano professionale da una lista di buone intenzioni.

Per ogni rischio identificato serve una strategia specifica: mitigazione (riduci la probabilità), contingenza (prepari una risposta se si verifica), accettazione (decidi consapevolmente di non agire). La mappatura minima richiede tre colonne: rischio, probabilità, impatto. E poi una quarta: chi è il responsabile della risposta.

Ma la parte che si salta quasi sempre è la revisione. Un registro dei rischi compilato in fase di pianificazione e mai più aperto è inutile. Va aggiornato a ogni milestone, almeno.

Step 7: definire il piano di comunicazione

L’ultimo step riguarda chi riceve quali informazioni, con quale frequenza e attraverso quale canale. Smartsheet include il piano di comunicazione tra gli elementi comuni di un piano di progetto strutturato, insieme a executive summary, ambito, timeline, ruoli e piano dei rischi.

Un piano di comunicazione efficace risponde a quattro domande: chi deve essere informato, su cosa, ogni quanto, e in che formato. Un report settimanale al cliente non è uguale a un aggiornamento quotidiano al team interno. E la confusione tra i due livelli genera rumore, aspettative disallineate, decisioni prese senza le informazioni giuste.

Harvest identifica esattamente questi 7 passaggi come la struttura portante di un piano di progetto: obiettivi, deliverable, compiti, timeline, risorse, rischi, comunic

Come si costruisce una WBS (Work Breakdown Structure) efficace?

La Work Breakdown Structure è la scomposizione gerarchica dei deliverable in compiti eseguibili, ciascuno con responsabile e durata. Non è un diagramma di flusso, non è un calendario: è la mappa di tutto il lavoro che il progetto deve produrre, organizzata dal generale al particolare. Nei progetti che ho seguito, la WBS è stato quasi sempre il documento che ha chiarito davvero quanto un progetto fosse più grande di quanto il team si aspettasse all’inizio.

Logica di scomposizione

Si parte dai deliverable. Sempre.

Prima descrivi cosa il progetto deve consegnare, poi scomponi ogni consegna in blocchi di lavoro più piccoli. Secondo l’approccio descritto da FlexiProject, la WBS si costruisce come un elenco organizzato di compiti necessari a realizzare i deliverable, una volta che prodotti e ambito sono già stati descritti. Questo ordine non è arbitrario: se salti la definizione dell’ambito e vai direttamente ai task, finisci per dimenticare interi pezzi di lavoro o, al contrario, aggiungere attività che non servono a nessun deliverable concreto.

La scomposizione segue una logica semplice. Prendi un deliverable, per esempio “sito web di prodotto”. Scomponilo in macro-aree: architettura informativa, design visivo, sviluppo front-end, integrazione back-end, collaudo, rilascio. Poi scomponi ciascuna macro-area in task eseguibili. E continui a scendere finché ogni voce è assegnabile a una persona, stimabile in ore, verificabile a fine lavoro.

Quante livelli servono? Dipende dalla complessità. Un progetto di tre mesi con quattro persone avrà forse due livelli di scomposizione. Un progetto che dura un anno con venti risorse coinvolte ne richiederà probabilmente tre o quattro. Non esiste un numero giusto in assoluto: il criterio è che ogni voce finale sia gestibile da una singola persona in un tempo definito.

Dal deliverable al task atomico

Un task si dice “atomico” quando non ha senso scomporlo ulteriormente. È assegnato a una persona, ha una durata stimata, ha uno stato tracciabile. Tutto sommato, è il mattone minimo del progetto.

Come indicano le specifiche di Twproject, ogni componente della WBS deve includere quattro informazioni di base: stato di avanzamento, priorità, tempo stimato e assegnazione delle risorse umane. Senza questi quattro campi, un task è solo un appunto su un foglio. Con questi quattro campi, diventa un’unità di lavoro misurabile, su cui puoi fare previsioni, identificare ritardi, redistribuire carichi.

Ma c’è un punto che spesso si sottovaluta. La WBS non è solo uno strumento operativo per il team: è la base su cui si costruisce la stima di durata e costo dell’intero progetto. Ogni task ha un tempo stimato e una risorsa associata con un costo. Somma tutto e ottieni la baseline di budget e calendario. Questo è il motivo per cui una WBS incompleta produce stime sbagliate, e stime sbagliate producono progetti in ritardo o fuori budget fin dalla seconda settimana di esecuzione.

Quindi, quando costruisci la WBS, non fermarti al livello “abbastanza dettagliato da capire cosa fare”. Scendi fino al livello “abbastanza dettagliato da stimare con un margine accettabile”. La differenza tra i due sta spesso in uno o due livelli di scomposizione in più, e qualche ora di lavoro in fase di pianificazione che si ripaga molte volte durante l’esecuzione.

Però attenzione a non esagerare dall’altra parte. Task da quindici minuti non si gestiscono: si tracciano su un blocco note e basta. Se ti trovi a stimare attività sotto le due ore, probabilmente stai scendendo a un livello di dettaglio che genera rumore invece di controllo.

A conti fatti, una WBS ben costruita risponde a una domanda sola: “Se completiamo tutti questi task, il progetto è finito?” Se la risposta è sì senza riserve, la struttura regge. Se durante la risposta ti viene in mente qualcosa che non hai incluso, torni al tavolo da disegno prima che lo faccia la realtà durante l’esecuzione.

Come si imposta il piano di comunicazione e l’approvazione dello sponsor?

Il piano di comunicazione è il sottoinsieme del piano di progetto che definisce chi riceve quali informazioni, con quale frequenza e tramite quale canale. Non è un documento di contorno. È la struttura che evita equivoci, escalation inutili e riunioni che non portano da nessuna parte. Secondo FlexiProject, un piano di comunicazione ben costruito richiede di identificare gli stakeholder, mapparne le esigenze informative e sviluppare un piano d’azione coerente con quelle esigenze.

Nei progetti che ho seguito negli ultimi anni, ho visto fallire non la parte tecnica, ma quella relazionale. Il team consegna in tempo, ma lo sponsor non è mai stato aggiornato davvero. Oppure il cliente riceve troppi report, li smette di leggere, e alla prima difficoltà dice che non sapeva nulla. La comunicazione mal gestita è, a conti fatti, uno dei rischi più sottovalutati in fase di pianificazione.

Mappare gli stakeholder

Prima di decidere cosa comunicare, si fa un passo indietro: chi ha interesse nel progetto e cosa ha bisogno di sapere?

Non tutti gli stakeholder sono uguali. Lo sponsor vuole aggiornamenti sull’andamento complessivo, sui rischi principali e sui costi. Il team operativo ha bisogno di sapere le priorità settimanali, le dipendenze tra attività, gli ostacoli da rimuovere. Il cliente finale, spesso, vuole solo sapere se le milestone sono rispettate. Dare a tutti le stesse informazioni è un errore. Dare a ciascuno troppo è un errore diverso, ma altrettanto grave.

La mappatura si fa su una griglia semplice: stakeholder, ruolo nel progetto, tipo di informazione rilevante, livello di dettaglio atteso. Smartsheet, tra gli elementi standard di un piano di progetto, elenca esplicitamente il piano di comunicazione come componente distinto, separato dalla gestione dei rischi e dal controllo dei costi. Non è un caso: merita lo stesso rigore.

Ma mappare non basta. Bisogna anche capire se uno stakeholder è attivo o passivo, se ha potere decisionale o solo un interesse informativo. Questa distinzione cambia completamente il canale e la frequenza che sceglierai.

Definire frequenza e canali

Una volta chiaro chi sono gli stakeholder e cosa si aspettano, si decide come raggiungerli.

La frequenza dipende dalla fase del progetto e dal livello di rischio. Nelle settimane di avvio, quando le decisioni si moltiplicano, serve più contatto. Nella fase di esecuzione stabile, basta un report settimanale per il team e uno bisettimanale per lo sponsor. Verso la chiusura, si intensifica di nuovo. Non esiste una formula fissa: esiste una valutazione contestuale.

I canali contano quanto la frequenza. Una mail con allegato Excel è utile per i report formali, ma è il canale sbagliato per segnalare un rischio urgente. Una call è efficace per decisioni rapide, ma non lascia traccia. Personalmente preferisco adottare canali diversi per scopi diversi, documentando nel piano di comunicazione quale canale è associato a quale tipo di messaggio. Così il team sa già, senza doverlo chiedere, come escalare un problema rispetto a come aggiornare lo stakeholder su un avanzamento ordinario.

Il formato del report è l’ultimo tassello. Uno sponsor impegnato non legge dieci pagine. Vuole una dashboard di una schermata, con traffico semaforico su tre aree: tempi, costi, rischi. Il team tecnico, invece, può lavorare con un documento più granulare, che mostri lo stato di ogni attività.

L’approvazione formale del piano

Il piano di comunicazione non è operativo finché lo sponsor non lo approva. Questo passaggio formale non è burocrazia: è un allineamento esplicito su cosa lo sponsor si aspetta di ricevere e con quale cadenza.

FlexiProject è diretto su questo punto: lo sponsor del progetto deve approvare il piano prima della fase di implementazione. Significa che non si inizia a eseguire nulla senza aver ottenuto quella firma, o almeno quella conferma scritta. Perché? Perché se lo sponsor scopre a metà progetto che i report non corrispondono a ciò che si aspettava, il problema non è solo comunicativo. Diventa un problema di fiducia.

Quindi si porta il piano di comunicazione nella stessa riunione in cui si porta il piano complessivo di progetto. Si illustrano i canali, la frequenza, il formato dei report, i destinatari. Si chiede conferma esplicita. E si registra quella conferma.

Anzi, il momento dell’approvazione è anche l’occasione migliore per chiarire le aspettative: lo sponsor preferisce una call mensile o un report scritto? Vuole essere coinvolto nelle decisioni operative o solo informato? Queste domande, fatte adesso, evitano conversazioni difficili più avanti. Tutto sommato, un quarto d’ora di allineamento in fase di pianificazione vale più di ore di gestione del conflitto durante l’esecuzione.

Studio autodidatta o percorso certificato: come si impara davvero a fare un piano di progetto?

Imparare a costruire un piano di progetto significa interiorizzare un metodo, non compilare un template: per questo i percorsi certificati restano il riferimento per i ruoli senior. La differenza tra chi sa fare un piano e chi sa gestirlo si vede quando arriva il primo trade-off reale, quando il budget si assottiglia e l’ambito non si riduce da solo.

I limiti dell’apprendimento da template

Scaricare un template risolve un problema di formato. Non risolve un problema di metodo.

Nei miei anni di lavoro con project manager alle prime armi ho visto lo stesso schema ripetersi: lo studente autodidatta compila tutte le colonne, inserisce milestone, attività e responsabili, poi il progetto parte e al primo imprevisto il piano viene abbandonato. Non perché il template fosse sbagliato. Perché nessun template insegna cosa fare quando ambito, tempo e costo tirano in tre direzioni opposte simultaneamente, e tu hai mezz’ora per decidere.

Un piano di progetto include executive summary, obiettivi, timeline, ruoli, linea di base dei costi, piano di gestione dei rischi e piano di comunicazione. Questi elementi li elenchi in cinque minuti cercando su qualsiasi fonte online. Ma sapere perché la baseline dei costi si definisce prima di spendere il primo euro, come raccomanda Asana, e come si usa quella baseline per prendere decisioni durante l’esecuzione, è un’altra cosa. È una competenza. E le competenze si costruiscono con metodo guidato, non per esplorazione casuale.

Inoltre, la pianificazione non è un atto unico. Teamleader lo dice chiaramente: il piano va rivisitato più volte per mantenere una visione realistica del progetto in corso. Chi impara solo dai template tende a trattare il piano come un documento statico. Chi ha fatto un percorso strutturato sa che è uno strumento vivo.

Il valore di una certificazione riconosciuta

Due certificazioni contano davvero sul mercato italiano per chi vuole fare del piano di progetto il proprio mestiere: la UNI 11648 e il PMP.

La UNI 11648 è la norma italiana che definisce i requisiti di conoscenza del Project Manager. Non è un corso privato, non è un badge da LinkedIn: è uno standard nazionale che stabilisce cosa deve sapere e saper fare chi assume questo ruolo professionalmente. Per aziende che lavorano su commessa pubblica o in settori regolamentati, questa certificazione è spesso un prerequisito implicito nelle selezioni senior.

Il PMP (Project Management Professional), certificazione rilasciata dal PMI, ha un costo chiaro: 555$ per i membri PMI, 675$ per i non membri (fonte: PMI.org). Non è economica. Però è riconosciuta in oltre 200 paesi e ha un peso specifico nelle organizzazioni internazionali che in Italia difficilmente si sostituisce con altro. A mio avviso, per chi punta a ruoli di program management o lavora in contesti multinazionali, il PMP resta la scelta più solida in termini di ritorno sull’investimento nel tempo.

Ma la certificazione da sola non basta. Conta il percorso che la precede.

Un programma di preparazione strutturato obbliga a ragionare su scenari reali: come si gestisce uno scope creep quando il cliente aggiunge requisiti senza rivedere il budget? Come si comunica uno slittamento di milestone senza perdere credibilità con gli stakeholder? Queste situazioni non si trovano in un template. Si trovano negli esercizi di simulazione, nei casi studio, nel confronto con chi ha già affrontato quegli stessi problemi. Il nostro corso di preparazione alla certificazione lavora esattamente su questo livello, costruendo la capacità di decisione sotto pressione, non solo la conoscenza teorica degli strumenti.

Tutto sommato, la scelta tra autodidattica e percorso certificato non è una questione di preferenze personali. È una questione di obiettivi professionali. Se vuoi gestire un piccolo progetto interno, un template funziona. Se vuoi essere la persona a cui affidano progetti da centinaia di migliaia di euro, serve qualcosa di più solido.

Domande frequenti su piano di progetto come si fa

Le domande più frequenti su come si fa un piano di progetto riguardano tempi, strumenti, approvazioni e aggiornamento del documento. Raccoglierle in un unico posto serve a togliersi i dubbi pratici prima di mettersi al lavoro, senza perdersi in teoria.

Quanto tempo richiede scrivere un piano di progetto?

Dipende dalla complessità. Un progetto piccolo, con un team di tre o quattro persone e obiettivi ben definiti, richiede qualche ora di lavoro concentrato. Un progetto articolato, con più stakeholder e budget significativo, può richiedere giorni interi solo per la fase di pianificazione. A conti fatti, la variabile che pesa di più non è la dimensione del documento, ma la qualità delle informazioni disponibili quando si comincia a scrivere.

Qual è la differenza tra piano di progetto e Gantt?

Il piano di progetto è il documento completo. Contiene obiettivi, ambito, budget, rischi, ruoli, criteri di successo e molto altro. Il diagramma di Gantt è uno strumento visivo che mostra la sequenza delle attività nel tempo. È una parte del piano, non il piano stesso. Usare solo il Gantt per gestire un progetto è come navigare con la sola bussola e senza mappa.

Chi deve approvare il piano di progetto?

Lo sponsor del progetto approva il piano prima dell’implementazione. Questo è il passaggio formale che sblocca le risorse e autorizza il team a procedere. In alcuni contesti, specialmente nelle organizzazioni strutturate, si aggiungono approvazioni da parte del comitato di steering o dei responsabili di funzione coinvolti. Ma la firma dello sponsor rimane il punto di snodo centrale, senza il quale il piano resta un documento senza forza esecutiva.

Ogni quanto va aggiornato il piano di progetto?

La pianificazione va rivisitata più volte durante il progetto, secondo quanto indica Teamleader. Non esiste una frequenza fissa valida per tutti i contesti. Però, come regola pratica, ogni milestone conclusa è un buon momento per fare il punto. Nei progetti agili si aggiorna a ogni sprint. Nei progetti tradizionali, almeno a ogni fase.

Nei progetti che ho seguito, il piano lasciato fermo per più di tre settimane si discostava già dalla realtà in almeno due o tre attività. Aggiornarlo non è burocrazia: è l’unico modo per mantenere una visione realistica di quello che sta succedendo.

Serve una certificazione per scrivere un piano di progetto?

No. Chiunque abbia chiaro il perimetro del progetto, le risorse disponibili e gli obiettivi da raggiungere può scrivere un piano di progetto. Ma c’è un però. La certificazione in project management, come il PMP o CAPM rilasciati dal PMI, fornisce un metodo condiviso e un linguaggio comune che rende il piano più solido, più leggibile da altri professionisti e più difendibile davanti agli stakeholder. In soldoni: non serve per iniziare, serve per fare meglio.