Alan Alda's Interviewing Tips for Uncovering Business Requirements

Good listening and conversational skills will uncover hidden needs and 'shadow functions.'

April 05, 2005

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.

Quick Study

Dos and Don'ts for Gathering Requirements

Do talk with a vertical span of businesspeople, including executives, directors/managers and analysts.
Don't rely on a single user to represent the business, even if it's less intimidating and easier to schedule.
Do allow plenty of time to coordinate calendars for scheduling, especially with traveling business management.
Don't get angry if someone has to reschedule at the last second.
Do get help from skilled assistants to manage scheduling.
Don't offload interview coordination to someone unfamiliar with the project or organization.
Do arrive for the interview on time.
Don't bring food to the interview, leave your cell phone on or spill a large latte over the interviewee's conference table and sample reports.
Do plan on a two-person requirements team in each interview, if possible.
Don't overwhelm a lone interviewee with six people sitting across from him, Inquisition-style.
Do designate one person as the lead interviewer with primary responsibility for steering the session.
Don't turn the interview into a free-for-all, bouncing randomly from one interviewer to the next.
Do flesh out your scribbled interview notes immediately, or you'll lose much of the interesting detail by the next day.
Don't schedule more than four interviews per day.
Do document what you learned during the requirements gathering and feedback results to close the loop with participants.
Don't lose sight of the scope of your DW/BI requirements process.

Required Reading

"Boosting Business Acceptance"
intelligententerprise.com/showArticle.jhtml?articleID=26100520

The Data Warehouse Lifecycle Toolkit by R. Kimball, L. Reeves, M. Ross and W. Thornthwaite (Wiley, 1998), Chapter 4.

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].