Nel mondo delle costruzioni e, più in generale, in quello della gestione dei progetti, capita spesso d’imbattersi in una pluralità di commesse simili, caratterizzate dalla presenza di forti analogie. Questi progetti costituiscono un programma, a capo del quale è usualmente posto un Program Manager. Di solito, ogni commessa ha il suo responsabile, sebbene possa capitare che due o più progetti siano affidati al medesimo Project Manager. In qualche caso, egli potrebbe anche coincidere con il Program Manager: si tratta di una soluzione frequente, soprattutto nel caso dei programmi più piccoli.
Methodology Management ed Enterprise Project Structure (EPS)
La presenza di forti analogie fra le commesse rende particolarmente conveniente la creazione prima e l’uso poi di un Repository comune, in cui porre le Best Practice aziendali. Grazie a una pluralità di Template, ciò che si è fatto nel passato può essere utilizzato come base di partenza per agevolare la pianificazione dei progetti futuri. Questo modo di procedere potrebbe rivelarsi utile, fra l’altro, anche in fase di preventivazione, qualora si decidesse di partecipare a una o più gare, al fine di aggiudicarsi altrettanti appalti. Un Repository comune, infatti, può costituire un’ottima base di partenza per l’implementazione di un raffinato sistema di preventivazione parametrica. Quando si è chiamati a gestire una pluralità di commesse caratterizzate da forti analogie, bisogna predisporre l’Enterprise Project Structure, in modo tale da prevedere un ramo di primo livello per il programma, sotto il quale vanno collocati i progetti che lo costituiscono. A ciascuno di essi corrisponde un ramo di secondo livello.
=> Project Manager e Leadership: guida pratica
Work Breakdown Structure (WBS)
Per ogni commessa, occorre creare la cosiddetta struttura di scomposizione del lavoro. In pratica, si tratta di raggruppare i compiti da svolgere in una pluralità di famiglie, che potrebbero orientativamente essere le seguenti: Project Management, Design/Engineering, Manufacturing & Procurement, Construction e Test & Commissioning/Close Out. Il primo gruppo potrebbe comprendere le Contractual Milestone e i QA/QC Meeting. All’interno del secondo, invece, andrebbero poste le attività di elaborazione, stesura e rilascio dei cosiddetti Shop Drawing (prima) e degli As Built Drawing (poi). Lo stesso discorso vale per gli Operation & Maintenance Manual. La terza famiglia è di fondamentale importanza: un grossolano errore nella pianificazione di un suo Task, infatti, potrebbe avere delle conseguenze a dir poco disastrose sulle attività di Construction e, di conseguenza, sulla Completion Date. La fase di Test & Commissioning/Close Out, infine, termina con la Beneficial Occupancy Date (BOD), quando il beneficiario, che non coincide necessariamente con il committente, prende possesso dell’edificio o dell’impianto (Turnkey Contract).
A ciascun raggruppamento corrisponde un ramo di primo livello all’interno della Work Breakdown Structure. Sotto di esso, è possibile inserire degli altri rami, con figli e nipoti. Così, per esempio, la famiglia costituita dalle attività di Construction potrebbe comprendere i seguenti gruppi di Task: 1) accantieramento/Mobilization; 2) Foundation; 3) Elevation; 4) Roofing; 5) Electrical/Mechanical Plant; 6) Finishing; 7) Furniture & Equipment. A ciascuno di questi insiemi corrisponderebbe un ramo di secondo livello, all’interno della struttura di scomposizione del lavoro. Il processo di analisi e disaggregazione fin qui descritto può essere continuato sino al raggiungimento del livello di dettaglio desiderato, dando vita a una struttura ad albero sempre più complessa, costituita da una moltitudine di rami, in cui le foglie corrispondono ai vari Task.
Drawing Code
L’adozione dell’innovativo approccio noto come Fast Track Implementation può stravolgere il tradizionale ciclo di vita dei progetti, con pesanti ripercussioni sull’intera Work Breakdown Structure. Salvo rare eccezioni, i vari Shop Drawing andrebbero rilasciati prima che la fase di Construction abbia inizio. In questo modo, ci sarebbe la possibilità di collegarli alle attività da svolgere. Ciò potrebbe essere fatto per mezzo di opportuni codici, usualmente chiamati Activity Code. In genere, la corrispondenza Shop Drawing – attività da svolgere non è biunivoca, bensì di tipo molti a molti (molti -> molti). Tramite la costruzione di opportuni filtri, gli Activity Code, i Project Code, i Resource Code e gli User Defined Field permettono di visualizzare soltanto ciò che interessa, snellendo le operazioni di pianificazione (Project Scheduling) e agevolando quelle di controllo (Project Control).
=> OPPM: gestire il progetto su un unico foglio di calcolo
Altri codici
Fra questi, ci sono i seguenti: Phase Code, Area Code, Responsibility Code, CSI Code, Modification Code e Request for Equitable Adjustment (REA)/Claim Code. Il Phase Code permette d’individuare la fase del ciclo di vita della commessa alla quale appartiene il Task oggetto d’interesse. Salvo rare eccezioni, la corrispondenza fra le attività da svolgere e le fasi del ciclo di vita del progetto dovrebbe essere di tipo molti a uno (molti -> 1), non essendo possibile che il medesimo Task appartenga a più fasi del ciclo di vita della stessa commessa. Una possibile eccezione a quanto appena esposto potrebbe essere rappresentata da un’attività di tipo Level of Effort (LoE), estesa dall’inizio alla fine del progetto. Un esempio in tal senso può essere costituito da un ipotetico Task chiamato genericamente “Project Management” e comprendente tutti gli aspetti di carattere meramente gestionale. Il Project Manager, infatti, segue le commesse di sua competenza dall’inizio alla fine, attraverso tutte le fasi del loro ciclo di vita. L’Area Code si rivela utile soprattutto nel caso di un grande progetto di Construction, che può essere diviso in più zone (per esempio: North, South, East e West Area). In questo modo, è facile capire a quale zona si riferiscono le varie attività da svolgere. Si noti, comunque, che lo stesso risultato potrebbe essere ottenuto tramite una struttura di scomposizione del lavoro ad hoc, oppure includendo nel nome di ciascun Task l’informazione presente nel corrispondente Area Code (per esempio: “Concrete Pouring – North Area” al posto di Activity Name = “Concrete Pouring” + Area Code = “North Area”).
Il Responsibility Code permette di associare a ciascun compito da svolgere il suo responsabile (General Contractor, Subcontractor, liberi professionisti, lavoratori autonomi et cetera). Per ogni attività, dovrebbe esserci un solo responsabile, con una corrispondenza di tipo molti a uno (molti -> 1), poiché più Task possono dipendere dalla medesima risorsa. Il CSI Code è, per certi versi, analogo al Drawing Code. Infatti, esso consente di legare i compiti da svolgere alle specifiche emesse dalla committenza. Il Modification Code permette di gestire meglio le attività che sono state aggiunte, cancellate o modificate in base a una o più Contract Modification (Project Change). Per certi versi, il Request for Equitable Adjustment (REA)/Claim Code è analogo al Modification Code, ma è legato a eventuali riserve. Esse rappresentano un fallimento, spesso imputabile all’assenza di una proficua comunicazione e, soprattutto, di una reale Partnership fra i vari Stakeholder.
=> Tempi e scadenze con il diagramma di Gantt
Activity Network e Gantt Chart
Dal punto di vista concettuale, la costruzione di una rappresentazione reticolare delle commesse dovrebbe precedere la stesura dei rispettivi diagrammi di Gantt. Quando i compiti da svolgere vengono subappaltati ai vari Subcontractor, che sono responsabili della loro esecuzione, il General Contractor può non essere interessato a un cronoprogramma che includa anche l’allocazione delle risorse. Dal punto di vista concettuale, ciò equivale a rinunciare alla formulazione di esplicite ipotesi circa la capacità produttiva effettivamente disponibile, sebbene nella realtà essa sia sempre finita/limitata. In pratica, queste considerazioni sono demandate ai vari Subcontractor, chiamati ad allocare le risorse facendo fronte agli impegni presi circa il rispetto dei tempi di consegna. Occorre notare, comunque, come tutto ciò sia, in realtà, già parzialmente presente nel cronoprogramma redatto dal General Contractor. La durata prevista per lo svolgimento dei vari compiti (Original Duration), infatti, è legata alla stima della disponibilità delle risorse necessarie per la loro esecuzione. Un buon diagramma di Gantt dovrebbe privilegiare i legami logici (Relationship: Finish to Start, Finish to Finish, Start to Finish o Start to Start) a scapito delle Constraint, in modo tale da lasciare i Task liberi di scorrere. L’introduzione di un vincolo di progetto (Must Finish By) è preferibile all’utilizzo di pietre miliari (Milestone) abbinate a Constraint di tipo Finish On/Mandatory Finish, che possono ostacolare la corretta visualizzazione del programma lavori, soprattutto in presenza di un cospicuo ritardo (Total Float < 0 giorni).
* Giovanni Bonini (giovanni-bonini@virgilio.it)
