Engineers As Consultants Pt. 7: How to Write a Client Acceptance Clause in a Consulting Contract

There are a lot of consultants out there who like to think of themselves as great businessmen and women. They focus in on the contract and make sure their contingencies are covered so they will get paid even if lawyers are needed. Sadly, most off those engineers are fooling themselves and are not good at business. I take a different approach: I'm a poor businessman. I don't particularly like working with lawyers, and I would probably prefer to walk away from a client and pick up other business than spend a lot of time and money chasing them in court over fees. Instead, my principal method of protecting against nasty situations like that is to carefully select with whom I work. I base my contract on IEEE's template that you can get here.

There is, however, a portion of the contract that I find to be central to the project's success: the Client Acceptance clause. In any fixed-price contract, the acceptance clause is the finish line that everyone agrees to. The payment that a consultant will receive can be easily written in black and white with a simple number. What the consultant delivers is much more difficult to define and I have learned that if left undefined or under-defined there will ALWAYS be trouble.

I experienced an example of this 6 or 7 years ago when I started to see fixed-price bids as the best way to work. A previous client with whom I had a great relationship with needed another job done, and I wanted put her on a fixed price quote instead of our previous hourly agreements. We both understood the project well; it was an improvement on an existing design with which I had already worked. It was a standard product-redesign project. She wanted me to get rid of several obsolete components, and update to a new communication protocol for communication to a computer. She already had a plan for some of the new components she wanted to use, and in the quoting process I found the rest of the components that would almost certainly work well. The project seemed straightforward enough and I wrote the quote by listing what work I would perform. The project started off great, although there was some adjustment on my working relationship with the client since she was used to my hourly rate where she could request changes instantly without a delay. This new structure required us to renegotiate when she wanted a change half way though. But this was a simple adjustment and we quickly reworked the contract when needed. I was able to finish my work as expected and slightly ahead of schedule.

Except what I considered to be 'finished' was not what my client considered 'finished.' This is an example of a poor contract corrupting two otherwise nice people. I went into our meeting to discuss the completion of the project with the contract in hand, confident that she would see things my way. I stepped through each of the line items in the statement of work and described how I had checked them off. However she was able to show different definitions of what some of the line items should produce in terms of performance. “Yes, you changed the A/D chip to the new one I requested, but you didn't update the firmware calculations to take advantage of the higher resolution” she said. I thought that she wanted to change to the new chip because the old one was going obsolete. She assumed that of course I'd adjust the firmware to take advantage of the better performance since I already had to change the firmware to accept the higher resolution data coming in. But I was able to show other features that are available in the new chip that she didn't need implemented. How was I to know that she wanted supply chain improvements AND performance improvements? It was a contentious meeting.

Thankfully, all of the aspects of the job that she found to be lacking were not very hard for me to do. We were able to agree that the contract could have been written with more clarity and I offered to make the changes she wanted for a slightly increased fee. It is lucky that the changes were minor; I don't think she would have been agreeable to a big budget change. Remember, the consultant is the expert on the subject and should be the one to predict things like this, not the client.

I delivered the changes, and the client accepted them. We both walked away satisfied, but frustrated with the process. I did more work for her in the future, but she always insisted on an hourly contract.

Had I added an acceptance clause to the contract, there would have been no problem. An acceptance clause is the list of tests performed to exclusively determine if the work has been completed to spec. It should be agreed that it is the only deciding factor used for client acceptance of the project. It should include the test setup, the inputs, and the expected outputs with specified tolerances. Obviously, this can be challenging to write at the start of the project. It forces the client to understand the project at a level that they would probably prefer not to think about so early. But it is the single best way to make sure everyone is happy at the end of the project.

There are some projects that can't have a rigid acceptance clause. Sometimes a client will say, “I want it to be as accurate as you can make it.” It is important to tie them down to a minimum acceptable accuracy for the acceptance testing, with a promise that you'll attempt to beat it. Other times part of the project needs to be completed before defining acceptance criteria. Try to only quote the first phase of the project and then quote the second part separately after there is enough information to generate an acceptance clause. You may have to give a rough cost estimate on the second part since the client won't want a nasty surprise after spending the money to complete the first part. Finally, if an acceptance clause cannot be defined, quote it as an hourly job.

Contracts are just a more refined version of the “I get things my way because I called it!” game we all used to play as kids. For some reason, the same rules apply. If you're bad at the game and don't follow the rules, nobody will want to play with you anymore. Everything we need to know we really did learn in kindergarten.

James Benson is writing a series on 'Engineers As Consultants' to educate and encourage salaried engineers to consider if hanging a shingle is right for them. New posts on the first Monday of every month.

Pt. 1: So You Want To Be A Consultant

Pt. 2: How Do Engineers Find Consulting Gigs?

Pt. 3: How To Price Consulting Services?

Pt. 4: How To Keep A Client?

Pt. 5: Finding The Best Client Mix

Pt. 6: How To Turn Down A Client

Pt. 7: How to Write a Client Acceptance Clause

Pt 8: Business Structures

Pt. 9: Taxes, Writeoffs, and Accounting

Pt. 10: When Subcontractors Quit

Pt. 11: When a Client Turns into a Deadbeat

Pt. 12: Getting Paid with Company Stock

Pt. 13: How to Assign IP Ownership in a Contract

Pt. 14: Annual Review

Pt. 15: How to Take Vacation

Pt. 16: How to Engage Peers