Map the workflow
Identify users, source systems, permissions, exceptions and the business owner. Use anonymised samples until data-sharing arrangements are agreed.
Delivery & project governance
A project should be understandable before it becomes a commitment.
Agree the problem, scope and decision owners before selecting the delivery model. Use the checkpoints below to shape a project plan with our team. The signed scope determines the deliverables, controls and support included in your engagement.
01 / Discover
Turn the request into an evidence-backed scope.
Record the unknowns
List assumptions, unavailable integrations and decisions that could change the estimate. Discovery should make a proceed, investigate or stop decision possible.
02 / Define
Choose the engagement around the uncertainty.
Discovery or feasibility
Suitable when data, requirements or integration access are unresolved. Agree the investigation, findings and next-step decision as deliverables.
Scoped delivery
Suitable when a release can be bounded. Agree features, exclusions, dependencies, milestones, acceptance scenarios and the process for changing scope.
Dedicated collaboration
Suitable when priorities evolve. Agree roles, allocation, working overlap, backlog ownership and how progress and availability will be reviewed.
03 / Review
Make progress visible through working decisions.
Use a shared decision log and demonstrations against agreed scenarios. Discuss meeting cadence and reporting format during planning; avoid treating activity counts as evidence that a feature meets the business need.
| Decision | Evidence to agree | Owner to identify |
|---|---|---|
| Architecture | System boundaries, integration assumptions and deployment constraints | Technical decision makers |
| Quality | Normal journeys, failure paths, permissions and device checks | Engineering and acceptance owners |
| AI evaluation | Representative examples, source grounding, error handling and human escalation | Domain owner and engineering team |
| Scope change | Impact on deliverables, estimate, dependencies and acceptance | Commercial and product owners |
04 / Release
Define acceptance and handover before go-live.
Acceptance evidence
List the scenarios the release must pass and who signs off. Capture known limitations and unresolved items rather than hiding them in a success summary.
Operational ownership
Agree repository access, environment ownership, deployment notes, credential handover and rollback responsibilities where included.
Support boundaries
Confirm the support period, response expectations, third-party dependencies and treatment of new features in writing. Do not assume round-the-clock coverage.
Before you decide
Questions to resolve together
Can we start with a pilot?
Yes, discuss a focused scope with an explicit decision at the end: what will be tested, which evidence is needed and what would justify a wider release.
Who owns the code and intellectual property?
Agree ownership, third-party components, licences, payment conditions and handover in the contract. Ask us to confirm the terms for your engagement before signing.
Is pricing fixed?
The commercial model depends on scope clarity, dependencies and allocation. Request an estimate with assumptions, exclusions and change-control terms; published examples are not a binding quote.
What should procurement request?
A scoped proposal, team responsibilities, delivery milestones, acceptance criteria, data-handling arrangements, dependency list and contractual ownership/support terms.
An informed next step
Bring your workflow. Define the right first release.
Share the problem, existing systems and the decision you want to improve. Use anonymised examples first. We can discuss scope, ownership and the evidence needed before committing to delivery.