If you're consulting or performing PM services through a third party that is paying you, then generally you're covered by that organization. And if not, then your own liability insurance will cover you. Still the negative connotation of being a party in a lawsuit is enough to cause harm to a consulting or project management practice. So – hint - you want to avoid a lawsuit whenever possible.
I'm sure there are many ways to quickly get yourself into the middle of an ugly lawsuit as a Project Manager or consultant, all of which we want to avoid. What I'm going to cover here are the top 5 that come to mind for me. Again, this is far from a comprehensive list, so please be ready to share your own thoughts and experiences and let's discuss.
Providing an unusable end solution. This one goes without saying. Obviously, if you blow through the client’s project budget and turn over an unusable solution to their end users, you might find yourself the subject of a lawsuit. Always show yourself as willing to right any wrong and stay with a project until you get it right. You will greatly reduce your chances of facing a lawsuit if the project fails at first but stick with it to make it right or, at least, show good effort and intent. A good show of faith in the face of project adversity will help the client to see that you are on their side and are willing to do whatever it takes to fix the end solution as much as possible. I'm not saying you won't have to give away some free work. You likely will but just about anything is better than an expensive and disruptive lawsuit.
Misrepresenting your credentials and experience. You shouldn't lie on your resume, and you shouldn't lie on your website. Never give yourself credit for credentials you don't have. I'm not sure how easy it is for someone to check your credentials or how many even would, but you just don't do that. And, if that deceit is coupled with any failures on your part during the course of the project, a lawsuit may happen. The integrity of the Project Manager or consultant should never be in question. The minute it is, the word can get around fast, and you may find yourself losing all of your clients at once, and fast.
Leaking proprietary client information to a competitor. Most project clients will want you to sign a non-disclosure agreement (NDA). There also may be a formal contract involved. Either way, logic should tell you that you don't leak proprietary client information to anyone, let alone a competitor of your valued client. I have had several clients writing into our agreement a list of direct competitors that I agree not to work with while I'm engaged with this client. Our project clients are important – honor all such agreements and always be above and beyond reproach. I don't even like to give out client names when prospective customers ask for references. I avoid this at all costs. It's been a good practice for me.
Related Article: Strategies to Keep Your Project on Track
Failing to cover your bases with signoffs/approvals. I'm not saying you always need formal signoffs on all deliverables. But why not? You never know when you might run up against a client who seems a bit overly litigious, and if you don't have the documentation to prove that you met dates, milestones, and deliverables along the way, then you could find yourself being sued without the documentation to defend yourself. Come up with a formal, generic signoff sheet or email for each deliverable and ask your client to sign it or respond to the email with their approval. That documentation may be golden one day. Always be careful.
Failure to document requirements well. As Project Managers, we all know that it's a bad idea to embark on a project without good, detailed project requirements in place. It's what you use to develop your customer's final solution. Unfortunately, bad requirements happen all the time, and they can lead to projects going over budget, over time, and – if not corrected at all - the final result may be an end solution that isn't usable. So really, this one can overlap a bit with the first topic above. But requirements are the lifeblood of the project and as the delivery organization it is your job to make sure that the requirements are well documented and signoff/approved by the project client. If you have poor requirements to develop the solution from then, don't start the project work until you have good requirements. If you start, then the finger will be pointed at you, and a lawsuit may come about.
Summary / call for input
Lawsuits are ugly. Customers can sometimes be overly litigious. And sometimes you don't know that until the project is well underway. A lawsuit may have a basis, or it may be unfounded...but either way, it can be damaging to you. Be honest, by above reproach, follow through, and don't forget to document everything.
Thankfully, I've never even been close to being involved in one. No threats, no actions. The key is to be open and honest with your project clients at all times and always give them your best. Failure happens, but if the project client knows you've been upfront with info, have given the project 100% and are willing to do what you can to fix issues along the way, then you will greatly reduce any chance of legal action should failure be the final outcome. Stick with the client and make their satisfaction your ultimate goal. It will always work to your benefit over time.
How about our readers? What are your thoughts on this? Have you or your organization ever faced a lawsuit as a result of a failed project? What happened? What did you do to work it out with the client? Please share and discuss.