Top 10 easy ways for consultants to end up in court
Now it’s time to shine a spotlight on the worst practices for agile project management consultants.
You want to win this thing, don’t you Euphemisms sell. So itemize things like crazy, using words that sound important but commit you to nothing. Make sure that the wording in the Statement of Work (SOW) can be interpreted at least two ways, using jargon and concepts that are open to debate. Don’t put in “fences” that clearly demarcate “in” versus “out” of scope.
[Related: Top 10 ways to have your project end up in court]
Everybody hates to write, so don’t require your team members to document discussions, decisions, provisos or verbal warnings. Agile doesn’t say much about documentation, so just leave the requirements and process details as incomplete spreadsheets and terse story-cards. After all, nobody could possibly misinterpret those two years later in court.
We’re all in IT here, so of course the client understands the implications of agile work and knows about the risks inherent in their project. Particularly the ones involving interdependencies, integration, data migration and custom coding. Of course they do, even though they’ve never done a cloud or agile project before. So you don’t need to brief the executives about expectations, guide their project lead or add explicit circuit breakers in the project plan.
The client needs a fixed price so he can manage to a budget. You need some wiggle room. So you bid time and materials, but end up with time and materials with a budget cap – the best of both worlds! The client thinks they’re going to get everything they want (without having actually specified any of it in detail), and there’s no chance that you’ve underestimated the effort.
Now that we’ve got No. 7 under control, we can just let the project boundaries move. We want to be flexible, right You don’t have to document every change order because this is “just hours” and this is agile so the customer understands more requests just mean more hours. And you won’t need to notify the client that some of their original features aren’t going to be worked on to make room for their new requirements.
[Related: Top 10 project management certifications]
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.
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.
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.
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...
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!
All the above may sound like legalisms, but each of them represents a noose. So don’t put your head in there. And if a dispute starts, find a way to settle even if that means you suffer major pain. Read that sentence again. Because undergoing an arbitration or trial will be more pain than you can imagine, even if you win. The proceedings take forever, are an enormously stressful distraction, and cost you billable hours even when you win. If you lose, the legal costs of a “nothing” case will be hundreds of thousands of dollars. And unfortunately, the results are never certain. It’s just a gamble rarely worth taking. And yes, my attorney is yelling at me for writing that.