Tempi, risorse, costi: il triangolo di ferro e l’agilità

Il triangolo di ferro nel project management

Il triangolo di ferro (meglio conosciuto in inglese come Iron Triangle) è un modello ideato da Martin Barnes nel 1969 (Martin Barnes: ingegnere inglese, fondatore dell’Associazione per il Project Management) teorizza una composizione dei vincoli per l’evoluzione e lo sviluppo di un progetto in base a tre principali fattori, intorno ai quali il progetto si regge: la durata (time), le risorse (resources) e l’ambito (scope) del progetto.
Time: si riferisce alla durata del progetto, in termini di giorni, settimane, mesi… è la stima di quanto il progetto debba durare per raggiungere l’obiettivo.
Resources: si riferisce alle persone e, più genericamente, ai costi che si stimano essere necessari per raggiungere l’obiettivo.
Scope: lo scope di un progetto è il suo obiettivo, ovvero il risultato finale che il progetto porterà in campo e che intende soddisfare le richieste del cliente.

Il triangolo di ferro si chiama appunto ’di ferro’ per la sua scarsa flessibilità: non è possibile modificare uno dei vincoli (time, resources, scope) senza impattare anche sugli altri.
Nel project management tradizionale si ipotizza che il triangolo di ferro sia inserito in un contesto nel quale l’unico vincolo fisso è lo scope, mentre i restanti due vincoli sono variabili; un esempio pratico: una volta concordato lo scope di un progetto (concordo con il cliente quale soluzione risolverà il suo problema), in base alla deadline richiesta dal cliente (time), avremo di conseguenza anche i costi (risorse).

Il triangolo di ferro e il Cynefin

Il modello del triangolo di ferro, così come è stato descritto, sembra efficace quando il contesto muta lentamente e il ciclo di vita del progetto ha una durata inferiore al periodo di stabilità del contesto stesso. Ipotizziamo un contesto nel quale i fattori che possono incidere sulle necessità del cliente varino con estrema lentezza (il mercato, i competitor, la tecnologia, etc…) e ipotizziamo che sia il cliente che il fornitore abbiano completa consapevolezza delle problematiche, degli strumenti e delle opzioni applicabili in questo contesto: in tal caso è lecito pensare che il nostro progetto soddisferà il cliente seguendo un processo che preveda dapprima una analisi dettagliata del problema e una scelta implementativa e, a seguire, una fase esecutiva nella quale ci avvicineremo alla deadline ’giocando’ sulle risorse. La descrizione di questo tipo di contesto e di problematiche richiama fortemente il quadrante del Complicato del Cynefin framework: anche in questo caso si ha un problema, se ne analizzano le cause e si definisce un piano, quindi si implementa questo piano per raggiungere l’obiettivo, utilizzando tipicamente delle best practices.

Il triangolo agile e il Cynefin

Immaginiamo ora di trovarci in un contesto nel quale le condizstima di quanto ilioni variano velocemente, le assunzioni che possiamo fare devono adattarsi velocemente ad una realtà in continuo mutamento, le condizioni di mercato, competitor, tecnologia, cambiano con una frequenza maggiore di quella che abbiamo ipotizzato per i nostri rilasci di valore.
In tal caso risulterà estremamente rischioso portare in produzione l’implementazione di requisiti che non sono stati verificati frequentemente durante lo sviluppo stesso del progetto: dovremo integrare in corsa le modifiche derivanti dalle variazioni del contesto; conseguentemente: la pianificazione a lungo termine ha un’elevata probabilità di risultare uno spreco di risorse; dovremo accettare di ripianificare frequentemente, utilizzando strategie che minimizzino i costi dei cambi di requisito.
Siamo nel quadrante del Complesso del Cynefin framework e stiamo ribaltando il triangolo di ferro: lo scope è adesso variabile e, nel nostro progetto, fissiamo invece tempi e risorse per determinare i costi.
Il nostro cliente non sta pagando per la promessa di un (inaffidabile) risultato, ma per le professionalità e le skill che saremo in grado di mettergli a disposizione. In quello che possiamo chiamare triangolo agile, vanno considerati due principali fattori che determinano le caratteristiche del processo: qualità e valore.
La qualità è un fattore da considerare come non variabile, definito in accordo fra il Dev Team e il PO e formalizzato con una Definition of Done.
Il valore è quello che in buona sostanza sostituisce il concetto di scope, concentrandosi non tanto su effimeri obiettivi a priori, quanto su risultati basati su feedback frequenti.
I nostri constraint saranno quindi: Risorse e Tempi: dipendenti dal parametro fisso della Qualità Scope: variabile, basato sul feedback del Valore. Come si può ben immaginare, avviare un progetto con scope variabile necessita di una notevole fiducia tra le parti, non essendo definito a priori l’output finale del progetto stesso; esistono diverse tipologie di contratto agile (approfondimenti nella sezione dedicata), utili a capire l’approccio nella fase di contrattazione e accordo con il cliente (es: Time and Material, Target Cost, Incremental Delivery, Pay per Use…). La domanda sorge spontanea: perché il cliente dovrebbe riporre la sua fiducia nel fornitore? Di rimando, rispondiamo con un’altra domanda: meglio un rischio consapevole, o un inconsapevole rischio?