Buyer guide / Delivery warning signs
Turn delivery concerns into evidence you can act on.
A missed date or difficult conversation does not prove that a technical partner will fail. A stronger warning is a repeated gap between what is claimed, what can be inspected and what changes after the concern is raised. Check the work, the explanation and the response before deciding what happens next.
Observe before concluding
Ask what happened, what it affects and what would resolve it.
Replace a general concern such as poor communication with an inspectable observation: a dependency has no owner, a claimed feature cannot be demonstrated, or a failed check remains unexplained. Agree the evidence needed to resolve that concern and examine the response.
- A signal is not a verdict
- One incident can have a reasonable explanation. Consider its consequence, whether it recurs and whether the explanation matches the evidence. A serious immediate exposure may still require prompt containment.
- The client is part of delivery
- Unavailable decisions, changing requirements and missing access can block a capable team. Separate supplier work from client responsibilities before assigning a correction.
- Reassurance is not closure
- An apology or revised presentation may explain intent. Close a concern when the agreed corrective work and its evidence have been inspected by the responsible owner.
Six signals worth investigating
Make the concern specific enough to check.
Use these examples as prompts for a delivery review. Their significance depends on the agreed scope, stage of work and consequences of getting it wrong.
The solution arrives before the problem is understood
01Question to ask: Which user need and constraint shaped this approach?
- Observed signal
- A proposed build is detailed, but the team cannot explain the current workflow, difficult cases or why this solution fits.
- Evidence to request
- A walkthrough of the user task, representative examples, constraints, unresolved questions and the reason for the proposed approach.
- Constructive response
- Choose a consequential assumption and investigate it before extending the build. Record what would support a different solution or a decision to stop.
- Accountable decision
- The product owner confirms the problem and acceptance needs; the technical owner explains feasibility and tradeoffs.
- Review record
- Observed assumption, affected workflow, investigation owner and decision that depends on the answer.
- Concern deepens when
- Questions are dismissed as unnecessary, or the same solution is repeated despite contradictory examples.
- Closure evidence
- The investigation produces inspectable findings and a documented decision about the approach.
Important decisions have no owner
02Question to ask: Who can resolve this blocker, and who needs to be involved?
- Observed signal
- The same access, scope or integration question appears in successive updates without a person able to decide it.
- Evidence to request
- The unresolved decision, available options, consequences of waiting, authority needed and supplier or client dependency.
- Constructive response
- Assign the decision to someone with authority. Escalate an issue outside the team's remit with the context needed to act.
- Accountable decision
- The sponsor resolves organizational constraints; delivery and technical owners act within their agreed boundaries.
- Review record
- Decision owner, requested action, affected work and agreed review point.
- Concern deepens when
- Everyone is said to own the issue, or the supplier and client repeatedly redirect it to one another.
- Closure evidence
- The decision is made, communicated and reflected in the work or an explicit revised plan.
Progress cannot be traced to working evidence
03Question to ask: Show one claimed outcome and the checks behind it.
- Observed signal
- Updates list activity or completion percentages, but the buyer cannot inspect the relevant behavior or understand what remains.
- Evidence to request
- A demonstration tied to acceptance conditions, the current work record, known gaps and the environment in which the evidence was produced.
- Constructive response
- Review a useful slice of the actual work. Distinguish a prototype, a tested implementation and an operational release.
- Accountable decision
- The product owner accepts the intended behavior; technical and operating owners assess their respective release conditions.
- Review record
- Claim reviewed, version or environment, observed result, remaining work and acceptance decision.
- Concern deepens when
- Demonstrations are repeatedly postponed without an explanation, or a curated happy path is presented as complete acceptance.
- Closure evidence
- The claimed behavior can be inspected, and unfinished testing, integration or operating work remains visible.
Engineering checks exist only as assurances
04Question to ask: Which relevant checks ran, and what did they find?
- Observed signal
- Quality is described as a standard practice, but nobody can show the result for the change under review.
- Evidence to request
- Relevant test and review results, unresolved defects, known limitations and the relationship between those checks and the release risk.
- Constructive response
- Ask for proportionate evidence for the affected behavior, including consequential exceptions. Resolve failures or make the release limitation explicit to its owner.
- Accountable decision
- Technical owners judge coverage; the authorized release owner decides whether the remaining risk is acceptable.
- Review record
- Change reviewed, checks performed, failures or skipped checks, correction owner and release decision.
- Concern deepens when
- Failed checks are hidden, assertions are weakened to get a pass, or a successful build is offered as proof of every user journey.
- Closure evidence
- The repaired behavior passes the relevant checks and the evidence states what was not verified.
The forecast changes without explaining why
05Question to ask: What changed since the previous plan?
- Observed signal
- A new date replaces the old one without reconciling scope, assumptions, accepted work or unresolved dependencies.
- Evidence to request
- Previous and current forecast, accepted changes, completed work, remaining risks and the assumptions behind the revision.
- Constructive response
- Separate new requirements, corrected assumptions, external blockers and delivery performance. Discuss the decisions available under the revised situation.
- Accountable decision
- The sponsor decides scope and investment priorities with delivery evidence from the team.
- Review record
- Reason for revision, affected outcome, options considered and decision taken.
- Concern deepens when
- Every update promises recovery while the same unfinished work and dependencies remain unexplained.
- Closure evidence
- The revised plan has an inspectable basis and subsequent reviews show whether the corrective action is working.
Operating knowledge stays with a few people
06Question to ask: Who can run and change this service when the current team leaves?
- Observed signal
- The product is approaching handover, but the receiving team cannot explain deployment, configuration or recovery.
- Evidence to request
- Named operating responsibilities, usable documentation, required access, support boundaries and a practical knowledge-transfer plan.
- Constructive response
- Have the receiving team perform an agreed operating task with support. Identify missing knowledge and grant only the access needed for the role.
- Accountable decision
- The receiving service owner confirms readiness; system owners control access and its removal when no longer required.
- Review record
- Task rehearsed, participant, documentation used, missing capability and follow-up owner.
- Concern deepens when
- Handover is reduced to sending files, or essential work can only be performed through an unavailable person's account.
- Closure evidence
- The receiving team demonstrates the agreed task and unresolved operating responsibilities have explicit owners.
Match the response to the evidence
Not every concern needs the same intervention.
These are review situations, not a numerical supplier score. Choose an action proportionate to the consequence and the evidence available.
| Situation | Inspect first | Avoid assuming | Decision owner | Useful next action |
|---|---|---|---|---|
| Unclear update | Claim and work example | Poor wording proves failure | Delivery owner | Clarify the evidence |
| Client dependency | Access or decision needed | Supplier controls the blocker | Client sponsor | Resolve or replan |
| Failed acceptance | Expected and actual behavior | A demonstration means ready | Product and technical owners | Correct and retest |
| Repeated unexplained gap | History and prior actions | Another promise closes it | Accountable sponsor | Escalate with evidence |
| Immediate exposure | Affected system and impact | Routine review can wait | Relevant incident owner | Contain and assess |
| Weak handover | Receiving team's task rehearsal | Documents alone prove readiness | Service owner | Close operating gaps |
A practical delivery review
Leave the meeting with a checkable next step.
Keep the review small enough to help delivery. It should produce a decision and an evidence request, not another reporting burden.
- 01
State the observation
Write down what was claimed and what you actually saw. Include the affected work and date. Separate facts from interpretation.
- 02
Hear the explanation
Ask the people doing the work. Check missing client decisions, changed requirements and environmental constraints before judging the response.
- 03
Inspect a useful example
Choose a work sample that can resolve the concern. Use authorized access and avoid requesting unrelated private customer material.
- 04
Agree the correction
Name the owner, action, review point and evidence needed. Decide whether affected work can continue while the issue is addressed.
- 05
Review what changed
Inspect the result. Close the concern, revise the action or escalate it. Keep unresolved consequences visible to the person making the next commitment.
Keep the review fair and useful
Judge the work in its actual context.
A review becomes less useful when it rewards polished reporting or turns incomplete data into a league table.
- Use evidence the team already produces
- Start with work records, demonstrations and relevant check results. Request additional reporting only when it answers a decision that those records cannot support.
- Use metrics within their limits
- DORA's current guidance describes five delivery metrics and favors application-level context. Use trends to investigate improvement; avoid one-number targets or comparisons between unlike systems.
- Preserve the response history
- Retain the original observation alongside explanations, agreed actions and later evidence. Repetition is easier to assess when each revision does not erase the previous commitment.
- Separate risk action from commercial action
- Contain a serious operational problem through the responsible owner. Decisions about the engagement itself need the appropriate business authority and agreed commercial process.
Questions buyers ask
Look beyond the presentation.
A useful conversation makes the work and its limits easier to understand.
- Does a missed deadline mean the partner will fail?
- No. Examine what changed, who controlled the dependency and whether the revised plan has evidence behind it. Repeated unexplained gaps deserve more attention than an isolated, well-explained change.
- Should I ask to see every ticket and code change?
- The review should be proportionate. Start with evidence tied to the concern and involve someone qualified to assess technical details. Exhaustive oversight can consume delivery time without resolving the question.
- What if the supplier cannot share client work?
- Respect confidentiality. Ask for an authorized, redacted example or a demonstration that shows the relevant practice without exposing another customer's information. An inability to disclose private work is not itself a warning sign.
- Can delivery metrics rank potential partners?
- A number without its application context is a weak comparison. DORA cautions against comparisons between dissimilar systems and using metrics as competition. Ask how the team interprets its evidence and acts on the constraints it reveals.
- When should the issue be escalated?
- Escalate when the consequence exceeds the team's authority, an important concern remains unresolved after agreed action, or an immediate exposure needs the responsible incident owner. Record the evidence and decision needed rather than making a general accusation.
Source basis
Sources behind the control model.
- 01
GOV.UK Service Manual
Measuring and reporting progressGuidance on reporting that supports decisions using delivery information, while avoiding counterproductive extra reporting. Government roles and reporting arrangements are context, not Werkon commercial requirements.
- 02
GOV.UK Service Manual
Governance principles for agile service deliverySupports visible work, clear decision boundaries, escalation and supportive review. The article's signal-and-response method is an editorial application, not a government supplier-rating scheme.
- 03
GOV.UK Service Manual
Working with contractors or third partiesUpdated October 2024. Covers quality evidence, knowledge transfer and necessary system access. Its government purchasing guidance is not adopted as a universal contract rule.
- 04
DORA
DORA's software delivery performance metricsUpdated January 2026. Describes five metrics and cautions against single-metric goals, dissimilar comparisons and competition. Delivery measurement is not a validated prediction that a particular supplier will fail.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD