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?

  • 2
    This has got to be better than the opposite, clients who know what they want but not what they need.
    – Craig
    Commented Nov 10, 2010 at 3:57
  • 2
    Do clients ever know what they want? Commented Nov 10, 2010 at 4:07
  • 8
    "The client doesn't know what he wants until you give him what he asked for"
    – Benjol
    Commented Nov 10, 2010 at 7:23
  • A long time ago, I started to fantasize about hiring requirements analysts from organized crime. "Are youse gonna tell me what happens when da client ain't in da database, or does I have ta get rough?" Commented Nov 10, 2010 at 17:08
  • Please follow this proposal for that kind of question: Organization aspects
    – Maniero
    Commented Dec 10, 2010 at 20:08

6 Answers 6


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.

  • 2
    Excellent list, especially point 1. A lot of customers will ask 'can you add a button here that does X'... but if you query further about why they want the button, you find out its because they are trying to solve some problem they have with a completely different feature. Commented Nov 10, 2010 at 4:50
  • 2
    A slight addition to the first point there- if they need a feature to facilitate some task, ask if you can watch how they do the task now. This can make it much easier to see what the real problem is and what potential pitfalls are.
    – glenatron
    Commented Nov 10, 2010 at 11:58
  • @glenatron: That's a very good idea, esp. since it's impossible for me to learn the entire system.
    – Michael K
    Commented Nov 10, 2010 at 13:05
  • @Gsto: On #2, are you talking about the programmer writing the request with the client's input, or the client writing it? One of the problems I have is that the client's written request is inaccurate.
    – Michael K
    Commented Nov 10, 2010 at 13:07
  • I often times make the customer or requester really prove that the feature or change is a need and will improve things. You may not have this luxury, but if you can get the client or requester to show you that they understand fully why they want the change and how it will benefit others, you may be able to offer an alternative to meet their need instead of their want.
    – Josaph
    Commented Nov 10, 2010 at 13:08

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.


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.

  • 1
    It's actually quite normal here, but it's something I would like to change at least for my projects. I think many of these requests could be turned around much more quickly - a simple one could take 3-4 (or more) weeks depending.
    – Michael K
    Commented Nov 10, 2010 at 13:11

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.

  • 1
    +1 for "First of all, you should accept the fact that clients don't really know what they're looking for until they see it.". And this is no bad thing. Some of the worst projects I've worked on are the ones where they spent for ever trying to work out what they wanted before they got developers involved. Believe it or not multiple iterations are often faster than massive upfront design. Commented Nov 10, 2010 at 12:22

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.