AMA
Playbook

4 Simple Actions to Keep Your Project (and You) Out of Court

March 5, 2014

keep your project out of court with these simple tips

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.

1. Did You Deliver?

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.

2. Never Knowingly Lie

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.

3. Be Clear on Whether a Change Is a Contract Extension or New Statement of Work

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.

4. Never Talk In Generalities

“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.

These Principles Set The Foundation To Keep Your Project Out Of Court

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.

Related Posts Plugin for WordPress, Blogger...
Enhance your project management skills with these AMA seminars and resources.
avatar

About The Author

Todd C. Williams is the founder and president of eCameron, Inc. (www.ecaminc.com), they help companies make their vision profitable. He has over 25 years of experience in recovering failing projects, preventing their failure, and applying those lessons to help other organizations fulfill their strategic goals. He has helped his clients through strategic planning facilitation, setting up and running operations, IT leadership, and as an expert witness. He is the author of Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure and can be found on LinkedIn (linkedin.com/in/backfromred/), Twitter (twitter.com/backfromred), Facebook (facebook.com/BackFromRed ), by phone: +1 (360) 834-7361, or email: todd.williams@ecaminc.com.

2 Comments »

  1. avatar

    Thanks for pointing out the typo. It has been fixed.

    I think you missed the point, though. Regardless of the omission of “A Guide to the…” in the contract, saying you are going to follow every part of it, still holds up in court that you better use EVERY part of it. Whether your project is values at $10,000 or $10,000,000,000. It is a huge liability.

    Also, there are many people who do not follow the PMBoK. In general, the agile community shuns it, the critical chain/TOC proponents feel it is woefully thin, and I am not sure the PRINCE2 world would agree with that assessment.

    The point is, saying a project will follow ANY doctrine to the letter in a contract is poor practice. I am quoting an actual situation with a definitive outcome. I hope you see the issue in doing so.

  2. avatar

    Everyone follows the Project Management Body of Knowledge since it is an inclusive term that covers everything anyone anywhere knows about project management. There is no such thing as the Project Management Book of Knowledge.

    There is, however, a document called “A Guide to the Project Management Body of Knowledge” (PMBoK Guide) that some people do follow.

Leave a Comment