Alan Alda's Interviewing Tips for Uncovering Business Requirements

Alan Alda is still widely known as "Hawkeye" Pierce from the hit television series "M*A*S*H" but he's also the long-time host of the PBS series "Scientific American Frontiers," in which he interviews research scientists. Discussing his 11-year hosting stint on National Public Radio recently, Alda described his approach for eliciting information from brilliant scientists. His tactics struck a chord with us because they're similar to the methods we advocate for collecting information from brilliant businesspeople at requirements interviews. Here are a few of Alda's practical techniques with our embellishments for DW/BI professionals.

Be curious, but not too smart. Skilled interviewers must be curious. Alda has a natural interest in science, but he warns of the "too-smart syndrome" where interviewers think they're nearly as well versed in the subject as interviewees:

"I found I wasn't asking good enough questions because I assumed I knew something. I would box them into a corner with a badly formed question, and they didn't know how to get out of it. Now, I let them take me through it step by step, and I listen. Then I say, 'Well, if that's true, then how could this be true?' or 'Tell me more about that.'"

Perhaps you've observed too-smart interviewers. Their questions tend to be long-winded, often eliciting blank stares or responses like "What was the question again?" Interviewers who try to impress others are missing the point. Ask simple, straightforward questions and you'll have a better chance of understanding complex concepts.

Know-it-all observers are also a potential problem. The observer's behind-the-scenes role during requirements interviews should be self-explanatory. Observers who would rather be in the limelight sometimes jump right in and start answering the questions on behalf of the intended interviewees. Once, while interviewing end users at a large manufacturer, a team had to have a "time out" after the first interview so they could suggest to one of the IT "observers" that he let the end users answer the questions.

The goal of a requirements interview is to ask questions in order to discover unknown frontiers. Think of it as a one-hour immersion to better understand what businesspeople do and why. How do they make decisions today, and how do they want to be making decisions in the future? First ask interviewees about their roles and responsibilities to get them engaged and focused on their spheres. From there, cover the following areas:

A good question to get the interview started is "How can people tell when you're doing a great job?" Marketing and salespeople especially like to answer this question.

Take a look at the sample questionnaires in The Data Warehouse Lifecycle Toolkit (see "Required Reading" at the end of this article ) to get a feeling for the process.

Be conversational. Alda believes "Scientific American Frontiers" is popular because of his conversational approach. Alda sets a tone that makes the interview more enjoyable for his subject:

"The conversational element ... makes it good. I'm trying to find out what she's doing, what it really means and how she really does it ... and she's trying to make me understand. She's not just giving a lecture. So it's a very personal interaction."

This is a profound subject, well known to office anthropologists. Thirty years ago at the Xerox Palo Alto Research Center, I (Ralph Kimball) was very influenced by the well-known researcher David Holtzmann, who said that the procedures in a typical office manual are worthless as indicators about how people acquire information and make decisions. What was needed, in Holtzmann's opinion, were the "shadow functions" that described what really took place. Perhaps the crucial source of information to make a decision came from informal conversations around the water cooler. The interviewer needs to get past the procedures manual and find these shadow functions.

For the DW/BI practitioner, being conversational means putting yourself into a business frame of mind. Learn the language of the business. Don't intimidate end users by asking "What do you want in a data warehouse?" End users aren't systems designers. Acronyms and IT vernacular don't belong in a business requirements interview. Business as a second language is a challenge for some of us: Not everyone is cut out to be a lead interviewer.

Tape recorders change meeting dynamics, so don't use them. Users are often uncomfortable being taped and they might want segments of the meeting to be "off the record," which makes for awkward transitions. If you rely on recorders, your written notes won't capture the interview's full content, so inevitably you'll have to listen to the recordings and take supplemental notes. This process is like watching reruns on television: It isn't very interesting, but consumes large chunks of time. It's better for the lead interviewer and an expert note-taker to be actively engaged in the session.

You're not setting the stage for conversation if you hand a list of data elements to interviewees and ask which ones are important. Ask open-ended questions to draw them out. Several techniques can help you establish a more conversational tone:

Listen, and expect to be changed. When you're gathering requirements, your job is to listen intently:

"There's one skill that I really make use of in a big way, and that is listening. If you don't listen deeply, the connection won't take place.... [You have to be] willing to be changed by the person you're listening to, where you're not just waiting for a pause so you can say your thing, but you're actually letting them have an effect on you if they can."

Good interviewers should be seen but not heard — well, at least not heard too much. Strong active listening skills are required (and don't be surprised if you're exhausted after a full day of requirements interviews). Use physical body language and verbal clues to encourage interviewees and show your interest. Interviewees often understand what information we're looking for during the requirements process; with a little prodding and a lot of subtle encouragement, they essentially interview themselves.

Without a doubt, assumptions regarding the scope, timeline, architecture and other matters were made before the requirements process was in full swing. It's also inevitable that you'll uncover requirements not accounted for in those pre-existing assumptions. Many times in operational environments, the end user will announce that the data warehouse "has to tie to the financial books." That's a classic hidden assumption that may be impossible to address. Pay close attention and actively listen for the unexpected: Of course, once you discover a discrepancy, the DW/BI team needs to correct the assumptions.

As you're gathering requirements from the business users, intersperse some data reality into the process by interviewing key IT personnel, especially the master database administrators responsible for operational systems. Consider what the business needs are in tandem with the availability of data to support these requirements. It's a balancing act, but failure is inevitable if you consider one without the other. IT meetings tend to be informal discussions, beginning with knowledgeable project team members. Once you start to hear consistent themes from users, it's time to sit down with the data gurus and get into the extreme detail of their source systems. A COBOL copy book is worth its weight in gold! During these data audit interviews, try to understand whether complete, realiable data is there to support what users are asking for. You're also trying to understand where to find the data land mines — indicator fields that were never populated, for example. A good data profiling tool is enormously helpful for digging into the actual data records.

Your attitude and approach as an interviewer are more important than tactical and logistical concerns of setting up and conducting the sessions. A good interview should seem to the end user like an interesting discussion with a touch of flattery, rather than a courtroom cross-examination. We're sure Alan Alda would agree.

Ralph Kimball, founder of the Kimball Group, teaches dimensional data warehouse and ETL design through Kimball University and reviews large warehouses. He has four best-selling data warehousing books in print, including The Data Warehouse ETL Toolkit (Wiley, 2004). Write to him at [email protected].

Margy Ross is president of the Kimball Group. she cowrote The Data Warehouse Lifecycle Toolkit (wiley, 1998) and The Data Warehouse Toolkit, 2nd Edition (wiley, 2002). Write to her at [email protected].