Scope e Change Management in PM²: cambiare con criterio, non per inerzia
Diciassettesimo articolo della serie “Imparare PM² attraverso un progetto”
Lo scope non è l’elenco delle cose che il team pensa di fare. È il perimetro approvato del progetto: deliverable, requisiti, confini, assunzioni e criteri che stabiliscono cosa il progetto produrrà e cosa non produrrà.
Cambiare scope non è un fallimento. È normale che emergano nuove esigenze, vincoli o opportunità. Il problema nasce quando il cambiamento entra nel progetto senza una decisione esplicita sugli impatti.
Scope: includere significa anche escludere
Un buon perimetro rende visibili quattro aspetti:
| Elemento | Domanda |
|---|---|
| Deliverable | Che cosa sarà prodotto e consegnato? |
| Requisiti | Quali capacità, regole e vincoli devono essere soddisfatti? |
| Confini | Che cosa resta esplicitamente fuori dal progetto? |
| Criteri di accettazione | Come si dimostrerà che il risultato è accettabile? |
Dire “faremo una gestione delle prenotazioni” lascia tutto aperto. Dire “rilascio web e app per prenotare, annullare e gestire lista d’attesa, senza integrazione con tornelli fisici nella prima release” rende il perimetro discutibile, stimabile e governabile.
Scope creep: il rischio delle piccole aggiunte
Lo scope creep è l’espansione graduale e non controllata dello scope. Spesso nasce da richieste apparentemente innocue:
- “aggiungiamo solo un campo”;
- “è una modifica veloce”;
- “già che ci siamo”;
- “non serve formalizzare”.
Ogni singola aggiunta può essere piccola; l’effetto cumulativo può consumare capacità, ritardare il rilascio, aumentare difetti e togliere attenzione ai benefici prioritari.
Change Management: il processo corretto
In PM², una change request modifica un elemento approvato del progetto: requisito, scope, piano, costo, calendario, organizzazione, deliverable o altro elemento di baseline.
Il ciclo essenziale è questo:
flowchart LR
A[Richiesta] --> B[Registrazione nel Change Log]
B --> C[Analisi di impatto]
C --> D[Decisione dell'autorità competente]
D -->|Approvata| E[Aggiorna baseline e comunica]
D -->|Respinta o rinviata| F[Registra esito e motivazione]
E --> G[Implementa e verifica]
La registrazione non crea burocrazia fine a sé stessa: preserva il motivo della richiesta, le alternative, chi ha deciso e cosa è cambiato nel piano.
L’analisi di impatto non è solo una stima tecnica
Prima di decidere, vanno considerate almeno queste dimensioni:
| Dimensione | Esempio di domanda |
|---|---|
| Valore e priorità | Quale beneficio aggiunge? È più importante di ciò che sposta? |
| Scope e requisiti | Quali requisiti, criteri di accettazione e deliverable cambiano? |
| Tempi e dipendenze | Sposta date, milestone o dipendenze esterne? |
| Effort, costi e risorse | Chi deve lavorarci e cosa non potrà fare? |
| Qualità e rischio | Introduce complessità, regressioni, sicurezza o vincoli nuovi? |
| Adozione e comunicazione | Cambiano formazione, procedure o aspettative degli utenti? |
La domanda decisiva non è “possiamo farlo?”, ma “vale la pena farlo ora, a queste condizioni, rispetto alle alternative?”.
Correggere, chiarire, cambiare: tre casi diversi
| Caso | Esempio | Trattamento |
|---|---|---|
| Difetto | La lista d’attesa non promuove l’utente successivo come previsto. | Correggere l’implementazione rispetto al requisito approvato. |
| Chiarimento | Il requisito dice “tempo configurabile” e si definisce che l’unità è in minuti. | Documentare il dettaglio, se non altera l’accordo di base. |
| Change | Il gestore chiede la priorità in lista in base al tipo di abbonamento, non prevista. | Registrare, analizzare l’impatto e decidere. |
Non usare “è solo un chiarimento” per evitare una decisione. Se cambia il risultato, le regole, l’effort o la baseline, è una change.
Chi decide?
Il PM coordina il processo: raccoglie la richiesta, assicura l’analisi, prepara opzioni e aggiorna i documenti dopo la decisione. Non decide automaticamente ogni modifica.
L’autorità dipende dalla governance e dalla delega concordata:
| Tipo di impatto | Decisione tipica |
|---|---|
| Entro tolleranze e delega del PM | PM, con tracciabilità e comunicazione. |
| Incide su priorità business, benefici o requisiti rilevanti | PO/BM e, se necessario, PSC. |
| Incide su fattibilità, capacità o qualità della soluzione | SP coinvolto nella valutazione e nella decisione pertinente. |
| Cambia budget, mandato o impegno significativo | PSC/AGB, secondo le regole del progetto. |
La soglia precisa non è universale: deve essere definita nel Project Handbook, nei piani pertinenti o nel mandato di governance.
Il caso Annotatio: esportazione CSV delle presenze
Per Prenotazioni Smart, la baseline prevede prenotazioni, cancellazioni, lista d’attesa e dashboard di occupazione. A due settimane dal go-live, il gestore chiede un’esportazione CSV delle presenze “perché sarebbe molto utile”.
Una valutazione seria produce, per esempio:
| Opzione | Impatto | Decisione possibile |
|---|---|---|
| Includerla nel rilascio | +5 giorni; nuovi test e aggiornamento guida; rischio sul go-live. | Approvare solo rinviando la data. |
| Sostituire una funzione meno prioritaria | Data invariata, ma un requisito già previsto slitta. | PO/BM decidono il trade-off. |
| Pianificarla nella release successiva | Go-live protetto; valore posticipato. | Registrare e comunicare il rinvio. |
“Sì, è utile” non basta a scegliere. La gestione del cambiamento rende visibile il prezzo e permette a chi ha l’autorità di decidere quale valore privilegiare.
Da non confondere
| Affermazione | Correzione |
|---|---|
| “Ogni change è un problema.” | Una change può aumentare il valore; deve essere valutata e decisa. |
| “Se è piccola, non serve registrarla.” | La dimensione non elimina l’impatto cumulativo o la necessità di tracciabilità. |
| “Il Change Log serve solo alle change approvate.” | Registra anche richieste respinte, rinviate o ritirate e la loro motivazione. |
| “L’approvazione è l’ultimo passaggio.” | Dopo l’approvazione vanno aggiornate baseline, piani, comunicazioni e verifiche. |
Tre domande per fissarlo
- Quale elemento approvato cambierebbe questa richiesta?
- Che cosa dovremmo rinunciare a fare se la includessimo ora?
- Chi possiede l’autorità per accettare il trade-off?
Flashcard
D: Che cos’è lo scope creep?
R: L’espansione graduale e non controllata dello scope tramite aggiunte non valutate o non approvate.
D: Cosa deve avvenire prima di implementare una change?
R: Registrazione, analisi d’impatto, decisione competente e aggiornamento controllato delle baseline.
D: Il PM è sempre l’autorità che approva le change?
R: No. Dipende da governance, deleghe e impatto della modifica.
Domanda in stile esame
Un utente chiede una nuova regola di priorità per le prenotazioni. Il team può svilupparla in due giorni, senza costi esterni. Il PM autorizza lo sviluppo subito, senza aggiornare documentazione né informare il PO.
Qual è l’errore principale?
Risposta: la facilità tecnica non sostituisce il Change Management. La nuova regola può modificare equità, esperienza utente, criteri di accettazione, test e priorità business. La richiesta va registrata, valutata e decisa secondo l’autorità competente prima di aggiornare la baseline e implementarla.
Fonte
Change Management, Change Management Plan e Change Log sono trattati nella PM² Methodology Guide 3.1 della Commissione europea.
Nel prossimo articolo: Risk Management, per anticipare gli eventi incerti invece di limitarci a rincorrere i problemi già accaduti.