Scope without hierarchy
A long requirement list exists, but the essential journey, learning goal, and sequence of value are not visible.
02 · Delivery stage
Planning & Design
Translate an agreed outcome into prioritised scope, product flows, technical direction, responsibilities, and reviewable delivery stages.
The context
What this stage helps the team resolve.
Planning and design connect what should change with how the team intends to deliver and evaluate it. The goal is not to predict every detail; it is to make the important sequence, dependencies, behaviours, and decisions clear enough for responsible implementation.
Design and engineering diverge
Interface decisions, system behaviour, data, constraints, and implementation assumptions develop separately and conflict late.
Plans hide uncertainty
Dates and tasks appear precise while unresolved dependencies, acceptance decisions, and stakeholder responsibilities remain implicit.
What the work considers
Keep product, delivery, and ownership connected.
Activities are selected for the project's current questions and risk. A useful process is structured, but never busy for its own sake.
01
Scope and sequence
Organise work around priority outcomes, dependencies, validation needs, and the smallest coherent stages of progress.
02
Journey and interaction design
Represent important flows, content, states, errors, and responsive behaviour at a useful level of fidelity.
03
Technical direction
Shape application, data, integration, security, and operating decisions around the product context and existing estate.
04
Acceptance and review
Define how important behaviour will be checked and when product, design, and technical decisions need review.
Potential outputs
Leave the next decision easier to make.
Outputs are agreed around the work and may be lightweight or detailed. Their value comes from supporting action, review, and shared understanding.
- 01Prioritised scope and staged delivery view
- 02User journeys, flows, or interface direction
- 03Architecture and integration decisions
- 04Acceptance criteria and quality considerations
- 05Dependencies, responsibilities, and review points
Working agreement
Make inputs, evidence, and boundaries explicit.
The stage works best when the right context is available and the team agrees how useful progress will be judged.
What we need to understand
- Agreed problem, outcomes, and priority users
- Existing product and technical context
- Business rules, content, data, and integration needs
- Team responsibilities, constraints, and decision owners
Evidence of useful progress
- Each delivery stage has a coherent purpose
- Critical journeys include non-ideal states
- Technical decisions include relevant trade-offs
- Acceptance expectations are reviewable by the right people
Important boundary
A plan is a decision tool, not a promise that new information will not change the work. Material changes should be assessed openly against outcome, scope, dependencies, and risk.
Stage rhythm
A visible path through the work.
The sequence is adapted to the engagement while preserving clear decisions, review points, and responsibilities.
Confirm the outcome
Revisit the problem, audience, constraints, and evidence so planning remains connected to the intended change.
Shape product behaviour
Map journeys, rules, information, states, content, and acceptance needs across the important experience.
Align technical direction
Evaluate architecture, data, integration, security, operational, and migration implications with the product plan.
Create delivery stages
Sequence implementation, review, validation, release preparation, responsibilities, and decision points.
Process questions
Useful details to clarify.
How detailed should a delivery plan be?+
Detailed enough for the next responsible decisions, dependencies, and review points. Later work can remain at a broader level until evidence justifies more detail.
Do designs need to be final before engineering?+
Not always. Stable foundations and important flows should be clear, while lower-risk detail can continue through an agreed collaborative rhythm.
How are changing requirements handled?+
The effect on outcome, priority, dependencies, acceptance, effort, and timing is made visible before the plan is updated.
Can planning focus on a technical improvement?+
Yes. The same approach can shape a modernisation, integration, reliability improvement, or architectural decision around clear outcomes and boundaries.
Start a conversation
Need help with planning and design?
Tell us where the work stands, what needs to change, and what is currently unclear. We can help identify a sensible next step.