The delivery path
Five stages, with permission to stop.
A good diagnostic does not exist to justify a build. It exists to improve the decision.
01
Define the consequence
What is slow, risky, inconsistent or constrained, and why does it matter?
02
Establish the evidence
Map the workflow, baseline and ownership. Separate symptoms from causes.
03
Compare the options
Process change, existing software, integration, custom engineering, AI, or no investment.
04
Delivery for real use
Design around quality, integration, controls, adoption and operating ownership.
Diagnostic Sprint
Decide whether the problem warrants investment.
The Diagnostic Sprint establishes whether a defined operational problem warrants investment, what should change first and what it would take to put that change into reliable use.
14 days · fixed scope · senior-led
01
What consequence matters?
02
What is causing the constraint?
03
Which options are viable?
04
How would benefit be realised?
05
What has to be true operationally?
06
What happens next?
What the Sprint needs and what you receive
What we need from you
A named sponsor who can make decisions about the problem, scope and next step.
Short conversations with the people doing the work and those responsible for its results.
Access to agreed documents, systems and representative sample data, with confidentiality and access arrangements agreed before work begins.
Someone who can help establish the current baseline and identify who would own an eventual change in operation.
What you receive
A workflow and ownership map — How the work moves, where decisions happen, where it waits and who is responsible.
An assessment of the constraint — Its operational consequences, a baseline where the available evidence supports one, and any gaps that still need investigation.
A comparison of practical options — Process change, better use of existing software, integration, custom engineering or AI where appropriate, alongside the option of no further investment. The comparison identifies the main costs, assumptions, risks and dependencies.
A recommendation and next-step brief — A bounded intervention or further test, with proposed scope, acceptance criteria, measures and the conditions needed to proceed.
A decision before a delivery commitment
The 14-day Sprint supports a decision about what to do next. It may recommend proceeding, narrowing the scope, gathering further evidence, deferring or stopping.
Implementation and ongoing support are scoped and agreed separately. The Sprint creates no commitment to further work.
Before any delivery begins, we agree operating ownership, handover, monitoring and support responsibilities.
ILLUSTRATIVE DIAGNOSTIC · NOT A CLIENT RESULT
Where enquiry-to-quote delays constrain capacity
A team spends too long turning enquiries into complete quotations. Requirements arrive across emails and documents, information is checked repeatedly, and ownership becomes unclear when clarification is needed. Customers wait while experienced staff repeat work.
What we examine
Follow representative enquiries from arrival to quotation. Establish enquiry volume, elapsed time, staff handling effort and the proportion ready for quoting without further clarification. Identify where work waits, returns for correction or depends on one person.
What might change
Compare a shared requirements brief, completeness checks and explicit ownership with changes to existing software or a focused integration. The recommendation depends on the evidence; AI may have no useful role.
What the decision would contain
A recommended first intervention, the alternatives considered, its dependencies and indicative costs, and the evidence that would justify proceeding or stopping.
How value would be tested
Compare the agreed baseline with response time, handling effort, rework and quotations completed after a change. The operational owner agrees how released capacity would be used—for example, processing a backlog or handling additional enquiries.
Less handling time does not automatically create cash savings. Financial benefit requires an observable mechanism, such as reduced overtime or an avoided additional cost. Any effect on conversion or revenue remains a hypothesis until measured.
The Small Engine Approach
Controls should match the consequence.
Not every workflow needs heavyweight assurance. But quality, traceability and release decisions should become stronger as the cost of getting something wrong increases.
Security & assurance
Security is part of the system, not a final checkpoint.
The right level of assurance depends on the consequence. For a bounded internal tool that may mean sensible cloud architecture and access controls. For higher-risk systems it may require formal threat modelling, specialist review or independent human-led penetration testing.
Engagements
The route depends on how much is already known.
A Diagnostic is not a compulsory toll gate. Where requirements and ownership are clear enough, delivery can begin directly.
Technology follows the problem
Small Engine is not paid to make AI inevitable. The right answer might be a process change, a better use of software you already own, a focused integration, custom engineering, an AI-assisted system or no investment at all.
The useful outcome of diagnosis is a better decision
If the evidence doesn’t justify a build, stopping is a valid result.
