Per ogni iniziativa tendiamo a individuare un principio e un termine. Se poi parliamo di un qualunque progetto, la necessità di avere una data di inizio e una di fine la ritroviamo nella sua stessa definizione. La cosa aiuta noi e qualunque organizzazione all’interno della quale il progetto si realizza a produrre una pianificazione, effettuare un monitoraggio e controllo del lavoro che ci permetta di valutarne i risultati, capire quando iniziare e terminare le attività. Nelle organizzazioni questo è fondamentale anche per definire le responsabilità dei vari dipartimenti coinvolti, il trasferimento di attività da uno all’altro. Per aggiornare i sistemi gestionali, monitorare e chiudere i conti economici e finanziari, sentenziare sul successo o fallimento del lavoro in base agli obiettivi definiti all’inizio. Non è mica poco. Direi la base di impostazione del Project Management.

Ma la realtà ci racconta che i progetti iniziano prima di cominciare e terminano dopo essere finiti. Lo so. Vi devo una spiegazione più approfondita.

In qualunque azienda l’inizio del progetto è segnato dalla firma del contratto, a valle di una negoziazione più o meno lunga tra i rappresentanti commerciali delle parti coinvolte. Ma si sa che una volta firmato il contratto, un pezzo importante della storia del progetto è già segnata. A volte in maniera irreversibile. Di certo questo non può costituire in alcun modo un alibi per il Project Team, ma resta il fatto che quel progetto è evidentemente cominciato molto prima che la documentazione contrattuale firmata arrivasse sulla scrivania o nell’inbox del Project Manager e dei suoi collaboratori.

Non è un caso che alcune best practice aziendali indichino, almeno per i progetti più complessi, di nominare il Project Manager e le figure principali del team di progetto già nella fase commerciale e di negoziazione finale. Questo permette di individuare in anticipo eventuali rischi, aree grigie nella definizione dello scopo del lavoro. E magari di specificare dettagli non chiari in quella che diventerà la documentazione contrattuale. In aggiunta, questa pratica aiuta anche a realizzare un passaggio di consegne più accurato dal team commerciale a quello operativo, limitando così ogni tipo di conflitto interno tra chi ha venduto e chi dovrà realizzare. Spesso poi tale assegnazione anticipata dei principali attori del progetto non viene fatta per questioni di workload (carico di lavoro delle risorse), ma è un altro discorso. Ciò che è sempre vero è che, quando nei sistemi gestionali dell’azienda viene registrato il fatidico numero che indica il progetto (o commessa) da realizzare, quel progetto è iniziato già da tempo e si porta con sé vincoli e caratteristiche che influenzeranno la fase di esecuzione del lavoro.

Durante il normale ciclo di vita del progetto poi ha luogo tutto ciò che classicamente costituisce il flusso del lavoro per consegnare il prodotto finale al Cliente. Il Project Team esegue le attività di pianificazione, progettazione, acquisto e produzione, spedizione e tutto quello che lo scopo del lavoro contrattuale include. In parallelo all’esecuzione delle attività, si monitora e controlla l’avanzamento in base alla pianificazione tecnico-operativa e a quella economico-finanziaria, indicando e analizzando ogni eventuale scostamento. In pratica scorre tra cronoprogrammi, gestione di rischi e opportunità, piani di recupero e completamento di deliverable (risultati intermedi o finali delle attività), la vita dei professionisti che lavorano a progetto.

Ad avvenuta consegna di tutti i deliverable contrattuali e dopo aver eseguito le attività previste per la chiusura, il progetto vede la sua fine. Si tira una linea ed ecco i numeri definitivi. Nei tempi ed entro il budget? Bravi. In ritardo e oltre il budget? Molto male, questo progetto è stato un vero fallimento. E chi potrebbe dire il contrario con i sistemi di controllo e le metodologie che seguiamo per fare le valutazioni, registrare i risultati, chiudere i bilanci? Nessuno. A meno di spostare l’attenzione oltre i deliverable e considerare il valore totale che il progetto genera. Perché può capitare che buona parte di quel valore si realizzi in fasi successive alla consegna.

Foto di Octavian Dan per Unsplash

Il mondo è pieno di slides che raccontano di progetti falliti (dal punto di vista della pianificazione tempi-costi) come ad esempio l’Eurotunnel, l’imponente opera sotto la Manica che collega Inghilterra e Francia. Un progetto consegnato in grave ritardo e con significativi extracosti. Ma anche un’opera che ha creato oltre 220 mila posti di lavoro e che permette a 21 milioni di persone e oltre 100 miliardi di Euro di merci di passare ogni anno da una parte all’altra del canale. E di esempi ce ne sarebbero molti altri.

Chiaramente il nostro mondo regolato dal controllo e dalle misurazioni, dalla necessità di chiudere le contabilità di periodo, va in difficoltà quando si deve valutare il valore totale generato, per di più successivamente alla consegna del progetto. Ma dovremmo muoverci verso la valutazione di questo tipo di valore, includendo quello intangibile e differito, quello per la società e il sistema. Ciò permetterebbe anche una valutazione iniziale dei costi e una pianificazione dei tempi forse meno “ottimistiche” e quindi di limitare gli extracosti finali. Infatti proprio una pianificazione molto ottimistica (in buona fede, puntando sulle proprie capacità di execution) è spesso l’unico modo per far approvare il progetto all’interno dell’organizzazione e dargli inizio.

Cominciando a ragionare sul valore generato potremmo anche arrivare, in alcuni casi, a modificare le condizioni di negoziazione iniziale e firmare contratti più vantaggiosi per tutte le parti coinvolte. Iniziando a basarci sul valore generato potremmo evitare di perdere occasioni importanti “solo” perché il profitto e i risultati a breve termine o dichiarati nella fase di analisi di fattibilità del progetto non sarebbero quelli attesi.

E allora non solo deliverable consegnati ma anche valore generato. Non solo “questo progetto ha generato l’ x% di profitto” ma anche “questo progetto ha dato lavoro a xxx persone e creato i seguenti benefici per la società”.

Serve un cambio di prospettiva e di visione, ricordando sempre che un progetto comincia prima dell’inizio e finisce dopo il completamento.

È tempo di cambiare passo. È tempo di progetti.

Twitter @walterromano

È stata una lettura interessante?  Ne vuoi parlare con me?

Contattami su Linkedin Walter Romano | LinkedIn o su WR The Project Manager