“The plan looks sound, but it assumes capacity we don't have.”
Most scoping designs around what the technology can do and forgets who has to run it. I scope your programme so the plan you approve is one your team can actually deliver.
The problems surface six months in.
The timeline assumes people nobody has freed up
Delivery depends on availability that was never agreed with the teams involved.
The business case assumes behaviour nobody agreed to
The return relies on teams working differently, but no one has signed up to the change.
The people who will run it weren't in the room
The scope was written with vendors and IT, not with the team expected to use it every day.
Scope it around the people, not only the platform.
Understand
Interviews with sponsors, data, IT and the teams who will run it, plus a review of your current stack and data.
Shape
Scope, phasing and business case built around the capacity and behaviour you actually have.
Commit
A plan your leadership can sign off with confidence, with owners and adoption measures built in.
A plan your team can actually deliver.
A programme about to commit budget, where getting the scope right the first time matters.
- Realistic scope and phasing tested against your team's capacity
- Business case with the adoption assumptions made explicit
- Owners and decision rights named before the budget is committed
- Adoption measures defined up front, not after go-live