Understanding the customer - how well does the customer understand the problem

I think a true story will best illustrate the potential problem here.

When I was a self-employed consultant, I was hired to develop a PC-based Purchase Order tracking system for a small distributor close to my office. I worked with the manager of the group that handled the incoming purchase orders - and only that manager. I asked if I could talk to the people who reported to him and actually processed those purchase orders (in other words, the people who would be the actual users of the program), but he said that they were too busy to help define the requirements for the computer program and that talking to them was unnecessary because he understood the process in sufficient detail to define the requirements

After our discussion, I completed the specification, I reviewed it with the manager who then approved it and I developed the software to match what was written in the specification.

Then it became time to install the application and train the users. I trained the users individually (there were only three of them), but as I did so each of them made this comment: “This isn’t going to help us. It has nothing to do with how we handle purchase orders.”

Based on those comments, I called a meeting with the manager and the users and we found out that – basically – the manager had no idea what the people who reported to him actually did, at least not in any level of detail.

After talking to the actual users, I modified the specification so that it more closely matched the processes that they used. I then provided a quotation to the manager to make the necessary changes to match that spec. The manager acknowledged his mistakes, but he also did not have the authority to get additional funding. Or, more likely, if he asked his own manager for the money, he would have to admit his mistake. So, instead of authorizing me to make those changes, he said that he would get his users to use the program as I developed it. I don’t believe that they ever really used the program.

That is an extreme example, but it illustrates the point.

A more realistic example would be a customer requiring a web-based application, and knowing that they need to encrypt data as it is sent over the Internet, but not knowing whether Secure Socket Layer (SSL) – the most common methodology for encrypting data - is adequate for the customer’s needs. Some customers will understand SSL. Some won’t.

The most important things to learn from the customer are:

1. What is the problem that the computer system is intended to solve

2. What are the current processes (if any) currently used to address that problem.

In some cases the customer will think that they know the answers but don’t. If at all possible, talk to the users who actually implement whatever process is currently being used.

If the customer is ISO-9000 certified, they will have well documented processes. But even then you should review the processes with the users to insure that the processes are accurate. (I know that they are supposed to be accurate because that is what ISO-9000 is supposed to guarantee and the processes should be audited periodically. But some companies are more rigid about following the actual processes than others are. The users who do the work will know.)