Piani e progetti

Strategie e piani di battaglia

Vediamo in azione il project manager che, come uno stratega militare, fa piani di battaglia e coordina le forze in campo in uno spazio mutevole, denso di rischi, seguendone gli sviluppi e registrando i progressi.

Carl von Clausewitz (Burg bei Magdeburg, 1.6.1780 – Breslavia, 16.11.1831), il più famoso teorico moderno dell'arte militare, nel 1832 dava la seguente definizione di strategia o piano di battaglia nel famoso “Vom Kriege” (Della guerra):

 

«…l'impiego del combattimento agli scopi della guerra. Esso deve dunque porre ad ogni atto bellico uno scopo immediato che possa condurre a quello finale. In altri termini, elabora il piano di guerra, collega allo scopo immediato predetto la serie delle operazioni che ad esso debbono condurre, e cioè progetta i piani delle campagne e ne coordina i singoli combattimenti…»

Le similitudini con i nostri piani di progetto sono impressionanti. In una sola frase von Clausewitz ci parla di scopi intermedi e finali, operazioni e loro collegamenti, elaborazione e progettazione di piani, coordinamento delle forze in campo.

Quando parliamo di piano di progetto, il nostro pensiero va subito a rappresentazioni come il Gantt, il Pert, o il cronoprogramma. Nell’esperienza professionale di tutti i giorni, i project manager hanno il loro bel daffare a correggere il più comune dei fraintendimenti nel settore dei progetti: il piano di progetto non è (solamente) un Gantt o qualsiasi altra rappresentazione delle attività su una scala temporale; e non si comprende come mai, quando si parla di progetti, si associa al termine piano il concetto di tempo. Eppure sono nozioni molto distanti tra loro, tanto da poter affermare che la rappresentazione grafica di attività distribuite nel tempo è tutt'altro che naturale e non appartiene al patrimonio della cultura comune. Inoltre il tempo non è una variabile indipendente ma essa è influenzata da altri fattori chiamati rischi tra noti e ignoti. Quando si parla di guerra, si associa al termine piano l’idea di battaglia e in particolare la disposizione delle forze in campo. Giungo alla conclusione che dovremmo pensare ai progetti più in termini di battaglie che di pacifiche attività produttive; dopo tutto, anche se nei progetti non scorrono fluidi vitali, si fanno pur sempre morti, feriti e prigionieri sebbene nel loro significato figurativo. Ma i danni, anche quelli collaterali, possono essere molto ingenti tanto da scatenare guerre legali che sono tutt'altro che figurate.

Chiarita l’idea che i piani di progetto sono molto articolati e vanno ben oltre la pianificazione temporale delle attività, diciamo subito che essi portano con se rischi, modifiche e progressione del completamento.

I piani rispondono alle domande “Come? Quando? Quanto?”

Il parallelo con i piani di battaglia è dunque ben giustificato se consideriamo quante analisi di rischio, di rapporti causa-effetto e quanto monitoraggio e controllo richiedono le battaglie vere e proprie e quelle progettuali. Inoltre il concetto di piano di progetto, come quello di battaglia, viaggia col concetto di comunicazione. A titolo di esempio, nella prima pagina del 7° capitolo del “Managing Successful Projects with PRINCE2” incontro per ben quattro volte la parola “information”; sembra proprio che “planning” e “information” viaggino insieme. Leggo con attenzione e trovo la conferma che i piani, fatti e custoditi nella scrivania del project manager e mai comunicati, hanno lo stesso impatto sul progetto di un buco nell'acqua. Infatti le pianificazioni sono la spina dorsale dei sistemi di gestione dell’informazione di progetto, se e solo se sono oggetto di comunicazione ai vari livelli gerarchici del project team, committenza inclusa. Se trovo con facilità i documenti di pianificazione di progetto sono abbastanza confidente che il progetto gode di buona comunicazione. E se apro l’archivio di progetto e trovo in bella vista una pianificazione aggiornata, sono confidente che sia un progetto ben gestito. E un progetto ben gestito e con un buon processo di comunicazione è un progetto con ottime probabilità di successo.

Ma a cosa servono, dunque, i piani? A informare e allineare tutte le persone e organizzazioni coinvolte nel progetto riguardo:
  • il “cosa”;
  • il “come” sarà ottenuto e “chi” lo produrrà;
  • il “quanto” di risorse economiche, umane, di prodotti e di attrezzature che saranno impiegate;il “quando” sono previsti determinati eventi rilevanti;
  • il “grado di avanzamento” verso gli “obiettivi” di progetto (tempo, costo, qualità, ambito, rischi e benefici) e se sono ancora raggiungibili e in che misura.
I piani devono essere sviluppati e mantenuti credibili; anche su questo tema si potrebbe dibattere a lungo sulle deprecate abitudini di fare piani molto accurati nella fase di acquisizione dell’incarico, fatto salvo abbandonarli e riprenderli solo in occasione di audit esterni o SAL. Il mantenimento in termini credibili dei piani deve essere considerata attività progressiva e continua perché la “scommessa” iniziale contenuta nel piano originale, è soggetta a mutazioni nelle direzioni del tempo, costo, ambito, qualità, rischi, benefici.

(Il temine inglese “scope” è comunemente tradotto con la parola ambito, intendendo il dominio entro cui è definito il “cosa” del progetto. I prodotti del progetto possono cambiare ed essere modificati entro il perimetro dell’ambito per venire incontro a mutate condizioni al contorno. Lo “scope” invece non dovrebbe cambiare perché andrebbe a modificare profondamente il Business Case.)

I piani di progetto sono documenti dinamici che godono della vitalità che il project manager concede loro. Sussiste una stretta correlazione tra salute del progetto e tempo dedicato dal project manager alla stesura e mantenimento credibile dei piani di progetto, tanto da affermare che, l’attività di planning non è mai banale indipendentemente dalle dimensioni del progetto.

Ma qual è la ragione intima per cui senza piani aggiornati e credibili non è possibile raggiungere il risultato di progetto richiesto? Qualunque progetto possiede un orizzonte temporale oltre il quale nessuno è in grado di vedere nel dettaglio. Questo è il cosiddetto orizzonte di pianificazione. L’orizzonte di pianificazione, pur rimanendo di lunghezza costante – ad esempio 180 giorni solari – scorre sull'asse temporale come i giorni del calendario. All'inizio del progetto, il project manager descriverà con molto dettaglio le attività, le risorse, i tempi di esecuzione e la qualità entro l’orizzonte di pianificazione. Tutto ciò che va oltre quell'orizzonte è abbozzato con un dettaglio progressivamente decrescente. Un piano non aggiornato è un piano il cui dettaglio delle attività presenti è rimasto abbozzato per il progressivo incedere dell’orizzonte di pianificazione. Un piano non aggiornato sull'orizzonte di pianificazione corrente è come una lente sfocata che non consente di vedere il sentiero che dovremmo seguire per arrivare alla meta.

(L'orizzonte di pianificazione, ha una lunghezza che è funzione inversa del grado di incertezza per un particolare settore di interesse. In molti settori industriali maturi, l'orizzonte di pianificazione è definito in base a calcoli statistici sulle serie storiche di eventi pregressi. Da ciò discende che quanto più il settore è innovativo tanto più breve è l'orizzonte di pianificazione venendo a mancare le nozioni maturate in passate esperienze.)

Abbiamo detto che i documenti di pianificazione sono strumenti primari di comunicazione e decisione. Come tali hanno caratteristiche diverse in funzione dei destinatari. I piani di progetto hanno in genere tre livelli di gestione: a livello di intero progetto, a livello di fasi di progetto, a livello di team di progetto.

I piani di progetto sono sempre product-oriented, ovvero l’approccio è strettamente orientato alla produzione di deliverables siano essi finali che intermedi – circostanza tutt'altro che scontata. Anche i piani sono products oggetto di consegna e come tali devono essere trattati con i dovuti livelli di qualità e competenza dal professionista che li produce. Come tutti i deliverables di un progetto, anche i piani sono il risultato ovvero di un processo di progetto.

 

Project plan

Questo tipo di piano fornisce indicazioni riepilogative sui tempi, costi, qualità e ambito di esecuzione del progetto. È redatto dal project manager con un preciso allineamento ai programmi aziendali – sia in termini di regole di conduzione che di obiettivi da raggiungere – e definisce i prodotti finali, le attività e le risorse coinvolte. La prima versione (approvata) di questo piano, è congelata e rappresenta la baseline di progetto per le informazioni riepilogative – durata complessiva, costi totali, marginalità (se applicabile), indicatori e metriche di qualità, ambito, rischi, benefici e molto altro ancora.

Stage plans o piani di fase

Abbiamo accennato al problema dell'orizzonte di pianificazione, ora vediamo come approcciare la questione. La suddivisione del progetto in stages o fasi consente, tra l’altro, di pianificare nel breve periodo con un livello di dettaglio spinto per la corretta gestione quotidiana delle attività. In prossimità del termine di ogni fase, il project manager avvia l’attività di pianificazione della fase successiva avendo informazioni certe delle performance ottenute nelle fasi già concluse.

Team plans o pianificazioni orientate ai team

L’esecuzione dei Work Packages può richiedere la realizzazione di piani specifici di conduzione di uno o più team di progetto. Solo la dimensione, complessità, articolazione dei Work Packages rende ragione della necessità di definizione dei team plans che sono comunque di responsabilità dei team manager. I team operativi sono strutture che possono essere sia interne che esterne all'organizzazione che ha promosso e autorizzato l'esecuzione di un progetto. Molto spesso i team operativi sono espressione diretta dei fornitori anch'essi rappresentati nel Project Board. I project team sono dunque task force il cui controllo e conduzione è in carico a professionisti diversi dal project manager; un caso esemplare è nella conduzione del cantiere dove il capo cantiere è responsabile del coordinamento delle squadre in azione sull'opera. In alcuni casi il project manager potrebbe non avere la visibilità diretta dei team e dei team plans. Ciò non di meno, il project manager che esercita il controllo globale di progetto – quindi anche dei team esterni sebbene in modo indiretto – deve ricevere da ogni team manager, un set di informazioni riepilogative dei contenuti dei Team plans con un livello di dettaglio definito e concordato in funzione della complessità e criticità di ogni Work Package autorizzato nello Stage plan corrente.

Exception plans

Il project management è un metodo product-based perché solo l’approccio per prodotti tangibili è garanzia, secondo questa filosofia, di buona gestione e elevata probabilità di successo. Il project management impone anche il paradigma management-by-exception che prevede la definizione di piani alternativi e/o complementari in caso di superamento degli indicatori di performance oltre i limiti di tolleranza predefiniti nella baseline di progetto. Gli exception plans sono preparati dal project manager sia a livello di project plan che a livello di stage plans a seconda dei casi. L’exception plan di progetto ridefinisce in parte o del tutto la baseline fissata dall’originario project plan. In questo caso, il Project Board richiede l’approvazione all'autorità superiore competente a livello di programma; le varianti d'opera ne sono un esempio perfetto perché, quasi sempre, le varianti modificano in modo sostanziale i contenuti del progetto ampliandone l'ambito iniziale: ad esempio la riduzione di una cubatura di un'opera civile controbilanciata (?) da opere di urbanizzazione o infrastrutture di mobilità è una pratica molto diffusa, non lo è affatto la rimodulazione dei piani attraverso un exception plan di fase.

Gli exception plans hanno gli stessi livelli di dettaglio dei piani che vanno a sostituire; nel caso specifico degli stage plans, i Work Packeges coinvolti non richiedono nuovi team plans. I team manager avvieranno le opportune analisi di raggiungibilità dei risultati nei termini previsti e, se del caso, concorderanno con il project manager nuove condizioni di esecuzione dei Work Packages, definendo le azioni correttive. Se non fosse possibile rientrare nei limiti di tolleranza a livello di stage, il project manager e il team manager concorderanno un differente Work Package e l’emissione di un nuovo Team plan. Quando ciò non è fatto, si assiste alla lievitazione dei costi dell'opera e all'allungamento dei tempi di consegna a tempo indeterminato.

Non sfuggirà la circostanza che l’emissione di un nuovo project plan non è un’evenienza comune. Solo il pesante sforamento di importanti indicatori di performance – ad esempio l’azzeramento dei margini operativi e la prospettiva di perdite economiche – possono autorizzare l’emissione di una nuova baseline, sempre che l’azienda non decida di chiudere il progetto anzi tempo. Avere l’opzione dell'Excpetion plan è come fare una crociera con la consapevolezza che ci sono le scialuppe di salvataggio ma, francamente vorremmo non doverle usare. Altrettanto il project management professionale non può, non deve fare affidamento su questa possibilità ponendosi in uno stato d’animo per cui, l'exception deve essere solo la conseguenza di eventi esterni imponderabili, e non l’opportunità per correggere errori di gestione o l'occasione per recuperare marginalità con altro lavoro tramite la variante d'opera appunto.

 


Progetti e opere civili

Project management e processo edilizio

FLAVIA ANTONELLI Flewsplash's Photography

Già la legge Merloni (D.lgs. 109/1994) introduceva alcuni principi generali innovativi in tema di programmazione, monitoraggio e controllo dell’avanzamento oltre ai più tradizionali principi di verifica della legittimità degli atti amministrativi per le opere pubbliche: costituiva dunque un passo avanti verso l’effettivo controllo dell’opera anche, e soprattutto, per quella parte del processo chiamato esecuzione.

L’evoluzione della legislazione in tema di appalti pubblici per le opere civili, non ha modificato sostanzialmente il quadro di riferimento in cui si deve muovere la stazione appaltante e l’impresa sulla questione dei processi di gestione del progetto (edilizio). Anche ANAC con le linee guida n. 3 di attuazione del D.Lgs. 18 aprile 2016, n. 50, recanti “Nomina, ruolo e compiti del responsabile unico del procedimento per l’affidamento di appalti e concessioni” ha continuato sullo stesso sentiero virtuoso già tracciato da AVCP nel lontano 2001:

AVCP Determinazione n.10/2001 del 23/2/2001

“… il ruolo del responsabile del procedimento all'interno dell'iter realizzativo dell'opera pubblica è piuttosto quello del project manager e, quindi quello di fornire impulso al processo anche avvalendosi di uno staff di supporto”

Fin qua dunque solo buone notizie ma la strada da percorrere è ancora lunga e con qualche insidia. La mia esperienza professionale ha sempre riguardato i processi informatici e solo saltuariamente quelli edilizi ma, in occasione di una recente consulenza per la redazione dell’offerta tecnica di due gare d’appalto in ambito civile, è stata interessante constatare la perplessità dei colleghi ingegneri e architetti, avvezzi a questo mestiere, manifestata sulla struttura ed organizzazione della documentazione tecnica delle due gare. Non che non fosse completa, tutt'altro, ma i consulenti del RUP incaricati di redigere i capitolati, avevano senz'altro seguito le migliori prassi suggerite da PMI, IPMA, ISIPM (o altri soggetti privati non meglio identificati), ma senza la consapevolezza che quello che fai di buono e di cattivo in fase di processo di affidamento, lo ritrovi buono e cattivo in quello di esecuzione ovvero nella gestione dell’appalto, del cantiere, delle forniture e delle realizzazioni fino al collaudo ed oltre. Chiarisco meglio i fattori di vulnerabilità e fallimento di un tale approccio riferendo uno dei tanti elementi critici dell'esempio citato: nel capitolato lavori era presente una WBS costituita da circa 10.000 articoli organizzati a vari livelli dal 1° al 6° a partire dalla radice. Se da una parte si riconosce lo sforzo di creare un set completo di informazioni, dall'altra dobbiamo constatare che l’approccio non genera nessun valore aggiunto ma, anzi, produce due effetti molto negativi: 1) costringe l’esecutore dell’opera ad un’operazione di trasposizione degli articoli di WBS su una struttura gerarchica dedicata al computo metrico e al controllo delle forniture in quantità e qualità, non al controllo del progetto; 2) costringe sempre l’esecutore alla realizzazione di un’altra WBS più orientata al controllo del progetto perdendo così ogni relazione con il contenuto del capitolato; è un po’ come dire che stazione appaltante e impresa sacrificano la possibilità di parlare la stessa lingua solo perché non è chiaro come si governano i processi di progetto all'interno del processo edilizio.

Penso che il salto di qualità per tutti, imprese e stazioni appaltanti pubbliche e private, arriverà solo dopo una solida formazione ed applicazione in campo di certe tecniche, con una chiara consapevolezza del come e del perché si opera solo e soltanto in un certo modo. Dire che un articolo ha un legame permanente con un codice di WBS e che il codice lo possiamo creare, lo possiamo cancellare ma non lo possiamo più riusare; e che all'articolo non può essere assegnato un altro codice, vuol dire affermare che esiste un fil rouge senza soluzione di continuità dall'ideazione, verso la programmazione, la progettazione, l’affidamento e l’esecuzione; e in questo fil rouge possiamo creare e cancellare elementi a piacimento ma essi mantengono alcune proprietà permanenti per l’intero ciclo di vita dell’opera, almeno fino alla consegna e all'avvio in esercizio.

Conclusioni
La Direttiva 2014/24/EU del Parlamento Europeo, al punto 52 delle premesse introduce la valenza dei mezzi elettronici di informazione per semplificare e accrescere l’efficacia e la trasparenza delle procedure d’appalto. La documentazione elettronica d’appalto prevista dalla direttiva EU, integra tutti i processi dalla programmazione all'esecuzione e collaudo e anche oltre. Il cosiddetto Building Information Modeling è dunque un sistema costituito da processi, procedure, formati inter-operabili e piattaforme applicative e di comunicazione tese a integrare l’intero processo edilizio.

Il DM 560 del 1/12/2017 stabilisce le modalità e i tempi di progressiva introduzione dei metodi e degli strumenti elettronici di modellazione per l’edilizia e le infrastrutture. Secondo il Decreto, a gennaio 2019 scatterà l’obbligo d’utilizzo di sistemi inter-operabili di modellazione (leggi BIM) per appalti pari o superiori a 100 milioni di euro; a partire dal 2025 tutti gli appalti dovranno adottare l’approccio BIM.

L’introduzione del sistema BIM può essere una grande opportunità per tutti gli operatori del settore, imprese, professionisti e RUP, di alzare l’asticella delle competenze in tema di integrazione del project management col processo edilizio; un impegno che dobbiamo prendere molto seriamente.

Il futuro del project management

 

"Innovazione" è tra le parole ai primi posti nei motori di ricerca e "project management" segue a ruota, ma non è un caso. Stiamo assistendo ad una nuova primavera per la professione del project manager perché l'innovazione impone regole vincolanti non derogabili. Voglio condividere queste mie idee maturate in tanti anni di lavoro, e tentare di diffondere un diverso approccio all'innovazione.


Si parla sempre più spesso di innovazione; scusa il gioco di parole, ma la "innovazione" non è un fatto "nuovo". L'innovazione ha caratterizzato la nostra cultura occidentale a partire dalla prima rivoluzione industriale nel '700; l'innovazione è diventata la chiave del successo delle Nazioni (non solo di singoli soggetti!) nell'800; l'innovazione si è trasformata in dominio e controllo (purtroppo anche e soprattutto in senso militare!) nel '900; l'innovazione è diventata la necessità di grandi, piccoli e piccolissimi per non soccombere nel 3° millennio.

L'innovazione è sempre stata difficile perché, come spesso dico a me stesso, "se penso di avere avuto un'idea veramente geniale, quasi certamente qualcun altro l'ha avuta prima di me"... ma non è detto. L'innovazione passa anche attraverso il miglioramento di quello che già esiste: si tratta di perfezionare un processo produttivo o il funzionamento di un sistema introducendo qualche tecnologia già disponibile ma che non è mai stata usata, fin'ora, per quello scopo specifico.

C'è un aspetto dell'innovazione che spesso sfugge: l'innovazione passa sempre attraverso un progetto e le imprese, dai giganti ai piccolini, temono i progetti, soprattutto quelli innovativi, perché anche solo i progetti convenzionali vanno in sofferenza, con una frequenza allarmante. Qualche dato forse potrà chiarire il concetto.

La società di consulenza Standish Group è molto attiva da anni nei sondaggi sullo stato di salute dei progetti in aziende di diverse dimensioni, tutte impegnate nel miglioramento dei propri prodotti e dei processi produttivi e nell’innovazione tecnologica; tutte sfide che passano, obbligatoriamente, attraverso i progetti. Il report del 2014 è stato effettuato intervistando 365 responsabili dei servizi IT di altrettante aziende per un totale di 8.380 progetti di sviluppo di applicazioni informatiche (Chaos Report 2014). I dati raccolti da Standish Group sui progetti IT sono molto significativi perché il nostro mondo è dominato dall’informatica; la capacità del mondo delle industrie e dei servizi di fornire prodotti affidabili, a costi ragionevoli e disponibili tempestivamente è un indicatore globale sulla qualità del mondo che vivremo da qui a 1, 5, 10 anni e oltre. Avete dei dubbi? Automobili, elettrodomestici, strumentazione medica per la diagnostica, monitoraggio ambientale e di eventi intensi (meteo, suolo, vulcanologia, sismologia) sono solo pochi esempi di contesti in cui i progetti sono cruciali e devono godere di un sano ciclo di vita, ma non è così. In altri ambiti, come ad esempio quello del mattone, le imprese di costruzioni sono strette dalla morsa di ricavi molto più bassi rispetto solo a 20 anni fa. Oggi bucare del 20% il budget di un’opera civile può rappresentare un disastro finanziario a rischio di fallimento. Il mondo dei servizi pubblici, quelli erogati dalle Pubbliche Amministrazioni, non fanno eccezione. Ma sappiamo molto bene che nei progetti, come in tutte le attività umane, le persone e la loro preparazione sono alla base dei modelli organizzativi e del loro successo, oggi ancora più che nel passato.

 

Il grafico a barre mostra i risultati del sondaggio di Standish Group: come si vede oltre il 70% dei progetti è fuori budget per oltre il 50% del valore stimato inizialmente, e questo non è sano.

Le imprese lo sanno bene che avere una squadra di project manager esperti e professionali fa la differenza. Le aziende cercano col lanternino project manager veramente bravi, ma la domanda di queste figure professionali, al top delle capacità è molto, molto superiore all'offerta reale: Talent Economy non ha dubbi, ed ha pubblicato questo articolo che spiega bene lo stato dei fatti The Future of the Project Management Role.

Fare il project manager vuol dire, oggi, GUIDARE L'INNOVAZIONE. Vuol dire abilitare le imprese a vedere un futuro migliore, forse anche solo "vedere un futuro". Seguire un corso di preparazione professionale è il primo passo per esplorare un ambito produttivo che sta vivendo un nuovo fermento, con ampi spazi di crescita per tutti i professionisti e le imprese.