Scope

Lo scope definisce il perimetro del progetto: cosa è incluso, cosa è escluso, quali deliverable saranno prodotti e con quali confini. È uno dei tre vincoli classici del Triple Constraint (scope, tempi, costi) insieme alla qualità.

Le due facce dello scope

Product scope

Cosa verrà prodotto: caratteristiche e funzionalità del deliverable finale.

Esempio: "Un'app iOS con login, dashboard spese, esportazione PDF"

Project scope

Come verrà prodotto: il lavoro necessario per consegnare il prodotto.

Esempio: "Design UI, sviluppo nativo iOS, testing, deploy su App Store"

Il product scope si misura sul prodotto; il project scope si misura sul lavoro.

In scope vs Out of scope

La regola più importante dello scope è esplicitare cosa NON è incluso. Le ambiguità si trasformano in conflitti.

Esempio: progetto "Sito e-commerce"

In scope ✓	Out of scope ✕
Sito web responsive (desktop + mobile)	App nativa iOS/Android
Catalogo con max 500 prodotti	Catalogo > 500 prodotti
Pagamenti con Stripe	Pagamenti con bonifico bancario
Italiano + inglese	Altre lingue
Integrazione con CRM esistente (HubSpot)	Migrazione del CRM
Training amministratore (2h)	Training continuativo, supporto post-go-live

Scope Statement

Documento (spesso parte del Project Charter) che contiene:

Obiettivi del prodotto (cosa deve fare)
Deliverable (cosa si consegna)
Criteri di accettazione (vedi Success Criteria)
Esclusioni esplicite (out of scope)
Assunzioni (cosa diamo per vero)
Vincoli (cosa ci limita: budget, tecnologie, normative)

Scope Creep — il nemico numero uno

Lo scope creep è l'espansione incontrollata dello scope durante il progetto. Tipicamente avviene per:

Richieste piccole non tracciate ("dai, è solo un campo in più...")
Stakeholder che evolvono i bisogni in corso d'opera
Mancanza di un Change Control formale
PM che dice "sì" per evitare conflitti

Sintomi

I deliverable crescono ma le date no
Il team straordina, la qualità cala
Nessuno ricorda più cosa fosse "out of scope"
Il budget va in rosso senza una causa singola identificabile

Difesa: Change Control

Ogni richiesta che modifica lo scope deve passare un processo formale:

Richiesta → Valutazione impatto (tempi, costi, rischi) → Decisione → Aggiornamento baseline

Lo scope può cambiare — non è immutabile — ma il cambiamento deve essere consapevole e tracciato.

Tecniche per definire bene lo scope

MoSCoW: classifica i requisiti in Must have, Should have, Could have, Won't have (questa volta)
User stories + Acceptance Criteria (in ambito agile)
WBS (Work Breakdown Structure) per scomporre lo scope in lavoro
Prototipi e wireframe per validare lo scope con gli stakeholder prima di firmarlo

MoSCoW in pratica

Categoria	Significato	Esempio (e-commerce)
Must	Senza questo, il progetto fallisce	Checkout funzionante, pagamento sicuro
Should	Importante ma non bloccante	Wishlist, recensioni prodotto
Could	Bello da avere se c'è tempo	Programma fedeltà, chatbot
Won't	Esplicitamente fuori, almeno per ora	App nativa, marketplace multi-vendor

Buone pratiche

Scrivi sempre out of scope esplicitamente — il vuoto si riempie da solo, e mai a tuo favore
Fai approvare lo scope per iscritto dallo sponsor (parte del Charter)
Rileggilo ad ogni milestone — è facile dimenticare cosa era stato pattuito
Distingui scope da requisito: lo scope è "abbiamo un sistema di pagamento", il requisito è "supporta Stripe, PayPal e Klarna"
In agile: lo scope del singolo sprint è fisso, lo scope complessivo evolve

Collegamenti

Purpose — lo scope realizza il purpose, non lo definisce
Success Criteria — definiscono quando lo scope è considerato consegnato bene
WBS — scompone lo scope in lavoro eseguibile
Project Charter — contiene la sezione "In scope / Out of scope"
Pianificazione — fase in cui lo scope viene baselined
MVP — il taglio più radicale possibile dello scope iniziale
Roadmap — scope strategico di alto livello