Close
Il Project Manager ingessa i processi…

Il Project Manager ingessa i processi…

Shares

Ovviamente non voglio ingessare nessuno… 🙂 Ho però deciso che da oggi userò questo blog non solo per Project Management, lean e i processi, ma anche per comunicare con i miei clienti, visto che non c’è mai il tempo di parlare di argomenti importanti con i “decision makers” delle aziende che seguo.

L’episodio è questo:

mi è capitato di discutere in un’ azienda di un argomento a me caro: l’adozione di metodologie di Project Management per la gestione di progetti. Ne ho parlato con il responsabile e la risposta è stata più che positiva, per cui sono certo che si andrà in quella direzione, ma… c’è un “ma”:

L’ azienda richiede giustamente flessibilità nell’approccio ai progetti, volendo evitare situazioni in cui , tra la proposta al cliente, la chiusura del contratto e la consegna dei deliverable con conseguente chiusura del progetto (perché , ricordiamolo, un progetto per definizione ha una fine) si debbano attraversare dei passaggi obbligati che costringono le risorse ad essere poco “creative” e a trasformarsi in “manodopera non pensante”, giusto per semplificare.

Alla fine l’introduzione della gestione per progetti diventerà, si spera, graduale, e porterà, secondo la visione del responsabile, ad innegabili vantaggi in termini di impiego di risorse e budget, ma l’approccio non sarà totalmente “waterfall”. Probabilmente sarà più o meno Agile, anche nei confronti del cliente.

Ora, appurato che non ho alcun problema nei confronti di Agile (anche perché vengo dal mondo della produzione, e trovo che Agile sia per certi versi l’applicazione di parte della filosofia “lean”, tipicamente operational, alla produzione di software), vorrei provare a sfatare il mito secondo il quale l’approccio cosiddetto “waterfall” (quindi anche quello secondo norma, a sentire il responsabile) non sia flessibile, e perciò poco adatto all’evoluzione dei moderni progetti, che sempre più stanno diventando veloci, adattivi e inquadrati in ambiti in continua trasformazione (non uso volutamente l’espressione “cambiamento continuo” perché ha un significato completamente diverso per chi mastica di lean).

Dovrei dare però qualche definizione, prima di continuare. Mi limiterò a dire che l’approccio “waterfall” per come originariamente era stato concepito non esiste più da un pezzo. Diciamo almeno dalla fine degli anni 80, quando è stata pubblicata la prima guida PMBOK. Per chi ha voglia di approfondire, qui e qui ci sono degli articoletti interessanti che fanno quantomeno intuire anche il contesto storico in cui quell’approccio è nato.

In realtà quindi l’approccio “waterfall” che genericamente si vuole porre in contrapposizione con il framework Agile riguarda sempre e solo esclusivamente lo sviluppo del software, non dei progetti in generale. E già qui iniziano i primi problemi.

Mi pare evidente che un approccio “waterfall” oggigiorno non sia più adatto allo sviluppo di software. Su questo siamo abbastanza d’accordo. Ma non è di questo che voglio parlare.

L’approccio “waterfall” non è altro che la standardizzazione di fasi : analisi, design, sviluppo, collaudo e manutenzione. Queste fasi avevano la pretesa di essere applicate “tout court” allo sviluppo di software.

Il moderno Project Management non ha nulla a che vedere con questo approccio, tant’ è vero che il concetto di “fase” non esiste se non come suddivisione arbitraria e di comodo per la gestione delle milestones.

Quindi già a questo punto la questione non si pone. Storicamente il “waterfall” è rigido e non si discute. Ma il Project Management moderno non è waterfall! Lo definiamo così perché ci è più comodo, ma di waterfall resta solo l’etichetta. Comunque sia, continuerò ad usarla,  quest’ etichetta , visto che è entrata nel linguaggio comune, ma la distinzione era doverosa. Detto questo, veniamo ai punti che analizzerò uno alla volta altrimenti l’articoletto rischia di essere pesante… 🙂 .

 

  • Il primo dei punti che vengono portati a sfavore  dell’ approccio waterfall  è che le metriche di progetto (Earned Value su tutti) vengono principalmente usate per misurare gli scostamenti dal piano di progetto. Se il piano muta, perché muta il contesto, perché cambiano gli attori, perché il budget varia o per altri motivi, allora le metriche vanno a farsi benedire.

Questa è un’argomentazione sicuramente fondata, ma è un falso problema. L’ approccio al moderno Project Management non è assolutamente rigido da questo punto di vista. la ripianificazione a seguito di un cambiamento è prevista e anzi, ampiamente incoraggiata. Il modello PDCA di Deming stesso è fortemente radicato nella definizione di gruppi di processi del Project Management (avvio,pianificazione, esecuzione, controllo e chiusura ).Ovvio che questo comporta dispendio di energie in termini di costi, autorizzazioni, coinvolgimenti e responsabilità, ma questo è inevitabile, qualunque sia l’approccio metodologico o la filosofia adottata. Da questo punto di vista Agile si salva semplicemente ponendo come pilastro fermo che il committente deve essere pienamente coinvolto nello sviluppo del progetto. Per dirla con la storiella del maiale e della gallina, si assume che il cliente deve fare la parte del maiale (senza offesa… 🙂 ).  Il risultato sarà che, nell’ipotesi che non si centrino gli obiettivi con la qualità concordata, nel tempo previsto e con i costi attesi, il cliente sarà con buona probabilità il primo a giustificare il mancato raggiungimento dell’obiettivo.

Parlando di progetti in genere (non solo software) sarà ben difficile trovare un cliente disposto ad interpretare questo ruolo accondiscendente. Per partnership, progetti interni o progetti di ricerca può avere un senso, ma quanto ne ha per un cliente che si aspetta che il suo deliverable gli venga consegnato quando lui lo ha deciso? la produzione del valore per il cliente sta anche in questo.

A presto con la seconda parte!…

Leave a Reply

Your email address will not be published. Required fields are marked *

Shares