Define the evidence the business needs

A final project review is the structured checkpoint where you confirm that what was built matches what was agreed, before you formally sign off and move into the next contractual phase. It is not a general debrief or a retrospective on how the project felt. It is a verification exercise tied directly to your acceptance criteria, contract terms and deliverables list.

The review should happen once the supplier has declared the build complete and has provided evidence that each acceptance criterion has been met. At that point, the ball is in your court to either confirm satisfaction, raise specific defects or flag items that remain incomplete. The review itself does not replace user acceptance testing; it sits after UAT, using those results as input.

Who should attend

The review needs people who can speak to three separate areas: the business requirements, the technical deliverables and the commercial contract. Typically this means an operations manager or internal product owner, someone from your IT or technical team if you have one, and a person with authority over the contract — often a finance or procurement lead, or the business owner. The supplier should bring a project manager and a developer or technical lead who can answer questions on the spot.

What the review covers

  • Each acceptance criterion from the specification, checked against the live system.
  • Deliverables listed in the contract: source code, documentation, access credentials, infrastructure details and any third-party licence keys.
  • Known defects and their severity, with a clear record of what is accepted as-is versus what must be fixed before sign-off.
  • Any scope items that were deferred, changed or removed during the project, with confirmation that both sides agree on the current state.
  • Training materials or session records, if these were part of the agreement.

The output of the review is a short written record — often a meeting note or formal sign-off document — listing what passed, what failed, what is deferred and what actions remain, with owners and dates. This document becomes the reference point if a dispute arises later about whether the project was actually completed.

Structuring the session

Walk the system in the order of your acceptance criteria, not the supplier's feature list. This keeps the review tied to what you specified rather than what was easiest to build. For each criterion, have someone demonstrate it live, then confirm whether it passes. If something does not pass, record the specific behaviour observed and the expected behaviour from the specification. Vague statements such as "it doesn't feel right" create ambiguity; precise descriptions such as "clicking submit returns a 500 error instead of saving the record and showing the confirmation screen" do not.

Checking non-functional requirements

Acceptance criteria often focus on what the system does, but your specification may also have covered performance, data handling or access controls. The final review should confirm that these have been tested and evidenced. For example, if the contract stated that a report must load within a certain response time under a stated data volume, ask to see the test results. If role-based access was specified, have someone log in under each role and confirm the restrictions work as described.

Asset handover verification

For a custom web application, the system itself is only part of what you are paying for. The review should confirm that you have received, or will receive within a defined window, everything needed to operate and maintain the software independently. This typically includes repository access, database schemas, environment configuration details, credentials for hosting and third-party services, and any documentation that was contractually promised. Verify access by logging in, not by taking the supplier's word for it.

When the review reveals problems

If the review uncovers defects or missing items, you have three practical paths. Minor issues that do not prevent business use can be logged as accepted defects and addressed during the defect liability period. Significant gaps that prevent the system from serving its intended purpose should block sign-off until resolved. Ambiguous items — where the specification was unclear and the interpretation differs — need a commercial decision rather than a technical one, because the contract may not give you a clear right to demand changes.

Where the work usually goes wrong

  • Conducting the review without the acceptance criteria to hand. If you are working from memory or a summary, you will miss items and create room for disagreement.
  • Allowing the supplier to drive the agenda. A supplier-led demo naturally showcases what works well and steers around weak areas. Your criteria list should set the order.
  • Signing off while critical access or documentation is still outstanding. Once you sign, your leverage to obtain those deliverables diminishes sharply. Tie sign-off to confirmed receipt.
  • Conflating the review with a general project debrief. Discussing what went well or what you might do differently next time is valuable, but it belongs in a separate conversation. Mixing it into the sign-off review creates noise and can delay formal closure.
  • Skipping the review entirely because the project felt smooth. A good working relationship does not guarantee that every contractual deliverable is in place.

Limitations of the final review

The review confirms that the system meets the acceptance criteria you defined. It does not guarantee that those criteria were correct, complete or sufficient for your business needs. If the original specification missed a critical workflow, the final review will not catch that omission — it will only confirm that what was specified has been delivered. The review is also not a security audit, a penetration test or a performance benchmark under production load. If you need those assurances, they require separate exercises with appropriate specialists.

Key checks before closing

  • Every acceptance criterion has a pass, fail or deferred status recorded in writing.
  • Failed items have either been resolved or formally accepted as defects with an agreed remediation plan.
  • All contractual deliverables beyond the software itself have been received and access has been verified.
  • Both parties have signed or otherwise formally agreed the review record.
  • The transition to the next phase — whether that is a defect liability period or a support arrangement — is clearly dated and understood by both sides.

Close with an owned defect and evidence record

The final project review is a short, focused exercise that protects your position and clarifies exactly where the project stands. Conducted properly, it gives both sides a clean reference point and reduces the chance of disagreements surfacing weeks or months later.