It's not the client's job to know what he needs - It's our job to find out

"In software, we can't expect our clients to know what they need." - yes, but too many clients think they know and stipulate what they want - like prescription drugs in the US (and New Zealand).

"It is the our job to listen and ask pointed questions to determine need." - but a lot of business software isn't based on NEED, it's based on WANT. Agile helps there (XP, Scrumm, just-in-time design etc), but a lot of software isn't done that way.

"The client can't tell us what he wants. It our job to find out" - correct, so if someone hires a consultant to do analysis, and the results are not what they expected, they need to accept that there is a very good chance that their expectations were wrong in the first place.

And to be honest, it's been a long time since I've seen that. "hey, come in and look at this thing, and make the report match up with my thoughts on it (right or wrong) so I look good". Result: crap solutions.

Or maybe I'm just jaded :)

Good post. But I think the recurring challenge is that many clients think they know what they want by the time they bring in the software expert. Often the important decisions have already been made and the software expert is expected to simply implement them.

When flaws in some of the early decisions are inevitably found, the client may posture and issue ultimatums to the software expert to just "get it done."

This situation can then lead to a lot of incorrect assumptions, cut corners, and generally low quality output from the software expert.

Hence the jaded attitude you see from a lot of software devs that are doing primarily consulting work :)

"It is our job to listen and ask pointed questions to determine need."

Why do you think this? How many developers know what questions to ask - or what to do with a less-than-well-articulated answer? Not that this wouldn't be a good skill for a developer to HAVE, mind you; I've just met very few in my career who know how to do it.

@Mike,

Do you know how to do it? Would you be satisfied with yourself if you didn't know how to do it? I assume you have the skill given that you are discussing it. I acknowledge that there are software professionals without this skill, but the existence of them doesn't negate the need.

Software professionals need this skill.

This is part of what separates Consultant from mere Software Developer. The latter knows how to build something, the latter adds the capability to ask the proper questions so that which gets built is actually useful.

Problem is that in this business, we do a piss poor job of understanding the difference between the two skill sets.

I agree with Aaron. Often you see clients that hired too many software developers when all they really needed was one good consultant.

Unfortunately, pure consulting tends to get a bad rep because of the consultants that can't implement any of the great ideas they come up with because they don't have enough good software developers.

One solution, which Jeff is advocating, is to build a stronger consulting practice around software developers by helping them learn the consulting skills to be more effective when they take on projects.

One thing you may have looked over.... where the users in this story?

You are correct and I agree 100% that we, developers / designers, must be able to show the clients what they need and what they are looking for. But the recommendation and question must not come from the developers point of view. We need to get the actual users involved and come up with user stories. If the time and money do not allow you to contact users, hire a user experience professional or usability consultant who can direct the team to a right path to think like users.

Karthik.. i love this "Unfortunately, pure consulting tends to get a bad rep because of the consultants that can't implement any of the great ideas they come up with because they don't have enough good software developers.".. Maybe they don't have enough experience in the real world, many of them are talking in perfect world.

I don't agree and you are comparing apples to oranges when you give the analogy of the doctor and diagnosis - trust me cause I was a doctor once and now I am a developer - fairly good at both.

#1 A doctor has just one business which he should be familiar with - the business of human body - a developer on the other hand may be simultaneously dealing with hotel booking, car spare parts manufacturing and migrating birds - these are not some imaginary topics but real world things that I am working on.

#2 What follows from #1 is unless a developer is told what is that the users of software X are wanting or will be doing with the software development cannot proceed.

@TariqueSani,

I think one of the big points here is that the developer needs to get the "what" from the user, the broad strokes, but leave the "how to get there" decisons to themselves. I think it is a good analogy that many people go to the doctor with an expectation of a certain diagnosis and treatment, just as many businesses may have a certain way to accomplish a software task in mind when they consult a developer. The doctor or consultant *should* determine for themselves what the best solution is to achieve what the patient/user needs, rather than just go with whatever they think should be done. There are two domains in every software project - the business domain and the technological domain, and you the developer need to act as the domain expert for the technology (and how it's used) just as much as the business domain expert needs to do so for the business, if the end result is to be a success.

As a consultant, I am always walking the fine line among wishes, needs, expectations and the cruel realities of the mashup between business model and technology.

Over the years, I have developed a requirements methodology which attempts to extract the maximim amount of information from the limited attention span of my clients, short of using the yet-to-be-invented psionic interface.

The trick is to find out what they are really trying to accomplish. Most of the time, they do know their business, but can't describe it in the terms we are used to in the computer realm.

Also, most clients are not prepared to fork over the money it takes to do a proper requirements analysis.

I start with all new clients with an initial contract for specifications and preliminary design. The value of that contract is in the order of $250-$500, and takes 3-5 days. Once the terms are agreed, I pull out my list of 20 questions (actually about 100), and start the process. By this time the client is committed, and you have his undivided attention for about an hour, before corporate ADHD sets in. Within 3-5 days, they can expect a concise report which lays out the scope, schedule, and deliverables for the completed project.

I have had very few clients refuse to go on to the next level, and only one who didn't pay the consulting fee - he was later discovered trying to shop around using my requirements.

Part of the artform is devining the client's budget and whittling down his expectations until they fit within that budget.

I guess the point of this long-winded diatribe is to point out that application development is still an infant profession: part science, lots of art, and all mercenary. Unlike the medical profession, we don't have hundreds of years of diagnostic experience. Then again, we are unecumbered by a lot of voodoo practice that is hampering medicine today.