It’s not the client’s job to know what he needs – It’s our job to find out

While I was at Tech Ed 2008, I was a guest on a Software Quality panel hosted by the .Net Rocks crew, Carl Franklin and Richard Campbell. David Platt said something that I really love (and I’ll paraphrase). David gave the analogy of a doctor and a patient.

We go to a doctor because we think we have a medical need and we need an expert to consult with and a provide a solution to what is ailing us. The doctor listens and asks questions by which to formulate some possible solutions to the problem we present. The doctor doesn’t expect us to even be able to talk in the language of medicine.

In software, we can’t expect our clients to know what they need. Much like the depth of a patient may be “I need to get rid of this infection” or “Give me some pills. I’m in pain”. Our clients know what is causing them pain, in the business sense, so the problem is from that experience perspective. Some clients might go so far as to ask for some “pills”, that is, they might ask for a specific software system that is assumed to solve the problem.

It is the our job to listen and ask pointed questions to determine need. Being software experts, we must also know how to ask the right questions to flesh out the need. If the clients asks for something specifically, and we deliver, but that delivery doesn’t solve the pain, it’s our fault. If I ask my doctor for a specific pill, he prescribes it, then I’m still in pain, it’s the doctor’s fault for allowing me to drive diagnosis. We, as software professionals, are on the hook for responsible analysis that ensures any solution we provide adequately addresses the root of the problem at hand.

The client can’t tell us what he wants. It our job to find out. A required skill of any consultant at Headspring is analysis. Analysis is something underrated, but analysis ensures we build the right thing. The risk of building the wrong thing is so great that we can not afford it. Building (prescribing) the wrong thing would be disaster for our reputation. Analysis is what ensures we build the right thing.

dar7yl 6:00 pm on July 15, 2008

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.

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

It’s not the client’s job to know what he needs – It’s our job to find out

Related

Related

Discover more from Programming with Palermo