Progetti agili a prezzo fisso

A voler essere agili (non smetterò mai di sottolineare l’uso della “a” minuscola), i progetti a prezzo fisso sarebbero da evitare, poiché l’agilità è possibile solo quando ambito, tempo e costi sono malleabili.

Benvenuti nel mondo reale, dove molti (troppi?) clienti pagano al fornitore un prezzo fisso (definito nel contratto), con l’aspettativa che il progetto venga completato secondo un piano immutabile, indipendentemente dalle fluttuazioni di rischio, complessità e (perché no) di ambito (dopotutto, solo gli stolti non cambiano mai idea).

A costo di semplificare, definiamo:

1. Proposta del fornitore: esprime la “business value proposition” per un determinato lavoro. Descrive in dettaglio gli obiettivi di alto livello del cliente, fornendo intervalli di stima su costi e tempi per raggiungerli.

2. Contratto cliente-fornitore: (se la proposta viene accettata) accordo reciprocamente vincolante per far rispettare i vincoli commerciali del progetto proposto. Qui le stime possono diventare cifre più o meno fisse, a seconda dell’approccio concordato sia dal cliente che dal fornitore.

3. Progetto: esecuzione del contratto.

In poche parole: nella proposta definiamo un costo e una tempistica stimati per raggiungere i risultati del progetto, nel contratto leghiamo l’esecuzione del progetto a (alcune) cifre (in un range più o neo ampio).

Le definizioni di cui sopra vanno oltre gli approcci predittivo (non ho scritto Waterwall, son bravo eh?), agile (sempre “a” minuscola), iterativo o incrementale: ciò che cambia per ogni approccio è il contenuto effettivo.

Se sei una società che chiede al fornitore un prodotto per uso interno, sappiamo già tutti come le cose vanno a finire: benvenuti nel mondo delle Request For Change…

Se sei una società che chiede al fornitore una piattaforma (magari in white label) che dovrà essere fornita/venduta a più clienti esterni, secondo un ciclo di rilascio ben definito, dove ogni rilascio deve essere pianificato e comunicato per tempo (il cliente finale dovrà farsi i suoi conti in termini di effort di test e aggiornamento), per consentire una corretta vendita dei servizi implementati dalla piattaforma (uff!!!), allora chi non vorrebbe fissare tutte le cifre nel contratto, per evitare di pubblicizzare una nuova versione in tre mesi che non arriverà mai o arriverà castrata?

E se la soluzione fosse una preparazione della proposta e una esecuzione del progetto più efficaci?

E se invece di impegnarsi nel completamento di risultati specifici, la proposta discutesse di obiettivi aziendali concreti e misurabili?

E se il focus non fosse sulle funzionalità, che sono solo un mezzo per raggiungere uno scopo, ma sulla definizione dei criteri di business attesi, per soddisfare i quali occorre stimare costi e tempi?

In questo modo, se in esecuzione di progetto dovessimo incorrere in nuove complessità e rischi, possiamo eliminare dall’ambito le funzionalità che non contribuiscono direttamente ai nostri obiettivi aziendali, pur rimanendo entro il prezzo fisso e la pianificazione fissa.

Un approccio iterativo, in questo caso, ci viene incontro, ma poiché non è sostenibile ri-calcolare una nuova baseline di costi e tempi all’inizio di ogni iterazione, è necessario facilitare una conversazione sulle scelte, ad esempio: “Il progetto è in ritardo di x giorni, quali compromessi siamo pronti a fare per rispettare budget e tempi? Il costo e la pianificazione devono essere fissi, ma forse abbiamo flessibilità in merito alla qualità e/o alla conformità dei processi e/o alla sicurezza del prodotto e/o al gold-plating delle caratteristiche e/o (nel peggiore dei casi) a funzionalità non strategiche?”

In poche parole, dobbiamo sempre essere in grado di rispondere alla seguente domanda: quale dei nostri elementi progettuali mostra più o meno flessibilità?

Sebbene l’approccio di cui sopra abbia lo scopo di proteggere il cliente dal superamento di costi e tempi, limita anche [1] l’innovazione (non è possibile aggiungere facilmente nuove idee in tempo reale) e [2] il business value (la rimozione di funzionalità può rendere il prodotto finale meno attraente).

Per affrontare il problema [1] si potrebbe concordare che, dopo ogni iterazione (dopo, non durante, ma dopo), è possibile aggiungere una nuova funzionalità solo se ne rimuoviamo un’altra di dimensioni comparabili, generando potenzialmente il problema [2], che può essere risolto dando priorità chiare alle caratteristiche in termini di business value.

Ovviamente quanto sopra funzionerà se e solo se c’è spazio per modificare facilmente il contratto on-the-run, per onorare le nuove stime di riferimento. Da qui la necessità di avere processi di procurement e modalità contrattuali più agili.

Da sottolineare che per una relazione soddoisfacente occorre comuqnue creare e condividere con il fornitore un bilanciamento tra clause che permettano di “litigare bene” e clausole che permettano di “non litigare mai”.