Delivery Definition
A bounded investigation before committing to delivery. Optional, separately priced, and worth buying only when unresolved technical or process questions genuinely prevent a reliable quote.
- Investigate
- Evidence
- Decide
Know what can responsibly be delivered before committing to the build
When unresolved technical or process questions prevent a reliable quote, DBHQ offers a separately priced Delivery Definition. It investigates agreed questions about one proposed change and produces an evidence-backed scope, acceptance criteria, delivery options and remaining uncertainties.
You receive the editable pack and can use it with DBHQ, your own team or another supplier. There is no obligation to commission implementation, and the investigation fee is not credited against later work.
If the work is already clear enough to quote, this step is unnecessary.
What the pack contains
- A decision summary - proceed, change approach, defer or stop, with the reasons behind it
- The evidence, answering each named question and distinguishing observed, reported, assumed and unknown
- Scope - inclusions, exclusions, interfaces, responsibilities and dependencies
- Acceptance criteria, naming who accepts and on what evidence
- The delivery approach - migration, cutover, operational ownership and handover
- The commercial implications
Already clear on what needs building? See the production delivery route →
What you are buying
One proposed change, a named set of questions, and a fixed fee against the investigation and its outputs.
- Purchase trigger
- Named uncertainties require substantive investigation before delivery can responsibly be quoted
- Unit of scope
- One proposed business outcome, one workstream, up to three named questions
- Standard boundary
- Up to three named systems, with the specific repositories, workbook versions, documents and samples listed in the agreement
- Participation
- One accountable owner on your side, a kickoff, up to three one-hour stakeholder sessions and one readout
- Effort and schedule
- Around five working days of effort inside ten working days of the prerequisites being ready, with dates agreed before you buy
- Investigation
- The agreed evidence reviewed, the process or flow mapped, dependencies examined and the named assumptions tested
- Feasibility testing
- Only a specifically described probe agreed in advance, run in an approved non-production environment
- Output
- An editable decision pack, an evidence register, diagrams, acceptance criteria and delivery options
- Pricing
- A fixed fee for the agreed investigation and its outputs, with implementation quoted separately
The most common shape of this is a spreadsheet the business quietly runs on. From Spreadsheet to System →
What it does not do
It does not guarantee a fixed-price build quote. "The interface remains undocumented, so a bounded implementation quote is not responsible" is a valid outcome, provided the agreed investigation was done and the evidence supports it.
- Production changes, implementation or migration execution
- Exhaustive discovery of undocumented rules
- Full-estate assessment
- Penetration testing
- Regulatory certification
- Procurement management
- Ongoing support
- Responsibility for another supplier's cooperation
The Azure Well-Architected Review is a separate purchase answering a different decision: whether one workload can go live, or be accepted into operations, by a named date. The Azure Well-Architected Review in full →
How does it run?
- Fit call - fifteen free minutes on the outcome, the context and whether paid investigation is needed at all
- Kickoff - the questions, the systems in scope and the evidence list are agreed, and then frozen
- Investigation - the evidence reviewed, the flow mapped, the dependencies examined and the named assumptions tested
- Readout - the pack walked through with your team, then one consolidated clarification round and a follow-up call
Around five working days of effort, inside ten working days of the prerequisites being ready
Why is this paid work?
Ordinary estimating is DBHQ's cost, not yours. A Delivery Definition is worth buying only when named questions need real investigation before anyone can quote responsibly - which is why the fit call is free, and stays free, with no file audit, no solution design and no written recommendations attached to it.
The boundary holds in both directions. The questions and the evidence list are frozen at kickoff, so new systems, outcomes or questions need a written change, with a fee and a schedule, before work restarts. Corrections to DBHQ's own errors, and anything agreed but not delivered, are never chargeable, and an effort allowance is not an excuse for unfinished work.
Nothing is riding on the answer, either: no licences to resell and no product behind the findings. Twenty-six years across defence, banking and digital identity means the questions are judged by someone who has built and run systems where failure was expensive.
Questions, answered
- What does it cost?
- A fixed fee for the agreed investigation and its outputs, quoted after a short call - never open-ended. Implementation is a separate purchase, priced separately, and the investigation fee is not credited against later work. You pay once for the work that is done.
- What if we do not commission the build?
- Nothing further is owed. The pack is editable and yours, and it is written so your own team or another supplier can act on it without DBHQ.
- Do you do the implementation too?
- Where it fits. A Production Delivery Sprint is a separate engagement with its own fixed price, and buying the investigation does not commit you to one.
- What if the answer is that it still cannot be quoted?
- Then that is the finding, and it is the one you paid for. "The interface remains undocumented, so a bounded implementation quote is not responsible" is a real answer - it names what would have to change before anyone could price the work honestly.
- What access do you need?
- Read-only, over the repositories, workbook versions, documents and samples named in the agreement. Nothing in your live environment is changed. Where a question can only be settled by trying something, that probe is described in advance and run in an approved non-production environment.
- How long does it take?
- Around five working days of effort, inside ten working days of the prerequisites being ready. The dates are agreed before you buy.
- Who owns what you produce?
- You do, on payment - the pack, the diagrams and any probe code commissioned with it, with rights that let your own team or another supplier use and modify them. DBHQ keeps its own pre-existing tools and methods.
Fifteen minutes will tell you if this fits
Bring the problem - the stalled pilot, the systems that do not talk, the manual process eating your team. You will get a straight answer on whether it is sprint-shaped, roughly what it would cost, and when it could be running.
I reply within 24 hours