UAT Without an Owner Is Chaos With a Schedule

UAT started on schedule. Environment ready, business users booked, dates agreed with everyone who needed to agree them.

Then somebody found something, and there was no answer to a very simple question: where does this go?

The Question Nobody Had Asked

Not one of these had a named answer on day one.

Where does a finding get reported. Who decides whether it is a defect or a change request. Who verifies the fix on the supplier side. Who confirms acceptance on the customer side.

There was no UAT Lead, and the reason there was no UAT Lead is the reason worth writing about: everybody assumed the role was unnecessary, because everybody knows what to do.

Nobody knew what to do.

Why UAT Specifically

Every project has implicit routing that works fine. A tester finds something, walks to a developer, and it gets fixed. Nobody documented that path and nobody needs to, because it lives inside one team with one board and one shared idea of what "done" means.

UAT is the one phase where the finder and the fixer are on opposite sides of an organisational boundary.

That single fact invalidates all the implicit routing at once. The business user who finds the problem does not have the tracker. The developer who would fix it does not attend the UAT session. The two people who could decide whether the behaviour is a defect or a change of scope report to different organisations, and the answer has commercial consequences for at least one of them.

So the informal path that carried findings for six months stops at the boundary, and there is nothing on the other side of it unless somebody built something.

That is the mechanism. It is not about competence or seniority. It is that a habit which depends on proximity cannot survive a phase defined by distance.

What Goes Missing Without a Named Destination

When there is no named destination, findings go wherever the finder's habits take them. A message to whoever they met last week. A note in a meeting. An email to the project manager, who forwards it to somebody who is on leave.

Each of those is a reasonable act by a reasonable person, and collectively they produce a phase with no dataset.

Then a second effect follows from the first. If findings are not in one place, nobody can say how many are open, how severe they are, or whether the trend is improving. The phase can only be judged by its calendar, because the calendar is the only artefact everybody can see. UAT ends when the dates say it ends, rather than when the exit criteria are met — and often the exit criteria were never written either, for the same underlying reason.

Chaos with a schedule is precisely what that produces. The schedule is real. Everything happening inside it is improvised.

The Rule

Name a UAT Lead before UAT starts. One person, by name, with the role written down somewhere both organisations can see it.

Not a committee, not "the project manager will coordinate," not an assumption that the role emerges once people need it. It does not emerge. By the time people need it, they are already mid-phase, already behind, and already dealing with a backlog of findings that arrived through four different channels.

The other half of the rule is the timing. Appointing a lead halfway through is not the same fix applied late — it is a harder job, because the first act of that person is now archaeology.

What the Role Actually Owns

The reason "everyone knows what to do" sounds plausible is that the role's content is rarely stated. Here is what I would put in it, and none of it is glamorous.

• Own the single intake path and publish it before day one. One destination for every finding, described in one sentence that a non-technical user can follow without asking a question first. If a business user has to decide where something goes, the process has already failed, and the finding you never hear about is the one that costs the most.
• Own the defect-or-change-request decision, and the escalation route when it is contested. This is the judgement call that crosses the commercial boundary, so it needs a named person on each side and an agreed way to disagree. Deciding this in the moment, under schedule pressure, with two organisations watching, is how a technical question becomes a contractual one.
• Own both verification halves, explicitly. Someone on the supplier side confirms the fix is delivered and works; someone on the customer side confirms it satisfies the business need. Those are two different confirmations by two different people, and collapsing them into "it's been checked" is how a fix gets accepted by the only party who did not need convincing.

Three lines. That is the whole role definition, and writing it down is a fifteen-minute conversation held before the phase rather than a fortnight of confusion held during it.

Why This Keeps Happening to Careful Teams

UAT readiness gets checked. Somebody confirms the environment is stable, the data is loaded, the users are trained, the sessions are booked.

Ownership is not on that checklist, because it is not a thing you can look at. There is no screen that shows it missing. The phase looks completely ready right up until the moment somebody needs to route a finding, and by then it is running.

There is also a social reason. Proposing a named owner can read as distrust — as if you think the team cannot organise itself. So the proposal does not get made, and the absence gets described as trust rather than as a gap. It is a gap. Trust is what makes the named owner unnecessary to police, not what makes them unnecessary to name.

Before your next UAT starts, can two people from different organisations independently name who receives the first defect?