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.
[*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
Sign up for CIO Asia eNewsletters.