Dealing with Difficult Customers

We’ve all had them. Whether we are an internal software development team trying to deliver to the business, or consultants delivering to clients, we’ve had clients with unrealistic timelines or deadlines. We’ve had clients that are disconnected and not responding to questions about development efforts. We’ve even had clients who try to “add” features and claim that those were features they originally asked for. It leads us to paranoia about documenting requirements, tightly scrutinized contracts and estimate padding. It’s not just how we protect ourselves from “bad clients”, but how can we deal with clients in such a way that things don’t get “bad” and we can ensure that everyone is happy with the resultant software product? After all, they’re generally not bad people, they’re just trying to get some software built to help them out. So what can we do to help them be successful?

Questions, Questions, Questions

The first way to guard against having a bad client, is to ask lots of questions up front. This seems like Big Design Up Front or a Waterfall-type requirements phase, but the questions can remain less detailed than that.

Questions like:

  • What is it you’re trying to accomplish with this software, from a business stand-point?
  • (another way to ask that is) How will this software improve your business/make your business more money?
  • (if there is a hard deadline) What are the business repercussions of missing the deadline?
  • What if the software works by the deadline, but not all of the features are there?
  • What if all the features are done by the deadline, but they’re not as “fleshed-out”? (The example I always give is, “What if the login page only has username and password, but no remember me button or forgot password function?”)

Honesty Up Front

A way to ensure a responsive client (internal or external), is to spell out the time requirements for them as it regards to project success. Something like, “I need someone with decision-making ability for this project available at least 15–20 hours per week.” It doesn’t have to be two full work days, it can be 2–3 hours a day, every workday. Just so the client knows that developing software requires a time commitment from them, too. It’s also important to ensure you have an “emergency” contact in case someone on the team cannot continue to make progress without an answer to a question or a decision being made. This doesn’t have to the same person, but it usually is. Sometimes using an automated task board/ticketing system can help, because you can assign a task/ticket to that contact person.

Give Them Control

Start by asking the client to relatively prioritize the features (from most important to least important), then manage the expectations by making them understand that you will be working on the features in that order. Then you can avoid scope creep by, instead of just saying, “That wasn’t in the original requirements.”, you can give control back to the client by saying, “Absolutely, we can add that, but it may mean that (the least important features) might not make it in by the deadline. Is that still okay with you?” You should also ask where the new feature goes in the prioritized list.

Avoid Confrontation (If Possible)

It’s easy to start getting defensive when you’re under a particularly aggressive timeline, but it rarely achieves a good result, for you or the client. So, even though this may sound like a weak way to manage a client, I am not suggesting that you let a client walk all over you. I am simply suggesting that when a client asks for something unreasonable, you don’t tell them they are being unreasonable. You should ask questions about their request until they (hopefully) come to that conclusion on their own. This is something I do well sometimes, but fail miserably at other times.

The biggest mistake I make, and see others make, is to let the questions start to get snarky. It’s easy to let questions like, “In addition to the features we still have left?” and “…and the deadline remains the same?” sounds snarky, or GET snarky, so I try to avoid them. I try to use questions that make them feel like they’re calling the shots and I am just here to get it done for them. This is mostly going to come up in conversations about whether this is a change/addition or whether it is what they originally asked for. With a prioritized feature list, you can take them back to the feature in the list and compare notes. If it stays friendly, and you genuinely want to help them get their software done, getting them to admit they might’ve been clearer, or that the feature has changed becomes easier. Keep them off the defensive and cooperation follows.

And The List Goes On

These are my experiences from twenty-ish years of writing software, both internally and as a consultant. What are some of your tips on keeping the project management of software as pain-free as possible for everyone?