Working with clients who don't know what they want

Question

I have recently started a job that has me working on an existing system. It requires tweaks and updates as well as new code. I have done several maintainance/feature adding projects now, and several of them have ended up being significantly different from what was actually requested. So, I had to program the item several times to get it to where the requester wanted.

Now, I don't mind reprogramming the feature if that's what needs to be done. However, I would like to decrease turnaround time on my projects. The bottleneck seems to be in the requester's perception of what needs to be done. Do you have any ideas on what I could do to figure out what the requester needs more quickly?

Answer 1

A few points of advice:

• Listen to problems, Not Solutions. A lot of clients like to tell you how to solve their problems. Don't listen to them. You're the programmer, and it is your job to find solutions to problems. Instead listen to what problems clients are having, and figure out the best way to solve it. As others have said, clients don't really know what they want; sometimes you have to show it to them first.

• Ask Questions. When you are done asking questions, ask some more. Clients are rarely forthcoming with details, as they don't really think about it. The only way you are going to get the information you need is to pry it out of them.

• Get Things in Writing. Depending on the situation with the client, this can be really important later when they start complaining about how what you delivered "isn't what they asked for". And if nothing else, writing out detailed specifications can help you make sure you have all of the information you need, and help clear up ambiguities between you and the client.

• Communication is key. Don't just talk to the client, get info, knock out some code and not talk to them until it's done. Always keep in touch with the client. Ask questions throughout the process. Show them the progress you've made and get feedback. It'll make everyone's life easier in the long run.

Answer 2

Pretty much any self-help book you pick up on communication is going to give you some variation of this:

• Seek first to understand, then to be understood

That comes from the 7 habits book, but they're all some variation of the "active listening" method. The goal is not just to understand, but to communicate back to them that you understood.

Once I think I have a good idea of what they need (stay away from what they want particularly if they start describing implementation details - that's your job not theirs), I give them examples of stories of various people using the system, and see if that jives with them.

Then I implement that, fully expecting that once they see the feature, they'll actually realize that's not exactly what they want. Keep everything flexible. The only constant is change. I usually get most of the rough edges worked out after the second quick update after the initial one, but I always find I'm asymptotically approaching some ideal that I can never reach. Eventually you need to let the unimportant things go and move on to higher value targets.

Answer 3

I feel your pain....

The bad news is: depending on exactly what kind of clients you're dealing with, this might be business as usual.

A common general problem is basically that clients don't know what they want. They usually know what they want to be achieved, in terms of a business goal, but they often have no idea how it should look in terms of the software solution. So in many cases you'll find yourself in this iterative cycle where a project bounces back and forth for five times as long as the initial estimate was, because the client keeps changing their mind and wants the solution tweaked and re-tweaked. And yes, it's not unusual for the final result to be morphed into something entirely different to what the initial goal looked like.

I had an epic example of this happen a couple of years ago - a project that initially took 10 weeks to code turned into a 15 month re-iteration grind. In that case, it was mainly because different managers and departments at the client company wanted different things, so they kept sending the work back, to be tweaked and re-tweaked (our software is subscription based and this was a major client, so this was no financial skin off our back - just a big technical annoyance really).

So basically my advice is this:

If this is the way your particular industry and these clients are (that's a big IF), then just get used to it. Think of it as being an Agile, maintenance-oriented job (this is how my current gig is, more or less). :)

If this isn't the way things are meant to be done, and you are catching blame for the long turnarounds, then speak up to your bosses. Explain to them that there are communication problems and that the specifications that are coming through to you from the clients are not clear enough for you to implement the desired solution. You don't want to find yourself in the situation where you're catching blame for not giving the clients what they want, if you're not getting all the required information to give them what they want.

Answer 4

First of all, you should accept the fact that clients don't really know what they're looking for until they see it. They might tell you right now that they need feature X. Show them feature X then they'll realize that what they really need is feature Y or another variation of feature X.

A good way to figure out what the customer really wants more quickly is by embracing and following the Agile Manifesto, which focuses on communication and customer collaboration. Divide the development cycle into iterations and show the client a prototype of the feature every end of the iteration. That way, you'll get immediate feedback and change it, according to the feedback from the client, without having to invest too much resource on the feature. That way, both you and the client will be happy with the outcome of the product.

I'm pretty sure the transition will be hard for your team or your company but it's one the best ways to cope with quickly changing requirements.

Answer 5

Lots, and lots of similar stories can be found here. I have never, even working as a subcontractor for another development company, found a client that knew exactly what they wanted.

I'm happy enough to work with someone who has a really good idea of what they DON'T want, or want to avoid. I can usually work from there to something that they are happy with.

My experience is mostly in application / platform development, though. Thankfully, I rarely have to deal with issues of aesthetics like web designers do.

Answer 6

After many annoying rewrites, I now operate what I call full disclosure.

So after discussing the customers requirements and desires, I will always write up what I perceive they want and how I will proceed to fulfil that requirement. I will then send them what I've written and wait until they reply in the affirmative before beginning work.

If its a large project (more than say 5 days work) I'll prototype as well. This gives them a chance to change their mind without massive code changes at my end.

It doesn't always work, but at least I am in a position where the client knows it is them changing their mind and not me implementing incorrectly.