Un piano di gestione del progetto è la guida principale per consegnare un progetto con successo. Con Trupeer, puoi risparmiare ore di pianificazione partendo da un modello di piano di gestione del progetto gratuito, personalizzandolo con la tua identità di marca e trasformando il piano in video sintesi che allineano rapidamente gli stakeholder.

Cos'è un modello di piano di gestione del progetto?

Un piano di gestione del progetto è il documento che descrive come verrà gestito un progetto specifico: il suo ambito, la pianificazione, i costi, la qualità, le risorse, le comunicazioni, i rischi, gli acquisti e l'approccio con gli stakeholder.

Nei metodi formali è il piano principale, che contiene o fa riferimento a piani sussidiari per ciascuna di queste aree. Questo è ciò che lo distingue da un piano di progetto, che nell'uso comune spesso indica solo la pianificazione temporale.

Un modello per questo piano di solito fornisce la serie completa di sezioni sussidiarie, motivo per cui le versioni completate arrivano a sessanta pagine e oltre. Tale completezza non è il problema, e questa pagina non è un invito a saltare la governance.

Il problema è ciò che riempie quelle pagine.

Il test dell'evidenziatore per qualsiasi piano di gestione del progetto

Prendi un piano di gestione del progetto completato della tua organizzazione. Evidenzia ogni frase che sarebbe diversa se questo fosse un progetto diverso.

Non le frasi che contengono il nome del progetto. Frasi il cui contenuto cambierebbe: un vincolo specifico, una dipendenza nominata, una decisione presa per le circostanze di questo progetto, una data che non potrebbe essere spostata.

Poi guarda quanta parte del documento è evidenziata.

Nella maggior parte delle organizzazioni si attesta tra il quindici e il trenta percento. Il restante settanta-ottantacinque percento descrive come l'organizzazione gestisce i progetti in generale, e apparirebbe immutato nel piano successivo e in quello dopo ancora.

Questo è il motivo per cui nessuno legge questi documenti. Un lettore in cerca di ciò che è specifico di questo progetto deve trovarlo all'interno di una quantità di materiale quattro volte superiore che non lo è.

Come personalizzare questo modello in Trupeer

Passo 1: Apri la sezione Modelli

Vai alla sezione Modelli dalla navigazione principale.

Passo 2: Seleziona e apri un modello

Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.

Passo 3: Espandi la vista del modello

Se necessario, espandi la vista del modello per vedere chiaramente il layout completo e i dettagli.

Passo 4: Modifica il modello

Fai clic su Modifica per iniziare a modificare il modello selezionato.

All'interno dell'editor puoi:

• Aggiungere nuove sezioni

• Definire o aggiornare le regole di formattazione

• Aggiungere un logo e regolarne la posizione e le relative impostazioni

Passo 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo.

Passo 6: Visualizza l'anteprima e perfeziona il modello

Quando vuoi vedere come appare il tuo modello personalizzato, apri l'Anteprima.

Dalla schermata di anteprima, puoi continuare ad apportare modifiche direttamente, se necessario, assicurandoti che il modello appaia esattamente come desideri.

Con un modello di piano di gestione del progetto puoi:

• Risparmiare ore di pianificazione: Evita la pagina bianca con una struttura di PM completa.

• Coprire ogni area di conoscenza: Sezioni integrate per ambito, pianificazione, costi, qualità e rischi.

• Rimanere in linea con il brand: Applica il tuo logo, font e colori utilizzando il brand kit di Trupeer.

• Allineare gli stakeholder: Converti piani densi in video sintesi che tutti possono comprendere rapidamente.

• Standardizzare tra i progetti: Utilizza lo stesso modello per ogni iniziativa.

• Raggiungere team globali: Traduci i piani in oltre 65 lingue con un solo clic.

Perché la maggior parte del documento si adatterebbe a qualsiasi progetto

Il contenuto generico non è presente per pigrizia. C'è perché il modello lo richiede e perché la governance si aspetta che ogni area sussidiaria venga affrontata.

Quindi la sezione sulla gestione dell'ambito dice che le modifiche all'ambito saranno sollevate come richieste di modifica, valutate per l'impatto e approvate dal comitato di controllo delle modifiche. Il che è vero, ed è il modo in care funziona ogni progetto in quell'organizzazione, e non dice nulla al lettore su questo progetto specifico.

La sezione sulla gestione della qualità descrive l'approccio standard di revisione e test. La sezione sulla gestione delle comunicazioni dice che gli stakeholder riceveranno un rapporto settimanale. La sezione sul controllo delle modifiche ribadisce il processo di controllo delle modifiche. Tutto accurato, tutto identico all'ultimo piano, tutto a scapito dell'attenzione del lettore.

Nel frattempo, il contenuto autenticamente specifico del progetto, che è ciò per cui un piano esiste, si trova disperso al suo interno. Una restrizione di accesso al sito. Un fornitore in regime di monopolio. Una finestra temporale che non può essere spostata. Uno stakeholder che deve approvare personalmente. Ognuno di questi elementi è una frase o due, ed è sepolto all'interno del testo.

La soluzione non è scrivere di meno. È spostare il materiale generico in un posto dove possa essere scritto una sola volta.

Come separare la metodologia dal piano

Due documenti invece di uno.

Un documento metodologico permanente. Come la tua organizzazione gestisce i progetti. Controllo delle modifiche, passaggi di qualità, cadenza dei report, percorsi di escalation, standard dei documenti, ruoli e relative responsabilità. Scritto una volta, di proprietà del project office, referenziato da ogni piano, aggiornato quando cambia il metodo anziché quando inizia un progetto.

Un piano di gestione del progetto. Solo ciò che è specifico per questo progetto. Ogni sezione pone una sola domanda: cosa c'è di diverso qui?

La regola che mantiene onesta la divisione è semplice da applicare. Qualsiasi frase che potrebbe apparire immutata nel piano di un altro progetto viene eliminata e sostituita con un riferimento alla metodologia.

Applicando questa regola a un piano esistente di sessanta pagine in genere ne rimangono da otto a dodici. Quelle pagine sono il piano. E sono anche, per la prima volta, degne di essere lette.

Sorgono due obiezioni ed entrambe hanno risposta. I revisori e i clienti a volte richiedono l'insieme completo dei contenuti sussidiari, nel qual caso il documento metodologico lo soddisfa e il piano vi fa riferimento, il che è generalmente accettato dai revisori perché la tracciabilità è più chiara. E le persone temono che il piano sembri scarno, il che è vero, fino a quando qualcuno non deve effettivamente usarlo.

Modello di piano di gestione del progetto gratuito: le sezioni da copiare

Copia da qui. Otto sezioni, da otto a dodici pagine, ognuna delle quali risponde a cosa c'è di diverso in questo progetto.

Intestazione. Progetto, sponsor, project manager, budget, date, versione del documento metodologico in base al quale opera questo piano.

Obiettivi e criteri di successo. Cosa deve raggiungere questo progetto, sotto forma di misure piuttosto che di deliverable, presi dalla scheda di progetto anziché reinventati.

Ambito e confini. Cosa è incluso, cosa è escluso e specificamente cosa è escluso che le persone hanno richiesto. Fai riferimento al processo di modifica anziché descriverlo.

Vincoli inderogabili. Date, finestre temporali, blocchi, scadenze normative, periodi di possesso o accesso, date di preavviso contrattuale. Tutto ciò che il progetto non può spostare, con il relativo responsabile. Il nostro modello di piano di progetto IT copre come strutturare correttamente questa parte, ed è la sezione che più vale la pena estrarre in una singola pagina.

Risorse e capacità. Chi è impegnato, per quanto del suo tempo, e cosa non sta facendo invece. Indica i nomi delle persone dalla cui disponibilità dipende effettivamente il piano.

Approccio agli approvvigionamenti. Cosa viene acquistato, su quale base, con i tempi di consegna. Il nostro modello di piano di gestione degli approvvigionamenti copre questo aspetto come piano sussidiario laddove il progetto lo richieda.

Rischi specifici del progetto. Solo i rischi particolari di questo progetto, ciascuno con un evento attivatore e un responsabile. I rischi generici appartengono all'elenco dei rischi permanente della metodologia.

Deviazioni dalla metodologia. Dove questo progetto farà qualcosa diversamente rispetto all'approccio standard, e perché è stato concordato. Questa sezione è breve, ed è quella che i revisori leggono per prima.

Copia fino a qui. I piani sussidiari vengono allegati laddove la scala del progetto lo giustifichi, e referenziati dove non lo fa.

L'ingegnere ferroviario la cui finestra di possesso si trovava a pagina 41

Kelvedon Rail è un'azienda di ingegneria infrastrutturale di circa milleseicento persone, che gestisce circa trentaquattro progetti all'anno sopra la soglia delle duecentocinquantamila sterline, ognuno dei quali richiedeva un piano di gestione del progetto.

Il modello prevedeva undici piani sussidiari e le versioni completate avevano una media di sessantotto pagine.

Qualcuno ha eseguito il test dell'evidenziatore su dodici di essi. Contenuto evidenziato mediano: diciannove percento.

Le sezioni relative ad ambito, qualità, comunicazioni e controllo delle modifiche erano quasi identiche in tutti e dodici i casi, e in nove casi parola per parola, perché ogni autore era partito dal piano precedente. Due dei dodici contenevano ancora il nome di un altro progetto nel corpo del testo.

Il project office tracciava anche le aperture dei documenti. Tra quei dodici piani, il numero mediano di volte in cui qualcuno ha aperto il documento dopo l'approvazione è stato tre. Due non sono mai stati riaperti da nessuno.

La conseguenza è emersa su un progetto. Una finestra di possesso dei binari, una data realmente improrogabile concordata con mesi di anticipo con il proprietario dell'infrastruttura, era registrata a pagina quarantuno del piano e in nessun altro posto. Il team di consegna ha pianificato i lavori per una settimana in cui l'accesso non era disponibile. Sono state perse tre settimane, a un costo stimato di centottantaseimila sterline.

L'informazione era stata documentata. Era stata approvata. Si trovava all'interno di sessantotto pagine, quattro quinti delle quali descrivevano come Kelvedon gestisce i progetti in generale.

La ristrutturazione ha prodotto due documenti. Un documento metodologico di circa quaranta pagine, scritto una volta e di proprietà del project office. E un modello di piano di gestione del progetto di otto sezioni, con un target di otto-dodici pagine, dove ogni sezione chiede solo cosa c'è di diverso in questo progetto.

Nei successivi ventuno progetti, la lunghezza mediana del piano è stata di undici pagine e le aperture mediane dopo l'approvazione sono state quattordici. Il test dell'evidenziatore su otto di essi ha restituito una mediana dell'ottantuno percento di contenuti specifici del progetto.

I vincoli inderogabili ora si trovano anche in un allegato di una sola pagina, estratto dal piano e diffuso separatamente, perché la lezione appresa dalla finestra di possesso è stata che le date importanti non dovrebbero essere reperibili solo leggendo l'intero documento.

I piani sussidiari e di quali hai effettivamente bisogno

La verità è che la maggior parte dei progetti ha bisogno di due o tre di questi come documenti separati e fa riferimento agli altri. Produrli tutti e dieci solo perché il modello ne elenca dieci è ciò che genera un piano di sessanta pagine che nessuno apre mai.

Come creare un piano di gestione del progetto, passo dopo passo

Parti dalla scheda di progetto, in modo che il piano risponda a un problema concordato invece di riformulare un approccio.

Scrivi prima i vincoli inderogabili. Essi determinano ciò che è possibile e sono la sezione che più probabilmente cambierà il resto.

Compila ogni sezione rimanente rispondendo solo a cosa c'è di diverso qui. Se la risposta onesta è nulla, scrivi il riferimento e vai avanti.

Indica i nomi delle persone ovunque il piano dipenda dalla disponibilità di un individuo e verifica con loro.

Decidi quali piani sussidiari richiedono documenti separati utilizzando la tabella sopra e fai riferimento agli altri.

Scrivi la sezione delle deviazioni per ultima, una volta che sai dove questo progetto si discosta dall'approccio standard.

Quindi applica il test dell'evidenziatore alla tua bozza prima di farla circolare. Qualsiasi cosa non evidenziata è candidata all'eliminazione.

Le fasi chiave che un piano di gestione del progetto deve coprire

Il piano dovrebbe dire qualcosa di specifico sul progetto per ciascuna fase, e per la maggior parte dei progetti quel qualcosa è breve.

Avvio. Cosa ha autorizzato questo progetto e rispetto a quali criteri di successo.

Pianificazione. I vincoli, le risorse e le decisioni sull'approccio. È qui che si trova la maggior parte del contenuto del piano.

Esecuzione. Cosa c'è di diverso nel modo in cui questo progetto verrà consegnato, inclusa qualsiasi deviazione dal metodo standard.

Monitoraggio e controllo. Cosa verrà osservato di insolito per questo progetto, piuttosto che la cadenza di reportistica standard.

Chiusura e consegna. Chi riceve l'output e di cosa ha bisogno per accettarlo, aspetto coperto dal nostro modello di checklist per la consegna del progetto, ed è opportuno concordarlo in fase di pianificazione piuttosto che alla chiusura.

La fase in cui i piani sono più deboli è l'ultima, perché è la più lontana nel tempo quando si scrive il piano. Indicare il team ricevente e i relativi criteri di accettazione in fase di pianificazione è la cosa di maggior valore che la sezione di chiusura possa contenere.

Metodologie di gestione dei progetti comuni e cosa cambia

La forma del piano cambia con il metodo e il test dell'evidenziatore si applica a tutti.

Waterfall o Stage-Gate. L'insieme sussidiario completo è convenzionale in questo caso e la disciplina di separare la metodologia dal piano è fondamentale, poiché i modelli sono più pesanti.

Agile. Gran parte di ciò che un piano tradizionale documenta vive invece nel modo di lavorare. Il piano ha comunque bisogno dei vincoli inderogabili, dell'impegno delle risorse, dell'approccio agli approvvigionamenti e delle deviazioni. Ciò di cui non ha bisogno è un piano di gestione dell'ambito per un ambito che è deliberatamente emergente.

PRINCE2. La Documentazione di Inizio Progetto (PID) svolge questo ruolo e la sua struttura è prescritta. La separazione della metodologia si applica comunque, poiché PRINCE2 prevede esplicitamente l'adattamento (tailoring) e l'adattamento è ciò che un lettore ha bisogno di vedere.

Ibrido. La realtà più comune, e quella in cui la sezione delle deviazioni merita il suo spazio, perché un progetto ibrido si discosta per definizione da un metodo standard in modi specifici che devono essere registrati.

Qualunque sia il metodo applicato, il compito del piano è lo stesso: registrare ciò che è particolare di questo progetto. Il metodo determina dove risiede il materiale generico, non se appartiene o meno al piano.

Semplice o completo: quanto dovrebbe essere lungo il piano?

Entrambi gli estremi compaiono nelle ricerche degli utenti, il che suggerisce che la questione è realmente irrisolta: alcuni vogliono un modello semplice di una pagina, altri vogliono un documento di piano completo.

La soluzione è che vogliono due metà diverse della stessa cosa. Un modello di progetto semplice è di solito la pianificazione e l'elenco delle attività, che è un artefatto operativo. Un piano di gestione del progetto completo è il documento di governance. Entrambi sono legittimi e nessuno dei due sostituisce l'altro.

Per il piano nello specifico: da otto a dodici pagine per un progetto consistente, due o tre per uno piccolo, più i piani sussidiari che giustificano realmente documenti separati. Se la tua governance richiede di più, produci il documento metodologico e fai riferimento ad esso, soddisfacendo così il requisito senza produrre un documento che nessuno leggerà.

Il numero che vale la pena monitorare non è quello delle pagine. È quello delle aperture dopo l'approvazione, che la maggior parte dei sistemi di gestione documentale ti dirà e che quasi nessuno guarda.

Piano di gestione del progetto o piano di progetto?

I termini sono usati in modo intercambiabile, ma vale la pena mantenere la distinzione.

Un piano di gestione del progetto descrive come il progetto sarà gestito: l'approccio, i vincoli, la governance, i piani sussidiari. È un documento di governance, approvato una volta e revisionato in caso di modifiche.

Un piano di progetto, nell'uso comune, indica solitamente la pianificazione (schedule): attività, dipendenze, durate e responsabili. È un artefatto operativo, aggiornato settimanalmente.

Confonderli produce due fallimenti noti. Un documento di governance con un diagramma di Gantt all'interno, che risulta obsoleto nel giro di due settimane. Oppure una pianificazione presentata come piano, che non contiene vincoli, nessun impegno sulle risorse e nessun criterio di accettazione.

Tienili separati e lascia che ognuno venga aggiornato secondo il proprio ciclo. Il nostro modello di piano di progetto IT copre la parte di pianificazione, incluso il calendario dei vincoli, e il nostro modello di documentazione di progetto copre quali dei documenti risultanti vale la pena conservare dopo la chiusura.

Posso avere un modello di piano di gestione del progetto in Excel?

Excel va bene per gli artefatti che sono tabelle e vengono aggiornati: la pianificazione, l'impegno delle risorse per persona, il registro dei rischi, l'elenco dei vincoli con responsabili e date, e l'elenco dei pacchetti di acquisto con i tempi di consegna.

Word o Google Docs per il piano vero e proprio, che è un testo in prosa che descrive le decisioni e viene approvato anziché tracciato.

PDF per la versione approvata, esportata e datata. Poiché il piano è ciò che le persone citano in caso di controversie, una versione approvata e congelata è fondamentale.

La maggior parte delle organizzazioni finisce per avere il piano in un documento e quattro o cinque fogli di calcolo collegati, il che è la disposizione corretta. Ciò che non funziona è uno dei due estremi: un piano interamente in un foglio di calcolo perde le decisioni, e un piano interamente in un documento fa sì che le tabelle diventino obsolete.

Come mantenere visibile il contenuto specifico del progetto nel piano

La lezione dell'esempio pratico non riguarda in realtà la lunghezza. È che i contenuti specifici del progetto importanti diventano invisibili quando sono circondati da materiale generico, e nessuna quantità di buona scrittura può rimediare a questo.

Due abitudini aiutano. Estrai i vincoli inderogabili su una singola pagina e falla circolare separatamente, perché questi sono gli elementi in cui una svista è più costosa. E mantieni il documento metodologico realmente aggiornato, poiché nel momento in cui diventa obsoleto le persone ricominceranno a riformularlo nei piani.

Trupeer AI è utile per questo secondo aspetto. Il documento metodologico descrive i processi, e i processi cambiano: un nuovo strumento di controllo delle modifiche, un diverso percorso di reportistica, un flusso di approvazione rivisto. Registrare il processo una sola volta produce una procedura scritta con i passaggi e le schermate già catturati, così la metodologia può essere mantenuta accurata a basso costo, evitando che vada alla deriva fino a quando nessuno si fida più di essa.

Registralo. Personalizzalo con il tuo brand. Traducilo. Usa Trupeer.

Questo è importante perché l'intera separazione dipende dal fatto che la metodologia sia affidabile. Un piano che fa riferimento a una metodologia che nessuno ritiene aggiornata ricomincerà a riformularla nel giro di due progetti. Il creatore di SOP copre quelle procedure, che risiedono nella tua base di conoscenza con un branding coerente. Le istruzioni di configurazione si trovano nella guida alla configurazione del modello di documento.

Domande frequenti

Esiste un modello di piano di gestione del progetto gratuito in Excel?

Excel si adatta alle tabelle da cui dipende il piano: pianificazione, impegno delle risorse, registro dei rischi, vincoli con responsabili, tempi di consegna degli acquisti. Non c'è alcun download protetto da paywall né moduli da compilare. Mantieni il piano vero e proprio come documento e collega i fogli, poiché i due vengono aggiornati con cicli diversi.

Esiste un modello di piano di gestione del progetto gratuito in Word?

La struttura in otto sezioni sopra descritta si incolla direttamente in Word o Google Docs. Applica il test dell'evidenziatore alla tua prima bozza prima di farla circolare, poiché questo esercizio di solito rimuove più di quanto aggiunga e produce la versione che le persone apriranno effettivamente.

Esiste un modello di piano di gestione del progetto gratuito in PDF?

Esporta il piano approvato e mantieni modificabile la versione di lavoro. Il piano è il documento citato quando l'ambito o l'approccio sono contestati, quindi vale la pena avere una versione congelata e datata accanto a quella attiva.

Dove posso trovare un piano di gestione del progetto completo in PDF?

Esempi pubblicati con il set sussidiario completo sono facili da trovare, anche da parte di enti pubblici e università, e sono utili per vedere la struttura convenzionale. Leggine uno ed esegui il test dell'evidenziatore: la maggior parte degli esempi pubblicati è sostanzialmente una riformulazione della metodologia, che è esattamente il motivo per cui sono sicuri da pubblicare.

Esiste un modello di progetto semplice in Excel?

Sì, e di solito si tratta della pianificazione e dell'elenco delle attività piuttosto che del piano di gestione. Vale la pena averli entrambi. La pianificazione traccia il lavoro; il piano registra i vincoli, le risorse e le decisioni sull'approccio. Scegliere il modello semplice quando si ha bisogno del piano è il motivo per cui i progetti finiscono senza alcuna registrazione di ciò che è stato concordato.

Ho bisogno di un software di pianificazione dei progetti?

Non per scrivere il piano, che è un documento. Il software merita il suo spazio per la pianificazione una volta superate indicativamente le trenta attività attive con dipendenze mutevoli e più di una manciata di persone che aggiornano lo stato. Al di sotto di questa soglia, un foglio di calcolo è più veloce e tutti ne hanno già uno.

Chi dovrebbe scrivere il piano di gestione del progetto?

Il project manager, con l'approvazione dello sponsor e il project office che conferma quali piani sussidiari sono richiesti. Laddove un piano sussidiario copra il lavoro di un'altra funzione, come gli acquisti, dovrebbe essere quella funzione a scriverlo anziché lasciare che il project manager indovini i tempi di consegna.

Ogni quanto dovrebbe essere aggiornato il piano di gestione del progetto?

In caso di modifiche piuttosto che su base periodica. Quando si sposta un vincolo, quando cambiano le risorse, quando l'approccio si discosta da quanto approvato o quando cambia l'ambito. La pianificazione si aggiorna settimanalmente mentre il piano no, che è il motivo pratico per cui vengono tenuti come documenti separati.