Management Skills:Gathering Information

Gathering Information

"What," you may ask, "is a section on gathering information doing in a book aimed at information systems people? After all, information is our raw material. 'Information' is our first name. We invented an entire technology to gather information. We don't need to be told how to do it."

Wrong. Our technology enables us to gather information about the content of a system, not what we need in order to manage building it. Despite our workshop facilitation procedures, data and process modeling tools, business reengineering practices, workflow analysis techniques, and all the other glories of our trade, we are no better, and frequently worse, than managers in any other discipline at acquiring and applying the information we need in order to manage our own projects and departments.

For you as project manager, your interest is not information about the application you are buildingthat is the responsibility of your team. Your interest is information about the team itself. How are they doing? What problems are they facing? Who is performing well and who is holding them back? To manage well, you need to know how to extract usable information about your people.

Information gathering can be reduced to two rules: Be ready, and be specific.

Be Ready

When two reasonably intelligent, cooperative people want to exchange information that both are capable of understanding, gathering information is simple: One person asks a question, and the other responds. Problems arise when either the person who has the information does not want to disclose it or the person receiving it does not want to hear it. For example, most team members do not want to tell you that they will be late, so when you ask, you are more likely to receive evasions than good information. Conversely, if your rosy view of the project's progress hinders your ability to hear about problems, you will make it difficult for team members to give you unpleasant truths.

In your role as a recipient of information, you must ensure that you are prepared to receive it, no matter what it is. Unwillingness to hear information is a form of denial, and denial is just as dangerous for a projector a corporationas for an addict. The best antidote is to be prepared for the worst. Do not expect itpessimism is a proven destroyer of enthusiasmbut do be prepared to hear it.

Not only must you be willing to receive information, you must also be able to hide your reaction. The harder it is for people to bring you bad news, the more they will leave you alone. Like the waiter who asks you how your meal is, then gets indignant at your honest but unflattering response, don't ask the question if you don't want to hear the answer. If you suspect that you are about to hear bad news, go neutral. Allow the person the freedom to speak without your feedback getting in the way. (See the discussion of neutral listening in "Listening.")

Be Specific

One of the barriers to communication is that language usage is subjective. You may know precisely what you mean by "userfriendly" (if you don't, you have no right to use the term), but you do not know what others mean by it, nor do others know what you mean until you have illustrated or defined it by being specific.

The best tool for getting specific comes from journalism: Who? What? Where? When? Why? Some of these questions may not be applicable to a given situation, but if you keep them in mind, you can select the ones that fit the occasion.

1. Who? You are not interested that "the users" insulted someone or "the analysts" never listen, you need to know who. Until you have a name, you do not have a complaint.

2. What? What, exactly, happened? Could you write a screenplay based on the information you've been given? If not, you do not know what happened, and you need to dig further.

3. Where? Location may or may not be important, but getting people to be clear about where something happened is one way to force clarity about the event itself.

4. When? When did this happen? If it is recent, it may indicate an emerging issue. If it happened six months ago, you are dealing with a grudge.

5. Why? Asking why something happened is an invitation to a comment like, "Because George is a jerk." However, if you do not have a reasonable understanding of why an event occurred, you probably have not dug deep enough.

These five questions allow you to zero in on the details of the issue and force those who are reporting it to be specific.

Being specific also means insisting upon neutral language. Colloquialisms and epithets, printable or otherwise, may be emotionally satisfying and a valuable release of tensions, but they do not convey usable information.

Being specific enables you to handle two frustrating problems: extracting information from tight-lipped types of the name-rankserial number school of communication, and making sense of the verbal geysers from those who believe that all details are critical and must be repeated at least three times. As long as you keep the five W questions in mind, differences in stylefrom the most reticent to the most effusivebecome little more than differences in background noise.

An Example

Consider the following exchange between a technical analyst and the project manager:

Technical Analyst:These users are bozos.

Project Manager: What do you mean?

TA:They don't understand their own application.

PM:They don't?

TA:Naw. They tell us one thing one day and another thing the next. We're always having to go back and change what we've done because they can't make up what they loosely call their minds.

PM: We can't have this. I'll talk to the client manager.

Of course, the response from the client manager will be something like, "It's your people who are the problem. If you had just one person who could remember the simplest thing from one day to the next, we wouldn't have to keep answering the same stupid questions."

The problem is that the project manager never forced the technical analyst to describe the situation in concrete terms that any reasonable passerby would understand. How should the conversation have gone?

Technical Analyst:These users are bozos.

Project Manager: What do you mean?

TA:They don't understand their own application.

PM: They don't?

TA:Naw. They tell us one thing one day and another thing the next. We're always having to go back and change what we've done because they can't make up what they loosely call their minds.

PM: Give me an example.

TA: I've got dozens of examples. The point is, they are jerking us around. The whole team is frustrated.

PM: I'd like an example where the users told you something and then changed their minds.

TA:They're always doing it. We can't depend on anything they say. You want an example? I'll give you an example. We submitted the data model two weeks ago and we still haven't got their comments back.

PM: That's frustrating, but it's not the problem you came in with. If they're telling you one thing and then changing their minds, we have a problem that I'll need to take up with the client manager. But I can't do that without some concrete examples. So give me some. When have they told you something and then changed their minds?

TA:OK. Last week, they told us to leave out the customer phone number from the input screen, so we did. This week, they reamed Fred out because the phone number is not on the screen. The same guy who last week insisted he didn't want it is now saying he uses it all the time and is calling Fred a klutz because it isn't there.

PM: They told you to leave out the phone number? That seems strange. Did you double-check to make sure that's what they meant?

TA:Of course. They said they never use it and they don't want to have to worry about maintaining it.

PM:Who is "they"?

TA: George. He's the key user from the billing department.

PM:Who else was there?

TA: Mary, from our team, and Ann and Will from the user side. Ann and Will both agreed with George about the phone number.

PM: And George is now saying that he needs it?

TA: Yes. And so are Ann and Will.

PM:OK. One more thing: George called Fred a klutz?

TA: Yeah.

PM:Did he actually use the word klutz?

TA:Well, not exactly, but he sure implied it.

PM:What, exactly, did he say?

TA:Well, I guess he said that any reasonable person would have known to include the phone number.

PM: Fine. Give me two or three more examples like that one.

The project manager now has a real casebased on events, not impressionsto take before the client manager. As a further bonus, the conversation will not include charges that the users called Fred names. Good information-gathering techniques help defuse the quick, angry response that you will have whenever anyone attacks members of your team.

There is one final point that the example illustrates. When you are trying to be specific about a problem, use the problem-giver's words to describe it. The project manager asked for an incident "where the users told you something and then changed their minds." You could have asked for an incident "where the users contradicted themselves," but such a rephrasing of the problem invites a response such as, "Oh, they do that too,'' with further unproductive expletives about contradictory users until the original complaint is overwhelmed by bile.

Good information-gathering techniques help you to understand what is really happening on your projects by extracting clarity from frustration, and descriptions from tirades.