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.
Dos and Don'ts for Gathering Requirements
"Boosting Business Acceptance"
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@example.com.
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 firstname.lastname@example.org.