Un diagramma di Gantt mostra quando devono avvenire le attività di un progetto, quanto durano e quali dipendono da altre. A prima vista è un grafico piuttosto semplice: attività disposte in verticale, tempo sull’asse orizzontale e barre che occupano il periodo previsto per ciascun lavoro.
La parte difficile, però, non è disegnare le barre.
Un diagramma di Gantt diventa realmente utile quando rappresenta un piano credibile. Se le attività sono incomplete, le durate poco realistiche o le dipendenze ignorate, puoi ottenere un grafico molto ordinato che descrive male il progetto.
Il principio da tenere presente è quindi questo: le date non dovrebbero essere il punto di partenza del Gantt. Dovrebbero essere il risultato della struttura del lavoro, delle durate, delle dipendenze e dei vincoli che hai definito.
È anche il motivo per cui un diagramma di Gantt è soltanto una delle tecniche disponibili nel project management. Serve soprattutto quando il tempo e le relazioni tra attività sono abbastanza importanti da richiedere una rappresentazione esplicita.
In questa guida vediamo come costruirne uno, come leggerlo quando il piano cambia e come capire se ti serve davvero.
Cos’è un diagramma di Gantt e cosa mostra davvero
Un diagramma di Gantt è una rappresentazione temporale delle attività di un progetto.
Sul lato verticale trovi normalmente l’elenco delle attività. Sull’asse orizzontale trovi il tempo, suddiviso per esempio in giorni, settimane o mesi. Ogni attività viene rappresentata da una barra: la sua posizione indica quando è prevista, mentre la lunghezza rappresenta la durata.
Questo è il livello più evidente.
Un Gantt strutturato può però mostrare anche:
- relazioni di dipendenza tra attività;
- milestone;
- attività che procedono in parallelo;
- responsabili;
- percentuale di avanzamento;
- vincoli e scadenze;
- percorso critico;
- confronto tra piano iniziale e situazione corrente.
Non tutti questi elementi sono necessari in ogni progetto.
Un piano con dieci attività non deve diventare un sistema di scheduling enterprise soltanto perché il software consente di aggiungere decine di campi. La quantità di dettaglio dovrebbe crescere soltanto quando aiuta a prendere decisioni migliori.
Attività, durate, date, dipendenze, milestone e avanzamento
Per capire un Gantt conviene separare gli elementi che spesso vengono confusi.
L’attività descrive il lavoro da svolgere.
“Progettare la homepage” è un’attività. “Nuovo sito pronto” è invece un risultato molto più ampio e dovrebbe probabilmente essere scomposto.
La durata indica quanto tempo di calendario deve trascorrere perché l’attività possa essere completata nelle condizioni previste.
Non coincide necessariamente con l’impegno.
Un’attività può richiedere quattro ore di lavoro ma occupare tre giorni di calendario perché dipende da revisioni, approvazioni o disponibilità esterne.
Le date collocano l’attività nel calendario.
Qui nasce uno degli errori più frequenti: scegliere prima le date perché “il grafico deve partire da qualche parte” e costruire successivamente una giustificazione per farcele stare.
Un piano più robusto procede nella direzione opposta.
Prima individui il lavoro, stimi le durate e stabilisci le dipendenze. Poi il calendario mostra le conseguenze di quelle scelte.
Le dipendenze spiegano invece perché un’attività non può essere trattata come completamente indipendente dalle altre.
Se i test possono iniziare soltanto dopo che lo sviluppo è terminato, esiste una relazione tra le due attività. Se sposti lo sviluppo e il test rimane immobile nel grafico, il Gantt non sta più rappresentando il processo reale.
La relazione più intuitiva è la finish-to-start: l’attività successiva parte quando quella precedente è terminata.
Nei piani più articolati possono esistere anche relazioni inizio-inizio, fine-fine o, più raramente, inizio-fine. Non serve introdurle per rendere il diagramma più sofisticato: hanno senso solo quando descrivono un vincolo reale.
Le milestone, infine, rappresentano eventi o passaggi significativi, non periodi di lavoro.
“Approvazione design”, “contenuti pronti” o “go-live” possono essere milestone. In uno schedule formale vengono normalmente trattate come eventi senza durata.
L’avanzamento aggiunge un altro livello: non mostra più soltanto cosa era previsto, ma consente di confrontare il piano con ciò che sta realmente accadendo.
Gantt di progetto e cronoprogramma: dove coincidono e dove no
I termini vengono spesso usati come sinonimi, ma non è sempre corretto.
Un cronoprogramma è, in senso ampio, una programmazione temporale delle attività. Può essere una tabella, una sequenza di scadenze, un calendario operativo o una rappresentazione più strutturata.
Il Gantt è uno dei modi con cui puoi rappresentare un cronoprogramma.
L’espressione cronoprogramma Gantt viene quindi usata frequentemente per indicare un piano temporale visualizzato attraverso barre orizzontali, attività e relative date.
Non significa però che ogni cronoprogramma debba essere un Gantt.
In determinati contesti tecnici, contrattuali o di settore, inoltre, “cronoprogramma” può avere requisiti e significati specifici. Conviene quindi distinguere il concetto generale di programmazione temporale dallo strumento visuale utilizzato per rappresentarla.
Perché un Gantt non è semplicemente una timeline
Una timeline mostra eventi collocati nel tempo.
Può essere perfetta se vuoi rappresentare:
kick-off → prima revisione → consegna → lancio
Il problema nasce quando devi capire ciò che accade tra quei punti.
Supponiamo che il lancio dipenda dal completamento di test, migrazione dei contenuti e configurazione del tracking. Una timeline può mostrarti quando vorresti arrivare al lancio. Un diagramma di Gantt può mostrarti le attività che devono rendere possibile quella data, la loro durata e le relazioni che le collegano.
La distinzione è semplice:
la timeline racconta soprattutto quando avvengono eventi importanti; il Gantt rappresenta il lavoro necessario per arrivarci.
Quando usare un diagramma di Gantt e quando è inutile complicare il progetto
Non serve un diagramma di Gantt per qualsiasi cosa abbia una data.
Se devi completare quattro attività indipendenti entro venerdì, costruire uno schedule con dipendenze, milestone e baseline potrebbe richiedere più lavoro del problema che dovrebbe risolvere.
Il diagramma di Gantt inizia a diventare interessante quando la domanda non è più soltanto:
Cosa dobbiamo fare?
ma anche:
In quale ordine può essere fatto, cosa può procedere contemporaneamente e cosa succede alle altre attività se qualcosa ritarda?
Quando dipendenze, scadenze e attività parallele rendono utile il Gantt
Il Gantt offre molto valore quando il progetto contiene una combinazione di elementi come:
- attività che devono rispettare un ordine;
- lavori che possono procedere in parallelo;
- scadenze esterne difficili da spostare;
- persone o risorse condivise;
- passaggi di approvazione;
- milestone;
- più team coinvolti;
- conseguenze rilevanti in caso di ritardo.
Pensa alla riprogettazione di un sito.
Content inventory e progettazione grafica potrebbero procedere in parte contemporaneamente. Lo sviluppo dei template dipende invece dall’approvazione del design. La migrazione completa dei contenuti può dipendere sia dalla preparazione editoriale sia dalla disponibilità dell’ambiente definitivo. I test vengono dopo alcune attività tecniche, mentre altre verifiche possono iniziare prima.
In una semplice lista leggeresti una serie di task.
Nel Gantt inizi a vedere il sistema di relazioni fra quei task.
È lì che il diagramma acquista valore.
Quando bastano una to-do list, un calendario o una board Kanban
Per organizzare poche azioni personali potrebbe bastare una to do list.
Se ciò che conta principalmente è ricordare una riunione, una consegna o un appuntamento, probabilmente stai descrivendo un problema da calendario.
Se devi visualizzare il flusso del lavoro attraverso stati come:
da fare → in corso → revisione → completato
una board Kanban può essere più leggibile.
È la logica su cui si basa anche Trello: osservi soprattutto dove si trova il lavoro nel processo, non necessariamente tutta la struttura temporale delle dipendenze.
Gli strumenti possono anche convivere.
Un team potrebbe usare un diagramma di Gantt per il piano generale del lancio e una board per gestire il flusso quotidiano delle attività.
La scelta non dipende da quale rappresentazione sembri più professionale. Dipende dalla domanda a cui devi rispondere.
I limiti del Gantt: complessità, manutenzione e falsa precisione
Il vantaggio del Gantt può trasformarsi facilmente nel suo limite.
Con poche decine di attività il quadro può essere leggibile. Con centinaia di righe, dipendenze, risorse e sottoattività, la visualizzazione rischia di diventare difficile da interpretare.
Esiste poi un costo di manutenzione.
Se il progetto cambia ma il diagramma non viene aggiornato, non hai più un piano: hai la fotografia di una situazione che non esiste.
Il problema più insidioso è però un altro.
Una barra disegnata tra lunedì e giovedì sembra precisa. Questo non significa che la stima su cui si basa sia precisa.
Se non sai ancora quanto durerà un’integrazione complessa, rappresentarla con una barra perfettamente delimitata non riduce l’incertezza. La rende soltanto graficamente ordinata.
Un buon Gantt rende visibile ciò che sai del progetto senza fingere che ogni stima sia una certezza.
Come fare un diagramma di Gantt passo dopo passo
Per capire come fare un diagramma di Gantt conviene dimenticare per qualche minuto il grafico.
Partire direttamente dalle barre porta facilmente a costruire un calendario prima di aver costruito un piano.
La sequenza più utile è:
risultato → lavoro → durata → dipendenze → responsabilità e vincoli → calendario → baseline → aggiornamento
1. Definisci il risultato e scomponi il lavoro
Parti da ciò che deve esistere quando il progetto è concluso.
“Rifare il sito” è troppo vago.
Una definizione più utile potrebbe includere:
- nuovo sito pubblicato;
- template principali completati;
- contenuti essenziali migrati;
- moduli e funzioni critiche verificate;
- tracking controllato;
- redirect implementati;
- approvazione finale ottenuta.
A questo punto puoi scomporre il risultato.
La Work Breakdown Structure, o WBS, viene utilizzata proprio per organizzare gerarchicamente lo scope del progetto in componenti più gestibili. Il Project Management Institute descrive la WBS come uno strumento centrale della pianificazione dello scope.
Non devi necessariamente costruire un enorme albero formale.
Devi arrivare a unità di lavoro abbastanza precise da poter essere comprese, stimate e assegnate.
Una sequenza potrebbe diventare:
nuovo sito → progettazione → wireframe → UI → sviluppo template
e parallelamente:
nuovo sito → contenuti → inventario → revisione → migrazione
Ora hai qualcosa che può entrare in uno schedule.
2. Stima durate e calendario di lavoro
Per ogni attività devi distinguere almeno due concetti:
impegno e durata.
Se una revisione richiede due ore ma devi attendere tre giorni per ricevere l’approvazione, il suo impatto sul calendario non è di due ore.
Allo stesso modo, cinque giornate di lavoro non significano necessariamente cinque giorni consecutivi se la stessa persona è impegnata anche altrove.
La durata deve quindi tenere conto del modo in cui il lavoro può realmente essere svolto.
Prima di trasformare le stime in date, considera anche il calendario:
- giorni lavorativi;
- festività;
- disponibilità delle persone;
- attese esterne;
- finestre tecniche;
- eventuali scadenze non modificabili.
Una precisione apparente nelle date non compensa una stima debole.
Quando l’incertezza è elevata, è più utile renderla esplicita e aggiornare il piano quando emergono informazioni migliori.
3. Mappa dipendenze e attività che possono procedere in parallelo
Adesso chiediti, per ogni attività:
che cosa deve essere vero perché questa possa iniziare?
Se la risposta è “nulla”, l’attività può probabilmente partire in modo indipendente, compatibilmente con le risorse.
Se la risposta è “deve essere approvato il wireframe”, hai individuato una dipendenza.
Questa fase è decisiva perché impedisce di trattare come indipendenti attività che nella realtà non lo sono.
Allo stesso tempo devi cercare il contrario: ciò che può essere svolto in parallelo.
Se contenuti e design non dipendono completamente l’uno dall’altro, costringerli in sequenza allunga artificialmente il progetto.
Un buon Gantt non mette tutto in fila.
Rappresenta sequenza e parallelismo.
Quando colleghi le attività, evita anche di creare dipendenze soltanto perché “normalmente facciamo così”. Una relazione nello schedule dovrebbe descrivere un vincolo reale, non una consuetudine che nessuno ha mai messo in discussione.
4. Inserisci milestone, responsabilità e vincoli
Una volta stabilite le relazioni principali puoi aggiungere i punti di controllo.
Le milestone funzionano bene per eventi come:
- scope approvato;
- design approvato;
- ambiente pronto;
- contenuti completati;
- QA superato;
- go-live.
Non trasformare però ogni attività completata in una milestone.
Se tutto è importante, le milestone smettono di aiutarti a distinguere ciò che conta.
Aggiungi poi il responsabile del lavoro quando questa informazione serve al coordinamento.
Infine registra i vincoli che possono influenzare lo schedule: una data imposta dall’esterno, una risorsa disponibile soltanto in determinati giorni, una finestra di manutenzione o una consegna da parte di un fornitore.
Il Gantt dovrebbe aiutarti a vedere questi vincoli, non nasconderli dietro una sequenza di barre apparentemente regolare.
5. Crea una baseline e aggiorna piano e avanzamento
Quando il piano ha raggiunto un livello di affidabilità sufficiente, puoi fissare una baseline.
La baseline è il riferimento contro cui confrontare l’evoluzione successiva del progetto.
È una distinzione importante.
Se ogni volta che un’attività slitta sposti semplicemente la data originaria e cancelli quella precedente, dopo qualche settimana il diagramma può sembrare perfettamente aggiornato ma non ti dice più quanto il progetto si sia allontanato dal piano.
La documentazione di Microsoft Project descrive la baseline come un riferimento che consente di confrontare lo schedule corrente con il piano precedente.
Questo non significa che la baseline debba diventare intoccabile.
Se cambia formalmente lo scope o il progetto viene ripianificato in modo sostanziale, può essere necessario definire un nuovo riferimento. La cosa importante è non confondere continuamente piano originario e previsione corrente.
Esempio di diagramma di Gantt: un progetto web dalla pianificazione al go-live
Vediamo un esempio di diagramma di Gantt illustrativo.
Le durate non rappresentano un benchmark universale per la realizzazione di un sito: servono esclusivamente a mostrare il funzionamento del modello.
Supponiamo di avere queste attività:
| ID | Attività | Durata | Dipende da |
|---|---|---|---|
| A | Discovery e definizione scope | 1 settimana | — |
| B | Architettura dei contenuti | 1 settimana | A |
| C | Wireframe | 1 settimana | B |
| D | Inventario e revisione contenuti | 2 settimane | B |
| E | UI design | 1 settimana | C |
| F | Sviluppo template | 2 settimane | E |
| G | Migrazione contenuti | 2 settimane | D, F |
| H | QA tecnico e funzionale | 1 settimana | G |
| M | Go-live | milestone | H |
Una rappresentazione semplificata potrebbe apparire così:
| Attività | S1 | S2 | S3 | S4 | S5 | S6 | S7 | S8 |
|---|---|---|---|---|---|---|---|---|
| Discovery e scope | ■ | |||||||
| Architettura contenuti | ■ | |||||||
| Wireframe | ■ | |||||||
| Inventario/revisione contenuti | ■ | ■ | ||||||
| UI design | ■ | |||||||
| Sviluppo template | ■ | ■ | ||||||
| Migrazione contenuti | ■ | ■ | ||||||
| QA | ■ | |||||||
| Go-live | ◆ |
Una rappresentazione semplificata potrebbe apparire così:
La milestone di go-live è collocata al termine della nona settimana, dopo il completamento del QA.
Questa tabella non sostituisce un software di scheduling e le durate non rappresentano un benchmark per la realizzazione di un sito. Servono a rendere visibili la sequenza delle attività, i parallelismi e le dipendenze dell’esempio.
Questa tabella non sostituisce un software di scheduling. Serve a far emergere la logica.
Dalla lista delle attività alla sequenza temporale
Guarda la differenza tra le attività C e D.
Entrambe dipendono dall’architettura dei contenuti, quindi possono iniziare quando B è completata.
Non devono necessariamente attendersi a vicenda.
È questo che permette a wireframe e lavoro editoriale di procedere in parallelo.
Lo sviluppo, invece, dipende dal design. La migrazione completa dipende sia dalla preparazione dei contenuti sia dalla disponibilità dei template.
Il Gantt rende quindi visibile una cosa che una semplice lista non mostra immediatamente:
alcune attività sono in sequenza, altre sono parallele e alcune convergono prima che il progetto possa proseguire.
Come leggere dipendenze, milestone e percorso critico
Il percorso critico non è semplicemente la barra più lunga del diagramma.
È la sequenza di attività dipendenti che, nel modello di scheduling, determina la durata del progetto. Un ritardo su un’attività priva di margine lungo questo percorso può spostare la data finale se non intervieni con una modifica del piano.
Nel nostro esempio semplificato puoi seguire una catena del tipo:
A → B → C → E → F → G → H → M
Il ramo dei contenuti procede in parte parallelamente.
Finché viene completato prima del momento in cui G può iniziare, può avere margine. Se invece la revisione dei contenuti si allunga abbastanza da bloccare la migrazione, quel ramo può iniziare a governare la data finale.
Questo è il punto interessante.
Il percorso critico può cambiare durante il progetto.
Non è un’etichetta da assegnare una volta per tutte.
Cosa succede al Gantt quando un’attività slitta
Supponiamo che il design non venga approvato alla fine della quarta settimana e richieda altri cinque giorni.
Se F dipende da E, lo sviluppo non può semplicemente restare dov’è.
Si sposta.
Se G dipende dallo sviluppo, anche la migrazione può spostarsi.
Se H può partire soltanto dopo la migrazione, viene coinvolto anche il QA.
A questo punto il go-live rischia di cambiare.
Un diagramma costruito soltanto disegnando manualmente le barre potrebbe obbligarti a modificare una per una tutte queste date.
Uno schedule con dipendenze reali può invece propagare il cambiamento.
Questo è uno dei criteri più utili per valutare un diagramma di Gantt: non chiederti soltanto se mostra bene il piano attuale. Chiediti se riesce a mostrarti cosa accade quando il piano cambia.
Diagramma di Gantt in Excel o software di project management?
Un diagramma di Gantt non richiede automaticamente un software di project management.
Per un progetto semplice puoi partire da un foglio di calcolo.
Se stai cercando un diagramma di Gantt Excel, è utile sapere che Excel non dispone di un tipo di grafico Gantt predefinito: puoi simularlo tramite un grafico a barre in pila oppure utilizzare un modello, come spiega la documentazione Microsoft per creare un Gantt in Excel.
Questo approccio può essere più che sufficiente quando hai poche attività e il piano cambia raramente.
La domanda quindi non è:
Excel è abbastanza professionale?
La domanda è:
Quanto deve essere dinamico il mio modello?
Quando Excel è sufficiente
Un foglio di calcolo funziona bene quando:
- il numero di attività è limitato;
- le dipendenze sono poche;
- il progetto è relativamente stabile;
- una sola persona mantiene il piano;
- non hai bisogno di gestione avanzata delle risorse;
- gli aggiornamenti non richiedono continui ricalcoli;
- la collaborazione in tempo reale non è critica.
Ha anche un vantaggio didattico.
Costruire il primo Gantt in una tabella ti obbliga a capire quali dati stai rappresentando. È più difficile nascondere un piano confuso dietro funzioni automatiche.
Il limite arriva quando la manutenzione manuale comincia a costarti troppo.
Quando servono ripianificazione, dipendenze dinamiche, baseline e collaborazione
Un software dedicato inizia ad avere più senso quando il diagramma deve essere un vero modello operativo.
Per esempio, quando devi:
- riprogrammare automaticamente attività dipendenti;
- lavorare con più persone sullo stesso piano;
- gestire molti progetti;
- confrontare baseline e situazione corrente;
- controllare carichi e disponibilità;
- mantenere storico e responsabilità;
- collegare task, file, commenti e approvazioni;
- filtrare viste diverse dello stesso lavoro.
Strumenti di project management come Asana possono rappresentare lo stesso lavoro attraverso più viste, aggiungendo dipendenze e pianificazione temporale quando il progetto lo richiede.
Anche piattaforme come monday.com permettono di osservare gli stessi dati tramite board, timeline, Gantt, calendario e altre viste.
Il vantaggio non è avere un diagramma di Gantt più bello.
È evitare di dover ricostruire manualmente il modello ogni volta che cambia un dato importante.
Quali funzioni valutare prima di scegliere lo strumento
Prima di confrontare software, individua le funzioni che derivano realmente dal tuo caso.
Per un Gantt semplice possono bastare:
- attività;
- data di inizio;
- durata;
- dipendenze;
- milestone.
Per uno schedule più complesso potresti aggiungere:
- calendari di lavoro;
- baseline;
- percorso critico;
- avanzamento;
- assegnazione delle risorse;
- gestione della capacità;
- vincoli;
- storico delle modifiche;
- autorizzazioni;
- portfolio di più progetti.
Più funzioni non significano automaticamente un piano migliore.
Se una piattaforma richiede dieci campi per descrivere un lavoro che il team riesce a governare con quattro informazioni, il software sta aggiungendo complessità.
Se invece un foglio richiede continui aggiustamenti manuali per rappresentare dipendenze che cambiano ogni settimana, probabilmente il problema ha superato lo strumento.
Gantt, WBS, PERT e Kanban: quale strumento risponde a quale domanda
Gantt, WBS, PERT e Kanban vengono spesso messi nello stesso elenco di “strumenti di project management”.
È corretto, ma può far sembrare che siano alternative equivalenti.
Non lo sono.
| Strumento | Domanda principale |
|---|---|
| WBS | Di quale lavoro è composto realmente il progetto? |
| Gantt | Quando avviene il lavoro e come si collega nel tempo? |
| PERT | Qual è la rete logica delle attività e delle dipendenze? |
| Kanban | Come scorre il lavoro attraverso il processo? |
| Timeline | Quando avvengono gli eventi principali? |
La scelta diventa molto più semplice se parti dalla domanda invece che dal nome dello strumento.
Gantt vs WBS: quando contro cosa
La WBS riguarda principalmente lo scope.
Scompone il risultato complessivo in componenti più gestibili.
Il Gantt riguarda invece lo schedule.
Prende attività che puoi pianificare e le colloca nel tempo, evidenziando durata e relazioni.
In pratica:
WBS → cosa dobbiamo produrre
Gantt → quando e secondo quali dipendenze possiamo farlo
Per questo i due strumenti possono essere usati in sequenza.
Se il lavoro non è stato ancora definito bene, costruire subito un Gantt può significare pianificare con grande precisione attività che hai dimenticato di identificare.
PERT e Gantt: rete delle dipendenze e pianificazione temporale
PERT e Gantt possono rappresentare informazioni simili da prospettive differenti.
Un diagramma PERT mette in primo piano la rete: attività o eventi collegati secondo le loro relazioni logiche.
Il Gantt mette in primo piano la scala temporale: quando il lavoro dovrebbe avvenire e quanto dovrebbe durare.
Per un progetto complesso potresti utilizzare il ragionamento a rete per capire sequenze e dipendenze e successivamente rappresentare lo schedule risultante con un Gantt.
Atlassian, nella sua guida al diagramma PERT, presenta i due strumenti come complementari: PERT enfatizza le relazioni e il percorso delle attività, mentre Gantt rende immediata la pianificazione sul tempo.
Non serve però produrre entrambi per qualsiasi progetto.
Se le dipendenze sono semplici, un buon Gantt può già fornire tutta la visibilità necessaria.
Gantt vs Kanban: piano del progetto e flusso operativo
Il confronto Gantt vs Kanban riguarda soprattutto due modi diversi di osservare lo stesso lavoro.
Kanban guarda il lavoro da un’altra prospettiva.
L’obiettivo centrale è visualizzare il flusso e controllare come gli elementi avanzano attraverso il processo. La documentazione Atlassian su Kanban mette infatti al centro visualizzazione del lavoro, gestione del work in progress e miglioramento del flusso.
Un Gantt risponde meglio a domande come:
Quando dovrebbe terminare questa attività?
Da quale altra dipende?
Quale spostamento può compromettere la data finale?
Kanban è più naturale per domande come:
Quante attività sono in lavorazione?
Dove si sta accumulando il lavoro?
Quale elemento può avanzare adesso?
Non devi necessariamente scegliere un solo modello.
Puoi governare una roadmap con un Gantt e utilizzare una board Kanban per il lavoro quotidiano.
Gantt vs timeline: quando le sole date non bastano
Una timeline è spesso più leggibile per comunicare pochi eventi importanti.
Se devi presentare:
kick-off → prototipo → beta → lancio
non hai bisogno di mostrare cinquanta attività.
Il Gantt è preferibile quando devi capire come il progetto arriva a quegli eventi.
Le due rappresentazioni possono quindi servire pubblici differenti.
Uno stakeholder può avere bisogno di una timeline sintetica. Il team operativo può aver bisogno del Gantt sottostante.
La rappresentazione giusta è quella che mostra abbastanza informazione per la decisione che deve essere presa, senza costringere il lettore a interpretare dettagli inutili.
Errori comuni che rendono un Gantt poco utile
Il problema di molti diagrammi di Gantt non è il software.
È il modello che stanno rappresentando.
Impostare le date prima di capire le dipendenze
Hai una deadline tra otto settimane.
Apri il software, distribuisci le attività nello spazio disponibile e ottieni un piano che termina esattamente il giorno richiesto.
Graficamente funziona.
Ma hai dimostrato soltanto che sai disegnare barre dentro otto settimane.
Devi invece capire se attività, durate e dipendenze producono realmente quella data.
Se il risultato supera la deadline, hai ottenuto un’informazione utile: il piano e il vincolo non sono compatibili nelle condizioni attuali.
A quel punto puoi discutere scope, risorse, sequenza o data finale.
Nascondere il problema comprimendo arbitrariamente le barre significa perdere proprio l’informazione che il Gantt dovrebbe rendere visibile.
Confondere attività, deliverable e milestone
“Homepage” può significare tre cose molto diverse:
- un deliverable;
- una fase composta da più attività;
- una singola attività.
Se usi lo stesso livello di dettaglio per elementi differenti, il Gantt diventa difficile da stimare.
Lo stesso vale per le milestone.
“Completare il design” è normalmente lavoro.
“Design approvato” può essere una milestone.
La distinzione sembra piccola ma cambia il significato del diagramma: una barra rappresenta un periodo di lavoro, una milestone un punto significativo.
Trattare il piano iniziale come una promessa immutabile
La baseline serve a ricordare da dove sei partito.
Non serve a fingere che il progetto non possa cambiare.
Nuove informazioni possono modificare stime, rischi e priorità.
Un piano serio deve essere aggiornato.
La cosa importante è conservare la possibilità di distinguere:
- cosa avevamo pianificato;
- cosa sappiamo adesso;
- perché la previsione è cambiata.
Se ogni modifica viene interpretata automaticamente come un errore, il team può iniziare a proteggere il diagramma invece del risultato.
Se invece il piano viene riscritto continuamente senza conservare riferimenti, diventa impossibile capire gli scostamenti.
Serve equilibrio tra controllo e adattamento.
Aggiungere così tanti dettagli da rendere il diagramma illeggibile
Un Gantt non deve necessariamente mostrare ogni microattività.
“Spostare il bottone di cinque pixel” difficilmente merita una riga nello schedule principale.
Il livello di dettaglio deve permetterti di:
- stimare;
- assegnare;
- riconoscere dipendenze;
- controllare avanzamento;
- prendere decisioni.
Quando il diagramma diventa una trascrizione completa di ogni azione svolta dal team, perde la sua capacità di fornire una visione d’insieme.
Puoi mantenere le microattività nel task manager e lasciare nel Gantt il livello di pianificazione che serve davvero.
Conclusione
Un diagramma di Gantt vale il tempo necessario a mantenerlo solo quando rende visibili relazioni che altrimenti sarebbero difficili da governare.
Se hai poche attività indipendenti, resta sullo strumento più semplice.
Se invece il progetto contiene sequenze, parallelismi, milestone e dipendenze che possono modificare la data finale, il Gantt può trasformare una lista di task in un vero modello temporale del progetto.
Quando lo costruisci, non partire dal calendario.
Definisci prima il risultato, scomponi il lavoro, stima le durate e collega le attività che dipendono realmente l’una dall’altra. Solo allora lascia che le date emergano dal piano.
E usa un ultimo controllo per capire se il diagramma è davvero utile:
se un’attività importante slitta, riesci a vedere immediatamente cosa cambia nel resto del progetto?
Se la risposta è sì, il Gantt sta facendo il suo lavoro.