E.1 INTRODUCTION

This appendix discusses a number of guidelines for the interviews that you will carry out during the systems analysis phase of a development project. You are likely to interviews users, managers, auditors, programmers who maintain existing computer systems, and a variety of others. Why do we conduct interviews during systems analysis? The reasons are these:

1. We need to gather information about the behavior of a current system or the requirements of a new system from people who have this information stored somewhere in their heads.
2. We need to verify our own understanding, as systems analysts, of the behavior of a current system or the requirements of a new system. This understanding was probably acquired through previous interviews, together with independently gathered information.
3. We need to gather information about the current system and/or systems in order to carry out cost-benefit studies (see Appendix C for more information in this area).

This appendix covers the following topics about the interviewing process:

• Types of interviews
• Fundamental interviewing problems to worry about
• General guidelines for conducting interviews

E.2 TYPES OF INTERVIEWS

The most common form of an interview is a live, face to face meeting between you (perhaps accompanied by one or more fellow analysts on the same projects) and one or more subjects (interviewees). Typically, notes will be taken with pencil and paper by one of the interviewers; less commonly, the interview will be recorded on a tape recorder, or a secretary will take formal notes at the interview. Throughout this appendix, I will assume that your interview is of this general nature, but I will not make any assumptions about tape recorders or stenographers.

You should realize that the kind of information captured in an interview might also be obtained by other means, for example, by asking the subject(s) to respond to a formal, written questionnaire, or by asking the subject(s) to write a position paper describing the requirements of their new system. It’s also possible that the interviews could be augmented by the presence of various specialists (who might even conduct the interview while the systems analyst plays a passive role), such as industry experts, behavioral psychologists, and union negotiators. And, finally, you should keep in mind that another data-capturing media (e.g., video camera) might be used to record the content of an interview.

Beginning in the 1980s, one specialized form of interviewing has become popular in some IS/IT organizations; it is known as JAD (for Joint Application Development) or accelerated design, or team analysis, and by various other terms. It consists of an accelerated interviewing and data-gathering process in which all the key users and systems analysis personnel are gathered together for a single, intensive meeting (which may last from one day to a week) to document user requirements. The meeting is usually supervised by a trained specialist who acts as a facilitator to encourage better communication between the systems analysts and the users. For more details, see Joint Application Development, by Jane Wood and Denise Silver (New York: John Wiley & Sons, 1995).

While all these variations have indeed been used, they are relatively rare and will not be discussed further in this appendix. The most common interview is still the one-on-one meeting between a systems analyst and an end user.

E.3 FUNDAMENTAL PROBLEMS TO WORRY ABOUT

At first glance, it might seem that the process of interviewing a user is a simple, straightforward affair. After all, you’re an intelligent, articulate person; and the user is an intelligent, articulate person. You’re both rational people and you both want to accomplish the same thing: transfer information about a proposed new system from the user’s mind to your mind. What’s the problem?

In fact, there are lots of problems that can occur. In many high-tech projects, it has been observed that the most difficult problems do not involve hardware or even software, but rather “peopleware.” The peopleware issues in systems analysis are often seen best in the interview situation: it is the interview where “the tire meets the road” between user and systems analyst. The most common problems that you must watch out for are these:

• Interviewing the wrong people at the wrong time. It’s very easy, because of organizational problems and politics, to find yourself talking to the person who is the official expert on user policy, who turns out not to know anything at all about the true requirements of the system; it is also possible to miss the opportunity of talking to the unknown user who really does know what the requirements are. Even if you find the right person, you find yourself attempting to conduct an interview during a period when the user is unavailable or thoroughly swamped with other pressures and emergencies.
• Asking the wrong questions and getting the wrong answers. Systems analysis is, as Tom DeMarco likes to point out, a form of communication between aliens. Users and systems analysts have a different vocabulary, a different experience base, and often a different set of assumptions, perceptions, values, and priorities. Thus, it’s easy for you to ask the user a reasonable question about the requirements of his or her system and for the user to completely misunderstand your question, without either of you being aware of the fact. And it’s easy for the user to give you some information about his or her requirements and for you to misunderstand that information, again without either of you being aware of the fact. The modeling tools presented earlier in this book are an attempt to provide a common, unambiguous language in order to minimize these misunderstandings. But interviews take place largely in a common spoken language (English, Spanish, French, etc.), so the problem is a real one. This is why it is so important to schedule follow-up interviews to verify that both parties have understood both the questions and the answers.
• Creating bad feelings between both parties. As we will see in Section E.6, there are a number of reasons why a user might feel uncomfortable or even antagonistic about an interview with a systems analyst (e.g., because he feels that the whole purpose of the new system that the analyst is specifying is to take away his job). And the analyst may feel resentful about the way that the user is answering her questions (e.g., she may feel that the user is insulting her by suggesting that she is too young and inexperienced to offer any suggestions about the requirements for the new system). In either case, bad feelings can arise between the two parties, making communication that much more difficult.

There is no magic way of guaranteeing that these problems will not occur; they are the result of person-to-person interactions, and each such interaction is unique. However, the suggestions given next can help reduce the chances of these problems; other than that, you must depend on practice to get better and better with each succeeding interview.

E.4 GUIDELINES FOR CONDUCTING INTERVIEWS

The following guidelines can be helpful in conducting a successful interview with your user.

E.4.1 Develop an Overall Interview Plan

Before you get started, it’s extremely important that you find out who you need to interview. Otherwise, you’ll waste everyone’s time, and create an enormous political backlash, by talking to the wrong people about the wrong things.

This will require that you obtain an organization chart showing the various people in the user organization, as well as their reporting hierarchy. If a formal organization chart has not been published, find someone who knows how the organization works and ask for help. If an organization chart does exist, make sure that it is accurate and up to date; organizations often change far more frequently than the annual publishing cycle in which the charts are produced!

Even knowing the organization chart doesn’t necessarily tell you who you need to talk to; sometimes the most knowledgeable person about some aspect of a system will be an administrative or clerical person not even shown on the organization chart. As discussed in Chapter 3, there are often three levels of users in a large, complex organization — the real user, the operational supervisory user, and the executive supervisory user — and it’s often important to talk with all three levels.

It’s also important in many cases to talk to users in the proper sequence and in the right combination. That is, you may find yourself interviewing Martha, who says, “Well, of course, I get all of my input data from George; he can tell you what it looks like. And then I do the following ...” In such a case, it is often helpful to talk with George first, then Martha. Or you may find yourself interviewing Frank, who says, “Well, actually, Susan and I work on this function together; she does part of it and I do the rest ...” In this case, it would obviously be more productive to interview Susan and Frank together. Sometimes you can tell which users need to be interviewed in what sequence just from your general knowledge of the organization; sometimes the users themselves will tell you once they know you're going to be interviewing them.

E.4.2 Make Sure You Have Approval to Talk with the Users

In some informal organizations, there will be no restriction on your choice of which users to talk with or when the interviews should be scheduled. But in a large organization, this is unusual; it’s politically dangerous to wander around the user organization conducting interviews without some advance approval. In most cases, this approval will come either from the manager of a user area (a department or division or group) or it will come from a designated user representative who is attached to the systems development project. In any case, the users have legitimate reasons for wanting to approve, in advance, who you interview:

• They may feel that some users are not able to understand or articulate system requirements well.
• They may be worried that some of their operational-level users are “renegades” who will articulate false requirements (or, in any case, requirements that management doesn’t approve of).
• They may be very worried that the interviews will interfere with normal work assignments that the users need to carry out. Thus, they will want to schedule the interviews at an appropriate time.
• They may be worried that the interviews will be perceived as the beginning of an effort to replace the human users with a computerized system, causing layoffs, and the like.
• They may feel that they themselves (the managers) know far more about the requirements of the system than anyone else. Thus, they may not want you to talk with any users at the operational level.
• There may be an ongoing political battle, at a much higher management level, between the user organization and your systems development organization. Thus, the user manager may not have any real objections to your interviews, but by preventing such interviews from taking place, he may be able to send a political message to your boss’s boss’s boss.

For all these reasons, it’s a good idea to get approval in advance. In most cases, verbal approval is sufficient; if the organization is terribly bureaucratic or paranoid, you may even need to get it in writing. This also means, by the way, that you should be aware of and sensitive to the organizational politics if you feel strongly that you need to talk with a user (typically an operational-level user) that you have been told not to talk to. You may want to schedule some clandestine meetings off site, but it’s usually safer to pass the request up through the chain of command in your department so that it can be passed down the chain of command in the user organization. [1]

E.4.3 Plan the Interview to Make Effective Use of Time

The main point of this suggestion is that you should realize that you’re taking up the user’s time and that he (or his boss) may even feel that you’re wasting his time. Thus, it’s important that you do as much advanced planning and preparation as possible so that you can make effective use of the interview.

The first thing to do is make sure that the user knows the subject of the interview. In some cases, this can be done by phone or e-mail; in other cases, it might be appropriate to write a list of questions that you’re going to ask, or topics that you’re going to cover, or DFDs that you want to review, and send it to the user a day or two in advance. If you’re not able to do this, it’s an indication that you really aren’t prepared for the interview. And if the user hasn’t read the material you’ve sent, it means either that he’s (1) too busy, (2) uninterested, (3) feeling hostile about the whole concept of the interview, or (4) unable to understand the questions that you’ve raised.

A related point: gather as much relevant data in advance of the interview as possible. If there are forms or reports that are pertinent to the discussion, you can generally obtain them in advance. If there are other written user documents describing the new system or the old system, make sure that you have gotten them and studied them before the interview.

If you have prepared your questions in advance, you should be able to keep the interview to an hour or less. This is important; not only is the user generally unable to spare more than an hour or so at a time, but also (as I pointed out in Appendix D, too) people generally can’t focus and concentrate intently (especially if they are looking at somewhat unfamiliar diagrams) for more than about an hour. This means, of course, that you must arrange the interview to cover a relatively limited scope, concentrating typically on a small part of the system. It may also mean that you have to schedule several interviews with the same user to completely cover the area that she or he is involved in.

Finally, schedule a follow-up meeting to review the material that you have gathered. Generally, you will want to retreat to your desk with all the information that you have gathered from the interview, put on your “analyst’s hat,” and do a lot of work with the raw data. There may be DFDs to be drawn or data dictionary entries to be created; cost-benefit calculations may need to be done; the information from your interview may need to be correlated with data from other interviews, and so on. In any case, the data from that interview will be massaged, documented, analyzed, and transformed into a form other than what the user may have ever seen before. Thus, you need to schedule a follow-up interview to verify (1) that you did not make any mistakes in your understanding of what the user told you, (2) that the user hasn’t changed his or her mind in the interim, [2] and (3) that the user understands the notation or graphical representation of that information.

E.4.4 Use Automated Tools as Appropriate, But Don’t Overdo It

During the interview, you may find it convenient to use prototyping tools, especially if the purpose of the interview is to discuss the user’s view of the human-computer interface. Similarly, if you are reviewing a dataflow diagram and discussing possible changes, you may find it convenient to use one of the CASE tools discussed in Appendix A.

Remember, though, that the purpose of such tools is to facilitate discussions, not to hinder them; it should allow you and the user to explore alternative and changes quickly and easily; it may help you record your understanding of a user requirement on the spot and immediately correct any errors that you have made.

If, however, the technology gets in the way, then it should be kept out of the interview. If the user is required to venture far away from his or her normal work environment (e.g., to another building, into the computer room), the user may view the tool as a nuisance. If the user is unfamiliar with computer technology and is asked to use the tool, he or she may reject it. And if you are unfamiliar with the tool, (or if the tool is slow, error prone, or limited in its use) then it will interfere greatly with the interview. In any of these cases, it’s probably best to use the tool off-line after the interview has taken place; you can then show the user the output from the tool without causing any unnecessary problems.

E.4.5 Try to Judge What Information the User is Most Interested in

If you have to develop a complete system model for some portion of a system, you will eventually need to determine inputs, outputs, functions, time-dependent characteristics, and stored memory of the system. But the order in which you obtain this information usually doesn’t matter all that much, or, at least, it probably won’t matter that much to you.

But it may matter a lot to the user, and you should let him start wherever he wants in the interview. Some users will want to start with the outputs, that is, reports or data values that they want the system to produce (indeed, they may not even know what inputs will be required in order to produce those desired outputs). Other users may be more interested in inputs or in the details of a functional transformation. Still others will want to talk about the details of data in a data store. Whatever it is, do your best to see the system requirements from their perspective, and keep that perspective in mind when you ask them the questions required of your interview.

E.4.6 Use an Appropriate Interviewing Style

As William Davis points out,

Your attitude toward the interview is important in determining its success or failure. An interview is not a contest. Avoid attacks; avoid excessive use of technical jargon; conduct an interview, not a “snow job.” Talk to people, not up to them, down to them, or at them. An interview is not a trial. Do ask probing questions, but don’t cross-examine. Remember that the interviewee is the expert, and that you are the one looking for answers. Finally, whatever you do, avoid attacking the other person’s credibility. Don't say, “So and so told me something different,” or “You don’t know what you’re talking about.” [3]

Asking probing questions is not always easy; depending on the personality of the interviewee and the subject matter of the interview, you may need a variety of styles for drawing out the necessary information. Here are some styles that can prove helpful:

• Relationships: Ask the user to explain the relationship between the item being discussed and other parts of the system. If the user is discussing an object (e.g., a customer), ask him to explain its relationship with other objects; if he is describing a function (i.e., a bubble in the DFD), ask him to explain its relationship with other functions. This will not only help you discover more about the item being discussed, but will also help you discover interfaces (e.g., dataflows from one bubble to another in the DFD) and formal relationships.
• Alternative viewpoints: Ask the user to describe the viewpoint of other users about the item being discussed. For example, ask the user what her boss thinks about a bubble in the DFD, or an object type in the ERD; or ask what her subordinates think.
• Probing: Ask the user for an informal, narrative description of the item you’re interested in. “Tell me about the way you calculate shipping charges.” Or, if you’re talking to the user about an object type in the ERD, you might say, “Tell me about a customer. What things do you know (or need to know) about a customer?”
• Dependencies: Ask the user if the item being discussed depends for its existence on anything else. This is particularly useful when discussing potential object types and relationships in the ERD. In an order entry system, for example, you might ask the user whether it is possible to have an order (if that’s the item you’re currently discussing) without having a customer.
• Playing it back: Tell the user what you think you heard him say; use your own words instead of his and ask for confirmation. Thus, you might say, “Let me see if I understand what you just said: whenever a widget comes into the system, you always have to frogulate it and send a status message to the auditing department.”

E.5 POSSIBLE FORMS OF RESISTANCE IN THE INTERVIEW

As mentioned earlier, you should be prepared for the fact that some users will be opposed to the very idea of an interview; this is one of the reasons for ensuring that their manager or someone in authority in their department is aware of and has sanctioned the interview. Some of the more common objections (and some possible answers to those objections) are listed next.

• You’re taking up too much of my time. The answer to this is to tell the user that you’re sympathetic, and apologize for the time you need to take, but that you’ve done as much advance preparation as possible and will keep the interview as short as possible. This requires, of course, that you arrive punctually for the beginning of the interview, keep the discussion on target, and finish the interview when you said you would.
• You’re threatening my job. This is often a very emotional reaction, and it may or may not be well-founded. While you may be able to think of a number of replies to this comment, you must remember that you are not the manager of this person and that you are in no position to reassure him that his job is not in danger, or warn him that it is. You can try to disclaim responsibility by saying, “I have nothing to do with this; I’m merely documenting system requirements at the direction of management,” but the user in your interview won’t buy that. He will view you as the “efficiency expert” whose job is to advise management on how his job can be eliminated by computerization. The solution to this problem, if you run into it, is to let higher levels of user management know about it and get their official comment, either in person or in writing if at all possible.
• You don’t know our business, so how can you tell us what the new system should look like? The answer to this question is, “You’re right! That’s why I’m interviewing you to find out what you feel the requirements should be!” On the other hand, if you’re a clever analyst, you’ll probably suggest various ways of “improving” things (particularly if part or all of the work done by the user now is a manifestation of an old, inefficient implementation of a system); so this kind of comment may be unavoidable. However, the real trick is to continue to be as deferential as possible and to constantly acknowledge the user’s expertise in his own area, while continuing to ask him if he would be so kind as to explain to you (and thereby help educate you) why your idea won’t work.
• You’re trying to change the way we do things around here. A variation of the above comment. The trick here is to show the user that while you may be proposing some (radical) changes in the implementation of their current system, you’re not trying to change the essential features of that system, except in the areas where they themselves have asked for a change. Keep in mind, though, that some of the implementation features of the current system may have to be preserved, because the current system interfaces with other external systems that require inputs or outputs to take prescribed forms.
• We don’t want this system — our current system works just fine. This is a variation of the “you’re putting me out of a job” complaint. The real answer is that you’re there, conducting the interview, because user management wants the new system. It’s not your place to convince the operational user that they should want the system (no matter how wonderful you may think it is); to do that is to put the burden of responsibility on your shoulders, where it does not belong.
• Why are you wasting our time with this interview? “We know what we want, and if you were competent, you would understand immediately what we want. Why don’t you get on with it, and just build the system?” This is a difficult complaint to deal with, because it has to do with the basic fact that users and systems analysts are speaking different, alien languages; if the user doesn’t recognize this fact, he’s in for a lot of trouble. One possible solution is to draw an analogy: ask the user if he would let an architect begin building a house for the user without detailed discussions and blueprints, followed by close communication all during the construction. Ask the user if he would be willing to say to the architect, “Build me a nice three-bedroom house. You know what I mean, right?” However, keep in mind that with the widespread availability of 4GLs and personal computers, the user may feel that he can build the system himself; easy successes with simple projects (e.g., spreadsheets) may have given him the impression that all systems are easy to implement. This may explain his impatience with you.

E.6 OTHER PROBLEMS TO WATCH OUT FOR

The guidelines above have warned you of the many political problems you may face in an interview and the many reasons why a user may be resistant to an interview. But there are a few more problems that you should anticipate:

• A discussion that focuses more on implementation issues than requirement issues. This will often happen when the user says, “This is how I would like you to build the system ...” It happens quite often when the user is thinking in terms of the implementation of his current system; and it can happen if the user is somewhat familiar with computer technology (e.g., if he has his own PC or is an ex-programmer himself). Remember that it is not your job in an analysis interview to describe implementation features of the system unless they are so important that they truly belong in the user implementation model that we discussed in Chapter 21.
• Confusion between symptoms and problems. This is a problem in many fields, not just the computer field. Imagine a patient who is talking to a doctor and who says, “Doctor, my problem is that my face really feels hot. Can you solve that problem for me?” Presumably, this is a symptom, a fever of some sort, that is indicative of some kind of medical problem. The trick is to realize that it is a symptom and not the real problem, and then to find the real problem. The same happens over and over again in systems analysis interviews. However, much of it depends on where the boundary is drawn in the context diagram: whether the user’s complaint is a symptom or a problem depends on whether it is associated with something inside the system boundary or outside. Thus, you must pay special attention to the development of the environmental model; this is discussed in detail in Chapter 18.
• The user may be unable to say what she wants the system to do or she may change her mind. This is a common problem, and the systems analyst must be prepared for it. The more extreme this problem is, the more important prototyping becomes. For more about prototyping, see Chapter 5.
• Disagreement between user peers, subordinates, and managers. Unfortunately, this puts the systems analyst into the role of negotiator between various disagreeing parties. As an analyst, you can’t abdicate this role; you can’t say, “When you guys figure out what you want and agree with each other, come back and tell me.” Instead, you must act like a labor negotiator and bring all the concerned parties into a room and work with them to arrive at a consensus. Unfortunately, this involves skills and procedures beyond the scope of this book.

E.7 ALTERNATIVE FORMS OF DATA GATHERING

Interviews are not the only way to gather information about the requirements for a system. Indeed, the more information you can gather from other sources, the more productive your live interviews are likely to be. Among the alternatives to interviews are these:

• Questionnaires: You can send written questionnaires to users inside your organization, to the people (or organizations) who interact with the system, to managers who sanctioned the project, and others. Remember, though, that users who are too busy to be interviewed are also likely to be too busy to fill out a questionnaire, especially if it’s several pages long.
• Vendor presentations: Computer hardware vendors and software vendors may have already developed turnkey systems for the application you are interested in. Asking them to make a presentation of the features of their system may not only help you determine whether theirs is a good solution, but also point out functions and stored data requirements that you would otherwise have missed.
• Visits to other installations: Look for organizations that are in the same line of business or who have systems similar to the one you are working on. Arrange to visit the installation to get first-hand information on the features and capabilities of the system.
• Data collection: Look for forms, reports, manuals, written procedures, records, CRT displays, and program listings that already exist in the user organization. However, keep in mind that these are typically associated with the current implementation of the system; as discussed in Chapter 18, this will usually include redundant and/or contradictory and/or obsolete information. Nevertheless, it’s often a good starting point in order to familiarize yourself with the terrain before conducting face to face interviews with the user.
• External research: If you are building a system for a new application, one for which the user does not have any hands-on experience for describing her or his requirements, then you may have to look for information from professional societies (e.g., the ACM or IEEE), or from technical journals, textbooks, and research reports.

E.8 SUMMARY

The communication skills, diplomacy, and other human issues involved in interviewing are not easily communicated in a book. It’s something you have to learn by doing or by observing: as a junior systems analyst, it’s a good idea to tag along with a veteran to watch a few interviews being conducted. Also, get feedback: ask your boss to find out how the users think you’re doing with your interviews. And provide feedback to the users: tell them what will happen with the results of your interview, so they don’t think the whole thing was a waste of time.

REFERENCES

1. Abraham Maslow, Motivation and Personality. New York: Harper & Row, 1954.
2. Charles J. Stewart and Cash Stewart, Interviewing Principles and Practices, 2nd ed. Dubuque, Iowa: William C. Brown, 1978.
3. William S. Davis, Systems Analysis and Design: A Structured Approach. Reading, Mass.: Addison-Wesley, 1983.
4. Jane Wood and Denise Silver, Joint Application Development. New York: John Wiley & Sons, 1995.

FOOTNOTES

1. [1] All this involves organizational politics that are beyond the scope of this book. For more information, read any of the standard textbooks on management and organizational theory; or consult Robert Block’s delightful The Politics of Projects (New York: YOURDON Press, 1981).
2. [2] Why would the user change his mind from one interview to the next? Usually because the interview causes him to focus his attention on something that he has only thought about in a “fuzzy” way up to this point. Your questions during the interview may cause him to view his requirements in a different light.