Come formatore sul Project Management, presso Eureka Service, mi capita di soffermarmi su di una slide in particolare che, come in figura, descrive il  “Sistema di Project Management”.
Il sistema è rappresentato da tre cerchi che dovrebbero convergere verso un punto centrale, in modo da eliminare il più possibile aree di non sovrapposizione. Questa figura illustra gli elementi cruciali per la messa a punto di un sistema di PM, sistema che ha infatti il compito di “scegliere” gli strumenti più idonei, di “assumere o formare” le persone coinvolte e di “definire” i processi più corretti.

Il peso dell’elemento processi, come emerge dalla figura, è notevolmente maggiore rispetto agli altri. Ciò accade perché, abbracciando una filosofia squisitamente anglosassone, si ritiene di dover dare un maggior valore alla parte processuale in termini di standard procedurali aziendali a prescindere dalle persone che sono impegnate a seguirla. In tale ottica si tenta non solo di evitare di creare processi “ad personam” ma, nel rendere il processo stesso meno dipendente dalle persone impegnate ad implementarlo (tutti sono importanti ma nessuno è indispensabile!), lo si formalizza maggiormente per creare un chiaro standard.

Sulla base dell’esperienza maturata in questi anni, ho potuto appurare che introdurre un sistema di project management (il pallogramma di cui sopra) all'interno di un'azienda, o di una sua funzione, può risultare molto poco coinvolgente e poco produttivo qualora, nonostante se ne riconosca la necessità e l’esigenza, non esista un forte commitment ed una sponsorizzazione da parte di persone dotate di autorità. Inoltre, l’errato coinvolgimento degli stakeholder principali, potrebbe portare all’implementazione di un sistema scollato e disallineato con il contesto aziendale.

Se è vero che è il contesto che sceglie il processo, gli strumenti e forma le persone, questo non è immutabile e credo necessario che vi sia anche un processo di ritorno, un feedback al contesto stesso, per verificare che le scelte che sono state fatte ed implementate (il sistema nel suo complesso) risultino efficaci e possibilmente correggerle.

Molto spesso le aziende, con buona volontà, si affidano a consulenti esterni per tentare un primo approccio al sistema, o per migliorare quello esistente, confidando nella buona riuscita dell’impresa. Ma a volte capita che all’avanzare dell’opera, all’insorgere dei primi ostacoli, o solo alla sua conclusione, ci si accorga di non aver coinvolto correttamente le persone ed è molto più facile attribuire colpe all’esterno (i consulenti) piuttosto che predisporsi all’interno dell’organizzazione a rivedere in ottica critica i processi che hanno partorito una soluzione poco efficace. Ritengo che non sia corretto ritenere perfetto un processo, per il semplice fatto di averlo definito ed implementato, ma che, in ottica di miglioramento e dinamicità, qualunque processo, o sistema, debba essere considerato perfettibile.

Solo ora capisco l'importanza, direi strategica, del Process Improvement Plan (Piano di Miglioramento dei Processi) proprio in termini di qualità, ossia in termini di "idoneità allo scopo" per il quale ogni processo del sistema è stato definito. Spesso sento dire "il processo non funziona" ma al contempo vedo anche che nessuno fa niente per migliorarlo, con la conseguenza che le persone si disamorano e la novità perde il suo fascino.

E’ proprio in quest’ottica che, ritornando alla figura di partenza, ho ritenuto imprescindibile racchiudere il Sistema di PM in un framework, il contesto, che diviene rilevante non solo perché è impegnato a definire e giustificare certe scelte in fase di avvio ed implementazione del sistema di Project Management, ma deve esserlo ancor di più  nello sponsorizzare, con successivi ritorni ed aggiustamenti, le scelte che in corso d’opera vengono effettuate.

David Corbucci, PMP^®
Eureka Service