“Acceptance” sounds so simple, so what’s the big deal?

Acceptance is a transformational event in the world of Consulting Service Projects whether you are the Customer or the Consultant. On one side, everything leading up to acceptance is pre-sales (i.e. non-billable), and everything afterwards is post sale (billable),and you have very different legal rights depending upon what side of that line you stand upon. Perhaps the most import of these legal rights is simply the right of the Customer to cancel the order; once a Project is accepted you generally have warranty rights to address defects, but you no longer have the right to terminate the project (In “extremely” limited circumstances, Customers may rescind acceptance). Prior to acceptance, Customers often have certain rights to cancel “with cause” (Consultant has not complied with the Agreement and has not cured the defect) or “without cause”, in which case the Customer generally pays for services delivered through date of termination. However,  if acceptance isunfairly delayed Consultants are often forced to try to pay their staff while they continue to deliver Services beyond those services that they expected and budgeted (i.e. free service) to induce the Customer to accept. One of the key issues with any acceptance clause is to place an affirmative duty on the Customer to faithfully proceed with the acceptance process upon delivery completion. If you divide the service delivery into Milestones, it can help manage the risk for both parties. Essentially, one set of deliverables would be defined as Milestone 1, which would need to be accepted before the service delivery continues into Milestone 2; so each milestone would have its own individual acceptance test and most likely the overall project would have a Project-wide Acceptance test at the end to demonstrate the Milestones work together. If the entire Project is lumped into a single large deliverable, that might seem easy when you are getting started but your project will not have the mile markers AKA “milestones” necessary to help keep the service delivery on track and to protect both parties interests. Remember, you are depending upon participation from both parties to make a service delivery project successful; i.e. the other party cannot make up for your lack of timely participation.


It is often said an ounce of prevention is worth a pound of cure. With regards to Acceptance Test Criteria and Planning, that relationship is understated. Acceptance Tests should not be viewed as a trial drive, it is intended to be much more rigorous than a few hours or days meandering through unplanned user testing:

If you have an important Project that you are negotiating, look at the acceptance criteria in the SOW:

1. Do they adequately define all the critical functionality required;
2. Is the project divided into a logical sequence of deliverable Milestones;
3. Does it properly anticipate the volumes anticipated and the specific operational environment;
4. Does it define exactly what constitutes each Milestone’s success; and
5. Does it provide how much time the Consultant has to cure acceptance test defects.