Key to any Information Technology development project is the ability to effectively interview with end-users, people from business units who are not necessarily graced in the acumen of I.T., yet need solutions to some rather pressing business problems for their departments. Yet interviewing skills seem to be in decline lately, particularly among I.T. personnel. Its really not that difficult, but it requires a certain type of person to perform it adequately; someone who is naturally curious and works well with others, a “people-person.”
How you interview someone in business is somewhat different than how Barbara Walters interviews a celebrity on television. Although there are lessons she can teach us, you must remember you are not there for anyone’s entertainment. True, you want to be sociable, but you also need to get to the point.
There are essentially three types of situations for interviewing a user during an I.T. development project:
1. To specify information requirements (as to what is needed and why).
2. To review designs for viability and acceptance.
3. For current systems analysis.
In all three situations the interviewer must be one part detective, one part lawyer, and one part translator. The interviewer must be a detective in order to know how to investigate a problem and know what to look for; he must be a lawyer in order to know how to ask the right questions, and; he must be a translator to interpret what the user is saying.
KNOW THY USER
The first thing the developer must know is some background information on the person to be interviewed. The developer must be able to assimilate the user’s job and his interests to better serve the user as well as to gain his trust. To do so, pertinent organization charts and job descriptions should be referenced in advance to study the scope of the user’s area of responsibility and employee reporting relationships. Further, the developer should understand the user’s products or services he is responsible for, along with the customers and vendors he works with. The more the developer knows about the user prior to meeting him, the more credible he will be and the better his chances are for satisfactorily serving the user.
To develop the proper rapport, dress presentably, act professionally, and communicate effectively. Appearances in this regard are very important. Nobody wants to confide their interests in a Huckleberry who doesn’t appear to know what he is doing. Dressing and acting professionally expresses respect for the other person, as does a firm handshake. Very important: speak to communicate. This means the developer should communicate in terms the user will understand, not the other way around. Technical jargon should be avoided as this may be misinterpreted by the user and may even alienate him, thereby creating a hostile or uncooperative working relationship. Further, avoid the temptation to use slang, try to be as articulate as possible.
Learn to read the body language of the person you are interviewing. Look for signs of being guarded versus being open and candid. Likewise, consider your own body language so that you invite discussion. You want to convey an image that you are genuinely interested in what the user has to say. For example, don’t let your eyes wander around the room during the interview, stay focused on what the other person is saying.
Observe protocol. Remember, when you are visiting the user, you are on someone else’s turf. Do not be presumptive, take nothing for granted. Ask permission to tour the user’s area, talk to pertinent people, and gather notes. A little professional courtesy can go a long way.
DO YOUR HOMEWORK
Prior to meeting with the user, prepare a thorough interview outline highlighting the questions or subject areas you will be inquiring about. True, the actual interview will undoubtedly stray from the outline, but it offers you some structure to maximize your use of time. Also, to enhance productivity during an interview, it is a good idea to communicate the purpose of the interview to the user and what your objectives are. This should be done well in advance of the interview to give the user ample time to prepare for the meeting. Ideally, the user should be presented with a copy of the interview outline prior to the meeting.
During the interview, take plenty of notes. Frankly, I am of the old-school whereby I use nothing more than paper and pencil. I still find users who are intimidated by computer laptops and other recording devices. As an aside, some of the best interviewers I have seen over the years knew “shorthand” which simplified taking notes, but I’m afraid this is a language facing extinction. If you wish to use computer technology during the interview, be sure the user doesn’t have a problem with it, nor that it will inhibit his dialog with you.
In terms of venue, the interviewer must determine a suitable site to conduct the interview, either in the user’s office, your office, or a neutral site. Users tend to be more comfortable in their own offices where it is easier for them to reference paperwork for you. The only problem though is the possibility of interruptions (phone calls or people stopping by). Holding the interview in your office tends to be more threatening and may actually inhibit the person by making him think it is an inquisition. A neutral site near the user’s area is better to minimize distractions and allows the user to remain comfortable in his own area of responsibility. For example, I have seen some excellent interviews conducted in sequestered meeting rooms where the interviewer can scribble notes on a blackboard or flip chart. This can be very conducive for clarifying points during the interview, as well as general brain storming sessions.
During the interview, the developer tends to play the role of a lawyer, which means he probably knows the answer to a question before asking it. A well structured interview, therefore, is used to confirm your suspicions more than anything else. As in the lawyer analogy, avoid “fishing trips” whereby the interview goes down pointless avenues of discussion. Remember, if you are not using the right bait, you’ll catch nothing. Stay focused, stay in control and don’t let the interview digress into meaningless ramblings.
During the interview, there will be a lot of “give and take” in terms of controlling the direction of the interview. The interviewer should avoid jousting but always remain firmly in control of the meeting. Stay on target and accomplish the objectives as specified on your interview outline.
“WHY?”
More than anything, the interviewer is trying to understand the rationale for something. Because of this, it is no small wonder the term “Why?” is the most commonly used expression in his vernacular. When I am specifying user information requirements, I like to approach the question in another manner. For example, I’ll say something to the effect, “Assuming I can deliver the information to you in the manner you want, what will you do with it?” In other words, I am looking for the user to describe the business actions and decisions to be supported by the information, thereby justifying the need for it. This is a nice alternative to constantly asking, “Why?” Another technique is to simply ask the user for examples in order to illustrate his points.
How a manager perceives something may be different than what happens in fact. Consequently, I often find it necessary to interview key secretaries and clerks who are more intimate with the daily flow of business in the work area than the manager might be. Their answers may confirm or conflict with what the manager says. Nevertheless, it is the responsibility of the interviewer to find and substantiate the truth.
CONCLUSION
In interviewing, it is not so much what you ask as it is how you ask it. As such, both tact and diplomacy are part of the game. The interviewer has to convey a positive image of trustworthiness, professionalism, and organization. Further, he has to be able to ask pointed questions, as well as being approachable to confide in.
Aside from the human dynamics of interviewing, organization is vital for success, if for nothing else than to maximize your use of time (as well as the other person’s). Take good notes during the interview, pick through them carefully afterwards, and document them for review by the user for clarity. This review is important. Its like saying, “This is what I understood you to say; is this a correct interpretation?” Clearing up misinterpretations and inconsistencies early in a development project will save considerable time and money later on. As the old adage goes, “The best surprise is no surprise.”
