March 5, 2014
It was a rough project management day to deal with and you are glad it is over. People around the office continue to talk about it and a small team is still engaged wrapping up loose ends. An urgent email from the corporate lawyer titled simply “Lawsuit” drops into your inbox. It summons you to a meeting to talk about what you will need to provide.
You learn that the subpoena requests every contract, statement of work, and change order. Each log, email, document, piece of physical mail, specification, and test document. They want pictures, drawings, and even scratch notes. They have outlined everything that ever existed on your project. Reflecting back on the project, you wonder how many corners were cut before, during, and after you were on the project.
You may be reading this smiling, thinking it will never happen to you, but it does—projects go to litigation every day. A client can sue you for any reason and there is not a lot you can do to stop that from happening. There are, however, many actions you can take throughout the project to minimize the chances it will go to court. Here are the big four.
The first question you need to be able to answer with, supporting documentation, is “Did the client at any time agree the system was acceptable?” Identify every deliverable and find any correlating documents that implicitly or explicitly say that the customer accepted the deliverable. In litigation, signatures and their dates are the Holy Grail. The absence of signatures means “failure to reach agreement.” Every deliverable must have a document with the signature of a receiving party showing the items were accepted as satisfactory for use.
All is not lost if you are missing documents. Did the client ever use the deliverable in production? If so, they must have thought it was good enough to release. Surely, the contract has a clause saying that if the client uses the product in production, then they have accepted it. It is hard for your client to claim that a deliverable did not work if they have used it with customers, on a manufacturing line, to process transactions, or the like.
Determine if anyone has knowingly stretched the truth. Even little fibs are problematic. A trivial statement along the line of “We got done with that today,” when the person saying it knows quite well that engineering promised it for the following day, will get you in trouble. Inevitably, the delivery does not happen on the promised day and the emails fly discussing the issue. With the delivery of the subpoena asking for all project documents, this email thread is now part of the court’s evidence and proves that you lied to your client. Your credibility, ethics, and character are now reasonably in question. The lesson is, never lie and if you unknowingly say an untruth, clear it up with your client immediately.
Although the details are deeper than this article, there is a fuzzy line between change orders and statements of work. Change orders change the parameters of an existing contract while a properly worded statement of work says you are effectively starting something new. The latter triggers the start of the statute of limitations while the change order will not. With the statute of limitations, there are implications on warranty period, implied acceptance, and limitations on liability. If you only use change orders, nothing is completed. As you might imagine, in a legal battle, lawyers dissect these distinctions. As the client asks for project changes, get some set of deliverables complete and accepted before starting a new set of work. If the change is significant, get in a revised statement of work showing what in new and completed.
“We put only PMP® certified project managers on our projects and they follow the Project Management Body of Knowledge® (PMBOK).” Typically salespeople say things like this, but it should never creep into a contractual document. All standards are designed to handle plethora of conditions that exists inside a domain. Few projects intend to, or should, deliver every document or function prescribed in a standard. It would kill nearly any project.
Instead, the Statement of Work needs to define the methodology to be used on the project. It should also state the qualifications, roles, and responsibilities of the team required throughout the project lifecycle. Specify only the functions, documents, and pieces of work that are essential for delivering your product and meeting the compliance needs to advance your project management.
Remember, all of these items need to be defined for both the client and the supplier.
Getting a subpoena does not mean your project will end up in court. The four points above will not help if the project has failed to deliver what the contracts agreed to deliver the customer, if you have overstated your capabilities, or you have demonstrated breach of contract or negligence. Keeping to these four principles, however, reduces you chances of being sued and, if you do, gives you the best chance of staying out of court–A small amount of insurance that will let you sleep better at night.
For more business insights and strategies, sign up for our free management newsletter, Moving Ahead.