Secondo le definizioni del PMI, padre dello standard PMBOK, a cui rimandiamo per ulteriori approfondimenti, il progetto è uno “sforzo temporaneo intrapreso per creare un prodotto, servizio o risultato unico”. Così come il project management è da intendersi come “l'applicazione di conoscenze, abilità, strumenti e tecniche alle attività di progetto per soddisfare i requisiti del progetto”.
Ancor prima della diffusione del primo standard PMBOK nel 1996, il modello di gestione di riferimento, per la sua semplicità e chiarezza, era il cosiddetto ciclo di vita seriale (fasi in sequenza ordinata in cui non si può iniziare una fase fino a che non è terminata la precedente) di cui waterfall e “phase-gate” sono due declinazioni. In un ciclo di vita seriale, si pianifica l'intero progetto e poi si definiscono i requisiti, quindi l'architettura, quindi il design, quindi il codice e infine il test e la consegna al cliente.
Il problema dei cicli di vita seriali è che non si adattano al cambiamento. Gli approcci seriali senz’altro non utilizzano la pianificazione basata su risultati.
Nei cicli di vita seriali il completamento del lavoro è legato alla finalizzazione di attività e di documentazione, ma il criterio di valutazione in corso d’opera non prevede test e consegna al cliente fino al termine dell’intero progetto. Il punto è che nonostante tutti gli sforzi, il know how e l’esperienza messa in campo, solo allora si avrà la certezza di aver realizzato tutto e solo quello che il cliente aveva richiesto. E a quel punto il cliente potrebbe rendersi conto che non voleva esattamente quanto è stato realizzato, o nel frattempo altri hanno realizzato un prodotto che meglio si adatta alle sue esigenze attuali. E se anche in corso d’opera si volesse ricorrere a modifiche al progetto sia stimolata dal fornitore che dal cliente ci si troverebbe ad affrontare la totale o parziale revisione del contratto, con molte discussioni sulla remunerazione del lavoro svolto perché “non fruibile” dal cliente.
Possiamo anche lavorare nella miglior organizzazione in ottica di completamento delle attività secondo i tempi ed i costi pianificati, e anche a fornire esattamente il prodotto dei sogni al cliente, ma se sul mercato arriva un competitor con un prodotto o un servizio prima che il nostro sia disponibile, la nostra organizzazione non venderà. Troviamo quindi indicazioni sulla vulnerabilità del modello waterfall in un contesto ad alto tasso di cambiamento o VUCA come quello in cui siamo immersi.
Leggi altri articoli correlati a questo argomento:
Pubblicato nel 2001 il Manifesto Agile ha definito nuovi principi di riferimento per la gestione dei progetti software. Sulla base di questi principi sono state sviluppate diverse metodologie di cui la più conosciuta è Scrum.
Caratteristica comune delle metodologie Agile è la scomposizione del lavoro da svolgere in “pacchetti” dette iterazioni, delimitate in un tempo fissato a priori. Ogni iterazione diventa un piccolo progetto della durata in ordine delle settimane al cui termine viene rilasciata una funzionalità o una parte di prodotto testato e funzionante.
La prima osservazione è che così si riduce il rischio di fallimento in quanto il cliente ha la possibilità, molto più frequentemente, di verificarne l’aderenza alle proprie aspettative ed eventualmente definire dei requisiti diversi per le iterazioni successive.
In un contesto dove il cambiamento è la regola, le parole d’ordine sono quindi flessibilità ed adattabilità, per rimanere sempre “up-to-date” rispetto alle mutevoli richieste del cliente. Richieste che vengono tramutate nella metodologia Scrum in porzioni del Product Backlog, da prioritizzare per determinare lo scopo nelle successive iterazioni. Quindi la “risposta adattiva al cambiamento” prende il posto della onerosa “gestione delle richieste di cambiamento (modifiche)”.
La lunghezza fissata a priori dei “timebox”, se una determinata funzionalità richiede più tempo viene suddivisa in modo da rispettare il “timebox”, consente di avere “tempi e costi certi“ per il cliente, e anche la “capacità di previsione” che si finirà il lavoro entro la fine del timebox diventa tanto più una certezza, quanto più il timebox è breve, ed il team di progetto è abituato a lavorare secondo questa metodologia.
Muta anche lo scenario relativo agli indicatori dove Efficacia ed Efficienza sono più significativamente rimpiazzati da quante funzionalità, funzionanti e testate, si riescono a produrre per il cliente (curva cumulata), a cui si aggiungono il grafico del burnup del backlog di prodotto (per sapere a che punto è arrivato il progetto) e la misura della quantità dei lavori in corso (WIP= Work In Progress) da ridurre al minimo per non incorrere in ritardi ed extracosti. Normalmente lo strumento migliore per visualizzare WIP è il tabellone Kanban dove è possibile impostare i limiti corrispondenti sulle fasi di lavoro per assicurare che solo una certa quantità di attività possa risiedere in ogni colonna Kanban.
L’utilizzo del PM Agile è sempre più diffuso anche in contesti tradizionali. Scrum, ancora lui, è la metodologia più usata anche per la produzione della serie SouthPark e si trova anche applicato nel mondo scolastico con la derivazione EduScrum nata in Olanda per la gestione dei lavori di gruppo degli Studenti.
Altri esempi sono le guide turistiche Lonely Planet, il caccia Saab JAS 39 che ha avuto costi di progetto significativamente più bassi rispetto allo sviluppo del caccia F35 per cui sono state utilizzate metodologie tradizionali, e in Italia per esempio anche diverse tra le principali farmaceutiche hanno iniziato la sperimentazione per la gestione Agile dei progetti a livello locale.
Approfondisci che cos'è l'Agile Project Portfolio Management in questo articolo.