Analisi
Scope e prioritizzazione
Decida cosa entra nella fase 1 e cosa va alla fase 2 o oltre. MoSCoW con ambizione realistica, così consegna qualcosa invece di fare tutto a metà.
Aggiornato il 23 gen 2026
Discovery · 3.7
Perché farlo per primo
Il motivo più grande di fallimento: volere troppo nella fase 1. La fase 1 deve essere breve (8-12 settimane), funzionare dimostrabilmente e costruire fiducia. Solo allora si passa alla fase 2. Una discussione di scope stretta ora = qualcosa in produzione entro il trimestre invece di “pre-go-live infinito”.
Cosa consegna?
Tabella MoSCoW
Must / Should / Could / Won't, compilata con item dalla lista pain point e opportunità.
Roadmap di fase
Fase 1, 2, 3 — con scope, obiettivi e criteri di successo per fase.
Verifica di capacità
Abbiamo le persone per farlo? Chi, quante giornate, quando.
Parking lot
Cosa non facciamo in fase 1, con data e owner per riconsiderarlo.
Le 4 categorie MoSCoW
Must
Senza questo, la fase 1 è fallita
~40% dello scope. Processi critici, top pain point, questioni di compliance.
Should
Importante, non critico
~30% dello scope. Fatto se la capacità lo consente. Non un show-stopper se ritardato.
Could
Nice-to-have
~20% dello scope. Quick win che rifiniscono il risultato. Primi a saltare sotto pressione.
Won't
Esclusi deliberatamente
Registri esplicitamente cosa non è in fase 1. Previene lo scope creep durante il percorso.
Passi
- 1Raccolga gli input — top pain point (3.3), processi (3.2), service catalog (3.5), azioni di benchmark (3.6).
- 2Workshop con il gruppo direttivo — sessione di 2 ore. Collochi ogni item sulla board MoSCoW. Voto o consenso.
- 3Forzi 40/30/20/10 — se tutto è “Must”, ripeschi. Disciplina sopra simpatia.
- 4Verifica di capacità — riusciamo davvero a coprire i Must? Quante giornate-persona, quando disponibili?
- 5Imposti criteri di successo — per fase: cosa deve funzionare dimostrabilmente? KPI concreti da 3.3.
- 6Documenti Won't esplicitamente — non taccia su cosa non sta facendo, lo scriva con una data di revisione.
- 7Sign-off dello sponsor — lo sponsor firma lo scope. Cambiamenti dopo = formal change request.
Template — Tabella MoSCoW
| Item | Categoria | Punteggio (da 3.3) | Effort | Fase | Owner |
|---|---|---|---|---|---|
| Portale self-service ticket | Must | 20 | M | 1 | Head of Facility |
| Add-in Outlook per le prenotazioni | Must | 15 | S | 1 | PM |
| Auto-catering per meeting > 90 min | Should | 12 | S | 2 | Catering |
| AI Agent per ticket IT | Could | 9 | L | 2/3 | Head of IT |
| App mobile addetto antincendio | Won't | 6 | M | — | Review in Q1 2027 |
Template — Roadmap di fase
Fase 1 — 8-12 settimane
Fondamenta + top pain point
Dati anagrafici + 1-2 moduli. Risoluzione dimostrabile dei top-3 pain point.
Criterio di successo: KPI da 3.3 migliorati entro 3 mesi dal go-live.
Fase 2 — 2-3 mesi dopo
Ampliare e approfondire
Item Should, moduli aggiuntivi, integrazioni non critiche.
Criterio di successo: tasso di adoption > 70% tra gli utenti finali.
Fase 3 — dopo
Ottimizzare e AI
Item Could, AI Agent, reportistica avanzata, parking lot rivisitato.
Criterio di successo: guadagni di produttività misurabili, volumi di ticket più bassi.
Best practices
→ Piccole vittorie
Una fase 1 funzionante con 5 feature > una fase 1 bloccata con 25 feature.
→ Decida su effort + score
Score alto + effort basso = quick win, lo prenda. Score basso + effort alto = parking lot.
→ Scriva Won't esplicitamente
“Non facciamo X in fase 1” previene infinite domande “e X?”.
→ Ri-prioritizzi sotto pressione
Fase 1 in ritardo? Tagli Could+Should, non Must. Non estenda la fase.