The sign-off that proved nothing

I have sat in the meeting where a system gets accepted. Someone shares a screen, walks one record from the beginning of the process to the end, everything behaves, and six people say yes. Three weeks later half the team is back in a spreadsheet. Nothing broke. The software did exactly what it was shown doing. It turned out that what it was shown doing was about a fifth of the job.

That gap is not usually a quality problem on the build side. It is a problem with what acceptance was asked to prove. A walkthrough proves the software can do the thing when the person driving already knows the thing. Acceptance has to prove something harder: that the people who do this work can finish a normal week inside the system, and that the week includes the cases nobody enjoys.

A demo is a performance, a test is an attempt

The practical difference is who is holding the mouse. If the build team is driving, you are watching a rehearsed path. The developer knows which fields matter, skips the optional ones, and picks an example that behaves. That is a fine way to show progress. It is not evidence.

Acceptance means the person whose job it is sits down with their own work and tries to finish it, while the people who built it watch and say nothing. The silence is the point. Every question the build team answers out loud is a question your team will have at eight in the morning with a customer on hold. Write those questions down instead of answering them. They are your training gaps, and a surprising number of them are real defects wearing a disguise.

Script it from the exceptions, not the happy path

Most acceptance plans are written from the specification, which means they walk the main road: new customer, standard order, successful payment, done. Your team already knows that road works, because it is the one everybody talked about for three months. The case that decides whether this system survives contact with the operation is the other one.

Pull these from the last ninety days of your own mess. The emails that opened with "this one is weird." The tickets somebody closed by hand. The reason a side spreadsheet exists. If a case came up twice last quarter it belongs in the acceptance script, and if the system cannot carry it you want to know that now rather than in week one.

Separate a defect from a change before you start

Acceptance always produces a list, and the list always holds two different kinds of item. One kind is the system not doing what everyone agreed it would do. The other is the system doing exactly what was agreed, and the agreement turning out to be wrong. Both are legitimate findings. They are not the same conversation, and when nobody separates them, acceptance quietly becomes a second build with no budget and no date.

Defect

The behavior contradicts what was specified or what the workflow plainly requires. It is fixed inside the current scope, and it can hold sign-off.

Change

The behavior matches what was agreed and the agreement was incomplete. It gets priced and scheduled. It does not hold sign-off on its own.

Blocker

Either of the above, in a case where a named person cannot complete required work by any route, including by hand. This is the only category that should be allowed to move the date.

Sorting each item into one of those three in the moment, with both sides in the room, costs a few minutes. Sorting it two weeks later, after someone has already started building, costs real money and some goodwill. I would rather have a short, direct disagreement about whether something was in scope than a polite silence that becomes an invoice nobody expected.

Who signs, and what they are actually signing

A sign-off that says "the system works" is not worth collecting. Nobody can defend it later and nobody quite believes it at the time. What holds up is narrower, and it comes from the person who owns the work: I ran these cases, these ones failed, these are being fixed, and I can run my part of the operation on this by the date we agreed.

That means acceptance needs named people rather than a committee. One person per area of work, and specifically the person who gets the phone call when that work stops. In a payments operation it is usually whoever reconciles. On a donation platform it is whoever answers the donor whose receipt is wrong. In a regulated process it is whoever signs the thing that goes to the regulator. These are rarely the people who sat in the requirements meetings, which is exactly why their attempt is the one that counts.

Give them time on the calendar, in writing, and treat it as part of the project rather than something they squeeze in around a full workload. Acceptance that happens in the gaps of somebody's day produces a signature and no information.

What pass means on the day before cutover

The useful bar is not zero open items. No system of any size reaches that, and holding out for it just moves the risk into an open-ended pre-launch period where the business pays for two systems and runs on the old one.

The bar I use has three parts. Every required path has been completed end to end, on real data, by the person who will actually do it, with nobody from the build team touching the keyboard. Every open item is written down with a category and an owner, so the list is a decision rather than a rumor. And for each critical path there is a documented way to get the work done by hand if something fails in the first two weeks, which at least one person on the operating team has read.

That last part is the one people skip, and it is the one that makes the first fortnight survivable. Acceptance is not a guarantee that nothing will go wrong. It is a decision to proceed with a list you can see. Knowing the list is the whole value, and a signature on a walkthrough gives you a date with no list at all.