Statement of Work: What is the Difference between Acceptance and Completion Criteria for Software Companies?
July 22, 2013
Statement of Work Tips for Software Companies
As a software attorney, I have been running into this issue a lot recently when working on Statements of Work (SOWs), so I thought it warranted a blog post. What is the difference between acceptance criteria and completion criteria, and why should a software company care? Well, there are many differences — with significant consequences — and you definitely should care. This especially matters to your economic model, as we are talking about revenue (aka $) here.
What is Acceptance Criteria?
While there are many flavors of this concept in SOWs, you usually see it drafted (by the customer) and it says something like “subject to acceptance” or “customer can accept, review, and test the deliverables…” (i.e. a subjective measurement). The customer usually says something like, “we need to check that the deliverables meet our requirements.” (By the way, there are actually two flavors of customer acceptance wording, as well — see the chart below.)
What is Completion Criteria?
This is a different way of addressing the same issue. It is an objective measurement (i.e. “not subject to distortions by prejudices or interpretations”) of whether you, for example, “deliver” the report to the customer or “hold” the training session call. Said another way, this is something you can prove or demonstrate, and it is not subject to the interpretation or opinion of the customer whether it was done or not.
Why Should I Care?
I suggest you should care, as if you want to get paid, or are worried about ‘scope creep‘ or ‘revenue recognition‘, you should pay attention to this.
Summary Chart
Take a look at this chart, as I have tried to outline the issues are clearly as possible.
Rookie Mistake
I think it is a rookie mistake to trust the customer who says, “I just need to check if you did the work, and therefore we need our acceptance wording.” Well, what about scope creep? What about payment? What about delays in their acceptance? What about if the requirements change? What if you do the work but they just don’t like it? What if someone thought that your sales guy said that the software would cure cancer?
Now this may work fine for your first few SOWs, but I think you will find that over time too many customers will — without justification — not accept or delay acceptance of your work. My suggestion is to negotiate up front for more objective measurements of “completion” (be specific), and then work towards delivering that which you can demonstrate and prove that you completed (plus try to get paid in advance, as that always helps).
What are the big guys doing?
Well, glad you asked. Take a look at a sample IBM SOW, which just happens to be on the web. I consider this to be the gold standard, as it is clear, simple, and uses “objective completion criteria” instead of very customer favorable “acceptance.” IBM has probably been contracting for complex IT services engagements longer than anyone, so you know (and I know) that they have spent a lot of time thinking this through.
So, when thinking through your economic model, keep this blog post handy (maybe print it out or give it to your implementation team), and read it before you take your customer’s word for “we need our acceptance wording since we just need to check that you did the work.”
Resources: IBM SOW
Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.