Guida al project management · Pianificazione e ambito
Piano di project management: componenti, passaggi ed esempio
Un piano di project management è il documento approvato che spiega come un progetto sarà eseguito, monitorato, controllato e chiuso. Riunisce i piani di ambito, cronoprogramma, costi, rischi, qualità, comunicazione e altri, insieme alle baseline rispetto a cui misuri l'avanzamento. Questa guida ne illustra i componenti, un metodo in 10 passaggi, un esempio svolto e uno schema che puoi copiare.
Punti chiave
- Un piano di project management spiega come sarà gestito il progetto, non solo cosa consegnerà.
- Combina piani di gestione sussidiari (ambito, cronoprogramma, costi, rischi e altro) con le baseline di ambito, tempi e costi.
- Costruiscilo a partire dal charter approvato: prima requisiti e ambito, poi cronoprogramma e budget, quindi i piani di supporto.
- Proporziona il livello di dettaglio a dimensioni, rischio e complessità del progetto; un progetto piccolo può richiedere solo poche pagine.
- Consideralo un documento vivo: aggiornalo tramite il controllo delle modifiche e ridefinisci la baseline solo quando le modifiche sono approvate.
Che cos'è un piano di project management?
A piano di project management è un documento formale e approvato che definisce come un progetto sarà eseguito, monitorato e controllato, e chiuso. Integra i piani di gestione sussidiari per ambito, cronoprogramma, costi, qualità, risorse, comunicazione, rischi, approvvigionamenti e stakeholder, insieme alle baseline usate per misurare le performance.
La formulazione deriva dalla *Guida PMBOK* del PMI, che definisce il piano di project management come il documento che descrive come il progetto sarà eseguito, monitorato e controllato, e chiuso. In pratica, è il regolamento del progetto: il punto a cui team, sponsor e stakeholder si rivolgono per sapere come si prendono le decisioni, come si riferisce l'avanzamento e cosa succede quando qualcosa cambia.
Un buon piano risponde a una manciata di domande pratiche:
- Che cosa stiamo consegnando, e cosa è fuori ambito?
- Quando saranno completati i principali deliverable e milestone?
- Quanto costerà, e come sarà controllata la spesa?
- Chi svolge il lavoro, e chi prende quali decisioni?
- Come gestiremo qualità, rischi, problemi, fornitori e comunicazione?
- Cosa succede quando qualcuno chiede una modifica?
Di solito è redatto dal project manager con il contributo del team, degli esperti della materia e degli stakeholder principali, e approvato dallo sponsor o dal project board. Svilupparlo è un'attività centrale della gestione dell'integrazione di progetto, perché collega tra loro tutte le altre aree di conoscenza.
Piano di project management vs altri documenti di progetto
Spesso si usano come sinonimi "piano di progetto", "piano di project management" e "cronoprogramma". Si sovrappongono, ma non sono la stessa cosa. La tabella seguente mostra come si relazionano i principali documenti di avvio.
| Documento | Scopo principale | Livello di dettaglio | Responsabile tipico |
|---|---|---|---|
| Project charter | Autorizza il progetto e nomina il project manager | Alto livello, 2–4 pagine | Sponsor |
| Project initiation document (PID) | Baseline PRINCE2 per autorizzare e gestire il progetto | Dettagliato | Project manager, approvato dal project board |
| Piano di project management | Spiega come il progetto sarà eseguito, monitorato, controllato e chiuso | Dettagliato, proporzionato al progetto | Project manager, approvato dallo sponsor |
| Cronoprogramma di progetto | Attività in sequenza, durate, dipendenze e date | Dettagliato solo per le tempistiche | Project manager o pianificatore |
| Statement of work | Descrive il lavoro che un fornitore consegnerà in base a un contratto | Dettagliato per il lavoro contrattualizzato | Acquirente e fornitore |
| "Piano di progetto" (informale) | Spesso usato per indicare il cronoprogramma o un breve piano di sintesi | Variabile | Project manager |
La distinzione chiave è che il charter dice che il progetto esiste e perché, mentre il piano di project management dice come sarà realizzato. Il cronoprogramma è solo una parte del piano. Se lavori in un contesto PRINCE2, il PID svolge un ruolo simile al piano di project management, ma contiene anche il business case e la struttura del team di project management.
Perché un piano di project management è importante
Scrivere un piano richiede tempo, quindi è legittimo chiedersi cosa offre. Secondo la nostra esperienza, i benefici derivano meno dal documento in sé che dalle riflessioni e dagli accordi che impone fin dall'inizio.
- Comprensione condivisa: sponsor, team e stakeholder concordano ambito, priorità e modi di lavorare prima che venga speso denaro.
- Una base per misurare l'avanzamento: senza baseline approvate per ambito, tempi e costi, non puoi dire se il progetto è in anticipo, in ritardo o fuori budget.
- Decisioni più rapide: ruoli, limiti di approvazione e percorsi di escalation sono concordati in anticipo, così i problemi non restano bloccati mentre si capisce chi decide.
- Controllo delle modifiche: un processo definito di controllo delle modifiche protegge il progetto dallo scope creep.
- Meno sorprese: pianificare in anticipo rischi, qualità e approvvigionamenti fa emergere i problemi quando sono ancora poco costosi da risolvere.
- Inserimento più facile: nuovi membri del team e fornitori possono leggere un unico documento invece di ricostruire il quadro da email e verbali di riunione.
Componenti di un piano di project management
La checklist di componenti più usata proviene dalla *Guida PMBOK* 6ª edizione, che descrive tre gruppi: piani di gestione sussidiari, baseline e componenti aggiuntivi. Le edizioni successive sono passate a una struttura basata su principi e domini di performance e danno più peso all'adattamento, ma l'elenco della 6ª edizione resta un riferimento pratico per decidere cosa deve coprire il tuo piano.
Piani di gestione sussidiari
Ogni piano sussidiario spiega come sarà gestita un'area del progetto. In un progetto piccolo molti possono essere un paragrafo ciascuno; in un progetto grande ciascuno può essere un documento separato richiamato dal piano principale.
| Piano sussidiario | Cosa spiega |
|---|---|
| Piano di gestione dell'ambito | Come l'ambito sarà definito, convalidato e controllato; vedi ambito del progetto |
| Piano di gestione dei requisiti | Come i requisiti saranno raccolti, prioritizzati, tracciati e modificati |
| Piano di gestione della schedulazione | Il metodo di schedulazione, lo strumento, le unità, la frequenza di aggiornamento e le soglie per lo scostamento dei tempi |
| Piano di gestione dei costi | Come i costi sono stimati, messi a budget e controllati; vedi piano di gestione dei costi |
| Piano di gestione della qualità | Standard di qualità, metriche, revisioni, verifiche di accettazione e responsabilità |
| Piano di gestione delle risorse | Come persone, attrezzature e materiali vengono acquisiti, assegnati e rilasciati |
| Piano di gestione delle comunicazioni | Chi riceve quali informazioni, quando, in quale formato e da chi; vedi piano di comunicazione |
| Piano di gestione dei rischi | Come i rischi sono identificati, valutati, assegnati e riesaminati; vedi gestione dei rischi di progetto |
| Piano di gestione degli approvvigionamenti | Cosa sarà acquistato, i tipi di contratto e come i fornitori vengono selezionati e gestiti |
| Piano di coinvolgimento degli stakeholder | Come ciascun gruppo di stakeholder sarà coinvolto e tenuto informato |
Baseline
Le baseline sono le versioni approvate di ambito, tempi e costi. Cambiano solo tramite un controllo formale delle modifiche, e le performance effettive vengono confrontate con esse.
| Baseline | Composta da | Usata per misurare |
|---|---|---|
| Baseline dell'ambito | Dichiarazione dell'ambito, work breakdown structure e dizionario WBS | Se si sta consegnando il lavoro giusto |
| Baseline dei tempi | Il cronoprogramma approvato con date di inizio e fine | Scostamento dei tempi e ritardi |
| Baseline dei costi | Il budget approvato e distribuito nel tempo, esclusa la riserva di gestione | Scostamento dei costi e andamento della spesa |
Insieme, le tre formano la performance measurement baseline, che è il riferimento rispetto a cui confronta l'earned value management.
Componenti aggiuntivi
La *Guida PMBOK* 6ª edizione elenca anche componenti che descrivono come viene gestito il progetto nel suo complesso:
- Piano di gestione delle modifiche: come le modifiche vengono richieste, valutate, approvate e registrate.
- Piano di gestione della configurazione: come le versioni di deliverable e documenti vengono identificate e controllate.
- Descrizione del ciclo di vita del progetto: le fasi che il progetto attraverserà.
- Approccio di sviluppo: predittivo, adattivo (Agile) o ibrido, e perché.
- Riesami di direzione: quando lo sponsor o il comitato guida riesamineranno l'avanzamento e prenderanno decisioni di go o no-go.
Come creare un piano di project management in 10 passaggi
L'ordine seguente segue la logica usata dalla maggior parte dei professionisti: concorda cosa stai consegnando, poi quando e a quale costo, poi come gestirai tutto il resto. Nella realtà tornerai indietro man mano che i passaggi successivi fanno emergere problemi in quelli precedenti, ed è normale.
1. Parti dal charter e dal business case approvati
Leggete il project charter e il business case. Annota obiettivi, ambito di alto livello, date fisse, fascia di budget, rischi noti ed eventuali vincoli. Tutto ciò che è nel piano deve essere coerente con questi elementi. Se qualcosa nel charter non è realistico, sollevalo subito con lo sponsor anziché nasconderlo nel piano.
2. Identifica gli stakeholder e raccogli i requisiti
Elenca tutti coloro che sono influenzati dal progetto o possono influenzarlo, poi raccogli e prioritizza i loro requisiti. Interviste, workshop e analisi dei processi esistenti sono tutti utili. Registra i requisiti in modo da poter collegare in seguito ciascuno di essi a un deliverable.
3. Definisci l'ambito e costruisci la work breakdown structure
Scrivi una dichiarazione dell'ambito con inclusioni, esclusioni, deliverable e criteri di accettazione chiari. Poi scomponi i deliverable in una work breakdown structure finché ogni work package è abbastanza piccolo da poter essere stimato e assegnato. Il nostro modello WBS gratuito ti offre una struttura di partenza.
4. Scegli il ciclo di vita e adatta il tuo approccio
Decidi se il progetto sarà predittivo, Agile o ibrido, quali fasi avrà e quanta formalità richiede ciascuna area. Un progetto interno di due mesi e un programma regolamentato di due anni non dovrebbero usare lo stesso livello di documentazione.
5. Costruisci il cronoprogramma
Trasforma i work package in attività, mettile in sequenza con le dipendenze, stima le durate e individua il percorso critico. Aggiungi milestone per le decisioni chiave e i passaggi di consegne. La nostra guida alla schedulazione del progetto illustra ogni passaggio.
6. Stima i costi e definisci il budget
Stima il costo di ogni work package con tecniche come la stima analoga, parametrica o bottom-up, poi aggiungi una riserva di contingenza per i rischi identificati. Aggrega le stime in un budget di progetto distribuito nel tempo e concorda con lo sponsor un'eventuale riserva di gestione.
7. Pianifica risorse, ruoli e responsabilità
Conferma chi svolgerà il lavoro, quando è disponibile e quali attrezzature o materiali servono. Usa una matrice RACI per mostrare chi è responsible, accountable, consulted e informed per ogni deliverable e decisione principale.
8. Pianifica qualità, rischi, comunicazione, approvvigionamenti e coinvolgimento degli stakeholder
Scrivi i piani di supporto. Stabilisci standard di qualità e verifiche di accettazione, tieni un workshop sui rischi e avvia un registro dei rischi, concorda ritmi e canali di reporting, decidi cosa acquistare e come, e pianifica come coinvolgerai ciascun gruppo di stakeholder.
9. Definisci controllo delle modifiche, baseline e reporting
Descrivi come vengono richieste e approvate le modifiche, chi può approvare cosa (ad esempio il project manager fino a un certo costo, lo sponsor oltre) e come vengono registrate le decisioni. Stabilisci le baseline di ambito, tempi e costi e concorda come sarà riferito l'avanzamento, ad esempio in un report di stato settimanale.
10. Rivedi, approva e avvia
Illustra il piano allo sponsor e agli stakeholder principali, risolvi i commenti e ottieni l'approvazione formale. Poi tieni una riunione di kickoff affinché tutto il team comprenda gli obiettivi, il piano e il proprio ruolo. Un piano letto solo dal project manager non guiderà nessuno.
Esempio di piano di project management
L'esempio seguente è illustrativo e semplificato. Mostra come potrebbe presentarsi ciascuna parte di un piano per un progetto interno di medie dimensioni: il trasferimento di un team di 120 persone in un nuovo ufficio.
| Sezione | Voce di esempio |
|---|---|
| Obiettivo | Trasferire tutto il personale e le attrezzature nel nuovo ufficio entro il 28 febbraio con non più di un giorno lavorativo di disagi per team. |
| Ambito | Include pianificazione degli spazi, configurazione IT e di rete, arredi, trasloco e comunicazione al personale. Esclude l'allestimento dell'edificio, a carico del proprietario. |
| Deliverable | Planimetria approvata; rete e telefoni funzionanti; arredi installati; personale trasferito; vecchio ufficio liberato. |
| Tempi | Pianificazione ott–nov; installazione IT a gennaio; traslochi in tre fine settimana a febbraio. Il percorso critico passa per l'installazione della rete. |
| Budget | Baseline dei costi di £180,000 più £15,000 di contingenza gestiti dal project manager; riserva di gestione in capo allo sponsor. |
| Risorse e ruoli | Project manager, referente facility, referente IT, fornitore del trasloco. Sponsor: Direttore operativo. RACI per ogni deliverable. |
| Qualità | Rete testata e approvata dall'IT prima del trasferimento di qualsiasi team; elenco dei difetti chiuso entro 10 giorni lavorativi. |
| Rischi | Installazione della rete in ritardo (alto): verifiche settimanali con il fornitore e una data di riserva. Resistenza del personale (medio): anteprime anticipate della planimetria. |
| Comunicazioni | Email quindicinale a tutto il personale; aggiornamento settimanale allo sponsor in comitato guida; briefing ai team due settimane prima di ogni trasloco. |
| Acquisti | Trasloco e arredi tramite preventivi competitivi di tre fornitori; contratti a prezzo fisso. |
| Controllo delle modifiche | Il project manager approva modifiche fino a £2,000 e due giorni; oltre, decide lo sponsor. |
| Chiusura | Passaggio di consegne al facility management, report finale dei costi e una sessione sulle lezioni apprese entro un mese dall'ultimo trasloco. |
Nota che ogni voce è specifica e misurabile. "Disagi minimi" diventa "non più di un giorno lavorativo per team", e "tenere informate le persone" diventa un canale e una frequenza precisi.
Schema di piano di project management
Usa questo schema come indice del tuo documento. Elimina o accorpa le sezioni non pertinenti e collega i documenti separati dove esistono già.
- Controllo del documento: versione, data, autore, approvatori e cronologia delle modifiche.
- Panoramica del progetto: contesto, obiettivi e criteri di successo tratti dal charter.
- Ambito: dichiarazione dell'ambito, esclusioni, deliverable, criteri di accettazione e WBS.
- Approccio di sviluppo e ciclo di vita: fasi, metodi e decisioni di adattamento.
- Cronoprogramma: elenco delle milestone, diagramma di Gantt di sintesi e regole di gestione dei tempi.
- Budget: baseline dei costi, contingenza, finanziamento e regole di controllo dei costi.
- Organizzazione: ruoli, responsabilità, RACI e diritti decisionali.
- Gestione delle risorse: personale, attrezzature e materiali.
- Gestione della qualità: standard, revisioni e accettazione.
- Gestione dei rischi: approccio, scale, responsabili e ciclo di riesame; collegamento al registro dei rischi.
- Comunicazioni: stakeholder, messaggi, canali e frequenza.
- Approvvigionamenti: cosa sarà acquistato e come vengono gestiti i fornitori.
- Coinvolgimento degli stakeholder: approccio per ciascun gruppo chiave.
- Controllo delle modifiche e della configurazione: processo, soglie e registrazioni.
- Monitoraggio e reporting: report di stato, riesami e metriche chiave.
- Chiusura: accettazione, passaggio di consegne e lezioni apprese.
- Appendici: cronoprogramma dettagliato, stime, registri e modelli.
Il nostro modello di piano di progetto gratuito ti offre una struttura già pronta in Sheets, Excel e PDF. Abbinalo al modello di registro dei rischi, modello di piano di comunicazione e modello di matrice RACI per le sezioni di supporto.
Quanto dettagliato deve essere il piano?
Non esiste una lunghezza fissa. Il giusto livello di dettaglio è quello che permette al team di lavorare senza chiedere continuamente come fare le cose e allo sponsor di capire cosa sta approvando. A titolo indicativo:
| Tipo di progetto | Piano tipico | Cosa mantenere breve |
|---|---|---|
| Piccolo, a basso rischio (settimane, poche persone) | Poche pagine o una singola pagina di uno spazio di lavoro condiviso: obiettivi, ambito, milestone, budget, ruoli, rischi principali | Piani dettagliati di approvvigionamento, configurazione e qualità |
| Medio (mesi, un team o un fornitore) | Un documento principale di lunghezza moderata con cronoprogramma, budget e registro dei rischi in allegato | I piani sussidiari possono essere una sezione ciascuno |
| Grande o regolamentato (un anno o più, molti fornitori) | Un piano principale che rimanda a piani sussidiari e registri separati | Ripetizioni: collega anziché copiare |
Poni due domande per ogni sezione: qualcuno noterebbe se mancasse, e prenderebbe una decisione diversa grazie a essa? Se la risposta a entrambe è no, eliminala.
Piani di project management nei progetti Agile e ibridi
I team Agile pianificano comunque, ma in modo diverso. Invece di fissare in anticipo un ambito dettagliato, fissano la visione, i limiti di tempo e budget e i modi di lavorare, poi pianificano nel dettaglio un rilascio o uno sprint alla volta. A volte si parla di pianificazione a onda mobile (rolling wave).
- Mantieni fissi: obiettivi, governance, limiti di budget, milestone di rilascio, ruoli, definition of done e modalità di coinvolgimento degli stakeholder.
- Mantieni flessibile: l'ambito dettagliato, che si trova nel product backlog prioritizzato anziché in una baseline dell'ambito fissa.
- Sostituisci: il diagramma di Gantt dettagliato con una roadmap di prodotto e un piano di rilascio; le richieste formali di modifica dell'ambito con la prioritizzazione del backlog da parte del product owner.
I progetti ibridi spesso combinano entrambi: un piano predittivo per hardware, contratti o milestone normative, e una delivery Agile per software o contenuti.
Mantenere aggiornato il piano
Un piano approvato è una baseline, non una risposta definitiva. I progetti cambiano, e il piano dovrebbe cambiare con loro in modo controllato.
- Usa il controllo delle modifiche: valuta l'impatto di ogni modifica su ambito, tempi, costi, qualità e rischio prima di approvarla, poi aggiorna le sezioni interessate.
- Ridefinisci la baseline solo quando una modifica è approvata: non spostare di nascosto la baseline per mascherare i ritardi; lo scostamento è un'informazione utile.
- Rivedilo in momenti prestabiliti: a ogni phase gate, dopo modifiche importanti e almeno una volta al mese nei progetti più lunghi.
- Mantieni il controllo delle versioni: registra cosa è cambiato, quando, perché e chi lo ha approvato nella sezione di controllo del documento.
- Informa le persone: un piano modificato di cui nessuno è a conoscenza crea tanti problemi quanto l'assenza di un piano.
Errori comuni nel piano di project management
| Errore | Perché è dannoso | Cosa fare invece |
|---|---|---|
| Considerare il cronoprogramma come l'intero piano | Rischi, qualità, comunicazione e modifiche restano senza gestione | Copri ogni componente, anche brevemente |
| Copiare un modello senza adattarlo | Documenti lunghi che nessuno legge, con sezioni non pertinenti | Proporziona ogni sezione a dimensioni e rischio del progetto |
| Scriverlo da solo | Le stime sono irrealistiche e il team non se ne sente responsabile | Pianifica con le persone che svolgeranno il lavoro |
| Obiettivi e ambito vaghi | Controversie su cosa significhi "fatto" | Usa obiettivi misurabili ed esclusioni esplicite |
| Nessuna contingenza | Il primo rischio che si verifica fa saltare budget o scadenza | Aggiungi una contingenza basata sul registro dei rischi |
| Nessuna soglia per le modifiche | Ogni piccola modifica va in escalation, oppure quelle grandi passano inosservate | Stabilisci limiti di approvazione chiari |
| Archiviarlo dopo l'approvazione | Il piano si allontana dalla realtà | Rivedilo e aggiornalo a intervalli prestabiliti |
| Non ottenere l'approvazione formale | In seguito gli stakeholder negano di aver approvato ambito o budget | Registra l'approvazione con nomi e date |
Strumenti per costruire e mantenere il piano
Molti team scrivono le parti descrittive del piano in un documento e gestiscono cronoprogramma, attività, rischi e budget in un software di project management. Il software rende più facile mantenere vivo il piano: le dipendenze si aggiornano automaticamente, le dashboard mostrano l'avanzamento rispetto alla baseline e tutti vedono la stessa versione.
Quando confronti gli strumenti per pianificare il lavoro, cerca diagrammi di Gantt con dipendenze e baseline, viste di risorse o carico di lavoro, campi personalizzati per rischi e problemi, e dashboard di reporting. Wrike, il nostro strumento al primo posto, offre diagrammi di Gantt interattivi con dipendenze e dashboard condivisibili a partire dal piano Team, il che si adatta a team che gestiscono più progetti contemporaneamente, mentre strumenti più leggeri sono adatti a piani più semplici. La nostra guida al software per diagrammi di Gantt e la classifica degli strumenti di project management completa possono aiutarti a scegliere.
Una volta approvato il piano, il compito successivo è trasformarlo in un cronoprogramma che il team possa seguire.
Modelli gratuiti per questo argomento
Domande frequenti
Che cos'è un piano di project management?
Un piano di project management è un documento formale e approvato che descrive come un progetto sarà eseguito, monitorato e controllato, e chiuso. Riunisce i piani sussidiari per aree come ambito, cronoprogramma, costi, qualità, rischi e comunicazione, oltre alle baseline di ambito, tempi e costi.
Quali sono i componenti principali di un piano di project management?
Secondo la *Guida PMBOK* 6ª edizione, il piano comprende piani di gestione sussidiari (ambito, requisiti, cronoprogramma, costi, qualità, risorse, comunicazioni, rischi, approvvigionamenti e coinvolgimento degli stakeholder), baseline (ambito, tempi e costi) e componenti aggiuntivi come i piani di gestione delle modifiche e della configurazione, il ciclo di vita e l'approccio di sviluppo.
Qual è la differenza tra piano di progetto e piano di project management?
Nell'uso quotidiano, "piano di progetto" indica spesso il cronoprogramma o una breve sintesi di ciò che sarà consegnato. Il piano di project management è più ampio: spiega come sarà gestito l'intero progetto, inclusi i processi di controllo per ambito, costi, qualità, rischi, comunicazione e modifiche.
Il cronoprogramma di progetto coincide con il piano di project management?
No. Il cronoprogramma mostra attività, durate, dipendenze e date. È un componente del piano di project management, che copre anche ambito, costi, qualità, risorse, rischi, comunicazione, approvvigionamenti e modifiche.
Quali sono le tre baseline di un piano di project management?
La baseline dell'ambito, la baseline dei tempi e la baseline dei costi. Insieme formano la performance measurement baseline, con cui si confronta l'avanzamento effettivo. Consulta la nostra guida alla baseline di progetto.
Cosa sono i piani sussidiari?
I piani sussidiari sono le parti del piano di project management che spiegano come viene gestita un'area specifica, come il piano di gestione dei rischi, il piano di gestione delle comunicazioni o il piano di gestione dei costi. Nei progetti piccoli possono essere brevi sezioni; in quelli grandi sono spesso documenti separati.
Chi crea il piano di project management?
Il project manager ne guida lo sviluppo, lavorando con il team, gli esperti della materia e gli stakeholder principali. Stime e piani sono più realistici quando contribuiscono a costruirli le persone che svolgono il lavoro.
Chi approva il piano di project management?
Di solito lo sponsor del progetto, talvolta insieme a un comitato guida o ad altri stakeholder chiave. L'approvazione formale trasforma il piano e le sue baseline nel punto di riferimento per misurare le performance.
Quanto deve essere lungo un piano di project management?
Quanto serve al progetto e non di più. Un progetto piccolo e a basso rischio può richiedere solo poche pagine, mentre un progetto grande o regolamentato richiede di solito un documento principale che rimanda a piani sussidiari e registri separati.
Con quale frequenza va aggiornato il piano di project management?
Ogni volta che una modifica approvata lo riguarda, e in occasione dei riesami pianificati come i phase gate. Nei progetti più lunghi, rivedilo almeno una volta al mese affinché resti allineato al modo in cui il progetto viene effettivamente gestito.
I progetti Agile hanno bisogno di un piano di project management?
I progetti Agile hanno comunque bisogno di obiettivi, governance, limiti di budget, ruoli e modi di lavorare concordati, ma l'ambito dettagliato si trova nel product backlog e viene pianificato rilascio per rilascio. Il piano è più leggero e adattivo, non assente.
Qual è la differenza tra project charter e piano di project management?
Il project charter autorizza formalmente il progetto e ne definisce lo scopo, l'ambito di alto livello e l'autorità del project manager. Il piano di project management viene creato successivamente e spiega nel dettaglio come il progetto sarà realizzato e controllato.
Quali strumenti posso usare per creare un piano di project management?
Un elaboratore di testi o un documento condiviso va bene per le sezioni descrittive, e un software di project management con diagrammi di Gantt, dashboard e registri aiuta a mantenere aggiornati cronoprogramma, rischi e budget. Il nostro modello di piano di progetto gratuito è un buon punto di partenza.