Dr. Paul Dorsey

There are four basic steps in the CASE Methodology: Strategy, Analysis, Design, and Implementation. Within the Analysis phase, one of the most important initial steps is getting the necessary information from the client. If the information is incomplete, inaccurate or does not reflect the users' needs, the system to be implemented will be a failure. It is important to spend the time to gather this information completely and effectively.

The standard procedure for doing this is to interview the system users at the client site. This may sound like a straightforward and simple task; but it can be demonstrated that the methods used for getting and organizing the information can greatly affect the results. There are five aspects to this process which will be discussed in detail:

1) How the actual interviews are conducted.

2) Strategies for successful interviewing

3) Factors influencing the interview process

4) Structuring the information gathered

5) Writing up the interview reports

Each part of the process is important to ensure the overall success of the system design and implementation.

There are two usual approaches to client interviews:

1) Detailed questionnaires for users to fill out.

2) Open ended interviews.

The first approach is often not effective in getting accurate information about user needs. Questions may be ambiguous. Whole areas that need to be discussed may be left out. Answers to questions may be unclear, incomplete, etc. The interview approach can be effective if handled correctly.

The author did a doctoral dissertation on the topic of user interviews which sought to measure how much information was discussed. Hundreds of hours of video tape of actual interviews and contrived interviews conducted in laboratory settings were analyzed. Much has been written in the cognitive psychology body of research about the syntax of the questions asked in an interview and how this affects the information gathered. It was stipulated that questions must be open-ended in order not to bias the feedback. These studies concluded that careful attention must be paid to the exact words and syntax of the questions in order to get the most accurate answers. These conclusions were reached by looking at standardized exams, police interviews, psychiatric interviews and teacher/student interactions.

However, there is a substantive difference between the interactions in these settings and those in a systems development environment. The goal is to give and receive information. It is a cooperative relationship environment. There is no agenda for an adversarial relationship, or any attempt to coerce or trick the person being interviewed. Both the consultant and the person being interviewed are working towards a common goal. Therefore, the syntax of the questions asked is completely irrelevant in this setting.

The author precisely tested the amount of information transferred, the perceptions of the information transferred and the user satisfaction when the syntax of the questions was carefully controlled. Unlike the results perpetuated in the marketing literature, there was no appreciable difference between the questions regardless of syntax.

For example, the interviewer could ask:

Do you want a printer? (yes/no type of question)

How would you like to handle your printing needs? (complex, open ended)

Not only were complex questions no better at eliciting the desired information, but there was a statistically significant greater probability that the user would not understand the complex questions.

The issue then remained: If it was not the syntax that made a difference, what did matter in conducting a successful interview? The conclusion reached was that certain interviewer behaviors and strategies were the key factors.

It is critical to constantly keep in mind the nature of the analyst/user interaction and the purpose of the interview, namely to get the information necessary to build an effective system. This can be done in several ways through good questions/comments, productive feedback and a pre-existing structure for the information to be gathered.

The interview questions should be designed to open up topics for the user to talk about. The comment "Let's talk about printing," could elicit the same feedback as the yes/no or complex questions about printing. The nature of this interaction between analyst and user is a serial requirements communication. It is a half-duplex. The information can only go one way at a time. Someone must be giving information and someone must be receiving information. If both are trying to give information at the same time, then no one is listening. If both are trying to receive, no communication is taking place.

By looking carefully at this analyst/user interaction, another question emerged: How is it that good analysts are able to elicit as much as ten times as much information as inexperienced ones?*

*The most important factor that was observed from the hours of interview research tapes was that the interviewers who were most successful placed themselves in a "receive information mode" and stayed locked in it. Their primary goal was to listen, not give information. In order to do this, there were several key behaviors some of which are covered in the literature on active listening:

1) Asking good questions

2) Giving encouraging non-verbal feedback (i.e. note- taking, head nodding, "uh-huhs")

3) Letting the user say what he/she wanted to say without interruption until finished.

However, these behaviors do not go far enough. Good listening and "uh-huhs" do not communicate to an unhappy client that they have been heard and understood. The most successful interviewers repeated back what they had heard with statements like: "Let me see if I understand what you are saying" or "From what I've heard, this is what you are looking for." These interviewers were able to get as much as 20% more information from

the clients. There was a direct correlation between using these feedback interview strategies and getting more information. Finally, a key question that must always be asked is: "Is there anything else?" This makes the person being interviewed feel that the interviewer has heard and thought about what has been said and forces acknowledgment that the user has no more to say.

In reviewing the research video tapes, three levels of analysts emerged based upon their interviewing procedures:

1) Inexperienced - These interviewers took notes and did a lot of head nodding and saying "uh-huh" but only elicited a fraction of the potential information from the client.

2) Intermediate - These interviewers followed up on particular threads of information by asking some questions but let the conversation wander. If lucky, the appropriate information was elicited but it was disorganized which made it easy to miss important points.

3) Experienced - These analysts walked into the interviews with an "information template" (this will be discussed in greater detail in section 4) in their heads that allowed them to work through a systematic hierarchical structure of information retrieval. The user can provide a great deal of information but the information given will not be generated in a structured format.

For example, the skilled interviewer would already have identified 3 important areas (A, B, and C) that need to be discussed. He/she would begin by saying, "Tell me about A." From that prompt, topics A1, A2 and A3 would emerge. For each area, the interviewer leads the user through the information in a structured fashion. At some appropriate point, the interviewer reviews each point with the user. This helps to ensure that all the relevant information will be elicited.

There are several other factors that contribute to successful analysis interviews. The ultimate goal is to get the maximum amount of information about the client's existing system, desired changes, and new system aspects and features.

The question then arises, "Who should be interviewed?" It has been the author's experience that a single source of information should never be counted upon. Whether this single source is an individual or even a committee or group, all of the necessary information will not be elicited from one place. Interviews conducted with groups can be effective but the group itself has a dynamic of its own. Each individual in the committee should be interviewed individually as well.

The author has personal experience to back up the dangers of relying on a single source of information. At one client site, the analyst was matched with a systems person who was not well informed concerning the proposed project. Others who had valuable, much needed input were annoyed that they were not being consulted but were reluctant to come forward. By luck, the analyst determined which others in the organization should be interviewed. None of these individuals would have let the analyst know that the systems person was not a good source of information about the project.

The successful analyst should talk to a variety of users. Some very important sources include the architects or maintainers of the legacy system. They often know more about how the system actually functions in their specific business environment than the systems people. A strong report audit of the legacy system should be an early step in any effective analysis. Systems people, managers and rank and file users may also have valuable input.

Another important issue in conducting successful interviews was that of power. In a typical interview situation (job, police, teacher/student), there is a clear delineation of who is in the position of power. This is not the case in an analyst/user relationship. The optimal arrangement is a relative parity in power positions between the interviewer and the user. In general, the user needs to feel comfortable enough to talk about what needs to be discussed. If a user is insecure, it is the job of the interviewer to put them at ease. Ways that this can be accomplished include conducting the interview on the user's turf (i.e. their office), and using non-verbal cues. These non-verbal cues may include note taking, head nodding, body position, voice volume, etc. These cues can be used to manipulate the power structure of the situation to suit the needs of the interviewer. There are several ways to do this.

For example, if the user isn't letting the interviewer get a word in edgewise, the interviewer can take control by standing and walking to the white board or using paper and drawing or reviewing what has been discussed. This is the highest power situation since all attention will be focused on the person at the board. At that point, the interviewer owns the situation and is in control. Less severe measures include controlling the volume of talk. The interviewer can remain in an information receiving mode but flip the talk back and forth. If done correctly, this can make for a very effective interview. Also, body positions can influence the power balance. If the interviewer is sitting in a relaxed pose, this is a higher power stance and tends to put the user in a weaker position.

In the opposite situation where the user is reluctant to talk, it is up to the interviewer to give the user more power. This can be done with body language, i.e. the interviewer sits up in an attentive pose waiting to receive information. Gentle cues ("Tell me about....") and questions can draw the reticent user out to extract the necessary information.

A peripheral issue to that of power in analyst/user interviews is that of gender. Because of deeply rooted social norms and perceptions within society, the gender of the interviewer and user may play a role in the success of the interaction. The interviewer simply needs to be aware of this and make slight adjustments to the power shifts of the interaction. If a male interviewer is dealing with a female user accustomed to male boss/female employee situations, he may want to give the user more power in order to facilitate better transfer of information. Conversely, a female interviewer with a male user accustomed to being in control may want to use more power increasing strategies in her interviewing style.

Even if a skilled interviewer is able to elicit a great deal of information, without some type of format or structure, the value of the information is greatly diminished. A skilled analyst organizes his/her questions into related topics.

These structurally related questions typically start with a structural identifier. The interviewer introduces topic A, then provides contextual structural cues relating to the question in order to reduce the probability of misunderstanding the question. In this fashion, sub-topics A.1, A.2, etc. can be covered in depth. The interviewer builds a tree of information with 3 types of questions:

1) Validation questions: "Is this what you are saying?" "Have I got this right?"

2) Horizontal questions: "You've told me about A1 and A2. Is there an A3? Are there other areas about A that we need to discuss?"

3) Vertical questions: "Tell me about A.1. Is A.1 important? How should we handle things associated with A.1?"

The skilled analyst is able to organize the information as it is being gathered into a structural hierarchy of information. He/she begins with a list of questions and moves both horizontally and vertically through the topics. The responses can be organized into a tree structure where the topic (A) is the "parent". Each parent topic spawns "children" (A1, A2, A3). These children are "siblings" and follow a horizontal format. Each child can ten be further broken down into more layers of subtopics in a vertical format (A1.1 A1.2, etc.) Each horizontal and vertical topic is explored until a termination point is reached on every set of siblings in the tree. This point is reached when the answer to the question "Is there anything else?" is "no." In writing up this information, horizontal and vertical lines can be drawn at the appropriate termination points to indicate that this topic has been exhausted.

The most successful interviewers demonstrated feedback behaviors to reinforce and enhance this hierarchical structure. By identifying the context of the discussion, asking the three types of questions described above, the syntax and precise formulation of the questions themselves becomes irrelevant.

It is now important to return to the issue of the analyst's own internal "information template." This was found to be one of the biggest differences between a great systems person and an inexperienced one. There is a large body of research on schema theory suggesting that learning and comprehension of new information is strongly affected by whatever pre-existing schema exists in the learner. This can work both ways in an analyst/client interview. The experienced analyst brings a whole range of information about systems development and business applications to the interview. At his/her disposal will be many detailed questions about various types of systems that will help shape the structure of the interview and get at the desired information. From the client's perspective, they bring knowledge about their business and what they want the new system to be able to do. Also, they may have some expectations about what the interviewer will ask. If there is a conflict between the existing schema of the analyst and the user, it will be difficult to get the appropriate information.

At the highest subject level, the analyst's internal template (schema) might be the following: "If I'm going to build a system, what are the hardware and software requirements?" For an inexperienced analyst, this might be the whole template. A better, more experienced analyst would have a much more extensive, complete and detailed set of questions to ask.

For example, to get at the system requirements for performance, a good analyst would know to ask the following questions: Will modems be used? Will there be remote sites? Will the data need to be distributed to a database environment? What is the time requirement with each transaction type? How fast does the information need to be processed? - sub-seconds, quarter seconds, overnight?

The more complex pre-built structural template the analyst brings to the interview, the more likely he/she is to get all the necessary information to create a system that successfully meets the users' needs.

After all the interviews are completed, the analyst needs to give the client some kind of report. At one end of the spectrum of possible reports is a simple review of the notes taken during the interviews in narrative form. At the other end, the analyst can map the interview into a CASE functional hierarchy tool. The best solution may be a compromise between the two. The notes can be written up and a structured document can be generated using Word for Windows to put the information into a hierarchy. If desired, this Word document can be loaded into the CASE tool functional hierarchy using a C program.

Once the report is generated, a copy should go to each user interviewed for a sign-off. This sign off is the ultimate feedback since this will be the information that goes into the system being developed.

To summarize, the most successful interviewers were able to do four important things:

• Go into the interview with an internal template of topics and questions relevant to the specific business situation.

• Ask the kinds of questions designed to elicit the maximum amount information in a structured format.

• Listen actively and effectively, providing useful verbal and non-verbal feedback.

• Provide a hierarchical structure within which the information can be elicited and organized.

When all these elements are in place, the information gathered from the interviews provides a solid base from which to start the system development. This will go a long way towards ensuring that the client is entirely satisfied with the finished product. In addition, carefully documented and reported user interviews can be invaluable in determining the source of potential problems with the finished product and ways to solve them.