Scope creep: cause, esempi e come prevenirlo

Che cos'è lo scope creep?

Scope creep è l'espansione incontrollata dell'ambito del prodotto o del progetto senza adeguamenti corrispondenti di tempi, costi e risorse. Si verifica quando nuove funzionalità, deliverable o attività vengono aggiunti dopo che l'ambito è stato concordato, ma nessuno ne valuta l'impatto, li approva formalmente o aggiorna il piano di conseguenza.

Il PMI usa quasi esattamente questa formulazione nel suo glossario, ed è un test utile: se è stato aggiunto lavoro e la baseline dell'ambito, il cronoprogramma e il budget non sono cambiati, sei di fronte a scope creep.

È utile distinguere due tipi di ambito. Ambito del prodotto sono le caratteristiche e le funzioni di ciò che stai realizzando, come un sito web con ricerca e checkout. Ambito del progetto è il lavoro necessario per consegnarlo: progettazione, sviluppo, test, formazione e lancio. Lo scope creep può riguardare l'uno o l'altro. Un cliente che chiede una chat dal vivo amplia l'ambito del prodotto; uno sponsor che chiede al team di migrare anche dieci anni di dati d'archivio amplia l'ambito del progetto.

La parola "creep" (strisciante) è importante. Una singola grande modifica di solito viene notata e discussa. Lo scope creep è fatto di tante piccole modifiche, ciascuna apparentemente troppo marginale per essere formalizzata: un report in più, un ulteriore giro di revisioni, un rapido ritocco alla pagina di login. Singolarmente sembrano innocue; insieme possono aggiungere settimane.

È anche frequente. Il report *Pulse of the Profession* 2018 del PMI ha rilevato che il 52% dei progetti completati nei 12 mesi precedenti aveva subito scope creep, contro il 43% di cinque anni prima.

La nostra guida all' ambito del progetto spiega come definire correttamente l'ambito fin dall'inizio.

Scope creep vs modifica dell'ambito, gold plating e feature creep

Non ogni modifica all'ambito è scope creep. I progetti imparano strada facendo, e le modifiche approvate che aggiungono valore fanno parte di un buon project management. La differenza è il controllo.

Gold plating è una forma di scope creep che nasce all'interno del team. Di solito è in buona fede, ma consuma tempo e budget, aggiunge rischi e può introdurre difetti in aree che il cliente non ha mai richiesto. Feature creep è il termine usato nello sviluppo prodotto per lo stesso schema, con il focus sul prodotto anziché sul progetto.

Quali sono le cause dello scope creep?

Lo scope creep ha quasi sempre più di una causa. Queste sono le più frequenti.

Ambito e requisiti poco chiari

Se la dichiarazione dell'ambito è vaga ("un sito web moderno", "reporting migliorato"), quasi ogni richiesta può essere considerata nell'ambito. Requisiti requisiti e criteri di accettazione mancanti o scritti in modo approssimativo lasciano spazio all'interpretazione, e quello spazio tende a riempirsi di lavoro extra.

Nessun controllo formale delle modifiche

Senza un processo definito di controllo delle modifiche , non esiste un modo concordato per dire "sì, ed ecco quanto costa". Le richieste vengono accettate in silenzio o rifiutate con imbarazzo, e le accettazioni silenziose diventano scope creep.

Stakeholder che scavalcano il project manager

Le richieste inviate direttamente a un designer o a uno sviluppatore via email, chat o in riunione scavalcano il project manager. Il membro del team vuole essere d'aiuto, svolge il lavoro, e il piano non ne viene mai a conoscenza.

Gold plating e buone intenzioni

A volte i team aggiungono funzionalità o rifiniture per impressionare il cliente. Sembra un buon servizio, ma consuma tempo non previsto dal piano e può creare aspettative per i progetti futuri.

Progetti lunghi ed esigenze aziendali che cambiano

Più a lungo dura un progetto, più cambia il contesto aziendale intorno a esso: nuove normative, nuovi concorrenti, nuova leadership. Alcuni di questi cambiamenti sono legittimi, ma vanno valutati anziché assorbiti.

Sponsorship debole e pressione commerciale

Uno sponsor che non partecipa alle decisioni sui compromessi lascia il project manager senza il sostegno necessario per opporsi. Nel lavoro per clienti, il timore di scontentare il cliente (o un contratto a prezzo fisso con uno statement of workvago) rende allettante assorbire le richieste anziché sollevarle.

Esempi di scope creep

Questi esempi mostrano come si presenta lo scope creep in diversi tipi di progetto. In ogni caso la richiesta originale era ragionevole; il problema è che non è mai stata valutata rispetto a tempi e costi.

Esempio svolto: come si sommano le piccole richieste

Immagina un progetto web di 12 settimane con una data di lancio fissa. Nell'arco di sei settimane, il cliente chiede cinque cose "piccole", ciascuna concordata in modo informale:

• Una landing page in più (3 giorni).
• Un'iscrizione alla newsletter collegata alla sua piattaforma email (2 giorni).
• Un terzo giro di revisioni del design della homepage (3 giorni).
• Personalizzazione del banner dei cookie (1 giorno).
• Importazione di 40 vecchi articoli del blog (4 giorni).

Nessuna di queste sembra significativa da sola, ma insieme aggiungono 13 giorni lavorativi, quasi tre settimane, a un piano di 12 settimane. Nulla nel cronoprogramma o nel budget è cambiato, quindi il team fa straordinari, i test vengono ridotti e il lancio slitta o va online con dei difetti.

Ora fai passare le stesse richieste attraverso il controllo delle modifiche. Ciascuna viene registrata, l'impatto viene mostrato e il cliente sceglie: la landing page e l'iscrizione alla newsletter vengono approvate con una proroga di una settimana e budget aggiuntivo; l'importazione del blog passa a una fase 2; il giro di design aggiuntivo viene scambiato con una pagina a priorità più bassa. Il progetto cresce comunque, ma cresce intenzionalmente.

L'impatto dello scope creep

Lo scope creep danneggia i progetti a causa del vincolo triplo: ambito, tempi e costi sono collegati. Se l'ambito cresce e gli altri due non si muovono, qualcos'altro cede, di solito la qualità o il team.

• Ritardi nel cronoprogramma: il lavoro extra sposta in avanti le milestone, e spesso è il percorso critico ad assorbirlo per primo.
• Sforamenti del budget: più impegno, più materiali e più costi dei fornitori, senza budget per coprirli.
• Qualità inferiore: test, revisioni e documentazione vengono compressi per salvare la scadenza.
• Burnout del team: le persone lavorano più ore su attività che non compaiono in nessun piano, con danni al morale.
• Fiducia compromessa: gli stakeholder sono sorpresi quando le date slittano, anche se sono stati loro a chiedere le aggiunte.
• Benefici ritardati: il valore centrale del progetto raggiunge gli utenti più tardi di quanto avrebbe potuto.
• Reporting meno affidabile: le percentuali di avanzamento perdono significato perché la baseline non riflette più il lavoro reale.

Nei progetti commerciali c'è un costo aggiuntivo: il lavoro non fatturato. Agenzie e società di consulenza che assorbono lo scope creep perdono margine in ogni progetto in cui si verifica.

Segnali d'allarme dello scope creep

Lo scope creep è più facile da gestire quando lo si individua per tempo. Fai attenzione a questi segnali:

• Sulla board o nei timesheet compaiono attività che non sono nella work breakdown structure.
• Le richieste arrivano via email, chat o in riunione, anziché attraverso il canale di raccolta concordato.
• Senti frasi come "già che ci sei", "dovrebbe richiedere solo cinque minuti" o "davamo per scontato che fosse incluso".
• I criteri di accettazione vengono riscritti dopo l'inizio del lavoro.
• Il team fa straordinari ma il cronoprogramma non mostra variazioni.
• I deliverable restano "quasi finiti" per settimane.
• La linea dell'ambito in un burn-up chart continua a salire, oppure il backlog cresce più rapidamente di quanto il team consegni.
• L'impegno effettivo supera di molto le stime su attività ben comprese.
• Stakeholder non coinvolti nella pianificazione iniziano a influenzare la soluzione nelle fasi avanzate del progetto.

Come prevenire lo scope creep

La prevenzione consiste soprattutto nel concordare chiaramente l'ambito e nel concordare in anticipo come saranno gestite le modifiche. Questi passaggi funzionano nei progetti tradizionali e ibridi di qualsiasi dimensione.

1. Concorda obiettivi chiari. Scrivi obiettivi misurabili nel project charter in modo che ogni richiesta possa essere verificata rispetto a essi: aiuta a raggiungere l'obiettivo?
2. Raccogli correttamente i requisiti. Coinvolgi chi userà il risultato, non solo chi lo paga, e registra i requisiti con le relative priorità.
3. Scrivi una dichiarazione dell'ambito con le esclusioni. Elenca cosa rientra nell'ambito e, altrettanto importante, cosa non vi rientra. Le esclusioni evitano la conversazione "davamo per scontato che fosse incluso".
4. Scomponi il lavoro. Crea una work breakdown structure e un dizionario WBS, in modo che l'intero ambito sia visibile e ogni deliverable abbia una definizione.
5. Definisci i criteri di accettazione. Per ogni deliverable, concorda come saprai che è completato. Spostare i criteri di accettazione è una delle forme più silenziose di scope creep.
6. Ottieni l'approvazione e fissa una baseline. Fai approvare allo sponsor o al cliente la dichiarazione dell'ambito, la WBS e il dizionario WBS. Insieme formano la baseline dell'ambito rispetto a cui misurerai le modifiche.
7. Predisponi il controllo delle modifiche prima che serva. Concorda come vengono registrate le richieste, chi le valuta, chi le approva e come viene aggiornato il piano. Mantienilo leggero per i progetti piccoli.
8. Crea un unico canale di raccolta. Chiedi agli stakeholder di inviare tutte le richieste al project manager o tramite un modulo, e chiedi al team di reindirizzare con cortesia le richieste arrivate per canali paralleli.
9. Comunica regolarmente. Usa un ritmo costante di report sullo stato e revisioni, così gli stakeholder vedono l'avanzamento e si sentono ascoltati, il che riduce le richieste informali.
10. Inserisci le condizioni per le modifiche nei contratti. Nel lavoro per clienti, lo statement of work dovrebbe indicare come le modifiche vengono richieste, quotate e approvate.

Il modello di ambito di progetto copre obiettivi, deliverable, cosa è incluso e cosa è escluso dall'ambito, criteri di accettazione, vincoli e assunzioni: gran parte del lavoro preparatorio descritto sopra in un unico documento.

Il controllo delle modifiche è il controllo più importante di questo elenco.

Come gestire lo scope creep quando si verifica

Anche i progetti ben pianificati ricevono nuove richieste. L'obiettivo non è rifiutare il cambiamento, ma rendere ogni modifica visibile e deliberata.

Risposta passo passo a una nuova richiesta

1. Fermati prima di accettare. Ringrazia la persona e dille che valuterai l'impatto. Evita un sì o un no immediato.
2. Registrala. Registra la richiesta in un registro delle modifiche o in un modello di richiesta di modifica: cosa viene chiesto, da chi e perché.
3. Confrontala con la baseline. È davvero nuova, o è già coperta da un requisito o da un criterio di accettazione esistente?
4. Valuta l'impatto. Stima l'effetto su cronoprogramma, costi, risorse, qualità e rischio. Coinvolgi le persone che svolgerebbero il lavoro.
5. Prepara delle opzioni. Presenta scelte realistiche anziché un'unica risposta (vedi la tabella seguente).
6. Ottieni una decisione dalla persona giusta. Decide lo sponsor, il cliente o il comitato di controllo delle modifiche, non il membro del team che ha ricevuto la richiesta.
7. Aggiorna il piano. Se approvata, aggiorna dichiarazione dell'ambito, WBS, cronoprogramma, budget e registro dei rischi, poi ridefinisci la baseline.
8. Comunica l'esito. Informa il richiedente, il team e gli altri stakeholder di quanto deciso e di cosa cambia.

Come dire di no (o "sì, e") a uno stakeholder

Un no secco può danneggiare le relazioni, soprattutto con clienti e stakeholder di alto livello. Di solito funziona meglio mostrare il compromesso e lasciare la scelta a chi decide:

Mantieni la conversazione sugli obiettivi del progetto anziché sulle preferenze personali, e metti l'esito per iscritto. La nostra guida alla gestione degli stakeholder spiega come gestire queste conversazioni con diversi tipi di stakeholder.

Lo scope creep nei progetti Agile

Gli approcci Agile prevedono che l'ambito cambi. Ciò non significa che i team Agile siano immuni allo scope creep; significa che il cambiamento viene gestito diversamente.

In Scrum, tutto il lavoro noto si trova nel Product Backlog, che il Product Owner ordina. Secondo la Scrum Guide 2020, durante uno Sprint non si apportano modifiche che metterebbero a rischio lo Sprint Goal, e l'ambito può essere chiarito e rinegoziato con il Product Owner man mano che si impara. Le nuove idee vanno quindi nel backlog, non direttamente a uno sviluppatore, e vengono inserite in uno Sprint futuro durante lo Sprint Planning se hanno abbastanza valore.

Tempi e costi sono in genere fissi per ogni iterazione, e l'ambito è la variabile. Lo scope creep in Agile si presenta diversamente rispetto a un progetto tradizionale:

• Stakeholder che chiedono agli sviluppatori di infilare lavoro nello Sprint in corso.
• Sprint Goal mancati ripetutamente perché a metà Sprint viene inserito lavoro non pianificato.
• Un backlog che cresce senza essere ordinato o raffinato, per cui nulla viene mai declassato di priorità.
• Una data di rilascio e un elenco completo di funzionalità trattati entrambi come fissi.
• Il significato di "Done" che cambia in silenzio perché manca una Definition of Done.

condivisa. Un burn-up chart con una linea dell'ambito separata lo rende visibile: se la linea dell'ambito sale velocemente quanto quella del lavoro completato, la data di rilascio non arriverà mai. Anche il monitoraggio della velocity aiuta; consulta la nostra guida al Velocity chart Agile.

Strumenti e modelli che aiutano a controllare l'ambito

Non serve un software specialistico per controllare l'ambito, ma alcuni documenti rendono il lavoro molto più semplice:

• Modello di ambito di progetto: obiettivi, deliverable, inclusioni, esclusioni, criteri di accettazione, vincoli e assunzioni.
• Modello di richiesta di modifica: un modulo di richiesta di modifica e un registro delle modifiche con l'impatto su ambito, tempi e costi.
• modello WBS: codici WBS, livelli, deliverable, responsabili, impegno e costi.
• Modello di registro RAID: rischi, assunzioni, problemi e dipendenze, incluse le assunzioni da cui dipende l'ambito.
• Modello di documento dei requisiti di business: requisiti e priorità concordati prima dello sviluppo.

Il software di project management aiuta quando le richieste arrivano da molte persone. Moduli di richiesta, flussi di approvazione e una baseline visibile riducono il lavoro arrivato per canali paralleli. Il nostro strumento al primo posto, Wrike, è adatto ai team che vogliono moduli di richiesta strutturati e approvazioni su più progetti; anche altri strumenti lo gestiscono bene, come spiegano le nostre classifiche dei software di project management .

Errori comuni da evitare

• Considerare negativo ogni cambiamento. Rifiutare ogni richiesta frustra gli stakeholder e può portare il progetto a consegnare qualcosa di cui nessuno ha bisogno. Controlla il cambiamento; non bloccarlo.
• Accettare approvazioni verbali. Se non è scritto, in seguito verrà ricordato in modo diverso.
• Ignorare le piccole modifiche. L'esempio svolto sopra mostra come piccole richieste non registrate diventino settimane di lavoro.
• Tralasciare le esclusioni. Una dichiarazione dell'ambito senza un elenco di ciò che è escluso invita a fare supposizioni.
• Lasciare che il team faccia gold plating. Riconosci la buona intenzione, ma reindirizza le idee aggiuntive verso richieste di modifica o il backlog.
• Approvare modifiche senza ridefinire la baseline. Se il piano non viene aggiornato, i report di avanzamento diventano fuorvianti.
• Rendere il processo troppo pesante. Un modulo di dieci pagine per una modifica di un giorno incoraggia le persone ad aggirarlo. Proporziona il processo alla dimensione della modifica.

Per un quadro più ampio di come il controllo delle modifiche differisca dalla gestione del cambiamento organizzativo, leggi change management vs controllo delle modifiche.

Modelli gratuiti per questo argomento

Sfoglia tutti i modelli

Domande frequenti