Problem
Many projects start from a brief that means different things to different people. Developers build what they think was asked for, testers check what they think was meant, and the business sees the gap too late to fix it cheaply.
Needs are scattered across documents, meetings and inboxes, so nobody can say which are agreed, which conflict, or which matter most.
Outcomes
- A shared, written understanding of the business need and who it affects.
- Requirements that are clear, prioritised, agreed and testable.
- Current and future ways of working mapped, so the change is understood before it is built.
- Every requirement traced from business goal to what was built and tested.
- Conflicts and gaps found before build starts, and changes assessed for impact before they are approved.
- Confirmation, after delivery, that the service meets the need it was built for.
Scope
In scope
- Stakeholder analysis and a plan for how requirements will be captured, prioritised and signed off.
- Elicitation through workshops, interviews, observation and document analysis.
- Current-state and future-state process mapping.
- Business, stakeholder and solution requirements, functional and non-functional.
- User stories, use cases and acceptance criteria.
- Prioritisation, traceability and change control for requirements.
- Transition requirements, such as data migration, training and cutover needs.
- Support through build and test, and a check that the delivered service meets the agreed requirements.
Not included
- Making product decisions for you. Your product owner decides; we make the options and their impact clear.
- Legal, regulatory or compliance sign-off. Your own specialists decide what applies.
Product ownership support
Product owners are often stretched across meetings, decisions and backlog work. We support them with backlog management, prioritisation and stakeholder communication, so they can focus on the decisions only they can make.
- Backlog refinement and prioritisation support.
- Stakeholder communication and roadmap updates.
- Acceptance of finished work against agreed criteria.
Approach
Discovery
We agree the business need, the stakeholders and the scope of the analysis, then draw out requirements through workshops, interviews and document review, and map how work flows today and how it should work
Delivery Planning
We turn needs into clear requirements, user stories and acceptance criteria, prioritise them with the people accountable, and agree how each requirement is owned and how changes will be assessed
Build and Test
We keep every requirement traceable to what is built and tested, and assess the impact of each proposed change before it is approved. Before go-live, you get the traceability record, and a named person decides whether to go ahead
Operational Readiness, Hypercare and Closure
We support acceptance of the finished work against the agreed criteria, confirm the service meets the need it was built for, and hand over the requirements and traceability record. We provide extra support in the first weeks of live use, then close with your sign-off
Deliverables
Technologies
Controls
Frequently Asked Questions
What does a business analyst actually do on a project?
They work out what the service needs to do, agree it with the people who matter, write it down so it can be built and tested, and check that what is delivered meets the need.
Do you write user stories or formal requirements?
Whichever suits how your team delivers. Agile teams usually work from user stories with acceptance criteria; other work may need structured requirements. Either way, each requirement is testable and traceable.
How do you handle requirements that keep changing?
We expect change. Each proposed change is assessed for its impact on scope, cost and time and traced through, so the right person can approve it with the facts in front of them.
How do you decide what matters most?
We prioritise requirements with the people accountable for the outcome, so the team builds the most valuable things first rather than everything at once.
Can you support our product owner?
Yes. We can run backlog, prioritisation and stakeholder work alongside a product owner, or strengthen that role where it is stretched.
Not sure what you are building?
A Discovery Sprint turns an unclear problem into a prioritised, costed and delivery-ready set of requirements you keep whatever you decide next.