---

Over the years, I've noticed that too many people in our industry assume that we're all talking the same language just because we're in a relatively small, close-knit profession. This is one of the greatest misconceptions in our industry-as well as in many other industries.

A number of years ago, I attended a three-day workshop entitled "Understanding Customer Requirements." The instructor asked each of us why we were attending. Without fail, each of us said it was because the title was "Understanding Customer Requirements" rather than "Gathering Customer Requirements." Each of us claimed to be perfectly capable of "gathering" information, but wanted better ways of "understanding" the information we had gathered.

In many aspects of our work, we need the best level of understanding that we can manage. Understanding requirements helps minimize project time and aggravation-and ultimately, minimizes the cost of the project. This is especially true in the up-front work, such as requirements gathering, and why I emphasize with customers how important it is to have the right people working on the project, because the quality of work at each stage of the project will affect the cost of the project. As we all know or should know, cost savings come significantly from using the right resources for the right tasks at the right time.

Have you ever worked with someone on a project who just didn't "get" what their task was really about? Some of you reading this are nodding your heads; you know how much time and energy that situation drains from you and your staff-when you're constantly returning work to certain people, explaining it over-and-over, reviewing it and rejecting it time-and-time-again. This situation may occur because you have the wrong resource or because you need to find still another way to explain things.

Let's review three key reasons that we don't achieve the maximum level of understanding possible.

Factor One: We Don't Listen
When a person is new to the industry, they sometimes come in with preconceived ideas, some of which are wrong. When a person has worked in the industry for a while, they come into projects with preconceived ideas based on past projects, some of which don't fit the current situation. All of this is natural and probably a good thing, as we need people to think about what's ahead to at least some extent.

This only becomes a problem when we regularly substitute this "knowledge" for the act of gathering information about the current situation. Listening to each other is the only way we can gather this information.

Let's acknowledge that "hearing" isn't the same as "listening." A person can hear your voice; they can write down what you say word-for-word; and they can possibly repeat it to you, but if they're not really paying attention, i.e., "listening," then it does no good to you. They're probably caught up in what they "know" you want, which may be different from what you are trying to tell them you want.

Factor Two: We Use Confusing Language
We become so accustomed to using certain words and phrases that mean something specific to us and our companies that we forget that these terms may mean something different to someone else.

For example, over the years, in my articles and presentations, as well as during our face-to-face discussions, I have focused on the issue of using the words "customization" and "configuration," and mounted something of a campaign to convince people to stop using those words altogether, when trying to determine how much work will be involved in an implementation. You can get a feeling for this just reading some industry periodicals, where some people define "configuration" as "pressing a few buttons" and others define it as "lots of programming, but not in C++." (Note: These are not direct quotes or they would have appropriate footnotes to cite their sources.)

In the cases above, "configuration" is an example of a word for which we don't seem to agree on the definition. Sometimes we aren't specific-enough in our request. Using a word such as "configuration" -- a word with different meanings to different companies in our industry - is not specific. Instead, it is better to describe what is needed in some detail.

Factor Three: We Don't Try to Understand
Here's a non-industry example: A group that I was working with was moving to a new building. The managers were allowed to state their preferences for office features. One particular manager told the facility people that he "just wanted an office with a window." He indicated that he didn't care about the size of the office, the direction the window faced or any other factor. He thought he was specific in his request and was assured that this was "no problem," and that he'd get what he'd asked for.

That was the "requirements gathering" part of the moving project, so to speak. Jumping ahead to the "implementation phase," we are now at the time the group is relocated to their new space. This particular manager went to his new office--which turned out to be inside a corridor, far away from the outside. He immediately called the facilities people to complain. Remember that he'd been told that this was "no problem," and that he'd get what he'd asked for. The people in facility management pointed out that that was exactly what happened.

What do you think occurred? If you guessed that "he got what he asked for but not what he wanted," then you would be correct. He did get an office with a window - a window into the hallway. If you surmised that he'd wanted a window that would allow him to see the seasons change and get a little sunlight, you'd have guessed correctly.

You could argue that he wasn't specific enough. After all, he could have asked for an "outside" window, but I suspect that most of you reading this story would have assumed that that's what he meant. If the facility management people had tried to understand what he wanted or asked him a few questions, they might have "gotten" it.

I could have given examples of projects I'd worked on, but the window "requirement" is one that most of us would have considered basic and easy-to-understand-and much more straightforward than the requests we hear on most of our projects. But even this simple request for a window still wasn't "implemented" as desired.

A Couple Of Examples
Too often in this industry, I hear the following:

• A software/services vendor says:
  The customer is going to pay a fortune for what I'm selling them, so I'm sure they must have really researched this before they came to me. I'm sure they understand all the issues. If I make a mistake in something I say or the customer doesn't understand what I've said, I'm sure they'll know to ask about it.


My comment:
Customers don't always spend the time or even have the time to research our products and services so that they know them as well as we do. That's what they're paying us for.


• A customer says:
  The software/services vendor I'm talking to deals with many companies like mine. I'm sure they understand that I don't know all about what they're selling and will explain it in a way that will make it perfectly clear to me.
  
  My comment:
  Every company is unique. Nobody outside your company can really understand what it's all about. After all, it's your money that's wasted when things go wrong and no one will look after your money the way that you will. Additionally, you will sometimes deal with a variety of people who work for a particular vendor, and each of them does not know what you've discussed with the others, nor do all these people have the same level of skill or authority in dealing with these situations.

Bottom Line
None of us is a mind reader. None of us "knows" what another person is thinking about, and that's a two-way problem. The more assumptions we make about who understands what and the less we attempt to understand each other, the less understanding we have and the more it costs end customers to get anything finished.

---

---