Who should accept an enterprise software implementation

A supplier finishes configuration. The project team demonstrates the workflow. The sponsor says the system looks good. Yet the operations team is unsure who will support it, finance cannot reconcile the migrated records and users still rely on a spreadsheet to complete the process.

This is an illustrative implementation scenario, not a reported customer case. It shows why acceptance needs more than a meeting at the end of a project. Enterprise buyers and software suppliers should agree what must be demonstrated, who can accept it and how unresolved defects will be handled.

Define the decision before writing the tests

ISTQB’s acceptance-testing material emphasises collaboration between business analysts, product owners and testers. It covers acceptance criteria, business processes and non-functional requirements, including usability, performance and security.

The practical implication is that acceptance should begin with the business requirement. “The integration works” is too vague. A more useful criterion identifies the event, expected result, allowed delay and evidence required.

For an order-management integration, that might mean an authorised order reaches the correct destination once, preserves required fields and produces a visible exception when it cannot be processed. The parties must agree the actual thresholds; a generic template cannot supply them.

Give different reviewers different questions

Technical reviewers establish that the delivered system meets the agreed technical requirements. They may examine integration behaviour, permissions, logging and recovery. Users establish whether the workflow supports the tasks for which it was bought. Operations establishes whether the organisation can run and support it.

The business sponsor decides whether the evidence is sufficient to accept the agreed scope. That person should not have to perform every test personally. They need a reliable summary of results, unresolved issues and consequences.

Contractual acceptance can carry payment or other obligations. The authorised commercial and legal reviewers should align the process with the actual agreement. A project dashboard should not silently redefine what a signed contract requires.

Test exceptions alongside normal transactions

A clean demonstration usually follows the expected path. Live work also includes missing fields, duplicate submissions, expired permissions and unavailable connected services.

GAT recommends selecting exceptions from the buyer’s real process and recording the expected response. Can a user identify what failed? Is the work recoverable? Does retrying create a duplicate? Who receives the alert?

For an APAC rollout, include the relevant currencies, time zones, languages and local workflows in the agreed scope. Their relevance depends on the implementation. A successful English-language test in one office does not establish that a different deployment has been accepted.

Distinguish defects from later improvements

Without an agreed boundary, a supplier may call an unmet requirement a new feature while a buyer treats every preference as a blocking defect. Keep requirements and change requests separate.

Each unresolved item should have an owner, severity, workaround and decision date. Conditional acceptance can be useful if the agreement allows it and the remaining risk is understood. It should not become an indefinite arrangement in which the supplier considers the project complete while the buyer considers it unfinished.

A record of acceptance should identify the tested release and environment. Material changes after testing may require retesting the affected requirements.

Revisit value after the handover

Acceptance and benefits measurement should connect without being confused. A workflow may meet its specification before enough operating data exists to judge its long-term business effect.

Agree a later review using a defined baseline and comparable workload. Track rework, support demand and adoption alongside speed or cost. Do not present the implementation’s completion date as proof of an eventual return on investment.

This builds on GAT’s analysis of turning enterprise AI pilots into revenue. The purchase decision, acceptance decision and benefits review should each produce evidence. A project is easier to govern when those decisions have named owners and a clear relationship.