Ho chiesto ai miei studenti, in molti progetti, di pianificare  utilizzando i diagrammi di Gantt. Ci ho provato per diversi anni, debbo dire con scarsi risultati. I miei studenti, generalmente molto ferrati nell’uso delle tecnologie, individuavano software per costruire facilmente diagrammi di Gantt molto dettagliati, belli e scenici. Il problema era che durante la fase di esecuzione del progetto se ne facevano davvero poco: il deliverable che mi consegnavano era un documento esteticamente molto bello, ma praticamente inutile. Non ho mai visto un gruppo di studenti utilizzare il diagramma di Gantt come efficace guida durante lo sviluppo del progetto. Perché?

Al momento non riuscivo a capire i motivi dell’insuccesso. La letteratura era ricca di questi diagrammi e di software importanti, e.g. Microsoft Project, che ne prevedevano lo sviluppo. Eppure in classe non funzionavano, oppure funzionavano soltanto all’inizio e presto venivano abbandonati. Una sorta di insuccesso che avevano gli studenti; insuccesso che avevo anch’io tutte le volte che provavo ad impostare un mio progetto. E questa mia incapacità personale in fondo la ritenevo la causa vera degli insuccessi degli studenti in classe. La parte del diagramma che per un po’ funzionava era la costruzione dell’elenco delle attività mentre i tempi, le famose barre, non venivano mai rispettati.

Soltanto molti anni più tardi, quando ho approfondito scientificamente il Project Management, ho avuto la piacevole conferma di non essere stato il solo ad esperire questi insuccessi.  Il diagramma di Gantt è un artefatto strettamente legato alla progettazione Waterfall. Questo modello fissa tempi e piani molto rigidi che male si sposano con la progettazione agile, necessaria per gestire le complessità emergenti, soprattutto di classe.  In riferimento al diagramma di Gantt, Jeff Sutherland : “I ritardi … erano endemici. I primi piani step by step, descritti in confortevoli diagrammi di Gantt, però assicuravano il Management di avere il controllo del processo di sviluppo, ma in realtà fallivano tutti, sforando i tempi rapidamente e andando disastrosamente oltre il budget previsto. … Con l’avvento del personal computer negli anni 80, che ha reso molto facile creare questi grafici complicati – e renderli veramente complessi – sono diventati una vera opera d’arte. Ogni singolo passo del progetto è descritto in dettaglio. Ogni milestone. Ogni data di consegna. Questi grafici sono veramente impressionanti alla vista. Il vero problema è che sono sempre – sempre – sbagliati”. E quindi? Lo stesso Sutherland propone di basarci “su un’idea semplice: ogni volta che avviate un progetto, perché non controllarlo regolarmente, verificare se andate nella direzione giusta e se è veramente ciò che le persone vogliono? E controllare se ci sono modi di migliorare come fare ciò che fate, per farlo meglio e più velocemente, e che cosa potrebbe ostacolarvi dal farlo. È quello che viene definito il ciclo “ispeziona e adatta”. A brevi intervalli, fermatevi e rivedete quello che avete fatto, controllate se è ancora quello che dovreste fare e come potreste fare meglio. Questo, come vedremo, sarà il cuore della fase di esecuzione.”

Sutherland la definisce un’idea semplice. Così semplice da applicare in classe non è. Quello che stiamo sperimentando per fare in modo che gli studenti, durante la fase di esecuzione, partano davvero dal piano di progetto e lo seguano è di evidenziare per ogni attività l’eventuale prodotto associato, addirittura stiamo sperimentando di sostituire l’elenco delle attività con l’elenco dei prodotti intermedi attesi. Parlare di prodotti invece che di attività è una istanza di concretezza alla quale gli studenti sono molto sensibili: è naturale seguire un insieme di prodotti da realizzare più che di attività da eseguire.