Top 10 ways to have your project end up in court

As someone who’s sometimes called to be an expert witness, I’ve had to testify in arbitrations and court proceedings about the best practices in agile project management. Of course, when things devolve to the point of legal action, there haven’t been a lot of “best practices” in play by either side. Suffice it to say I’ve seen more than a few blunders by clients.

Here are the ones that show up over and over again:

10. Give the consultant ambiguous requirements, then start using rubber yardsticks*

Nothing’s more comforting to the client than the idea that they’ll get exactly what they want, even if they never put sufficient energy into specifying exactly what that is. This goes double for the high-risk area of custom software development. So state your requirements vaguely, to make sure that anything you dream up later can be construed as being within the bounds of your original wording. This tactic works best when you don’t really understand the technology, but you do know you need the deliverable to be infinitely detailed yet easy enough for your grandmother to use without training. This tactic is even more effective when you start having detailed conversations about requirements during acceptance testing, when there are no development funds left.

[Related: Top 10 project management certifications]

[*What’s a rubber yardstick? Instead of being like a regular yardstick that is a straight line of fixed length, the rubber yardstick stretches and shrinks and even bends and twists to connect dots that aren’t even on the same plane.]

9. Don’t put decisions in writing or email

Writing things down merely ties you down, and that just limits your flexibility in the future (see #10). Much better to give verbal feedback in wide-ranging meetings that never really come to a conclusion. During these meetings, make sure that many attendees are texting or responding to fire-drills unrelated to your project, so they lose focus and have no recollection of what was said. When it comes to signing off requirements, monthly reviews or acceptance testing – just ignore this bean-counting detail!

8. Under-staff your team

You’re paying good money for the consultant to do their job, so there’s no point in over-investing in your own team members. Put in no-loads and people who don’t care, so that the people who actually know what they’re doing can stick to their regular tasks. Once you have your drones in place, make sure to undercut their authority by questioning every decision. No point in motivating anybody – you’re already paying them more than they deserve!

7. Blow off approval cycles, wireframe reviews and validation testing

You’ve got to focus on the big picture of making your business more profitable, so you don’t have time to get into the niggling details of this software project. Besides, business processes and policy decisions are boring and can be politically charged. So when some pesky business analyst asks you to validate the semantic interpretation of a business rule, just leave that mail in your inbox. It’ll keep. Later, when it comes to testing and reviews, just send a flunkie with no decision-making authority to check things out.

6. Blatantly intimidate your team

Review meetings should be an expression of your personal power, prestige and authority. Change your mind endlessly and capriciously about details. Change the subject when substantive issues are brought up. Discuss how much your new shoes cost. Punish any questioner. Trust no one (not even your own team members), and make sure that trust never gets a chance to build within the team. Make sure team members know to hide bad news. Use blame as a weapon.

5. Focus on big-bang, slash cut projects with lots of dependencies

Crash programs are the way to get big things done in a hurry. Incrementalism is for wimps and weenies without the imagination to see the big picture. Since complex projects probably involve several vendors, make sure that nothing can progress without your direction and approval. Do not delegate – or if you do, don’t empower the delegate to do anything. You wouldn’t want to lose control!

4. Switch deadlines and priorities frequently

If the generals are right in saying that all your plans go out the window as soon as the first shot is fired, there’s no point in planning realistically in the first place. Make sure to have deadlines for things with lots of dependencies, and then move those deadlines three or four times during the project. This’ll ensure that the project will involve inordinate waste and overhead – but hey, that’s the consultant’s problem, not yours.

[Related: Agile project management lessons learned from Texas Hold’em]

3. Have no contingency plan and no tolerance for budget shifts

It’s pedal to the metal – nobody has time for insurance policies. You can’t afford to run two systems in parallel, validate live transactions or reconcile variances before full production use. Make sure you dedicate 100 percent of your budgetary authority to the vendors, so there’s no way to reallocate funds…let alone have a buffer to handle the unexpected. This works even better when your company enforces a use-it-or-lose-it financial regime.

2. Squeeze the vendor as early in the project as you can

Get your money’s worth. It’s never too early to start squeezing your vendors to get the most out of them. Their negative profit margin is not your problem. Show ’em who’s really boss. As the project nears its end-game, start modifying the production system yourself, and begin phase-2 work before phase-1 work has been signed off. Configuration control is for weenies.

And the #1 way to make sure your project ends up in court…

1. Don’t monitor your own budget and pay little attention at status reviews

Ignore invoices and progress-against-goals reports. Make sure the integrator doesn’t know you are not paying attention. Don’t ask questions at project review meetings. Delete emails that bore you. The vendor is there to deliver, so the details and consequences of project management are not your problem. As the project nears its deadline, insist on extra consultant personnel on site without giving any written authorization for extra charges.

Before I say anything more, I have to make it really clear that I’m not an attorney, and none of this is to be construed or used as legal advice. (Yes, my lawyer made me write that.) So get counsel from counsel about the best ways to remedy or prevent the issues above.

As I said at the start, projects that are deeply troubled have problems rooted in the behavior of both the client and the consultant. Next time, I’ll have a Top 10 list for consultants to make sure they end up in court, too.