Change request: come gestirle senza far esplodere budget e tempi

Nessun progetto software arriva alla fine identico a come è stato pensato all’inizio: è fisiologico, non un fallimento di pianificazione. Il problema non è che le richieste di modifica arrivino — è che arrivino senza un processo che le valuti prima di diventare lavoro fatto. È lì, non nella richiesta in sé, che budget e tempi cominciano a scappare di mano.

Cos’è lo scope creep, in pratica

Lo scope creep è l’espansione incontrollata degli obiettivi o dei task di un progetto oltre il piano originale, che avviene tipicamente quando nuovi requisiti vengono aggiunti senza una revisione formale. Non è quasi mai una singola richiesta enorme: è una somma di piccole aggiunte — “già che ci siamo”, “tanto è una cosa piccola” — ciascuna ragionevole da sola, insostenibile insieme.

Perché costa più di quanto sembra

• Il costo diretto della modifica, spesso sottostimato perché valutato a occhio invece che formalmente.
• Il costo di interruzione: rientrare su un modulo già chiuso costa più che svilupparlo la prima volta, perché richiede di ricostruire il contesto.
• Il costo sul resto del piano: tempo dedicato alla modifica non pianificata che non viene dedicato a quanto già promesso per quella data.

Preso singolarmente, ogni “piccolo cambiamento” sembra irrilevante. Sommati, spiegano la maggior parte degli sforamenti di budget e di tempi che si vedono nei progetti IT.

Un processo di change control minimo

1. Richiesta scritta, anche breve: cosa cambia, perché serve.
2. Valutazione d’impatto prima di procedere: effetto su tempi, costo, e su cosa altro nel piano deve slittare o essere ridotto per assorbirla.
3. Decisione esplicita del committente: approva, rifiuta, rimanda a dopo il rilascio. Mai un “sì” informale a voce che nessuno mette per iscritto.
4. Aggiornamento del piano visibile a tutti: se una richiesta viene accettata, la data di consegna o il budget si aggiornano di conseguenza — non restano quelli originali “per non fare brutta figura”.

La domanda che disciplina le richieste meglio di ogni processo

Davanti a ogni nuova richiesta, la domanda utile non è “si può fare?” — quasi sempre sì. È: “Cosa siamo disposti a togliere o spostare per farci stare questa?” Un processo di trade-off esplicito (aggiungi X, rimuovi o rimandi Y) mantiene il piano onesto. Aggiungere sempre, senza mai togliere né spostare la data, è la ricetta esatta per uno scope che cresce e un budget che segue.

Cosa mettere in contratto

Il processo di gestione delle modifiche va definito quando firmi il contratto iniziale, non inventato a metà progetto: come si valuta una richiesta, chi la approva, come viene prezzata (a preventivo separato, a tariffa oraria, a pacchetto di ore incluso). Un fornitore che non ha una risposta chiara su questo punto la inventerà — a suo favore — quando la prima richiesta arriverà davvero.

In sintesi

Le richieste di modifica non sono il problema: lo è affrontarle senza un processo che le valuti prima di eseguirle. Una richiesta scritta, una valutazione d’impatto onesta e una decisione esplicita — con un piano che si aggiorna di conseguenza — trasformano lo scope creep in un normale adattamento del progetto, gestito invece che subito.