How to accept work from a vendor stage by stage when you are not a programmer

Short answer: a development stage is accepted against scenarios written down before the stage started, and on your own data. A vendor demo shows that the system works on the vendor’s examples, which is not enough to sign anything. Defects split into blocking and everything else: only the blocking ones stop the sign-off, the rest move into the next stage. The person who accepts should be the person who will work in the system afterwards, and on our projects that costs twenty to thirty per cent of their working time for the duration of the build.

Below is the order that gets a stage accepted in a few days without any technical knowledge.

Scenarios are written before the stage starts

Before a stage begins, client and vendor write down what has to work at the end. Write it as actions: “the manager finds a customer by their tax ID, sees their orders for the year, creates a new order with three lines, and the order appears in the accounting system.” A stage usually has five to fifteen of those.

Both sides need them. The vendor knows what will actually be checked. The client stops inventing requirements at the moment of acceptance, when changing anything is already expensive.

Checking on your own data

A vendor demonstrates the system on test data the vendor created. On that data everything works. The errors show up on your data: long names, a customer with two legal entities, a product with no code, an order with a thousand lines.

So acceptance needs a copy of your real data, or at least a sample of it. Where the data includes personal information, an anonymised copy will do. Ask the vendor in advance so the test server is populated by the time you sit down.

What to check besides the screens

Input errors. What happens if a field is left empty, letters go into a number field, a button is pressed twice. The system should explain what is wrong and not create two orders.

Permissions. Log in under each role. A manager should not see other managers’ customers, if that is what was agreed.

Exchange with other systems. If the stage includes an integration, check that data arrived in both directions: the order reached the accounting system, the status came back.

The old after the new. Does what you accepted at the previous stage still work. New code sometimes breaks old code, and that only shows up if somebody looks.

Code and documentation. If the contract hands over code stage by stage, check that this stage’s code is in your repository. That takes five minutes without a programmer: the date of the last change is visible in the interface. Which clauses make that possible is in what to put in a development contract.

Defects with priorities

Everything found goes into one list, each item with a priority:

• blocking: the scenario does not pass, data is lost or corrupted;
• important: the scenario passes, but through a workaround or awkwardly;
• wish: works as agreed, but you would prefer it otherwise.

The sign-off waits while any blocking defect is open. Important ones are fixed within the stage or moved to the next one with a note in the minutes. Wishes are estimated separately, as a scope change.

That split removes most of the arguing. The vendor can see that nobody is asking for a rebuild, and the client is not signing off on lost data.

Who accepts

The person who accepts should be the person who will use the system every day. A director or an IT department can see that the system starts up, but will not notice that a manager now needs six clicks where two used to do.

That person needs time. If acceptance runs alongside their normal job with nothing taken off their plate, checking a stage stretches into weeks and the project slips without a single technical problem. Plan that time the way you plan developer time. How it shows up in an estimate is covered in how to check a development estimate.

Common questions

How many days does accepting a stage take? With scenarios ready and the test server populated, three to five working days is usually enough. If the scenarios are being invented on the spot, longer.

What if the vendor disputes a defect’s priority? Go back to the written scenario. If the scenario does not pass, the defect is blocking. If there was no scenario, it is a wish and gets estimated separately.

Do we need our own tester? For most projects, no: an employee who knows the process plus written scenarios is enough. Testing inside the stage is the vendor’s job, and it is worth checking that it is in the estimate.

The rule

Write the acceptance scenarios before the stage starts and run them on your own data. Anything that was not in the scenarios is discussed separately from the sign-off.