Guida pubblicata a settembre 2026. Le buone pratiche di Microsoft Project raccontate dal loro sintomo: diciannove cose che si vedono in un piano e che dicono se quel piano reggerà. Per ognuna: che cosa stai guardando, perché succede, come si evita se il piano è tuo e come lo scopri in trenta secondi se il piano te lo hanno mandato. Vale per tutte le versioni desktop, da Project 2010 a Project 2024 e Microsoft 365.
Un piano di progetto può avere date plausibili, colori ordinati, una struttura che fa una bella figura in riunione — e non reggere al primo imprevisto. Non perché chi l’ha costruito sia incapace, ma perché in Microsoft Project le decisioni sbagliate non producono errori: producono un piano che sembra funzionare. Nessun messaggio, nessun avviso, nessuna riga rossa. Il conto arriva mesi dopo, quando qualcosa slitta e il piano non reagisce.
Questa non è la solita lista di buone pratiche di Microsoft Project. Le liste dicono «non usare i vincoli», e nessuno le applica, perché un precetto senza meccanismo non convince nessuno. Qui si entra dalla parte opposta: dal sintomo. Si parte da qualcosa che si vede, si risale a che cosa lo ha prodotto, e solo alla fine arriva la regola — che a quel punto non serve nemmeno enunciarla.
In sintesi
- In Microsoft Project le date non si scrivono: si calcolano. Ogni data digitata a mano diventa un vincolo, e da quel punto il piano smette di reagire ai cambiamenti: diventa un disegno invece che un modello.
- Un piano si ispeziona in un ordine preciso, perché i controlli dipendono l’uno dall’altro: se le date sono scritte a mano non ha senso guardare il percorso critico, e se manca la previsione non ha senso guardare gli scostamenti.
- Le attività di riepilogo sono contenitori, non lavoro: non si collegano fra loro e non si assegnano risorse. Chi lo fa raddoppia il budget senza che una sola riga sembri sbagliata.
- Senza previsione salvata e senza data di stato esplicita un piano non è misurabile: qualunque numero di avanzamento è un’opinione.
- Chi riceve un piano ha bisogno di controlli diversi da chi lo costruisce: per ogni sintomo, qui sotto, c’è il gesto che lo rivela in trenta secondi.
Parte 0 · L’ordine in cui si guarda un piano
La domanda che mi fanno più spesso non è «quali sono le buone pratiche»: è «da dove comincio a guardare?». E la risposta conta più dell’elenco, perché i controlli non sono indipendenti. Ognuno ha senso solo se quelli prima hanno dato esito accettabile: guardare il percorso critico di un piano pieno di vincoli è tempo perso, e non perché il percorso critico non sia importante — perché quello che leggi non è il percorso critico del progetto, è il disegno dei vincoli che qualcuno ha messo.
Questa è la catena, in ordine. I primi tre controlli dicono se puoi fidarti del piano; dal quarto in poi dicono quanto vale.
- È un piano o è un elenco? Struttura, livelli, traguardi. Se manca l’ossatura, tutto il resto non ha dove appoggiarsi.
- Le date sono calcolate o scritte a mano? È il controllo che vale gli altri messi insieme, e condiziona i due successivi.
- La rete regge? Legami, attività appese, legami sui riepiloghi. Una rete rotta produce un piano che non propaga i ritardi.
- Il percorso critico dice la verità? Ha senso solo dopo il 2 e il 3.
- Chi lavora, e quando? Risorse, carichi, calendario. Qui si scopre se le date sono realizzabili da persone vere.
- C’è una previsione salvata? Senza, il piano non si potrà mai misurare.
- Il piano è in esercizio o è fermo? Data di stato e dati effettivi: dicono se quello che hai davanti descrive oggi o descrive il giorno in cui è nato.
Dieci minuti bastano per i primi tre. Mezz’ora per tutti e sette, su un piano di qualche centinaio di attività. Se hai fretta e devi sceglierne uno solo, scegli il secondo. Il percorso operativo dettagliato, con i comandi, è nell’articolo su come analizzare velocemente un piano ricevuto.

Parte A · La struttura
1 · Il riepilogo di progetto è stato creato a mano
In cima al piano c’è una riga che si chiama come il progetto e contiene tutto il resto. L’ha scritta qualcuno. Non serviva: Project ne ha già una, la riga con identificativo 0, che si fa comparire con una casella di spunta e che riepiloga da sola durata, lavoro e costo dell’intero progetto — sempre aggiornata, senza manutenzione.
Una riga fatta a mano invece è un’attività di riepilogo come le altre: si può spostare, si può collegare, e soprattutto qualcuno può assegnarci sopra delle risorse. Diventa un contenitore che finge di essere il progetto.
Se il piano è tuo — attiva la riga 0 e togli quella scritta a mano. È la stessa riga in cui conviene annotare, nelle note, le informazioni che devono viaggiare con il file.
Se il piano te lo mandano — guarda se la prima riga ha identificativo 0 o 1. Se è 1 ed è in grassetto e contiene tutto, è stata costruita a mano: vale la pena controllare subito se ha delle risorse assegnate, perché è lì che il budget si gonfia di più.
2 · I nomi delle attività non cominciano con un verbo
«Impianto elettrico». «Documentazione». «Fornitore Rossi». Sono nomi di cose, non di lavori, e in un piano generano una domanda a cui nessuno sa rispondere: che cosa bisogna fare? Un’attività dovrebbe dire un’azione — Posare i cavidotti, Redigere il manuale — e i traguardi, che sono verifiche, dovrebbero dirlo al participio: Collaudo superato, Progetto approvato.
Il sintomo gemello, più moderno e più frequente, è l’informazione infilata nel titolo: «Posa cavidotti [BLOCCATA – sentire Bianchi]». Tutto quello che sta nel nome è testo, e sul testo non puoi filtrare, raggruppare né fare totali.
Se il piano è tuo — una convenzione decisa all’inizio e scritta da qualche parte vale più di qualsiasi correzione fatta dopo: verbo all’infinito per le attività, participio passato per i traguardi, stati e responsabili in colonne dedicate.
Se il piano te lo mandano — ordina per nome attività e scorri: i sostantivi puri e le parentesi quadre saltano fuori subito. Se sono tanti, aspettati che le informazioni di stato del progetto non stiano da nessuna parte se non nella testa di chi lo ha scritto.
3 · La struttura di scomposizione non regge
Quattrocento righe allo stesso livello, oppure fasi che contengono una sola attività, oppure un ramo scomposto in cinque livelli accanto a una riga sola che dice «Messa in esercizio, 40 giorni». Sono tutti segni della stessa cosa: il piano è stato scritto come elenco e organizzato dopo, invece che scomposto prima.
Il costo non è estetico. Senza riepiloghi veri non esistono totali intermedi: non puoi dire quanto vale una fase, né a che punto è, né mostrarne una sola in riunione.
Se il piano è tuo — tre o quattro livelli, almeno due figli per contenitore, attività da uno a dieci giorni, un traguardo che chiude ogni fase. I sette passi della pianificazione cominciano da qui, e saltarli si paga per tutto il progetto.
Se il piano te lo mandano — chiudi tutto al primo livello di struttura. Quello che resta sullo schermo è l’idea che chi ha scritto il piano ha del progetto: se ci stai dentro con un’occhiata e lo riconosci, la struttura regge. I cinque segni di una WBS debole sono raccontati uno per uno in un articolo a parte.
Parte B · Il tempo
4 · Le date sono state scritte a mano
È il sintomo che vale tutti gli altri. In Microsoft Project le date non si scrivono: si calcolano. Tu dai le durate e i legami, il motore dice quando le cose accadono. Quando qualcuno digita una data di inizio, Project non protesta — fa l’unica cosa che può fare: piazza un vincolo, del tipo «non iniziare prima del», e da quel momento quell’attività è inchiodata al calendario.
Il risultato è identico a un piano sano finché non succede niente. Alla prima variazione la differenza è totale: il piano con i legami si riorganizza e ti mostra la nuova data di fine, il piano con i vincoli resta fermo e continua a mostrarti date che non succederanno. Hai un disegno, non un modello. E i vincoli fanno danno anche al calcolo: spezzano il percorso critico perché creano scadenze locali rispetto a cui il margine viene ricalcolato.
Esiste il caso in cui il vincolo è giusto: la data contrattuale, la consegna imposta, la finestra di fermo impianto. Un vincolo messo apposta, sapendo perché, è uno strumento. In un piano in salute se ne contano sulle dita di una mano.
Se il piano è tuo — durate e legami, mai date. Quando ti serve segnare una scadenza senza vincolare il calcolo, esiste la scadenza, che avvisa e non inchioda. È il cuore di quella che si chiama schedulazione dinamica.
Se il piano te lo mandano — inserisci la colonna Tipo di vincolo e ordina. Il valore sano è «il più presto possibile»; i valori che devono far drizzare le antenne sono «deve iniziare il» e «deve finire il». Se più di un’attività su dieci ha un vincolo rigido, quel piano non è schedulato: è disegnato.
5 · Le attività sono a pianificazione manuale
È il modo moderno di scrivere le date a mano, e si vede meno del vincolo perché non lascia un’icona nella colonna degli indicatori. Un’attività a pianificazione manuale sta dove l’hai messa: non si sposta quando cambia il suo predecessore, non partecipa al ricalcolo come le altre. In un piano di cento attività dove venti sono manuali, il motore lavora su ottanta e le altre venti sono decorazione.
La funzione esiste per una buona ragione: all’inizio, quando di un’attività sai solo che «dura più o meno tre settimane, verso maggio», la pianificazione manuale ti lascia scrivere anche un testo al posto della data. È un appunto, e come tutti gli appunti va convertito prima di consegnare il piano.
Se il piano è tuo — usala nella fase di abbozzo e passa tutto ad automatico prima di salvare la previsione. Occhio anche all’impostazione predefinita dei nuovi progetti, che in alcune installazioni è manuale.
Se il piano te lo mandano — inserisci la colonna Modalità attività: dice per ogni riga se è automatica o manuale. Se ne trovi molte, i primi tre controlli della Parte 0 vanno rifatti pensando che quella parte di piano non è calcolata.
6 · Mancano le durate, o sono tutte uguali
Il punto interrogativo accanto a una durata significa stimata: è il valore che Project mette da solo quando crei un’attività, «1 giorno?», e che nessuno ha ancora sostituito. Un piano che ne ha molti non è stato stimato: è stato elencato.
La variante peggiore è il piano dove tutte le durate sono identiche — cinque giorni ovunque, o dieci — che è il modo elegante di dire che nessuno ha guardato una per una. E c’è il caso opposto, il blocco da sessanta giorni: un’attività così lunga non si può seguire, e per due mesi ogni risposta sul suo avanzamento sarà una percentuale inventata.
Se il piano è tuo — prima di considerare chiusa la pianificazione, filtra le attività a durata stimata e svuota la lista. Sulle tecniche di stima c’è una guida a parte; qui basta la regola di forma: una stima deve poter essere spiegata a voce in una frase.
Se il piano te lo mandano — conta i punti interrogativi e guarda la distribuzione delle durate. Se sono tutte uguali o tutte tonde, la domanda da fare è una sola: «su che cosa sono basate?».
7 · I legami stanno sulle attività di riepilogo
Collegare due fasi fra loro sembra la cosa più naturale del mondo: è quello che si fa su una lavagna. In Project è una scorciatoia che rende il piano opaco, perché la fase è un contenitore: dire che la fase B segue la fase A non dice quale attività di B aspetta quale attività di A. Il ritardo si propaga in blocco, il percorso critico attraversa contenitori invece di lavoro vero, e quando qualcosa slitta non si capisce che cosa abbia spinto che cosa.
Peggio: si creano facilmente dipendenze circolari fra un riepilogo e le sue figlie, che Project rifiuta con messaggi che sembrano incomprensibili.
Se il piano è tuo — i legami si mettono fra attività di dettaglio. Il modo pulito di legare due fasi è collegare il traguardo di fine fase alla prima attività della fase successiva: è leggibile, ed è anche un punto di verifica.
Se il piano te lo mandano — metti in tabella la colonna Predecessori e guarda solo le righe in grassetto. Se ne hanno, il piano è legato per blocchi.
8 · Ci sono attività appese
Un piano è una rete: ogni attività dovrebbe sapere da che cosa dipende e che cosa fa partire. Nella pratica se ne trovano sempre di scollegate, in due varietà.
- Senza predecessori: sono libere di cominciare il primo giorno del progetto, e quasi mai è vero. A parte la prima attività reale, ognuna è una domanda da fare.
- Senza successori: più insidiose, perché non fanno rumore. Finiscono e non fanno partire niente: ritardarle non ha conseguenze sul piano, il che è quasi sempre falso nella realtà. A parte l’ultima, ognuna è un pezzo di catena mancante.
È il primo punto di tutte le checklist di qualità della schedulazione, e con ragione: una rete aperta non propaga i ritardi, quindi il piano resta ottimista anche quando il progetto non lo è.
Se il piano è tuo — prima di consegnare, metti in tabella predecessori e successori e ordina per ciascuna: la lista delle appese si legge in un minuto.
Se il piano te lo mandano — stesso gesto, e conta. Poche unità su un piano grande sono fisiologiche; decine dicono che la rete non è stata costruita, ma disegnata a pezzi.
9 · Il percorso critico non è mai stato guardato
Il percorso critico è la catena di attività che decide la data di fine: un giorno di ritardo lì è un giorno di ritardo del progetto. Tutte le altre attività hanno un margine, e sapere quanto vale quel margine è la differenza fra governare un progetto e subirlo.
Quando lo attivi, le patologie sono due e sono opposte. Quasi tutto è critico: il piano non ha margine da nessuna parte, e qualunque cosa vada storta sposta la data finale. Non è critico quasi niente, o la catena è spezzata in tronconi: è il caso più comune, ed è la conseguenza diretta dei vincoli. Se le date sono inchiodate, Project non ha niente da propagare e il percorso critico diventa una decorazione.
Se il piano è tuo — guardalo a ogni aggiornamento, non solo in pianificazione: il margine si consuma e la catena si sposta da sola su un altro ramo.
Se il piano te lo mandano — più del sì/no, metti in tabella il margine di flessibilità totale: dice quanti giorni di respiro ha ogni attività. Un margine negativo significa che il piano è già in ritardo rispetto a sé stesso, e quasi sempre nessuno se n’era accorto.
Parte C · Le risorse
10 · Le risorse sono assegnate alle fasi
Le attività di riepilogo sono contenitori: Project somma verso l’alto costi e ore delle attività che contengono. Quando qualcuno assegna una risorsa alla riga della fase, quel costo non sostituisce la somma delle figlie: ci si aggiunge, calcolato sulla durata dell’intero contenitore.
Il conto è brutale. Una fase di tre attività in sequenza da dieci giorni, con la stessa persona assegnata a tutte e tre, vale 240 ore. Assegnando quella persona anche alla riga della fase — che dura trenta giorni — Project aggiunge altre 240 ore. Il budget raddoppia, e non c’è una sola riga che sembri sbagliata: sono le tre attività a dire il vero, è la somma a mentire. In più la persona risulta al 200% per tutta la fase, e a quel punto il livellamento delle risorse diventa inutilizzabile.
Se il piano è tuo — le risorse si assegnano solo dove si lavora, cioè sulle attività di dettaglio. Se quello che volevi dire è «di questa fase risponde Bianchi», il posto è un campo personalizzato rinominato; se era «questo costo dura quanto la fase», il posto è un’attività dedicata. Qui il meccanismo per esteso, con i numeri e le tre alternative corrette.
Se il piano te lo mandano — metti in tabella Nomi risorse e guarda solo le righe in grassetto. Se una di loro ha un nome, il totale di quel piano non è un totale.
11 · Le risorse non hanno un nome, o non hanno ore
Apri il foglio delle risorse e trovi «Sviluppatore 1», «Risorsa A», «Team elettrico». Un piano di risorse generiche non è stato negoziato con nessuno: nessuna persona reale ha detto sì a quelle date. Va benissimo in fase di stima — anzi, è corretto — e diventa un problema nel momento in cui quel piano viene approvato come impegno.
Il difetto parallelo è il piano con le durate ma senza il lavoro. Durata è quanto dura un’attività; lavoro è quante ore costa. Un’attività di dieci giorni può valere ottanta ore o otto: senza il lavoro il piano non può dire se il carico è sostenibile, e non può produrre nessuna curva di impegno.
Se il piano è tuo — le risorse generiche si tengono finché si stima e si sostituiscono con le persone prima di impegnarsi. Se i nomi non li puoi mettere per ragioni organizzative, esiste il modo di segnare ruoli e responsabilità senza usare le risorse.
Se il piano te lo mandano — guarda il foglio risorse e la colonna del lavoro. Nomi generici e lavoro a zero, insieme, dicono che quel piano è una stima presentata come programma.
12 · La sovrallocazione non è mai stata verificata
Le date del piano funzionano solo se le persone che le devono rispettare sono libere di lavorarci. Nei piani costruiti in fretta succede regolarmente che la stessa persona sia impegnata a tempo pieno su tre attività parallele: il piano è coerente, la realtà no.
Project lo segnala — l’omino rosso nella colonna degli indicatori, i numeri rossi nella vista di utilizzo — ma segnala anche i sovraccarichi da un’ora, per cui in molti piani l’avviso è così frequente da diventare invisibile. Il livellamento automatico esiste e ha un valore pratico limitato: sposta il lavoro allungando il progetto, senza sapere quali attività contano davvero. Alla fine serve sempre una decisione umana.
Se il piano è tuo — guarda i picchi, non gli avvisi: chi è oltre il 100% per più di qualche giorno di fila, e quando. Le soluzioni sono tre e vanno decise, non calcolate: spostare, aggiungere qualcuno, ridurre l’impegno su una delle due attività.
Se il piano te lo mandano — apri la vista di utilizzo delle risorse e cerca i numeri rossi. Se trovi persone al 200% per settimane intere, tutte le date che hai davanti raccontano una storia che non succederà. E se la sovrallocazione riguarda proprio i nomi che compaiono sulle attività critiche, la data di fine è già persa.
13 · Il calendario non conosce le feste
Ogni piano nasce con un calendario che prevede lunedì-venerdì, otto ore al giorno, tutto l’anno. Zero festività: niente Natale, niente 25 aprile, niente Ferragosto, e men che meno la chiusura aziendale di agosto che in tante aziende italiane vale due settimane piene.
La conseguenza è subdola perché non produce nessun errore visibile: ogni attività che attraversa giorni di chiusura si accorcia sulla carta, e su una catena l’ottimismo si somma. Un’attività di otto giorni a cavallo della chiusura di agosto finisce due settimane prima di quando finirà davvero — e meglio saperlo a giugno che scoprirlo a settembre.
Il secondo livello è quello delle persone: le ferie di uno, il part-time del venerdì, i turni. Quelle non stanno nel calendario di progetto ma nei calendari delle risorse, che hanno regole di precedenza proprie.
Se il piano è tuo — cinque minuti nelle eccezioni del calendario, una volta sola per progetto. Meglio ancora: un file vuoto con il calendario già compilato da usare come base per ogni nuovo piano, e lo stesso per chi pianifica insieme a te — calendari diversi producono date che non si possono confrontare.
Se il piano te lo mandano — apri il calendario del progetto e guarda se le eccezioni ci sono. Se la lista è vuota, tutte le date del piano sono ottimistiche di giorni o di settimane, e nessuno se ne accorgerà finché non sarà tardi. È il controllo più veloce e più redditizio di tutta questa guida.
Parte D · Il controllo
14 · Non c’è una previsione salvata
La previsione — la baseline — è la fotografia del piano al momento dell’impegno: date, durate, lavoro e costi congelati. Serve a una cosa sola, e non ce n’è un’altra che la faccia: dare un termine di confronto. Senza, fra un mese, quando le date saranno cambiate, non ci sarà modo di sapere di quanto sono cambiate.
Niente previsione significa niente scostamenti, niente valore realizzato, niente misura del ritardo: solo la sensazione che le cose stiano andando peggio. Ed è un controllo che dura cinque secondi: se le colonne dell’inizio e della fine previsti sono vuote, quel piano non è ancora un piano approvato, qualunque cosa dica la mail che te lo ha portato.
Se il piano è tuo — si salva una volta sola, quando il piano è approvato, e si risalva solo a fronte di una modifica approvata. Project ne conserva fino a undici: il giorno uno conviene salvarla due volte, così l’originale resta intoccabile mentre la copia di lavoro segue le ripianificazioni. Il perché è qui.
Se il piano te lo mandano — colonne Inizio previsto e Fine prevista. Vuote: il piano non è misurabile. Piene ma identiche alle date correnti su tutta la linea, con il progetto in corso: la previsione è stata risalvata di recente, e gli scostamenti che leggi misurano l’ultima decisione, non l’impegno iniziale.
15 · La data di stato non è impostata
La data di stato è la linea rispetto a cui Project decide che cosa è passato e che cosa è futuro. Non è «oggi»: è la data a cui si riferisce l’aggiornamento che stai guardando. Quando è vuota, Project usa la data odierna — e questo significa che i numeri cambiano ogni volta che apri il file, e che due persone che lo aprono in giorni diversi vedono scostamenti diversi.
Tutto il controllo di progetto poggia su questa data: gli indici di avanzamento, la linea nel diagramma, la riprogrammazione del lavoro rimasto. Sbagliarla, o non metterla, falsa tutto il resto in modo silenzioso.
Se il piano è tuo — si fissa prima di inserire qualsiasi dato di avanzamento, e si fa comparire la linea nel diagramma, così è visibile invece che nascosta in una finestra di dialogo.
Se il piano te lo mandano — è il primo dei controlli sull’esercizio del piano. Vuota o vecchia di mesi, sai già quanto valgono i numeri di avanzamento che ti hanno mostrato in riunione.
16 · La schedulazione non viene aggiornata
Un piano che non si aggiorna smette di essere uno strumento dopo due settimane. Aggiornare non significa cambiare le date: significa scrivere che cosa è successo — inizio effettivo, quanto è stato fatto, quanto lavoro rimane — e lasciare che il motore ricalcoli il resto, riprogrammando il lavoro non completato dopo la data di stato.
Esiste una variante peggiore del non aggiornare, ed è aggiornare spostando le barre: trascinare le attività in avanti finché il piano torna a somigliare alla realtà. Il risultato sembra aggiornato ed è vuoto: ogni data spostata a mano è un vincolo in più, e di quello che è successo davvero non resta traccia da nessuna parte.
Se il piano è tuo — il ciclo è di cinque tappe sempre uguali, i numeri li dà chi fa il lavoro, e quello che conta più della procedura è il ritmo: un piano aggiornato ogni due settimane con dati approssimativi vale infinitamente più di un piano aggiornato una volta con dati perfetti, perché è la serie che mostra la direzione.
Se il piano te lo mandano — la domanda non è «è aggiornato?», perché la risposta sarà sempre sì. È «a che data è aggiornato, e con quale procedura?». E la verifica sta nelle colonne delle date effettive: l’ultima data effettiva presente nel file è l’ultimo aggiornamento vero, molto più affidabile della data di modifica del file. Gli altri sei segni sono raccolti qui.
17 · Gli scostamenti non vengono letti
Ci sono piani aggiornati con diligenza i cui scostamenti non guarda nessuno. È la forma più frustrante del problema, perché il lavoro è stato fatto e il valore non viene raccolto: la tabella delle variazioni si applica in un clic e dice, riga per riga, di quanto ci si è spostati rispetto all’impegno.
E c’è il secondo passo, che quasi nessuno fa: la direzione. Un ritardo del dieci per cento che si sta allargando è un’emergenza; lo stesso dieci per cento che si sta riassorbendo è un problema che si risolve da sé. Stesso numero, due decisioni opposte — e la differenza la dice solo il confronto fra rilevazioni successive. Sui numeri che misurano tutto questo in modo formale c’è la guida all’earned value, con il suo completamento sul lato tempi.
Se il piano è tuo — leggi le variazioni subito dopo l’aggiornamento, e comunica anche quando la notizia è brutta: un ritardo detto presto è un problema di progetto, detto tardi è un problema di fiducia.
Se il piano te lo mandano — applica la tabella delle variazioni e ordina per variazione di fine, decrescente. In dieci secondi hai le dieci attività che stanno facendo scivolare il progetto, che sono le uniche di cui vale la pena parlare in riunione.
Parte E · Quando il piano esce dal tuo computer
18 · Il file esce così com’è
Un piano di Microsoft Project contiene molto più di quello che si vede: le tariffe orarie delle persone, i nomi per esteso, le note scritte durante le riunioni, i collegamenti ai documenti interni, i campi personalizzati con le annotazioni di chi lo ha costruito, e la storia delle previsioni salvate — cioè il racconto di tutte le volte che avete ripianificato.
Niente di tutto questo è visibile nella vista che stai guardando, e tutto viaggia con il file quando lo alleghi a una mail. Quando il destinatario è fuori dall’azienda la cosa ha anche un risvolto normativo, perché fra quei dati ce ne sono di personali.
Se il piano è tuo — fuori non esce l’originale: esce una copia ripulita. A mano è una procedura di quattro passaggi, ed è proprio la noia di rifarla ogni volta che mi ha portato a scrivere GanttShield, che fa la stessa pulizia in un clic su una copia, senza toccare il file di partenza.
Se il piano te lo mandano — vale il rovescio, ed è un vantaggio da usare con misura: nel file che hai ricevuto ci sono tariffe, note e previsioni che raccontano la storia del progetto. Prima di usarle in una trattativa, vale la pena chiedersi se chi te lo ha mandato sapeva di avertele date.
19 · Chi lo riceve non ha Microsoft Project
Il committente, il capo, il fornitore: quasi nessuno di loro ha una licenza, e hanno ragione — la licenza serve a chi il piano lo costruisce. Ogni strada per far uscire il piano dal file perde qualcosa, e la scelta dipende da una domanda sola: chi lo riceve deve leggere, lavorarci o decidere?
Il PDF conserva l’aspetto e perde il calcolo; l’esportazione in foglio elettronico conserva i dati e perde il motore; un’immagine della linea del tempo perde tutto tranne il messaggio, che per chi deve decidere è esattamente quello che serve. Il regalo peggiore che puoi fare a un committente è un PDF di quaranta pagine con trecento righe.
Se il piano è tuo — prepara una volta sola le due uscite che userai per tutto il progetto, una vista da stampa e una riga del tempo, e salvale. Le cinque strade, con quello che ciascuna perde, sono messe a confronto qui.
Se il piano te lo mandano — se ti arriva un PDF e lo devi verificare, chiedi il file: da un PDF non puoi controllare niente di quello che conta. Se c’è riluttanza, chiedi una copia ripulita — senza costi e senza nomi, ma con struttura, legami e date intatti. È tutto quello che serve per giudicare un piano.
La scheda di ispezione
Tutto quello che c’è sopra, nella forma in cui lo uso quando devo dare un giudizio in mezz’ora. La colonna di destra è la parte che conta: la domanda da fare a chi il piano lo ha costruito.
| Quello che vedi | Quello che vuol dire | La domanda da fare |
|---|---|---|
| Righe tutte allo stesso livello | È un elenco, non un piano | Come sono raggruppate le attività per fase? |
| Molte durate «1 giorno?» | Nessuno ha stimato | Su che cosa sono basate queste durate? |
| Tanti vincoli «deve iniziare il» | Le date sono state scritte, non calcolate | Quali di queste date sono contrattuali? |
| Attività a pianificazione manuale | Quella parte del piano non è calcolata | Sono ancora appunti o sono definitive? |
| Attività senza successori | La rete è incompleta | Che cosa parte quando questa finisce? |
| Legami sulle righe in grassetto | Il piano è legato per blocchi | Quale attività aspetta davvero quale? |
| Percorso critico assente o a pezzi | I vincoli hanno spezzato il calcolo | Possiamo togliere i vincoli e vedere? |
| Margine totale negativo | Il piano è già in ritardo su sé stesso | Sappiamo che questa data non è raggiungibile? |
| Risorse sulle righe in grassetto | Il budget è gonfio | Questo costo è in aggiunta o sostituisce? |
| Risorse generiche, lavoro a zero | Nessuno ha detto sì a queste date | Chi sono le persone dietro questi ruoli? |
| Persone al 200% per settimane | Le date non sono realizzabili | Chi fa davvero questo lavoro, e quando? |
| Calendario senza eccezioni | Il progetto lavora a Ferragosto | Le chiusure aziendali sono nel piano? |
| Colonne della previsione vuote | Non si potrà misurare niente | Quando salviamo la previsione? |
| Data di stato vuota o vecchia | I numeri cambiano ogni volta che apri il file | A che data è aggiornato questo piano? |
| Date effettive vuote | Il piano non è in esercizio | Con quale procedura raccogliete l’avanzamento? |
| Variazioni a zero su tutta la linea | Manca la previsione, o è stata risalvata | Rispetto a quale versione stiamo misurando? |
Gli stessi controlli in forma di scheda, da tenere accanto alla tastiera: la checklist per analizzare un piano, con il PDF di una pagina da stampare.
Applicare le buone pratiche di Microsoft Project: da dove si comincia
Se stai leggendo con un piano aperto e hai contato dieci sintomi, la tentazione è rifarlo da capo. Quasi sempre è la scelta sbagliata: un piano imperfetto che le persone usano vale più di un piano perfetto che nessuno aggiorna.
L’ordine che funziona è quello delle dipendenze, ed è lo stesso della Parte 0. Prima i vincoli, perché finché ci sono il piano non reagisce e ogni altra correzione è provvisoria. Poi la rete: le attività appese e i legami sui riepiloghi. Poi il calendario, che costa cinque minuti e sposta tutte le date. A quel punto — e solo a quel punto — si salva la previsione e si comincia a misurare. Struttura e nomi si sistemano strada facendo, senza fermare niente.
E se il piano non è tuo, l’obiettivo non è correggerlo: è sapere di quanto ti puoi fidare, e di che cosa. Un piano con una rete solida e nessuna previsione è utilissimo per capire come è fatto il lavoro e inservibile per dire a che punto siamo. Sono due cose diverse, e confonderle è il motivo per cui certe riunioni finiscono con decisioni prese su numeri di marzo.
Domande frequenti
Quante di queste buone pratiche valgono anche fuori da Microsoft Project?
Quasi tutte, perché non parlano del programma ma del metodo del percorso critico, che è lo stesso in qualunque strumento di schedulazione. Cambiano i nomi dei comandi e qualche comportamento di dettaglio. I due punti più legati a Project sono la pianificazione manuale delle attività e il modo in cui vengono gestite le previsioni multiple.
Il piano che ho ereditato ha quasi tutti questi sintomi: lo rifaccio?
Solo se è piccolo. Su un piano grande conviene la sequenza descritta sopra: prima i vincoli, poi la rete, poi il calendario, e poi si salva la previsione e si comincia a misurare da oggi. Rifare da zero costa settimane e produce, nel frattempo, l’unica cosa peggiore di un piano sbagliato: nessun piano.
Esiste una soglia oltre la quale un piano è da considerare inaffidabile?
Le soglie che circolano — «non più del dieci per cento di attività vincolate», «non più del cinque per cento senza successori» — vengono dalle checklist di qualità della schedulazione usate nei grandi appalti, e come ordine di grandezza sono ragionevoli. Non sono però misure fatte su piani reali italiani: sono convenzioni. Il criterio che uso io è più prudente e più utile: non conta quanti sintomi ci sono, conta se il piano reagisce. Cambia una durata in mezzo alla rete e guarda se la data di fine si muove. Se non si muove, quello non è un modello, qualunque percentuale tu abbia contato.
Da dove comincio se ho solo dieci minuti?
Tre controlli, in quest’ordine: la colonna del tipo di vincolo, la colonna dei successori, e il calendario del progetto. Dicono rispettivamente se le date sono calcolate, se la rete propaga i ritardi e se il tempo è misurato su un anno vero. Un piano che passa questi tre può avere molti difetti, ma è un piano.
Che differenza c’è fra questa guida e una checklist di qualità della schedulazione?
Le checklist formali contano: quante attività vincolate, quante senza successori, quante con margine negativo. Producono un punteggio, servono nei contratti e non spiegano niente. Qui l’ordine è rovesciato: si parte da quello che si vede, si risale al meccanismo che lo ha prodotto e si arriva alla domanda da fare. Il punteggio dice che il piano è malato; il meccanismo dice di che cosa, e che cosa succede se non lo curi.
Serve applicarle tutte anche su un progetto piccolo?
No, e pretenderlo è il modo più sicuro per far abbandonare lo strumento. Su un progetto di venti attività e due mesi bastano quattro cose: niente date scritte a mano, una rete chiusa, il calendario con le feste, una previsione salvata. Tutto il resto diventa importante quando crescono le persone coinvolte e la durata — cioè quando il piano deve parlare a qualcuno che non eri tu.
Approfondimenti
Gli articoli che spiegano un sintomo per volta, con le schermate:
Come si legge un piano
- Come analizzare velocemente un piano di progetto con MS Project (2026)
- Come usi Microsoft Project e cosa dovresti sapere per avere il massimo beneficio (2020)
- Definizioni, trucchi e scorciatoie con Microsoft Project (2016)
Parte A · La struttura
- La WBS che non regge: cinque segni che si vedono dal piano (2026)
- Attività di Riepilogo del Progetto (Task 0) in Microsoft Project (2024)
- Come nominare le attività di un progetto (2024)
- Le colonne che ti mancano esistono già (2026)
- Introduzione alla Work Breakdown Structure (WBS) (2024)
- Pianificare un progetto in 7 passi con Microsoft Project (2024)
Parte B · Il tempo
- Il metodo del percorso critico: come si calcola e come si legge (2023)
- Cosa è il Float di una programmazione lavori (2024)
- Introduzione alla Schedulazione Dinamica (2024)
- Quando ritardare un’attività con un vincolo può essere utile (2024)
- Microsoft Project: ASAP e ALAP, pro e contro (2025)
- Come impostare le scadenze (deadline) (2010)
- Perché evitare di collegare le attività di riepilogo (2023)
- Tipi di dipendenze logiche in una schedulazione (2023)
- Metodologie di stima nei progetti (2024)
Parte C · Le risorse
- Le risorse non si assegnano alle fasi (e il budget te lo dimostra) (2026)
- Livellamento risorse: quanto è affidabile e preciso Microsoft Project? (2016)
- Come individuare attività sovrapposte che generano conflitti su risorse (2019)
- Gestire e comunicare responsabilità e ruoli senza usare le risorse (2013)
- Il progetto lavora anche a Ferragosto (se non glielo dici) (2026)
- Calendari di risorse in Microsoft Project (2024)
Parte D · Il controllo
- Aggiornare un piano: previsione, data di stato e avanzamento (2026)
- Come raccogliere i consuntivi dal team e aggiornare il piano (2026)
- Il capocantiere ha spostato la squadra: non riscrivere i legami (2026)
- Come si capisce che un piano non è aggiornato (2026)
- Baseline in Microsoft Project: cos’è, quando salvarla, cosa cambia (2024)
- Hai ripianificato: con che cosa ti confronti adesso? (2026)
- L’impatto della data di stato nei diagrammi di Gantt (2025)
- Comprendere le date di inizio e fine effettive (2020)
- Differenza fra percentuale di completamento di durata e di lavoro (2024)
- Come scegliere il migliore periodo di aggiornamento di un progetto (2024)
- Earned Value e indicatori di performance: guida completa (2024)
- Che cos’è l’Earned Schedule nel controllo di progetto (2026)
- Non nascondere al cliente che il progetto sta accumulando ritardo (2022)
Parte E · Condividere il piano
- Mandare il piano a chi non ha Microsoft Project (2026)
- Microsoft Project e GDPR: cosa contiene davvero un .MPP (2026)
- Come nascondere informazioni sensibili da un file di Microsoft Project (2019)
- La visualizzazione che il tuo capo capisce al primo colpo (2026)
- Personalizzare viste, tabelle e Gantt: la guida completa (2026)
- Inviare a ognuno i propri task via email, senza Project Server (2026)