Delivery diagnosis / Outsourcing
Find the mechanism behind the missed result.
A late release is an outcome, not an explanation. The work may have started from an untested assumption, waited for a client decision, followed the wrong incentive or reached integration too late. Reconstruct how one important change moved through the engagement before deciding that more people, more meetings or a replacement supplier will solve the problem.
Diagnose before prescribing
The same symptom can have different causes.
Software outsourcing can fail when the agreement and delivery system do not connect a real user need to clear decisions, usable feedback and accepted operation. That can involve supplier execution, client dependencies or the interface between them. A useful diagnosis explains how the problem arose in this engagement and which evidence would support or contradict that explanation.
- Observed result
- Describe what happened: a release missed its accepted scope, users could not complete a task or an integration repeatedly failed. Record the version and consequence.
- Proposed mechanism
- Explain the path that could have produced it. For example, an unresolved rule caused implementation to proceed on an assumption and later required rework.
- Competing explanation
- Test another plausible cause. A waiting task may lack approval, usable inputs, technical capability or available capacity. Its age alone does not distinguish them.
Six mechanisms to investigate
Ask how the work became stuck or wrong.
Use these mechanisms as hypotheses. Several can interact, and a single incident does not establish a pattern. Preserve explanations from both parties and compare them with the work record.
Incentives reward the wrong completion
01Mechanism: A payable milestone or status target becomes detached from usable, accepted work.
- Observed symptom
- Reported completion increases while integration or user acceptance remains unresolved.
- Inspect
- Milestone definitions, acceptance records, exclusions and changes to the commercial baseline.
- Test the explanation
- Compare what triggered completion with what the client could actually use at that point.
- Decision owner
- Commercial and product owners reconcile the obligation and acceptance decision.
- Useful evidence
- A specific gap between the rewarded event and the intended result.
- Alternative explanation
- The agreement was clear, but an unrelated dependency prevented use.
- Possible correction
- Clarify completion and risk allocation through the authorized commercial process.
Discovery leaves the decisive assumption untested
02Mechanism: Implementation treats an uncertain workflow, user need or system constraint as settled.
- Observed symptom
- A technically working feature is rejected when real users or real dependencies enter the process.
- Inspect
- Original problem, user evidence, assumptions and the first point of contradiction.
- Test the explanation
- Trace a rejected behavior back to the decision that made it a requirement.
- Decision owner
- Product and domain owners decide the intended behavior.
- Useful evidence
- An assumption was accepted without the evidence needed for that decision.
- Alternative explanation
- The need was understood, then legitimately changed later.
- Possible correction
- Revisit the specific uncertainty and revise affected scope before adding more implementation.
Governance creates a decision queue
03Mechanism: Work depends on a decision that nobody can make promptly or conclusively.
- Observed symptom
- The same question returns in several reports while dependent work waits or proceeds on guesses.
- Inspect
- Question history, requested decision, named authority and downstream dependencies.
- Test the explanation
- Check whether the owner received a usable question and had authority and time to answer it.
- Decision owner
- The sponsor resolves decision rights; domain owners supply the decision.
- Useful evidence
- A dated chain linking unresolved decisions to waiting or rework.
- Alternative explanation
- The decision was made, but the delivery team did not act on it.
- Possible correction
- Assign the decision, resolve its inputs and update the affected work.
Quality feedback arrives after commitment
04Mechanism: Important behavior is tested only after substantial dependent work has accumulated.
- Observed symptom
- Integration, permissions or operating failures emerge near the planned release.
- Inspect
- When the behavior changed, when it was tested and what earlier checks actually covered.
- Test the explanation
- Reproduce one escaped defect and locate the earliest practical check that could detect it.
- Decision owner
- Technical and release owners decide repair and acceptance.
- Useful evidence
- A repeatable failure and a meaningful check tied to the affected behavior.
- Alternative explanation
- The condition was genuinely new or outside the agreed scope.
- Possible correction
- Repair the defect and move the relevant feedback into the delivery path.
Communication loses the decision
05Mechanism: People exchange updates without maintaining a shared, usable account of what was decided.
- Observed symptom
- Participants implement different interpretations or repeatedly reconstruct the same discussion.
- Inspect
- Decision records, changed requirements, recipients and the version each person used.
- Test the explanation
- Ask the receiving person to explain the decision and its consequence from the available record.
- Decision owner
- The accountable decision maker confirms meaning; the delivery owner records it.
- Useful evidence
- A concrete mismatch between the approved decision and the recipient's working understanding.
- Alternative explanation
- The record was clear, but the underlying decision itself was wrong.
- Possible correction
- Repair the record and confirm understanding with the people whose work changes.
Ownership stops at the supplier boundary
06Mechanism: Each party finishes its local task while integration or operation has no accepting owner.
- Observed symptom
- Components are called complete but the complete workflow cannot be used or maintained.
- Inspect
- Interfaces, dependency owners, acceptance criteria and the receiving operating team.
- Test the explanation
- Follow one change from supplier completion to client operation and identify the unowned step.
- Decision owner
- The client service owner resolves the boundary with the supplier.
- Useful evidence
- A reproducible handoff failure or a required responsibility absent from both plans.
- Alternative explanation
- An owner exists but lacks the capability, access or capacity to act.
- Possible correction
- Assign the missing work and confirm the receiver can accept it.
Match correction to mechanism
A plausible remedy must change the failing step.
The examples describe possible responses, not instructions to change a contract or team immediately. An authorized owner should choose the response after reviewing evidence and delivery consequences.
| Mechanism | Inspect first | Possible response | Check afterward | Weak substitute |
|---|---|---|---|---|
| Incentives | Paid or reported completion vs accepted use | Reconcile milestone and acceptance | Next completion meets the clarified obligation | More status reporting |
| Discovery | Rejected behavior and original assumption | Test the uncertainty and revise scope | The affected decision has usable evidence | Faster implementation of the same assumption |
| Governance | Decision request and waiting work | Resolve authority and missing inputs | Dependent work can proceed correctly | Another meeting without a decision |
| Quality | Escaped failure and actual test coverage | Repair and add relevant early feedback | Affected behavior and regressions pass | A larger count of unrelated tests |
| Communication | Approved decision vs received meaning | Repair the shared record and confirm receipt | Participants apply the same decision | More messages in more channels |
| Ownership | Completion-to-operation handoff | Assign and accept the missing step | The receiver can use the result | Replacing people without changing the boundary |
Reconstruct one change
Follow the evidence through the whole delivery path.
Illustrative case: an approval-routing feature is late. A policy question remained unresolved, development assumed an answer, and integration exposed the mismatch. That is one possible chain, not the default explanation. The investigation should also test whether the decision was available, whether implementation followed it and whether the integration condition changed.
- 01
Choose a material missed result
Select one outcome that matters to users or operation. State the expected behavior, actual result, version and consequence without assigning blame.
- 02
Build the timeline
Use dated requirements, decisions, changes, reviews and tests. Separate active work, waiting and rework. Mark missing records as unknown rather than filling them with a convenient story.
- 03
Compare explanations
Ask client and supplier owners what produced each delay or rejection. Identify evidence that supports and contradicts each explanation. Multiple contributing factors may remain.
- 04
Test a bounded correction
Choose a relevant change such as resolving one rule or accepting one interface. Name the owner, expected observation and review point. Keep larger commercial or delivery decisions separate.
- 05
Decide from the new evidence
Check whether the failing step changed. Continue, revise the explanation or escalate the recovery decision. A successful local correction does not prove that the whole engagement has recovered.
Keep the investigation useful
Preserve facts while the recovery decision takes shape.
Diagnosis should make the next action clearer. It should not become an indefinite analysis exercise or a substitute for containing an immediate operational exposure.
- Separate containment from diagnosis
- The authorized owner may need to hold an affected release or protect an operating service before every cause is known. Record that decision and its basis.
- Keep both sides in the timeline
- Include client decisions, access and third-party dependencies alongside supplier execution. Shared contribution does not remove a specific party's agreed obligation.
- Use work evidence without personal rankings
- Inspect decisions, changes, queues and accepted behavior. A person's ticket count or hours do not explain the performance of the whole delivery system.
- Set a real review decision
- Agree what the next evidence will inform: a revised scope, changed governance, technical repair or a wider transition assessment. Avoid repeating the same recovery promise without new observations.
Questions during recovery
A better explanation should lead to a better decision.
Treat the diagnosis as something to test. Confidence should increase because the evidence fits and a relevant change works, not because the explanation sounds familiar.
- What percentage of outsourcing projects fail?
- This article does not claim a universal percentage. Definitions of failure, project populations and reporting methods differ. For an active engagement, establish which agreed result is missing and investigate the work that produced it.
- Does a missed deadline prove the supplier is the cause?
- No. Inspect estimates, execution, scope changes, decisions and dependencies. The supplier may be responsible for a specific failure, but the date alone does not establish the mechanism or allocate every obligation.
- Will more developers fix the delay?
- Only if useful capacity is the relevant constraint and the team can integrate the added work. Extra developers do not resolve an unanswered policy question, a missing acceptance owner or an unusable interface.
- When should the supplier be replaced?
- That requires an authorized commercial and delivery assessment of evidence, corrective response, remaining risk and transition feasibility. Preserve usable work and receiving capability. Replacement can leave client-side decisions or architecture constraints untouched.
- How do we know a correction worked?
- Check the observation agreed before the change. A resolved rule should remove the related uncertainty; a repaired interface should support the required workflow. Review other material failures separately before declaring recovery.
Source basis
Guidance behind the diagnostic questions.
- 01
GOV.UK Service Manual
How the discovery phase worksMain guidance reviewed; updated June 2021. Informs problem framing, assumptions, context and constraints. Government phases and typical durations are not imposed.
- 02
Government Commercial Agency
Risk Allocation and Pricing ApproachesJune 2026 guidance, sections 2-5 reviewed for controllable risk, payment incentives and clear triggers. Public procurement rules, liability terms and financial prescriptions are outside this article.
- 03
GOV.UK Service Manual
What each role does in a service teamRole guidance reviewed; updated November 2023. Informs product decisions, service ownership and delivery coordination without prescribing a universal team roster.
- 04
DORA
Test automationJuly 2025 capability guidance reviewed for early feedback, developer and tester participation, and meaningful regression checks. No performance uplift or timing threshold is adopted.
- 05
DORA
Loosely coupled teamsOctober 2025 guidance reviewed for dependencies, handoffs, testability and integration. Microservices, API-version limits and independent release are not prescribed for every system.
- 06
DORA
Documentation qualityCurrent guidance drawing on 2021 and 2022 research reviewed. Informs clear, findable, reliable and maintained records. Reported uplift figures are not used as recovery forecasts.
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