Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Top 10 easy ways for consultants to end up in court

David Taber | Aug. 20, 2015
Everyone loves to talk about best practices. After all, it’s only natural to want to replicate success. But sometimes you can learn more from worst practices. With that in mind, here’s a list of what not to do.

5. Assume that the client will ‘understand’

The client understands the consequences of their actions, good or bad. They understand the ramifications of their behavior and yours. They understand the consequences of changing architecture mid-project. They’re being reasonable when they refuse to pay for a sandbox. They’re responsible business people, and know what it means when they move deadlines. So they won’t need you to brief them or document the risks and provisos. And you don’t need to ask for deliverable sign-offs at the end of every sprint – just put that off until the very end so it’ll be quick and easy.

4. Apologize and make disparaging remarks about your own team in internal emails

Hell, let disparaging remarks go into test results, emails to the client and conversations with third-parties that can later be deposed. Put all the dirty laundry up for show, to demonstrate your candor and high standards. None of this could possibly be misinterpreted by lawyers taking things out of context in court.

3. Keep project status green until red is unavoidable

Expect that the client reads, understands and remembers all your status reports and emails. Expect that they’ve been tracking progress against goals versus budget. Expect they understand the repercussions of scope creep, slips and dependencies. Don’t use the yellow status as early warning flag – it’ll just upset people and cause more meetings. Skip the briefing meetings at 50 percent spend (“mid-course correction”) and 80 percent mark (“how do we bring this one in for a crash landing”). Avoid having meetings about tradeoffs and feature-demotion, because…well…they might yell at us.

2. Say ‘we can handle it’ all the time

Under-use the word "no," because…well…they might yell at us. Don’t actively manage expectations on deliverables, budget, schedule and usability. Get roped into things that aren’t documented as SOW deliverables. Over-promising is OK because the client will just pay for the extra hours. If they fall behind in payments, assume they just had a slip-up in AP. They’ll get that money to us.

And the #1 way to end up in court... 

1. Have a weak contract

Leave out or negotiate-away things that annoy the client, such as disclaimers for consequential damages, waivers of responsibility for all third party products, waivers of responsibility for third party contractors working on the system, or limitations of liability. Remove “outs” if the client modifies your work before accepting it, violates configuration control, or does not use your proscribed deployment practice. Expunge statements regarding client responsibility for all client actions. Remove provisos regarding unexpected bugs in the client’s existing integrations or data. Remove the words “agile” and “estimate” and “time and materials basis for all tasks and hours worked.”  Erase limitations for patent infringement and indemnification – that could never happen to you! 

 

Previous Page  1  2  3  Next Page 

Sign up for Computerworld eNewsletters.