Discovery & analysis
Scope & prioritisation
Decide what belongs in phase 1 and what moves to phase 2 or later. MoSCoW with realistic ambition so you ship something instead of doing everything half.
Updated Jan 23, 2026
Discovery · 3.7
Why this first
The biggest reason for failure: wanting too much in phase 1. Phase 1 must be short (8-12 weeks), demonstrably work and build trust. Only then do you move into phase 2. A tight scope discussion now = something in production within the quarter instead of “endless pre-go-live”.
What do you deliver?
MoSCoW table
Must / Should / Could / Won't, filled with items from the pain-point and opportunity list.
Phase roadmap
Phase 1, 2, 3 — with scope, goals and success criteria per phase.
Capacity check
Do we have the people to do this? Who, how many days, when.
Parking lot
What we don't do in phase 1, with a date and owner for revisiting.
The 4 MoSCoW categories
Must
Without this, phase 1 has failed
~40% of scope. Critical processes, top pain points, compliance matters.
Should
Important, not critical
~30% of scope. Done if capacity allows. Not a show-stopper if delayed.
Could
Nice-to-have
~20% of scope. Quick wins that polish the result. First to drop under pressure.
Won't
Deliberately excluded
Record explicitly what is not in phase 1. Prevents scope creep along the way.
Steps
- 1Bundle the inputs — top pain points (3.3), processes (3.2), service catalog (3.5), benchmark actions (3.6).
- 2Steering-group workshop — 2-hour session. Place each item on the MoSCoW board. Vote or consensus.
- 3Force 40/30/20/10 — if everything is “Must”, pick again. Discipline over sympathy.
- 4Capacity check — can we really hit the Must items? How many person-days, when available?
- 5Set success criteria — per phase: what must demonstrably work? Concrete KPIs from 3.3.
- 6Document Won't explicitly — don't go silent about what you're not doing, write it down with a review date.
- 7Sponsor sign-off — sponsor signs the scope. Changes after this point = formal change request.
Template — MoSCoW table
| Item | Category | Score (from 3.3) | Effort | Phase | Owner |
|---|---|---|---|---|---|
| Self-service ticket portal | Must | 20 | M | 1 | Head of Facility |
| Outlook add-in for reservations | Must | 15 | S | 1 | PM |
| Auto-catering for meetings > 90 min | Should | 12 | S | 2 | Catering |
| AI Agent for IT tickets | Could | 9 | L | 2/3 | Head of IT |
| Mobile fire-warden app | Won't | 6 | M | — | Review in 2027 Q1 |
Template — Phase roadmap
Phase 1 — 8-12 weeks
Foundation + top pain points
Master data + 1-2 modules. Demonstrable resolution of top-3 pain points.
Success criterion: KPIs from 3.3 improved within 3 months of go-live.
Phase 2 — 2-3 months later
Broaden & deepen
Should items, additional modules, integrations that weren't critical.
Success criterion: adoption rate > 70% among end users.
Phase 3 — after that
Optimise & AI
Could items, AI Agents, advanced reporting, parking lot revisited.
Success criterion: measurable productivity gains, lower ticket volumes.
Best practices
→ Small wins
A working phase 1 with 5 features > a stuck phase 1 with 25 features.
→ Decide on effort + score
High score + low effort = quick win, take it. Low score + high effort = parking lot.
→ Write Won't explicitly
“We don't do X in phase 1” prevents endless “what about X?” questions.
→ Re-prioritise under pressure
Phase 1 overrunning? Cut Could+Should, not Must. Don't extend the phase.