Microsoft Project: 10 sintomi che ti dicono che non lo conosci bene

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.

2 commenti su “Microsoft Project: 10 sintomi che ti dicono che non lo conosci bene”

  1. 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

    Rispondi
    • 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

      Rispondi

Lascia un commento