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”.
Waterfall
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.
Inizia ora il tuo primo video corso Agile gratuito
Quali debolezze
Criterio di valutazione
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.
Stime al completamento
Inoltre, portando l’attenzione al team di progetto si può incorrere ad esempio nel problema del “completamento del 90%” verso la fine del progetto. Quando si è completato il 90% del progetto ci si rende conto di avere un lavoro residuo ben oltre la stima effettuata molto tempo prima. Questo perché all’atto della pianificazione vengono effettuate “stime al completamento” quindi delle previsioni anche per attività molto avanti nel tempo, per le quali l’affidabilità predittiva decade significativamente.Le metriche
Riferendoci invece alle metriche utilizzate per la valutazione dello stato di salute del progetto, i plurigettonati indicatori di Efficacia ed Efficienza, si comprende come siano orientati all’interno dell’organizzazione del fornitore, ma non valgono certo a garantire le revenue a completamento avvenuto.
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:
Agile Project management
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.
Campo di applicazione dell’Agile Project Management
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.
Se dopo aver trovato la tua risposta, e quindi la tua certificazione, non hai ancora le idee ben chiare ti suggeriamo di scaricare la Guida alle certificazioni Agile.