La kick-off meeting è stata chiara. “Facciamo una piattaforma eCommerce. Catalogo, carrello, pagamento. Consegna entro Q4.”
Primo mese: “Ah, ma dovrebbe anche integrarsi con il gestionale, così i dati di stock sono real-time.”
Secondo mese: “Ci serve uno strumento di analytics integrato, per capire quali prodotti vendono.”
Terzo mese: “E se aggiungessimo un’area clienti, dove uno vede i suoi ordini storici e può gestire le preferenze?”
Approfondisci: Quando fermare un progetto digitale
Quarto mese: “Senza un sistema di reputazione, non sarà competitivo. Integriamo Google Reviews.”
Sei mesi dopo, il perimetro originale è raddoppiato. La timeline slittata di 4 mesi. Il budget è esploso. E non è un disastro — è un martedì pomeriggio. Nessuno ha detto “fermiamo, questo non era il piano”. È successo gradualmente. Una richiesta per riunione. Una slide con i “miglioramenti possibili”. Una decisione informale presa in corridoio.
Quando guardi indietro, il progetto non assomiglia più al contratto che hai firmato.
Il sintomo: la deriva progressiva
Non è cosciente. Nessuno sta consciamente allargando il progetto per sabotarlo. È il contrario. Ogni aggiunta sembra ragionevole. “Se facciamo comunque l’eCommerce, integrare il gestionale è poco sforzo extra.” (Spoiler: non lo è.)
La conseguenza è che il perimetro diventa una conversazione aperta. Non è scritto. O è scritto, ma vago. O era scritto, ma è stato interpretato diversamente dai diversi stakeholder.
Il fornitore aggiunge cose perché ogni feature aggiunta è ore fatturabili (se è su base oraria) o margine extra (se è su progetto fisso, ma non usa un controllo rigido del perimetro). Il team interno aggiunge richieste perché, mentre il progetto avanza, pensate a cose nuove che sarebbero “utili”.
Nessuno di questi incentivi è malvagio. Tutti convergono in una direzione: il progetto si allarga.
E quando finalmente ammettete a voi stessi che “questo non è quello che abbiamo contrattato”, il fornitore ha già investito le ore, il budget è già stato impegnato, il timeline è già sfasato. Tornare indietro costa un conflitto. Così vai avanti.
Il problema: scope non scritto, numerato e firmato
Qui è banale, ma fatale.
Se lo scope non è un documento preciso con voci numerate che entrambi avete firmato, allora non è scope. È una conversazione.
“Facciamo una piattaforma eCommerce” non è scope. È aspirazione.
“Piattaforma eCommerce include: (1) Catalogo con max 5000 SKU. (2) Carrello e checkout. (3) Gateway di pagamento (Stripe, Paypal). (4) Email di conferma ordine. (5) Pannello admin per gestione ordini. NON INCLUDE: integrazione con gestionale, analytics, app mobile, gestione resi.” — Questo è scope.
Se non c’è la prima versione, il perimetro è poroso. Le tue “future requests” e le sue “necessità di implementation” scivolano dentro gradualmente.
La decisione non presa: definire cosa c’è dentro e cosa no
Avresti dovuto decidere (e avrebbe dovuto deciderlo il fornitore con te): “Prima di partire, elenchiamo esattamente cosa facciamo e cosa non facciamo. Lo firmamo entrambi. Qualsiasi cosa oltre a questo è ‘out of scope’ e deve essere discussa, stimata e approvata con un change order.”
Change order non è una parolaccia. È la procedura corretta. Significa: “Avete deciso di aggiungere X. Ha un costo Y e un impatto di tempo Z. Lo approviamo?” Firmato da entrambi.
Senza il change order, le aggiunte scivolano dentro gratis.
Con il change order, aggiunte vengono viste come scelte e hanno un prezzo.
Scoperta: la gente chiede meno cose quando deve pagare per esse.
Meccanismo: incentivo del fornitore + governance assente
Il fornitore ha un incentivo chiaro a lasciar fuori scope definito. Voi durante il progetto penserete a cose nuove. Lui le farà (e fatturerà). Voi pagherete extra (se è un progetto a budget fisso che si è trasformato in time-and-materials) oppure lui avrà margine extra (se è base oraria).
Il tuo team interno non ha incentivo a controllare il perimetro. È impegnato. Se il fornitore aggiunge qualcosa che vi sembra bene, l’approvate. Non vi dite “questo non era nel contratto”, vi dite “bene, avremo più funzionalità”.
Nessuno di questi attori è sconsiderato. Sono incentivi strutturali.
L’unica cosa che ferma questo meccanismo è una regola scritta e applicata: “Qualsiasi cosa non nel documento di scope firmato è out of scope e richiede discussione + stima + change order + approvazione scritta.”
Se il fornitore propone features aggiuntive come “incremental improvement” senza change order, tu dici no. Non è cattiveria. È protezione del progetto.
3 segni che il tuo scope è già rotto
1. Non riesci a elencare in meno di 10 secondi cosa consegnerete.
Se non puoi rispondere rapidamente “consegniamo X, Y, Z”, il perimetro non è chiaro nella tua testa. Significa che non è chiaro nemmeno nei documenti (se li hai).
2. Le persone del tuo team dicono “potremmo aggiungere…” più di una volta al mese.
Non è male pensare a miglioramenti. È male non controllare se quei miglioramenti entrano nel budget e nella timeline. Se il numero di “potremmo aggiungere” supera il numero di “abbiamo deciso di non fare”, il perimetro è gestito da conversazione, non da criterio.
3. Il fornitore non sa dire no.
Quando proponete di aggiungere una feature, se la risposta è sempre “va bene, la facciamo”, senza un “questo è out of scope oppure aggiungiamo 2 settimane e 15 mila euro”, il fornitore non sta governando il progetto — sta dicendo sì a tutto per tenervi contenti.
Un fornitore bravo dice: “Vi capisco, è una buona idea. È out of scope. Se la volete, è 15 giorni e 20 mila euro, che traslano la live da luglio ad agosto. Decidete.”
Ora il vostro team può valutare: “Vale la pena? Possiamo permetterci il ritardo?”
Senza questa friczione, il progetto non è governato — è alla deriva.
Criterio: il modello 3+2
Prima di partire, documenti che include queste sezioni:
Must-have (M): funzionalità essenziali. Senza queste, il progetto non ha valore. Max 10 voci.
Should-have (S): miglioramenti desiderabili. Importanti, ma non critiche. Max 8 voci.
Could-have (C): nice-to-have. Valgono la pena se il budget e il tempo lo permettono. Max 5 voci.
Out of scope (O): tutto il resto. Esplicito. “Non facciamo: mobile app, integration con marketplace, gestione multi-valuta.”
Future (F): cose per fasi successive. “Queste le affrontiamo dopo il go-live.”
Questo è il vostro perimetro. Lo firmate con il fornitore.
Ogni richiesta nuova che arriva va classificata: “È in M, quindi è dentro. È in C, quindi discutiamo se il budget permette. È in O, quindi la trattiamo come change order.”
Non è perfetto. Ma è governance.
Taglio: cosa smettere di fare
Smetti di approvare feature aggiuntive in riunioni senza una stima scritta.
Se il fornitore propone X in una call, la risposta è: “Interessante. Mandarmi una stima (ore, costo, impatto timeline) per mercoledì, decidiamo giovedì.” Non approvare mai in real-time.
Smetti di dare “mini-approvazioni” verbali che poi neghi.
Se dici al fornitore “va bene, fai questa integrazione” in una call informale, e poi dici “non lo avevamo concordato”, lui ha ragione di sentirsi tradito. Se una cosa è out of scope, dillo adesso con chiarezza. Non aspettare la fattura per protestare.
Smetti di confondere “aggiunta di valore” con “controllo del perimetro”.
È bello che il fornitore suggerisca miglioramenti. Ma sono suggerimenti, non approvazioni. Ogni suggerimento dovrebbe passare dal tuo filtro: “Vale la pena? Ha costo? È in linea con la nostra priorità?”
Smetti di pensare che il fornitore si autodisciplinerà.
La cortesia professionale non basta. Se il tuo scope è vago, lui lo interpreta nel modo che gli conviene. Non per malafede — per mancanza di confini chiari. Dagli confini. Firmati.
La domanda finale
Prendi il tuo documento di scope attuale (se esiste) e fai un test: elenca 10 cose che NON farete, dettagliate. Se non riesci, non hai scope — hai una lista di desideri.
Comincia dalla negazione. È il confine più forte.
Leggi anche
- Quando fermare un progetto digitale
- Perché il go-live non è mai la fine
- Hai comprato il software sbagliato?
- Dati ovunque, informazioni da nessuna parte
Domande frequenti
Cos’è lo scope creep in un progetto digitale?
Lo scope creep è l’espansione progressiva e non controllata del perimetro di un progetto. Succede quando ogni riunione aggiunge funzionalità senza togliere nulla e senza rinegoziare tempi e budget.
Come si previene lo scope creep?
Con tre regole: perimetro scritto e firmato, change request formale per ogni modifica, e revisione trimestrale obbligatoria con criterio stop/go.
Chi è responsabile dello scope creep?
Non è colpa del fornitore né del team. È un problema di governance: manca un owner con autorità di dire no e un processo per valutare l’impatto di ogni aggiunta.
