The supplier says the form is finished. The person reviewing it says users cannot complete their task. They may mean different things: the form displays correctly, but an attachment is lost or an error is never explained.
Agree how acceptance will work when you agree the scope. The supplier then knows what result to deliver, and your organisation can prepare the people and data needed to check it.
Write a scenario, not an adjective
“The system must be convenient” is difficult to verify. A concrete task is easier:
A user completes a request, adds a file in a supported format and submits the form. They receive confirmation, and a staff member sees the request and attachment in the administration area.
Add the starting conditions, sample data and expected result. Include an unsupported file and an interrupted submission. Scenarios should test the agreed scope, rather than introduce new requirements at the end of delivery.
Prepare the reviewers and environment
Decide who checks each area, which version they will use and where findings will be recorded. Assign someone to turn conflicting feedback into a single decision. Otherwise the supplier may receive contradictory instructions from different departments.
Allow time for fixes and another review. A date for the demonstration is not a complete acceptance plan.
Check the handover as well
Alongside working features, you need the agreed accounts, instructions, documentation and training. Check whether the intended administrator can perform a basic task independently.
Keep a shared list of satisfied conditions, defects, owners and dates. Make formal acceptance decisions under your agreement. This makes it possible to discuss specific gaps instead of arguing over a general impression that the project is “not quite ready”.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database