Il ciclo di Deming rappresenta uno dei principali riferimenti concettuali, quando si deve gestire, pianificare e controllare un progetto, sia esso CAPEX od OPEX:
Plan → Do → Check → Act
Molti Tool di Project Management, Planning/Scheduling & Control si basano sul Critical Path Method (CPM), che consente di pianificare il lavoro da eseguire a capacità infinita, vale a dire come se non ci fosse alcun limite alla disponibilità delle risorse (equipaggiamenti, manodopera e materiali). Di conseguenza, la soluzione proposta potrebbe anche non essere ammissibile: per rendersene conto, bisognerebbe valutare attentamente i carichi di lavoro, livellando le risorse sovraccariche. Con ogni probabilità, ciò avrebbe un impatto sui tempi di esecuzione. Per questo, bisognerebbe rivedere la pianificazione, verificando l’ammissibilità della nuova soluzione dal punto di vista dei carichi di lavoro. In pratica, si tratta di un processo iterativo, che prevede più Step.
Salvata la pianificazione iniziale (Baseline), dopo averla approvata/validata, si procede con l’esecuzione del lavoro e il conseguente aggiornamento del piano, inserendo i consuntivi, la percentuale di completamento, le date effettive d’inizio (per le attività Completed e In Progress) e fine (per i soli Task Completed), oltre alle stime a finire (per le attività In Progress).
Ovviamente, la percentuale di completamento:
- è nulla (0%) per i Task Not Started;
- è unitaria (100%) per le attività Completed;
- deve essere opportunamente stimata (0% < Physical % Complete < 100%) per i Task In Progress.
È possibile rivedere la durata attesa dei compiti ancora da svolgere (Not Started), in base ai migliori dati disponibili: di solito, più si guarda lontano, maggiore è l’incertezza. A mano a mano che ci si avvicina all’inizio del lavoro da eseguire, invece, emergono nuovi dati, che consentono di correggere il tiro, perché l’incertezza cala. Quindi, è possibile aggiornare le stime di durata per le attività Not Started.
A questo punto, occorre lanciare nuovamente l’algoritmo di pianificazione, ottenendo una nuova soluzione:
- da confrontare con la Baseline, al fine di verificare l’efficienza (Cost Variance e Cost Performance Index) e l’efficacia (Schedule Variance e Schedule Performance Index) con cui si sta procedendo nell’esecuzione del lavoro, rispetto alla previsione iniziale;
- la cui ammissibilità dovrà essere verificata, sia dal punto di vista dei tempi (rispetto delle Deadline di progetto) sia per quel che concerne i carichi di lavoro.
In base al risultato emerso dall’analisi degli scostamenti, può rendersi necessario redigere un Recovery Plan: in pratica, si tratta d’implementare un meccanismo di controllo in catena chiusa, basato sul concetto di retroazione, particolarmente caro ai cultori dei controlli automatici e della meccatronica.
In realtà, soprattutto nel settore industriale dell’ingegneria, ci si può imbattere in Aziende con più progetti in portafoglio, che impiegano le medesime risorse condivise (Project Portfolio Management, Planning/Scheduling & Control). Quando ciò accade, la complessità è notevole: la medesima risorsa, infatti, può essere assegnata non solo a più Task facenti parte dello stesso progetto, ma anche a più progetti, ciascuno dei quali potrebbe avere una differente data di consegna contrattualmente imposta.
In genere, i Tool di Project Portfolio Management, Planning/Scheduling & Control si limitano a fornire una soluzione la cui attendibilità dipende dalla bontà dei dati, cioè degli Input. Per ogni progetto, infatti, bisogna conoscere e inserire:
- tutte le date che rappresentano dei vincoli per il progetto. Un esempio è costituito dall’eventuale presenza di una data di consegna contrattualmente imposta;
- il Project Calendar;
- tutte le attività, con i loro calendari (se differiscono dal Project Calendar), le durate, le risorse impiegate, i relativi costi, le curve di carico e i vincoli eventualmente presenti (da usare sempre con estrema parsimonia);
- i legami logici fra i Task, comprensivi dei Lag eventualmente presenti (positivi o negativi; per Default, infatti, tutti i Lag sono nulli).
Figura 1. Le curve di carico (profilo del lavoro, se si utilizza ProjectLibre) esprimono la legge con cui le ore/uomo di una risorsa di tipo Labor si distribuiscono sulla durata del compito che dovrà essere svolto dalla risorsa in questione. In questo esempio, Luca e Paolo sono stati assegnati all’attività – 1 (“Progettazione”). L’impiego di Luca sarà inizialmente massimo (8 ore uomo/giorno), per poi scemare (curva di carico Front Loaded). Paolo, invece, dovrà dedicarsi al Task in questione 8 ore uomo/giorno, tutti i giorni, fino al suo completamento (profilo del lavoro piatto).
Quando si utilizza il Critical Path Method (CPM), la data d’inizio e quella di fine di ogni attività, insieme allo scorrimento totale (Total Float) e a quello libero (Free Float), rappresentano i principali Output, a cui occorre aggiungere la durata del progetto, che è un campo calcolato, e i carichi di lavoro.
È importante osservare come, per ogni Task, anche la data d’inizio e quella di fine siano dei campi calcolati, con la sola eccezione delle date imposte dai vincoli eventualmente presenti, che vanno usati con estrema parsimonia, proprio perché alterano (in alcuni casi anche pesantemente) la logica reticolare.
Troppe persone continuano a utilizzare il Software di Project (Portfolio) Management, Planning/Scheduling & Control come se si trattasse di un Tool grafico, su cui riportano la pianificazione che hanno in mente, bloccando le attività con delle date vincolate. Non è certamente questo il modo più corretto e conveniente di procedere, poiché i vincoli impediscono ogni possibile scorrimento dei Task: ciò è palesemente in disaccordo con la realtà. Inoltre, se la data d’inizio del progetto (che, come si è visto, rappresenta un Input) dovesse slittare, bisognerebbe spostare a mano tutte le attività. Nel caso di un diagramma di Gantt con centinaia di compiti da svolgere, la perdita di tempo sarebbe decisamente notevole.
Stimare la durata dei Task non è affatto semplice: per questo, è estremamente importante sviluppare un Repository in cui porre Best Practice, Lesson Learned e Template, da aggiornare continuamente.
Quando devono stimare la durata di un’attività, le persone sono portate a nascondere un Buffer all’interno dell’Original (o Planned) Duration, perché nessuno gradisce fare brutta figura o lavorare in condizioni di Stress estremo.
Immaginiamo che ci venga chiesto quanto tempo potrebbe servire per svolgere un certo compito. Se pensassimo che 5 giorni lavorativi potrebbero essere sufficienti, con ogni probabilità saremmo portati a rispondere “5 + X giorni lavorativi”, con X > 0 giorni lavorativi (Buffer nascosto).
Durante l’esecuzione, sapendo che il tempo a nostra disposizione è sovrabbondante, saremmo portati a “prendercela comoda”: la legge di Parkinson, infatti, afferma che le persone tendono a sfruttare tutto il tempo disponibile.
Come se ciò non bastasse, le persone sono affette anche dalla temibile sindrome dello studente: in pratica, si è portati a procrastinare tutto ciò che è differibile, attendendo l’ultimo momento (il giorno prima dell’esame) per svolgere i compiti assegnati.
Quindi, sovradimensionare la durata attesa, annegando al suo interno un Buffer nascosto, non garantisce che il lavoro sarà effettivamente completato nel rispetto dei tempi pianificati. Al contrario, è un ottimo modo per generare (e mantenere) delle inefficienze, rendendole strutturali, poiché legate a una modalità operativa in corso di consolidamento.
Tornando all’esempio proposto, ipotizziamo che sia: X = 5 giorni lavorativi. Alla luce delle considerazioni espresse in merito alla legge di Parkinson e alla sindrome dello studente, 10 giorni lavorativi potrebbero rivelarsi insufficienti per svolgere il Task in questione. Di conseguenza, a consuntivo, l’Actual Duration potrebbe risultare pari a 11 o 12 giorni lavorativi: ben 2,2 – 2,4 volte il tempo che si pensava inizialmente sufficiente per svolgere il compito assegnato (5 giorni lavorativi).
Alla luce di questo semplice esempio didattico, che è meno lontano dalla realtà (ufficio tecnico, produzione, cantiere et cetera) di quanto si possa pensare, non ci deve stupire il frequente dilatarsi dei tempi di esecuzione, evidente anche nel caso di molti progetti pubblici o di ricerca scientifica.
Che cosa possiamo fare? C’è un modo per ovviare a tutto questo? La risposta, fortunatamente, è affermativa e una possibile soluzione è costituita dal Critical Chain Project Management, illustrato nella figura seguente:
Figura 2. Un confronto fra il Critical Path Method (CPM), in alto, e il Critical Chain Project Management (CCPM), in basso. I legami logici sono esattamente gli stessi. Cambiano, però, le stime delle durate delle attività e il monitoraggio del progetto.
L’idea alla base del Critical Chain Project Management (CCPM) è relativamente semplice: anziché nascondere dei Buffer nelle durate dei Task, conviene esplicitarli, per proteggere la catena critica (Project Buffer) e le catene che vanno a innestarsi su quella critica (Feeding Buffer). Di conseguenza, le attività sembrano essere più brevi, quando si adopera il Critical Chain Project Management (CCPM), proprio perché le loro durate vengono stimate in maniera particolarmente sfidante, spingendo nella direzione del miglioramento continuo.
La penetrazione dei Buffer permette di monitorare la corretta esecuzione del lavoro: una cospicua erosione del margine di sicurezza rappresenta sempre un campanello di allarme, soprattutto se si manifesta in tempi particolarmente brevi.
