A brief, a capable team and a realistic schedule are not enough. Work stalls at the point that should be simplest: deciding whether it is finished. Here is what acceptance criteria have to contain, and who has to own the decision.
Who decides when outsourced software work is done?
I have watched more delivery stall at acceptance than at build.
The brief was clear, the team was capable, the schedule was realistic. Then the work reached the point that should have been simplest, deciding whether it was finished, and stopped.
It is rarely dramatic. A review meeting produces a longer list than it started with. A deliverable sits in an inbox. A status stays amber for weeks while everyone waits for a decision nobody has been asked to make. And the plan that produced it usually said something entirely reasonable: the stakeholders will review the deliverable.
That sentence is where it begins. It names an activity and leaves out an authority.
Review is not acceptance
A stakeholder has an interest in the outcome. A specialist can explain what good looks like. A reviewer can inspect the work and raise a concern. None of the three, by virtue of the role, can close a milestone.
Acceptance is narrower than any of them. It is a decision, made by somebody authorised to make it, applying conditions agreed in advance to the evidence that was submitted, and recorded as a result.
The distinction sounds pedantic until you have watched a piece of work cycle through round after round of feedback without anyone ever being asked to say yes or no.
Acceptance criteria for outsourced software development: what they have to contain
Acceptance criteria are the conditions the work has to satisfy, written before it starts, in language somebody other than the author can check.
They carry more weight on outsourced software development than on work done in-house, for a plain reason. An internal team shares your context and can guess what you meant. An external team can only build what you wrote.
Criteria that hold up have four properties.
They describe an end state rather than an activity. "Improve onboarding" is a direction. "An eligible new customer can create an account, verify an email address, complete the minimum setup and reach the first product state" is a condition somebody can test.
They name what is excluded. Boundaries do more work than requirements. The user types, platforms, integrations and exception cases that are out of scope are the ones that otherwise arrive later as "surely that was obvious".
They name the evidence. Not that it works, but what will be shown: the working flow, the agreed test results, the handled failure states, the reference material needed for handover. Evidence named in advance gets produced while the work happens. Evidence named afterwards gets assembled by the person who most needs the answer to be yes.
They exist before anyone starts. Criteria produced after delivery are not criteria. They are a renegotiation, and the party writing them is the party who is already unhappy.
Four roles that get collapsed
One person can hold several of these. The distinction still matters, because the responsibilities are different and they fail differently.
| Role | Useful contribution | What the role does not own by default |
|---|---|---|
| Stakeholder | Explains business impact, constraints and priorities. | The acceptance decision. |
| Specialist | Tests technical, operational or domain assumptions. | Authority to close the milestone. |
| Reviewer | Inspects evidence and identifies a missed condition or a risk. | The decision, merely by virtue of having commented. |
| Acceptance owner | Applies the agreed conditions to the evidence and records accepted or changes requested. | Unilateral expansion of the agreed scope. |
A head of product can gather input from engineering, security and operations and still be the only person who decides whether the agreed outcome has been demonstrated. That is a healthy arrangement. What is not healthy is when the gathering happens and the deciding never does.
What the acceptance owner needs before work begins
Naming somebody after the work arrives is too late. By then the criteria are contested, and the person named inherits an argument rather than a decision.
The role needs four things at the point the work is commissioned.
Authority. The organisation has made it clear that this role can accept the milestone or request changes against the agreed conditions, and that the decision stands.
Conditions. The outcome and its boundaries are specific enough to be checked without inventing new standards during review.
Evidence. Both sides know what will demonstrate the outcome before any of it is produced.
A decision window. The owner knows when the evidence arrives and when the decision is expected, including what happens if review is delayed.
Acceptance control is usually presented as protection for the buyer. It is, and the executor gains more. A team working to written criteria with a named decision-maker can tell the difference between a correction and a new request. Without them every piece of feedback is potentially both, and the safe response is to absorb it. That is how a bounded piece of work quietly becomes an open-ended one.
The three end states
A usable acceptance step ends in one of three explicit states.
- Accepted: the evidence meets the conditions agreed before execution.
- Changes requested: the evidence shows that a specific agreed condition has not been met.
- Awaiting decision: the acceptance owner has not yet responded.
Silence belongs to none of them. A status that changes because nobody replied has recorded an absence rather than a result. An escalation rule is worth agreeing in advance, and it handles a missing decision rather than replacing one.
Where it goes wrong
- The business will review. A department is named. No role has final authority.
- Everyone has a veto. Several reviewers can block the decision and nothing resolves conflicting input.
- Criteria appear after delivery. Preferences that were never in the brief are treated as missed requirements.
- Silence becomes approval. The status moves because nobody responded.
- Authority and accountability diverge. The named owner carries the outcome but cannot obtain or record the decision.
A checklist before you commission the work
- Is the outcome written so that another person can recognise it?
- Are the boundaries and the excluded cases explicit?
- Is the evidence package named before work starts?
- Are reviewers distinguished from the role with acceptance authority?
- Can one named role record accepted or changes requested?
- Does a change request have to identify the unmet condition and the supporting evidence?
- Is there an agreed decision window, and a route if it passes?
The test
Clear acceptance ownership is not extra ceremony. It is part of what makes outsourced work executable at all. The executor needs a bounded outcome to produce. The buyer needs a named role with the authority, the conditions and the evidence required to close it.
So the test is not whether the plan names reviewers. It is whether one person, named before the work starts, can look at the evidence and say yes.
Everything else is consultation. Consultation is useful. It does not finish anything.
If you have a specific initiative that is stalled because nobody can say what finished means, tell us about it. If it fits how we work, we will map the next step with you. If it does not, we will say so.
