Clear decisions. Reviewable progress.
A useful delivery process turns a business question into a scoped decision, reviewable work and an agreed handover. At each step, name the input, approver and evidence needed before moving forward.
Let’s talk
Understand the actual problem
Bring us the outcome you need and an example of how things work today. That might be a customer trying to request a quote, or a staff member copying the same information between two tools. Content, account access, budget and timing help us judge what can be done.
We start with that task before settling on features. If a conversation leaves important questions unanswered, we can define a discovery stage with specific outputs, such as a workflow map or prototype. Agree which decision that work will inform.
Shape a scope people can use
The scope sets out what we will deliver, what is excluded, our assumptions and what you or another supplier need to provide. It also names who can approve the work and who should check details such as service information or an integration requirement. Implementation costs are separated from third-party subscriptions, advertising spend, licences and ongoing support.
Agree how you will check the result. For a website, that could mean completing an enquiry with representative information and checking what the receiving team gets. For a campaign, it could mean agreeing what counts as a qualified enquiry and how it will be reported.
Make progress visible
We show design and implementation in stages so you can respond while decisions are still practical to change. We explain decisions and note approved changes. Each review should make clear what is ready to check, what needs your input and what comes next.
Gather feedback through one client decision-maker, including comments from content reviewers and system users. For example, explain that an enquiry needs a service location so your team can assign it. That tells us what the form needs to do. If a request changes the scope, we discuss its effect on cost, dependencies and timing before adding the work.
Launch with a handover plan
Before a live change, we agree who approves the release, who makes it, which checks are needed and how backup and recovery will work. Account for access held by your team or another supplier.
The handover covers the access, documentation and training included in your scope. Agree who will handle everyday updates and where a problem should go after launch. Ongoing maintenance is a separate decision with explicit responsibilities.
Improve with evidence
Once the work is in use, customer behaviour and staff feedback can help choose the next improvement. For example, enquiries may reach the right inbox but lack information the sales team needs. Investigate that gap before proposing more features.
We use reliable measurement where it is available. If the data cannot answer the question, we explain what is missing rather than drawing a confident conclusion from it.
Discuss your project with an outline of the outcome you need.
Use acceptance to connect the stages
A realistic example can carry through the whole project. For an enquiry page, you might agree that a visitor must be able to choose a service, provide the details your team needs and understand what happens after submitting.
Use that example to review the proposed design, test the build and check the release. Include an exception, such as a missing required detail, so the review covers more than the easiest route. Checking the same task helps expose different assumptions about what “finished” means.
Agree a sign-off artifact for each stage
A sign-off artifact is simply something concrete you can review before agreeing to the next step. Depending on the project, that could be:
- A discovery summary explaining the options, recommendation and unanswered questions.
- A scope listing the deliverables, exclusions, dependencies and how changes will be agreed.
- A design or working demonstration reviewed with realistic content.
- Test results for the agreed customer or staff tasks.
- A release and handover checklist naming who approves, releases, recovers and operates the work.
A retainer still needs these decisions; ongoing prioritisation does not replace clear approval or operating responsibilities.
Understand the team roles · Explore technical discovery · Discuss the first approval decision.
Questions for a better brief
A few useful answers before you decide.
What if we do not yet know the technical solution?
How are changes to scope handled?
What should reviewers look at during a demonstration?
Who approves a release?
What happens when a dependency is delayed?
How do you use information after launch?
Start a conversation
Tell us what you are working towards. We’ll help you find a practical next step.