Aggiornato a settembre 2026. L’elenco originale è del 2019 e regge ancora: quello che è cambiato è che adesso ogni sintomo ha il suo capitolo, con il meccanismo e la cura. Qui resta la cosa più utile da fare per prima: contarli.
In vent’anni d’aula ho imparato che chiedere «conosci Microsoft Project?» non serve a niente: tutti rispondono «abbastanza». Serve invece guardare un piano fatto da chi risponde. In dieci minuti, senza fare domande, si capisce a che livello sta — perché i sintomi di chi non conosce bene Microsoft Project sono sempre gli stessi dieci.
Sono sintomi, non errori di distrazione: ognuno è la conseguenza di una cosa che lo strumento fa e che chi lo usa non sa che faccia. Ed è per questo che nessuno se ne accorge da solo: Project non protesta mai. Accetta tutto, calcola quello che può, e ti restituisce un piano che sembra funzionare.
Apri un tuo piano e conta. Poi in fondo c’è come si legge il risultato.
In sintesi
- Dieci sintomi si vedono da un piano e dicono a che livello chi lo ha scritto conosce Microsoft Project.
- Non sono errori di distrazione: ognuno è la conseguenza di una cosa che il programma fa e che chi lo usa non sa che faccia. Project non protesta mai.
- Il più grave è il secondo, le date scritte a mano: chi corregge solo quello fa il salto più grosso.
- In fondo c’è come si legge il punteggio, e la prova che vale quanto tutto il conteggio: cambia una durata in mezzo alla rete e guarda se la data di fine si muove.
I dieci sintomi di Microsoft Project, uno per uno
1 · Crei a mano l’attività di riepilogo del progetto
Scrivi in cima una riga con il nome del progetto e ci rientri dentro tutto il resto. Non serviva: Project ha già la sua, la riga con identificativo 0, che si accende con una casella di spunta e riepiloga da sola durata, lavoro e costo totali. La tua invece è un’attività come le altre, e qualcuno prima o poi ci assegnerà sopra delle risorse.
2 · Imposti a mano le date delle attività
È il sintomo che vale gli altri nove. In Project le date non si scrivono: si calcolano, a partire da durate e legami. Quando ne digiti una, il programma piazza un vincolo e da quel momento quell’attività è inchiodata al calendario. Il piano continua a sembrare uguale — finché qualcosa slitta e non si muove niente.
3 · Non inserisci tutte le stime di durata
Le attività che nessuno ha stimato restano al valore che Project mette da solo, con il punto interrogativo accanto: «1 giorno?». Un piano che ne ha molti non è stato stimato, è stato elencato — e la data di fine che mostra è il risultato di quei valori messi lì dal programma.
4 · I nomi delle attività non cominciano con un verbo
«Impianto elettrico» è una cosa, non un lavoro. Un’attività dovrebbe dire che cosa si fa — Posare i cavidotti — e un traguardo dovrebbe dire una verifica superata: Collaudo completato. Sembra una questione di stile e non lo è: da un piano di sostantivi non si capisce chi deve fare che cosa.
5 · Assegni predecessori alle attività di riepilogo
Colleghi la fase B alla fase A, come si farebbe su una lavagna. Ma la fase è un contenitore: così non hai detto quale attività aspetta quale, hai detto che un blocco aspetta un blocco. Il ritardo si propaga in massa e il percorso critico attraversa contenitori invece di lavoro vero.
6 · Assegni risorse alle attività di riepilogo
È il più costoso della lista, in senso letterale. Project somma verso l’alto i costi delle attività; la risorsa che metti sulla fase non sostituisce quella somma, ci si aggiunge, calcolata sulla durata dell’intera fase. Il budget cresce del doppio senza che una sola riga sembri sbagliata.
7 · Non analizzi mai il percorso critico
Il percorso critico è la catena che decide la data di fine: un giorno di ritardo lì è un giorno di ritardo del progetto, mentre sulle altre attività esiste un margine. Chi non lo guarda tratta tutte le attività come ugualmente urgenti, e quando deve recuperare interviene a caso.
8 · Non verifichi la sovrallocazione delle risorse
Le date funzionano solo se le persone che le devono rispettare sono libere di lavorarci. Nei piani costruiti in fretta la stessa persona è a tempo pieno su tre attività parallele: il piano è coerente con sé stesso e racconta una storia che non succederà.
9 · Non salvi mai la previsione
La previsione — la baseline — è la fotografia del piano al momento dell’impegno, e serve a una cosa sola: dare un termine di confronto. Senza, fra un mese le date saranno cambiate e non ci sarà modo di sapere di quanto. Niente scostamenti, niente misura del ritardo: solo l’impressione che le cose vadano peggio.
10 · Non aggiorni la schedulazione
Se non misuri, non gestisci: è la frase che ripeto da sempre ai miei allievi. Un piano che non viene aggiornato smette di essere uno strumento dopo due settimane e diventa un documento. E la variante peggiore non è non aggiornarlo: è aggiornarlo trascinando le barre in avanti finché torna a somigliare alla realtà.
Come si legge il risultato
Conta i sintomi che hai trovato sul tuo piano.
- Zero o uno. Conosci lo strumento. Il margine di miglioramento è altrove: nella qualità delle stime e nel ritmo con cui aggiorni.
- Da due a quattro. È la situazione più comune fra chi usa Project tutti i giorni. Quasi sempre i sintomi presenti sono il 3, il 9 e il 10 — cioè il piano è costruito bene e non è misurato. Si recupera in una giornata.
- Da cinque a sette. Lo stai usando come se fosse un foglio di calcolo con le barre colorate. Non è una questione di bravura: è che nessuno ti ha mai detto che le date si calcolano. La buona notizia è che il salto più grosso lo fa un sintomo solo, il numero 2.
- Otto o più. Il piano che hai davanti è un disegno del progetto, non un modello. Serve per comunicare e non reggerà al primo imprevisto — ma non va rifatto da capo: si sistema in ordine, e l’ordine conta più della fretta.
C’è anche una prova sola che vale quanto tutto il conteggio, e dura dieci secondi: cambia una durata in mezzo alla rete e guarda se la data di fine si muove. Se non si muove, hai un disegno. Poi annulla la modifica.
E adesso, le cure
Nella prima versione di questo articolo, sette anni fa, a ogni sintomo seguiva una cura di tre righe. Erano giuste e non bastavano, perché una cura di tre righe si legge e non si applica: quello che manca è sempre il perché, cioè che cosa fa Project esattamente in quel momento.
Per questo i dieci sintomi sono diventati una guida: Il piano che regge. Ci sono questi dieci e altri nove, ognuno con il meccanismo che lo produce, come si evita se il piano è tuo e — la parte che non trovi da nessun’altra parte — come lo scopri in trenta secondi se il piano te lo hanno mandato, che è la situazione in cui si trovano ogni giorno committenti, PMO e project control.
Se invece hai fretta, tre controlli in quest’ordine dicono quasi tutto: la colonna del tipo di vincolo, la colonna dei successori, il calendario del progetto. Dicono se le date sono calcolate, se la rete propaga i ritardi, se il tempo è misurato su un anno vero. Un piano che li passa può avere molti difetti, ma è un piano.
Complimenti Rosario ed un grazie per tutti gli approfondimenti messia disposizione.
Per quanto mi riguarda mi piacerebbe avere indicazioni chiare per esportare in excell i dati necessari alla costruzione della curva ad “S” del progetto di previsione e dell’avanzamento effettivo.
a presto
Buonasera Franco,
mi “appunto” di scrivere un articolo su questo argomento.
Ti anticipo che da Project 2010 in poi, sono disponibili i reports grafici, che permettono di esportare su Excel le informazioni del progetto sotto forma di Tabelle Pivot.
Rosario