Reposted: How do know what the customer REALLY wants

[aspearin1]

I posted this in a different forum, but it dawned on me that IT implementation of new software systems probably suffer the most from this. What tips, tools, best practices are used to completely extract information from the customer to find out what the customer REALLY needs, despite what he/she may be saying.

http://eng-tips.com/viewthread.cfm?qid=207403&page=1

Aaron A. Spearin
ASQ CSSBB
Engineering Six-S'$

http://www.Engineering6ss.com

"The only constant in life is change." -Bruce Lee

 

[MikeHalloran]

While drawings and specifications are common/ expected/ understood in business and engineering, I've lost faith in formal methods for software development.

In particular, using specifications as a communication medium tends to result in an abysmal product, while absolving all the participants of any responsibility. This may be good for business survival, but only in the short term. Okay, in software, there may only _be_ a short term, but that's a different problem.

I think one core of the problem is that the people who end up writing specifications typically don't know squat about software, or hardware, or how they interact.

I think the best way to deal with the problem is to re-phrase the usual answer, as "The customer may not know exactly what he wants, but he very clearly knows what he doesn't want, when he sees it."

I'll give you an example. I bought a too- expensive DVD home theater, with a brand that is old enough to know better than to ship what I got. The firmware within the damn thing just _screams_ "formal development methodology". (I use the excessively polysallabic version of 'method' only as a pejorative.) Anyway, I just want to throw the thing out every time I watch a DVD, because after I'm finished with the DVD, I switch to another source to watch cable. At which time, the furshlugginer machine no longer responds to the 'eject' button.

I.e., the 'eject' button does absolutely nothing unless the machine is in 'DVD' mode. Is that stupid, or what?






Mike Halloran
Pembroke Pines, FL, USA

 

[IRstuff]

There are always two aspects of design, the formal requirements and the stakeholder requirements. Both are important, and neither can be ignored. While there are those that scoff at formal requirements, those are the ones that are often left in the dust and require massive redesign later, because the designers "know" what to do.

The opposite is also true, a formal requirement to install a low-profile 5" faucet 3" from the rim of the bowl is just plain stupid; you can't even get your hands into the water stream.

In order to do a righteous job of requirements development, you need to either actually use the equipment, or have sufficient imagination/experience to simulate in your mind's eye how the equipment will be used.

Some engineers never do that, they just want to start designing and can't stand to wait for the sum total of the design requirements.


TTFN

FAQ731-376

 

[berty1971]

We work with projects that vary from extreme over specification, to one we got just this week which was a verbal (on the phone), I don't want to bog you down with a formal spec i.e. No spec at all.

The only thing you can be sure of in every case, is that the Spec will have changed by the time the project is finished.


Bert

 

[SomptingGuy]

I find the most common problem is when a customer has a problem and his idea of the solution. Rather than explain the problem, he demands his solution be implemented, which usually involves adding inappropriate behaviour to existing features. So you end up with clunky software that just doesn't feel right, a never-ending legacy and no chance of the problem ever being solved sensibly.

The worst scenario is when it's a software sales guy that's your "customer" and sees a quick sale based on bodging something. I cringe when I hear a question that starts: "How long would it take you to ... ?"

- Steve

 

[CajunCenturion]

That is a very real problem in IT systems development because the customer usually doesn't understand what is and is not cost effective, and the development team doesn't understand the what customer's needs.

One of the most effective techniques that I've used is to spend some time with the customer as the customers goes about their daily tasks. Actually seeing what the customer is doing, with the occasional, "why did you do that?", or "why did you do it that way?" can be valuable in understanding what a customer needs based on what they say and do.


Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[richs]

Hiya-
I typically do business with "Statements of Work" (SOW).

This typically does not mean a formal specification however it can be constructed from a request for quote (RFQ) from the customer.

All behavior in the finished project should be included in the SOW. Indeed, interpretation and implimentation if required should be included in the SOW (usually for extra cost if I have to conform to their documentation/tools standard).

Modifications to the SOW can be made along the way, however, including a modifcation to a SOW does change the costing of the project. This should be included in the SOW itself.

Meeting the terms of the SOW (as opposed to the expectations of the customer) should also be spelled out and part of the SOW itself. This often gives customers pause, however, if the SOW has been fullfilled, then I would not have any hesitation to take the customer to court for nonpayment.

A complete and meaningfull SOW can go a long way to making the project a success and keep a satified customer.

Hope this helps.

Cheers,

Rich S.

 

[daveh55et]

+1 for what CajunCenturion said.

As mentioned one difficulty is that you need to be given the proper time to really understand what's trying to be done, especially if it is a legacy system.

Prototyping helps quite a bit, even if it's just pencil drawings on paper. Even better of course if if you can create the prototype in the same code/system as what the real working system will be.

IME, especially when dealing with changes to a legacy system, you are really doing well when you are able to change the business process and make it more efficient. User may not like it initially but they will warm to it once they see how much time they will save or how much easier it is to do something.

My personal opinion is that it's also good to try to eliminate or marginalize little used functions. The KISS (Keep I Super Simple) works to simplify the user interface, business process, writing the code and mainting it.

Rein in people who want gadgetry and fancy features. This kind of goes with the above but typically a project can get dragged off course trying to make bunnies hop skip and jump on their way to the hole and as a result the bunnies never make it in. Better to make then scamper in and be done with it so you can move on to other issues.

Practice decoupling as much as possible. Much better to put smaller pieces into play until you get a symphony then trying to do the whole thing at once. Typically you discover things about the process and subsequently need ot change requirements after you have started. This starts to get into development process itself, but if you can't go back and fix or add new requirements, then you system will not be as sucessful.

Note that is not deature creep, it is changes to the basic understanding of what is supposed to be done by the system.