Al pari di come nel precedente post abbiamo affrontato il tema del Value Stream e del VMO, vediamo ora cosa accade nell’ambito dell’archetipo Singularity, ovvero quando il beneficio da soddisfare è una tantum e si opta per un modello di sviluppo a Progetto.
In questo caso, la struttura operativa è ispirata alle tipiche fasi di progetto (Avvio, Pianificazione, Esecuzione, Monitoraggio e Controllo, Chiusura), il che non vuol dire operare obbligatoriamente in chiave stage-and-gate: in pratica, se è vero che le fasi sono sequenziali (al netto di quella di Monitoraggio e Controllo), nulla vieta di avere un approccio adattivo che, entro certi limiti, rimette in gioco le decisioni prese.
È importante ricordare che Progetto non significa waterfall, bensì:
una iniziativa temporalmente limitata e istituita allo scopo di realizzare qualcosa di innovativo, ovvero una evoluzione che precedentemente non esisteva.
La differenza primaria, rispetto ad un approccio Value Stream-based (e di riflesso Continuum) è quindi il tempo, che in questo caso è sicuramente finito. Oltre ad una innovazione comprovata e fortemente percepibile, cosa che nell’approccio Continuum potrebbe anche essere meno evidente o addirittura assente perché concentrati sugli aspetti di evoluzione manutentiva e/o correttiva.
Le diverse fasi operative del progetto possono essere realizzate impiegando più lifecycle: da quello serial(waterfall) a quello scrum/kanban like, ovviamente utilizzando sempre strumenti ben radicati nella cultura del progetto, come, ad esempio, la classica matrice RACI (Responsible, Accountable, Consulted, Informed) per l’assegnazione, o se si preferisce “condivisione”, dei compiti.
Ma torniamo ai ruoli.
Negli ultimi anni ho constatato in prima persona parecchia confusione su due dei ruoli più comunemente legati ad un progetto: il Project Manager (PM) ed il Project Manager Officer (PMO).
Ebbene, pur rispettando le diverse declinazioni di contesto, è importante evidenziare che questi ruoli non sono la stessa cosa, ed hanno obiettivi e compiti molto diversi in relazione al progetto:
-
- Il PMè la persona accountabledi progetto, colui in pratica che in prima persona si assume il rischio del successo o del fallimento del progetto stesso. In tale ottica, si occupa di definire (in modo condiviso, certo), il piano, gestire il budget, rispondere agli stakeholder, ecc.
- Il PMO è in staff al progetto, ed è responsible del suo monitoraggio e del supporto al team nell’applicazione di quelli che sono gli standard e le best practicesdiffuse a livello aziendale in ambito di project management. Il PMO riporta al PM, che poi prendere le opportune decisioni in relazione alle informazioni ottenute.
Dovrebbe, quindi, risultare chiaro che il PM ha come obiettivo l’efficienza del processo in sé e l’efficacia di quanto prodotto (eventualmente con il supporto di un Product Manger/Product Owner), mentre il PMO ha come obiettivo quello di far si che il progetto segua i binari ritenuti aziendalmente corretti, e, al contempo, essere una leva di evoluzione delle strategie di Project Management in azienda.
E qui veniamo ad un altro punto dolente: molto spesso, in tantissime aziende, manca una vera e propria “cultura del Project Management”. Molti project manager, bravissimi nei progetti che seguono, sono PM de-facto, ma senza un verso percorso di sviluppo professionale annesso: “seguo progetti perché sono il Manager d’area”.
La soluzione ideale resta sempre quella della matrice forte: costituire all’interno dell’organizzazione un PMO (nel senso di ufficio/office) e avere dei professionisti che si occupano alle tematiche di Project Management che, all’avvio di un nuovo progetto, vengono insigniti del ruolo di PM e ne assumono, quindi, l’accountability, coadiuvati dai propri colleghi per la parte di monitoraggio.
In tal modo si sarà certi che il PM ha come interesse il progetto in sé, e non quello della singola area, dipartimento, funzione da cui proviene o che dirige.
Stay tuned J
