Design the plan before you commit the budget.
Design turns agreed requirements into a practical delivery plan – what will be built, in what order, over what timescale, and at what cost.
Why this stage exists
Yammayap deliberately separates understanding the requirement from designing the solution.
It’s a small discipline that changes outcomes considerably. When the two are done together, the solution tends to shape the requirements rather than the other way around – and the business ends up committing to an approach before anyone has properly tested whether it’s the right one. Separating them creates better decisions, more realistic expectations and lower delivery risk.
What happens during Design
Design begins only once the Define outputs have been agreed. It is built from those agreed requirements and nothing else. No technology is chosen before this point. What gets recommended follows from the requirements rather than from whatever we happen to enjoy building.
Typical activities include:
Solution planning against the requirements
Work package definition and sequencing
Delivery approach and resource planning
Timescale estimation for each package
Cost estimation and investment profile
Risk assessment and dependency mapping
Work is broken into packages rather than presented as a single number. Each has its own objective, scope, outcome, cost and timescale, so you can see what you’re getting for each part of the investment and decide what order it happens in.
That structure also makes phasing possible. If the full scope is more than you want to commit to at once, the plan shows what can sensibly be delivered first and what can wait – rather than forcing an all-or-nothing decision.
What Design is - and what it isn't
but
Design isn't
-
A complete technical architecture
-
A fixed commitment to build
-
Guesswork dressed up as a quotation
-
A plan you need to be technical to read
Design is
-
Planning grounded in agreed requirements
-
A realistic view of effort, cost and sequence
-
An honest assessment of risk
-
Written in plain English throughout
What you get
A specification document which covers:
- Business requirements
- Technical requirements
A delivery design document which covers:
- Recommended work packages
- Delivery approach & timescales
- Dependencies & risks
- Investment requirements
Together they replace assumption with evidence: a shared understanding of what needs to change, and a practical plan for achieving it. Decisions from here are made on planning and informed judgement rather than estimates and enthusiasm.
Could you specify the work yourself?
In principle, yes – and you already know more about the problem than we do.
The difficulty with the specification is knowing what to leave out, and spotting which requirements quietly commit you to an expensive approach. The difficulty with the plan is estimating work you haven’t done before – dependencies tend to be obvious only in hindsight, and plans written by people who want the project to happen are rarely pessimistic enough.
We write requirements precise enough to build from without locking in a solution, estimate against work we’ve actually delivered, and state our assumptions and risks plainly rather than burying them.
What happens next
With an agreed plan in place, Develop begins turning it into working software – built in controlled steps rather than one large leap.
Take the methodology with you
A complete guide to all six stages – Diagnose, Define, Design, Develop, Deliver and Depend – including what happens at each stage, what you receive, and how the stages connect.
Written to be shared with your team.
A plan you can budget against
Every delivery plan starts with a free Diagnose session to establish whether there’s an opportunity worth planning for.
Free, 90 minutes
