Risposta.

I confini del progetto (scope) sono una chiara definizione di ciò che deve essere realizzato nel progetto e ciò che è escluso. Una corretta definizione dei confini fornisce una comprensione del volume di lavoro, previene l'"espansione dei requisiti" e consente un'efficace gestione delle risorse e dei tempi.

L'analista di business descrive lo scope attraverso:

Mappe dei portatori d'interesse.
Diagrammi di contesto, confini e interfacce.
Catalogo delle funzionalità in formato storie utente o casi d'uso.
Manifesto "out of scope" (esclusioni).

Caratteristiche chiave:

I confini del progetto vengono fissati prima di un'analisi dettagliata dei requisiti.
Servono come riferimento per la validazione di eventuali cambiamenti.
Stabilire un reale volume misurabile di impegni per il team.

Domande insidiose.

È sufficiente definire solo l'elenco principale delle funzionalità per considerare lo scope fissato?

No. È necessario specificare chiaramente ciò che NON è incluso nel progetto per evitare interpretazioni multiple e "aspetti nascosti".

L'analista di business ha il diritto di espandere unilateralmente lo scope se lo considera utile?

No. Qualsiasi modifica dello scope deve essere approvata dai clienti/porter d'interesse e, di norma, formalizzata attraverso la procedura di modifica (change request).

È possibile modificare i confini del progetto dopo la loro approvazione?

Sì, ma solo attraverso un processo formale di gestione delle modifiche, con revisione dei piani, stima dei costi, tempi e consenso di tutti i principali stakeholder.

Errori comuni e anti-patters

Assenza di una chiara distinzione tra ciò che è incluso e non incluso nel progetto.
Aggiunta di nuove attività senza considerare l'impatto sui tempi e sui budget.
Validazione dello scope solo verbalmente, senza documentazione.

Esempio dalla vita reale

Caso negativo

Lo scope è stato definito verbalmente, senza un documento esplicito. Durante il processo compaiono compiti aggiuntivi che i portatori d'interesse "si aspettavano".

Vantaggi:

Flessibilità, possibilità di adattarsi a nuove esigenze.

Svantaggi:

Il progetto supera i limiti di tempo e budget, nasce incomprensione tra il team e il cliente.

Caso positivo

L'analista documenta lo scope, approva le eccezioni e tutte le modifiche passano attraverso il sistema di change request.