Anche se in questi ultimi anni è stato dato ampio spazio al Project Management, il Project Control continua a essere poco conosciuto e ancor meno utilizzato

In tempi abbastanza recenti, la criticità del controllo è stata ampiamente evidenziata nel corso del Workshop “Il Project Control nelle PBE italiane” (SDA Bocconi, Milano), con particolare riferimento al settore civile e ambientale e a quello industriale. Soprattutto nella gestione dello sviluppo del software, non è infrequente perdere di vista lo Scope Of Work. Questo costituisce l’esempio più evidente di assenza o perdita di controllo, in cui si dovrebbe fare x, mentre ci si ritrova a perseguire l’obiettivo y ≠ x. “Do the right job & do the job right”: ecco l’essenza del Project Control. Non basta, infatti, fare la cosa giusta: occorre anche farla nel migliore dei modi. L’applicazione dell’Earned Value Management System non è sufficiente per garantire il successo dei progetti. Infatti, essa non permette di controllare il pieno rispetto delle specifiche funzionali e di quelle tecniche (“Do the right job”), limitandosi al solo monitoraggio di quanto già pianificato (“Do the job right”). Nonostante sia di fondamentale importanza, l’Earned Value Management System continua a essere una sorta di mosca bianca per molte Project Based Enterprise italiane. Quando si opera in ambito IT, l’applicazione dei principi alla base dell’Earned Value Management System è poco fattibile. Nella gestione dello sviluppo del software, infatti, sovente si utilizzano degli approcci ad hoc, indicati con il nome di metodologie.

Consulenza e monitoraggio
Capita spesso che il consultant sia chiamato a porre rimedio all’assenza di controllo, capace di spingere i progetti alla deriva. Nella maggior parte dei casi, la perdita di controllo è tanto graduale quanto perfida e subdola: di solito, infatti, ci si rende conto della presenza di un problema soltanto quando, ormai, è troppo tardi, non restando altro da fare che salvare il salvabile. Il consulente dovrebbe comportarsi come una sorta di osservatore esterno, capace di analizzare i processi in tutta la loro estensione, studiandoli da ogni concepibile punto di vista. In molti casi, le cause del fallimento non sono contingenti ma strutturali, dipendendo da approcci del tutto inadeguati. Per questa ragione, le soluzioni prospettate andrebbero discusse, testate, interiorizzate e rese strutturali, entrando a far parte di un ridotto insieme di best practice aziendali, ben consolidate e poste in un repository comune. Queste dovrebbero essere assunte come base di partenza per un serio processo di miglioramento continuo, capace di rompere la cristallizzazione osservabile in una moltitudine di realtà. A volte, il mantenimento dello status quo è la naturale conseguenza del pensiero di sedicenti manager di successo, che finiscono con lo sposare il tristemente ben noto principio: “Se non conosco z, significa che non mi serve”. Troppo spesso, infatti, non c’è alcuna apertura al cambiamento, che continua a essere fortemente osteggiato.

Loosing & Restoring Control
Per evitare che accada l’irrimediabile, occorre essere proattivi, individuando tutti i possibili problemi, in modo tale da correre ai ripari prima che sia troppo tardi. Per fare questo, è necessaria un’adeguata pianificazione iniziale, che deve rappresentare il punto di partenza per il Lookahead Planning, fondato sul w Week Lookahead Report/Schedule (con w = 1, 2 o 3), e per il conseguente aggiornamento del piano. Una precisa registrazione del Progress (SAL: Stato di Avanzamento dei Lavori) è necessaria per fare periodicamente il punto della situazione. In pratica, si tratta d’implementare un vero e proprio sistema di controllo in catena chiusa, basato su continui e incessanti Feedback, che devono essere seguiti dagli interventi correttivi ritenuti più convenienti o indispensabili (PDCA: Plan → Do → Check → Act).  Grazie al cosiddetto Network Analysis Schedule/System, è possibile evidenziare le principali criticità, caratterizzate da uno scorrimento totale nullo, e le varie ipercriticità, con un Total Float negativo. Confrontando il Budgeted Cost of Work Performed con il Budgeted Cost of Work Scheduled, si possono calcolare la Schedule Variance e lo Schedule Performance Index, che consentono di tenere sotto controllo i tempi di esecuzione. Analogamente, il Budgeted Cost of Work Performed e l’Actual Cost of Work Performed permettono di giungere alla Cost Variance e al Cost Performance Index, grazie ai quali è possibile monitorare i costi di esecuzione.
Sebbene uno scorrimento totale minore di zero implichi sempre il posticipo della Completion Date, si potrebbe avere un ritardo, rispetto alla pianificazione iniziale, anche in assenza di un Total Float negativo. Oltre allo scorrimento totale bisognerebbe considerare pure quello libero. Il ritardo potrebbe riguardare soltanto le attività non critiche, caratterizzate da un Total Float strettamente positivo, o quelle Near Critical, per le quali lo scorrimento totale non è superiore a quattordici giorni di calendario. Insomma, sebbene il Critical Path, che può anche non essere unico, sia di fondamentale importanza, esso andrebbe sempre contestualizzato e inserito in una visione più ampia, capace d’includere l’intera rete (Activity Network). Il monitoraggio di tutti i task che precedono una determinata attività permette l’individuazione a monte di ogni possibile problema. In questo modo, si ha il tempo necessario per approntare gli interventi correttivi ritenuti più adeguati e maggiormente convenienti. Per esempio, i Task di Construction sono usualmente spinti dalle attività di Design, Manufacturing e Procurement, sicché monitorando i predecessori è possibile estendere il controllo pure ai Task che li seguono. Alla base del modus operandi appena descritto c’è un concetto tanto semplice quanto importante: il Project Manager di successo non passa il suo tempo a risolvere i problemi bensì a evitare che insorgano.

Mettere l’uomo al centro
I progetti sono fatti dalle persone per le persone: per questo, è importante mettere l’uomo al centro, prendendo in considerazione il parere di ogni Stakeholder. Con cadenza settimanale, bisognerebbe sondare le opinioni del panel di esperti di cui si dispone, vale a dire le figure chiave coinvolte nella realizzazione del progetto: Project Manager, Project Leader, Project Planner/Scheduler, Project Controller, Project Management Officer, QA/QC Manager, Safety Officer, Site Superintendent, rappresentanti della committenza e dei beneficiari. Questi Project Meeting potrebbero essere tenuti in occasione del rilascio, su base settimanale, del già citato w Week Lookahead Report/Schedule, attorno al quale dovrebbe vertere la discussione. Mentre il 3 Week Lookahead Report è generato, grazie all’ausilio di strumenti informatici, partendo dalla pianificazione iniziale e dai suoi aggiornamenti settimanali, il 3 Week Lookahead Schedule rappresenta una sorta di pianificazione dettagliata di breve periodo, relativa alla settimana successiva e alle due che la seguiranno. In un certo senso, il 3 Week Lookahead Schedule permette di apprezzare con un maggior livello di dettaglio quanto presente nell’omonimo Report, ottenuto partendo dalla Baseline o dal Weekly Network Analysis Update, che consiste nell’aggiornare il piano con cadenza settimanale. Dal punto di vista operativo, si potrebbe procedere nel modo seguente. Il Progress andrebbe registrato su base settimanale e inserito nel programma lavori il venerdì pomeriggio. Il rilascio del 3 Week Lookahead Report potrebbe seguire l’Update del piano, portando alla successiva stesura del 3 Week Lookahead Schedule, messo a disposizione il lunedì mattina. Ovviamente, i task presenti nella pianificazione dettagliata di breve periodo devono essere opportunamente legati alle attività presenti nel cronoprogramma originario. Questo può essere fatto, per esempio, tramite l’Activity ID. Così, al task Concrete Pouring (A1000), presente nel diagramma di Gantt da cui si è partiti, potrebbero corrispondere le attività:

 

• Concrete Pouring North Area (A1000_N)
• Concrete Pouring South Area (A1000_S)
• Concrete Pouring East Area (A1000_E)
• Concrete Pouring West Area (A1000_W)

 

Le quattro zone in questione (Nord, Sud, Est, Ovest) dovrebbero essere ben evidenziate nei disegni, legati ai Task dai Drawing Code. Il modo di procedere fin qui presentato agevola la pianificazione, da un lato, e la registrazione del Progress, dall’altro. L’ultimo aspetto, vale a dire la rilevazione della Physical % Complete, è alla base del Project Control, trattandosi dell’elemento da cui si parte per il calcolo dell’Earned Value Cost. L’inserimento dell’avanzamento nel programma lavori richiede un’opportuna aggregazione o Roll Up di quanto registrato in base alla pianificazione dettagliata di breve periodo (3 Week Lookahead Schedule).

 
A ruota libera
Mettere l’uomo al centro significa anche dare valore alle cosiddette risorse umane, vale a dire al bagaglio culturale delle persone e all’esperienza conseguita in anni di lavoro. Per questo, le opinioni e le percezioni del panel di esperti di cui si dispone andrebbero sempre confrontate con i risultati prodotti dal Network Analysis System. Eventuali discrepanze, soprattutto se marcate, dovrebbero essere oggetto di un’analisi particolarmente attenta. Le seguenti domande potrebbero aprire la discussione, che dovrebbe accompagnare i vari Project Meeting. I quesiti proposti si riferiscono al caso, purtroppo abbastanza frequente, di un progetto in ritardo. Come si è visto, però, la virtù consiste nello stroncare i problemi sul nascere, non nel correre ai ripari per fronteggiare le loro conseguenze. Nella tipica situazione di un progetto che sembra essere in ritardo, si potrebbe chiedere ai vari Stakeholder:

 

1) Credete che sia possibile rispettare la Completion Date contrattualmente prevista?
2) Quando pensate che il progetto possa essere completato?
3) Qualora riteniate che vi siano dei ritardi, da che cosa potrebbero dipendere?

 

Il terzo quesito apre le porte a una serie di ulteriori domande, atte a investigare circa la natura e le presunte cause dei possibili ritardi, che potrebbero essere legati: a conflitti o problemi con la committenza, i beneficiari, le autorità locali o gli altri Stakeholder (si pensi, per esempio, al frequente ritrovamento di reperti archeologici durante gli scavi); a rapporti assai tesi con eventuali Partner, nel caso di una Joint Venture con scarso spirito di collaborazione; a tensioni con i Subcontractor, se presenti; a cause di forza maggiore; a una struttura organizzativa inadeguata; a scarso supporto da parte dell’azienda o della direzione generale; ad approcci di Project Management insoddisfacenti o lacunosi; all’assenza di un reale Project Scheduling & Control; a problemi inerenti alla qualità o alla sicurezza; a risorse umane inadeguate o insufficienti; a un sistema informativo inesistente o non abbastanza evoluto.