Il Piano di Project Management. Una risposta strutturata a una domanda dovuta: Come?

Vi è mai capitato di veder uno dei quei film americani in cui il protagonista è un detenuto che organizza la fuga da un penitenziario e parlando con il suo complice dice “Fuggiremo mentre …” e l’altro chiede “ … e come pensi di riuscirci?”, “Ho un piano, … stammi bene a sentire … ” ribatte il primo. Per il raggiungimento degli obiettivi di un progetto vale la stessa cosa, non è sufficiente conoscere l’obiettivo da raggiungere, è necessario definire un piano.

In questa scena vi sono ben quattro aspetti che, non come detenuti, quanto piuttosto come aspiranti project manager dovremmo essere in grado di cogliere:

-       è già chiaro, a entrambi i protagonisti, l’obiettivo che si intende raggiungere;

-       vi è una domanda focale su cui è incentrato il confronto: come riuscire a raggiungerlo;

-       colui che promuove il progetto, per realizzarlo necessita di un "complice";

-       il complice necessita di conoscere il progetto e di farlo proprio, ne deve essere coinvolto, diversamente non potrà dare il suo contributo rischiando di divenire piuttosto un ostacolo.

Nei progetti accade esattamente la stessa cosa.

In questa scena, vista con gli occhi di un PM, il progetto, o meglio il suo obiettivo, è la fuga dal penitenziario, il protagonista principale è il PM, il complice è il suo team mentre il piano è la risposta ad una esigenza impellente: come raggiungere gli obiettivi del progetto.

Quando si arriva a definire un piano è evidentemente già abbastanza chiaro il risultato che si vuole ottenere, gli obiettivi che si intende raggiungere, a grandi linee il cosiddetto ambito del progetto. Diventa importante pertanto e impellente piuttosto, rispondere a una semplice ma cruciale domanda: “Come?”. Vale a dire: con quali strumenti? Quali tempi? Quali costi? Con quali risorse? Quali modalità? Quali rischi?

La risposta migliore a questi quesiti è spesso articolata, impegnativa, quasi mai immediata, né tantomeno perfetta o priva di incertezze. La risposta più corretta dovrebbe in ogni caso essere: attraverso un adeguato piano di gestione del progetto.

D’accordo ma adeguato a cosa? Adeguato al progetto e all’ambiente in cui esso si sviluppa, agli obiettivi, alle sue dimensioni, alla sua complessità, alla sua rischiosità e a numerose altre sue caratteristiche o aspetti. Ne consegue che il piano di project management, in generale, deve essere una risposta strutturata e specifica. Per ottenere questo risultato, il PM trae giovamento dalla conoscenza e la capacità di applicare processi, metodi e tecniche di project management al progetto.

Dalla consapevolezza di un corretto approccio alla pianificazione del progetto dipende spesso la probabilità di raggiungerne gli obiettivi in maniera non solo efficace ma anche efficiente.

Cosa è quindi un Piano di Project Management? Quale è il processo che ne consente uno sviluppo efficace? Quali sono gli input necessari e dove cercarli? Quali sono gli strumenti per processare al meglio questi ingressi?

Molto spesso i progetti falliscono o arrivano al traguardo centrando gli obiettivi con grande fatica. E’ una condizione inevitabile? Quanto ciò dipende da una pianificazione inadeguata?

Spesso non ci chiediamo in effetti se stiamo o meno adottando un buon Piano di Project Management, no ne abbiamo una reale consapevolezza. In realtà dovremmo sistematicamente chiederci:

-       in quali aspetti ciò che stiamo strutturando deve essere un buon piano?

-       fino a che livello occorre che sia strutturato?

-       quanto dinamico e adattativo è per natura il nostro progetto?

-       quanto dovrebbe esserlo?

-       il nostro piano lo è corrispondentemente altrettanto?

-       quanto siamo coscienti che il piano necessiterà in corso d’opera di review e aggiornamenti mirati e commisurati alla sua intrinseca natura e incertezza?

-       siamo davvero pronti e preparati a gestire questi aspetti attraverso un piano adeguato?

Se queste domande ci suonano nuove, probabilmente dovremmo porre maggiore attenzione nello sviluppare il nostro piano di gestione del progetto.

Il Piano di Gestione del Progetto può necessitare di taglio significativamente differente a seconda della tipologia di progetto, della sua incertezza, del suo grado di novità, dell’ambiente di progetto, delle sue dimensioni e di molteplici altri aspetti. Esso deve evolvere spesso e mutare, in una certa misura, dinamicamente con il ciclo di vita del progetto.

Se non anticipiamo adeguatamente queste dinamiche, il piano rischia di rimanere indietro e arrivare tardi al suo appuntamento con il grave rischio di fallire gli obiettivi.

Il Piano di Project Management, d’altro canto, non può esser visto come un monolita, necessita spesso di essere esploso in piani specifici per la gestione di aspetti specifici ma pur sempre tra loro interconnessi e ineterdipendenti come tempi, ambito, rischi, stakeholder, comunicazioni, approvvigionamenti, qualità, risorse.

Questo generale approccio è tanto più necessario quanto più ampio e complesso è il progetto. Pianificare comporta integrare esigenze spesso in conflitto. Il Piano di Project Management integra quindi a più alto livello e in maniera strutturata una buona parte o tutti i piani di dettaglio elencati in Tabella 1. Non a caso, il Piano di Project Managemnt si colloca, secondo lo standard del PMI, nell’area di conoscenza detta integrazione.

Pianificare è un processo specifico caratterizzato da ingressi, tecniche, metodi e strumenti specifici. Occorre quindi chiederci: quali sono questi ingressi e gli strumenti che maggiormente possono venirci in aiuto per sviluppare un adeguato Piano di Project Management?

Facendo riferimento allo standard del PMI possiamo affermare che sviluppare il Piano di Project Management significa preparare, in maniera coordinata, tutti i componenti del piano integrandoli e coordinandone consolidamento e modifiche in corso d’opera. Un buon Piano di Project Managemet fissa, modalità di esecuzione, monitoraggio e controllo del progetto, in base alle specifiche esigenze del medesimo e le rende ufficiali e condivise al team e allo sponsor che approva.

Per raggiungere questo obiettivo occorre che il PM e il team di project management si interroghino adeguatamente su quali saranno le attività del progetto che consentiranno la realizzazione degli obiettivi e in che modo esse dovranno essere affrontate. Si tratta di un processo a volte complesso, articolato, che può variare da progetto a progetto pur lasciando valido l’approccio generale qui discusso.

A seconda dei casi, il piano risulterà più o meno sintetico o dettagliato in base alla complessità del progetto e potrà mutare in corso d’opera man mano che informazioni più accurate si renderanno disponibili. Esso non va quindi inteso come qualcosa di statico, quanto piuttosto qualcosa da plasmare adeguatamente, da affinare e correggere in corso d’opera, da personalizzare rispetto allo specifico progetto.

Allo scopo, è importante distinguere due periodi temporali specifici: quello che precede la definizione della prima revisione delle baseline e quello che lo segue. Infatti, prima che si definisca una qualunque baseline è possibile, in linea di massima, modificare il piano anche senza particolari procedure formali.

Diversamente, una volta definite e approvate le baseline è necessario gestire le modifiche al piano con più attenzione, dal momento che esse hanno ripercussioni dirette sulle stesse baseline e quindi sull’operatività esecutiva del progetto. Per questo, si rende necessario un processo formale di analisi, valutazione ed eventuale approvazione delle modifiche. Diventa cioè necessario un formale processo di controllo integrato delle modifiche.

Un altro aspetto spesso trascurato in fase di pianificazione è legato al supporre, più o meno implicitamente, che il progetto giungerà a compimento. Ciò porta a non contemplare una exit strategy. Se ciò può essere accettabile in progetti relativamente standardizzati di cui si ha la quasi certezza di successo, la stessa cosa non vale in generale.

Il processo “Sviluppare il Piano di Project Management”

Ciò premesso, analizziamo il processo di Sviluppo del Piano di Project Management e descriviamolo in termini di ingressi, strumenti/tecniche e uscite. Nel far ciò rimaniamo aderenti all’impostazione standard del PMI, come già fatto per altri processi nel corso dei precedenti articoli. La Figura 1 rappresenta graficamente quanto di seguito esposto.

Figura 1-Il processo “Sviluppare il Piano di Project Management”: ingressi, strumenti, uscite

Gli ingressi

Generalmente, si giunge allo sviluppo del Piano di Project Managemet dopo aver strutturato un adeguato project charter, a sua volta basato su un adeguato business case. Il project manager ha a questo punto, generalmente, già una discreta conoscenza dei principali stakeholder di progetto.

Alla prima stesura del piano, il project charter è certamente documento di ingresso, come lo sarà per i piani di dettaglio di cui ci occuperemo in successivi articoli e di cui il Piano di Project Management è la naturale integrazione. Dovrebbe quindi venire naturale vedere il Piano di Project Management come la naturale prosecuzione o se vogliamo evoluzione di quanto già in parte focalizzato nel project charter. Gli elementi di alto livello contenuti nel project charter vengono infatti, a questo punto, elaborati ed esplosi opportunamente allo scopo di sviluppare il Piano di Project Management propriamente detto.

Ciò è principalmente quanto avviene alla prima stesura del piano. In corso d’opera il piano riceverà altri input costituiti da dati e informazioni provenienti da altri processi (i cosiddetti output da altri processi), in particolare quelli di esecuzione e ancor più di monitoraggio e controllo. Infatti, sono proprio i processi di monitoraggio e controllo che generalmente evidenziano la necessità di apportare modifiche al progetto e di conseguenza al suo piano, ai piani di dettaglio e alle baseline.

Fattori ambientali aziendali e aspetti specifici dell’asset dei processi organizzativi influenzano o inducono anche essi aggiornamenti al Piano di Project Management, sia in occasione della sua prima stesura che in corso d’opera.

Durante una corretta gestione del progetto, non è difficile constatare come, in effetti, gli ingressi che tipicamente prendiamo in considerazione rientrino generalmente tra quelli qui presentati (Figura 1 e Figura 2).

Figura 2-Interconnessioni tra il processo “Sviluppare il Piano di Project Management” e gli altri processi

Strumenti e tecniche

Il Piano di Project Management è elaborato dal Project Manager, il quale è supportato allo scopo dal team di project management e in alcuni casi da componenti specifici del team di progetto. Costoro in sostanza sviluppano il piano in qualità di esperti interni al progetto. Altri esterni, per esempio consulenti, se necessario, possono in taluni casi prendere parte al processo. Il cosiddetto parere di esperti, di cui abbiamo già parlato nell’articolo [10] viene per questo indicato secondo lo standard del PMI come strumento.

Un altro strumento o tecnica utile in questo processo è la raccolta di dati. A essere più precisi, con questo termine si intende piuttosto un insieme di tecniche utili a raccogliere dati e informazioni funzionali allo sviluppo del piano. Brainstorming, focus group e interviste sono strumenti, di cui abbiamo già parlato nell'articolo [10] appartenenti a questo insieme. Si tratta di tecniche che andrebbero padroneggiate e utilizzate in maniera sistematica dal PM per meglio elaborare il Piano di Project Management. La raccolta efficace dei dati assume forma strutturata e va così oltre il semplice pareri di esperti.

Altro strumento utile allo scopo sono le cosiddette liste di controllo. Esse consentono di verificare che si abbiano a disposizione tutte le informazioni utili e sufficienti a sviluppare un adeguato Piano di Project Management. Esperienze pregresse acquisite nel corso della gestione di altri progetti, in scenari e contesti più o meno simili, possono aiutare a utilizzare efficacemente questa tecnica.

Ancora una volta, il PM in particolare, per gestire adeguatamente le sessioni di raccolta dei dati deve padroneggiare anche altre tecniche già discusse nell’articolo [10]: gestione di conflitti, tecniche di facilitazione e di gestione delle riunioni. Le classiche riunioni, anche quelle informali, sono infatti esse stesse un importante strumento di raccolta di dati.

Nei piccoli progetti è prassi comune che lo stesso team che esegue la pianificazione ne curi l’esecuzione o che quest’ultima sia curata da un sottogruppo del team.

Nei grandi progetti è invece più comune avere un gruppo di project management che sviluppa il Piano di Project Management mentre il resto del più ampio gruppo di progetto è semmai coinvolto nella revisione e nella definizione dei piani di dettaglio che scaturiscono dal Piano generale di Project Management e che sono grazie a esso correttamente integrati.

In presenza di un progetto ampio e complesso è inoltre opportuno che esso sia strutturato in più fasi e che ciascuna fase sia caratterizzata da uno specifico Piano di Project Management e relativi piani ausiliari.

Rimane valido comunque un concetto: non sono le tecniche e i metodi di project management a determinare il piano, quanto piuttosto le esigenze del progetto a suggerire la migliore applicazione di tecniche e strumenti al fine di produrre il piano più efficace ed efficiente possibile.

Uscita

Il Piano di Project Management è il documento output del processo ed è un documento cruciale per la gestione efficace e il successo del progetto. L’assenza di un siffatto documento adeguatamente strutturato è infatti spesso causa di incomprensioni e inefficienze, nell’organizzazione, nel gruppo di progetto, tra questo ultimo e lo sponsor. Un piano che si fatica a strutturare e documentare è probabilmente un piano non sufficientemente definito e quindi difficilmente attuabile. Ciò nulla ha a che fare con un’eccessiva formalizzazione, rischio anche questo da evitare. Un piano poco formalizzato è possibile qualora il progetto è relativamente contenuto e standardizzato. Lo stesso approccio può tuttavia rivelarsi invece devastante in altri casi.

Se non ne siamo convinti chiediamoci:

-       ci è mai capitato di lavorare a un progetto il cui piano era scarsamente documentato e non adeguatamente strutturato, per quanto condiviso?

-       quali difficoltà abbiamo incontrato nella sua gestione?

-       quali osservazioni e riflessioni ci sentiamo di fare in merito?

-       quali lesson learned ne abbiamo tratto?

In un progetto ampio, complesso, incerto quello che è e rimane nella nostra testa senza trovare riscontro in un piano formalmente strutturato e approvato è spesso un rischio non sostenibile. Nella mancanza o inadeguatezza di un piano è spesso impresso il DNA del fallimento. Ciò emerge evidente quando dalla pianificazione occorre passare all’esecuzione del progetto e al coinvolgimento di coloro che dovranno attuare quel piano per produrre risultati.

Non è difficile in progetti con un piano non adeguatamente strutturato continuare a sottovalutare aspetti apparentemente secondari destinati ben presto a generare equivoci, indeterminazioni e pericolose inefficienze.

Spesso un piano può apparire chiaro in principio tanto da mettere d’accordo tutti solo perché è ancora puramente generale. Se questo è accettabile in una prima fase del progetto, non può esserlo nelle successive, quando l’esecuzione diventa impellente. Il PM deve avere un occhio acuto e percepire il rischio per tempo, rimanendo pronto e preparato a evolvere il piano lungo il ciclo di vita del progetto.

Il Piano di Project Management è lo specchio gestionale per eccellenza del progetto, è responsabilità del PM ma necessita di condivisione con il team e approvazione dello sponsor.

Approfondimenti sui componenti del Piano di Project Management

Il Piano di Project Management può in parte contenere, in parte richiamare, in parte completarsi con altri piani di dettaglio che verranno sviluppati, in parte contestualmente e in parte in momenti successivi. Ne consegue che, non vi è una linea di demarcazione netta tra Piano di Project Management, piani di dettaglio e relative baseline. A seconda dei casi, potrebbe essere opportuno mantenere i piani di dettaglio come documenti ben distinti tra loro, lasciando al Piano di Project Management il ruolo di documento di integrazione oppure integrare le informazioni di alcuni piani di dettaglio direttamente nel Piano di Project Management.

Piano, Baseline e Documenti di progetto

Generalmente per Piano di Project Management si intende il piano generale, i piani ausiliari e le baseline di riferimento per l’esecuzione. Queste ultime sono sostanzialmente tre: la baseline dell’ambito, la baseline della schedulazione e quella dei costi sebbene con l’ultima edizione (2017) del PMBOK è stata introdotta anche la cosiddetta baseline delle misurazione delle prestazioni.

I documenti di progetto sono invece, generalmente, considerati separati dal piano. Si tratta per lo più di registri, elenchi, stime, calendari, schedulazioni e molto altro ancora. Le Tabelle 1 e 2, direttamente estratte dalla Tabella 4-1 del PMBOK ed. 6 del 2017, chiariscono in maniera esaustiva come distinguere e in che relazione reciproca siano Piano di Project Management, piani ausiliari, baseline e documenti gestionali di progetto.

Tabella 1 - Componenti del Piano di Project Management

Tabella 2 - Tipici documenti gestionali di progetto

Conclusioni

Non di rado, quando avviamo ufficialmente un progetto, riteniamo erroneamente di avere già un piano, sebbene esso non sia ancora né definito, né strutturato e poiché riteniamo di averlo non ci curiamo di produrlo. Altrettanto spesso confondiamo il project charter, “stirandone” oltremodo il significato, con il piano, “comprimendo” oltremodo invece il significato di questo ultimo.

Così facendo, non ci rendiamo conto di quanto il nostro piano sia spesso e in realtà solo accennato, parziale, scarsamente strutturato e persino poco visibile al team, il quale apprestandosi all’esecuzione, avrebbe bisogno di vedere in esso rispecchiati ben altri dettagli.

Stando così le cose, anche le informazioni di sintesi che se ne traggono, necessarie allo sponsor e ad altri stakeholder, rischiano di essere affetti da eccessiva incertezza. Non di rado si confonde poi il piano con il documento che lo contiene.

Così facendo non si coglie la struttura intrinseca del progetto che il piano dovrebbe rispecchiare e come priorità strategica la necessità di integrare la gestione del progetto in una forma realmente efficace. Non si tratta di formalismi, molti dei quali possono essere in effetti evitati, si tratta piuttosto di avere realmente un piano.

Ricondividi l’articolo, lascia un commento o delle osservazioni. Grazie!

Articoli della collana

INDICE

ACCESSO:

SE LA TUA APP MOBILE NON RISPONDE AL LINK ACCEDI DA BROWSER MOBILE

Articolo n°1: Il Project Management è sempre esistito

Articolo n°2: Chi ha ucciso il Project Management

Articolo n°3: Project Management: il progetto prima di tutto!

Articolo n°4: Comprendere organizzativo per il successo dei progetti – Parte I

Articolo n°5: Comprendere l’ambiente organizzativo per il successo dei progetti - Parte II

Articolo n°6: Il ruolo del Project Manager nell’ambiente di progetto

Articolo n°7: La gestione strutturata dei progetti: fasi, ciclo di vita del progetto e processi di Project Management

Articolo n°8: I processi di Project Management

Articolo n°9: E’ la Magna Carta del progetto e si chiama Project Charter

Articolo n°10: Il Project Charter come uscita di un processo fatto per alimentare altri processi

Articolo n°11: Dal Project Charter (ma non solo) all’identificazione degli stakeholder

Articolo n°12: Il Piano di Project Management. Una risposta strutturata a una domanda dovuta: "Come ... ?"

Articolo n°13: Un piano di gestione specifico per l'ambito, la sostanza intorno a cui tutto ruota

... gli articoli che seguono non sono accessibili …