In my opinion the most important and challenging aspect of a BI project is to understand the business requirements. Majority of BI projects failures are due to lack of understanding the business. This lack is primarily due to BI being thought as an IT project, instead of being a business project with IT as one of the enablers.
It's very important to find out "what they need" and not just focus on "what they want". The most effective way of doing that is by "face to face" meetings with managers, business users and IT people. 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 business people 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 from there, cover the following areas:
- What are the key business objectives?
- For each objective, ask about measures for success to learn more about key metrics and business dimensions.
- What roles do data and analysis play in achieving goals? Alternatively, how would better access and analysis benefit them?
- What are the current analysis challenges?
A good question to get the interview started is "How can people tell when you're doing a great job?"
Be conversational: 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.
Several techniques can help you establish a more conversational tone:
- Learn a bit about the business beforehand by reviewing the Web site or annual report to understand company-specific vocabulary and hot-button issues.
- Meet with interviewees on their own turf. Go to their offices or conference rooms, rather than IT meeting spaces.
- Prior to the interview, send out an announcement describing the high-level discussion topics and confirming the interview time and place. Don't attach a detailed questionnaire to this meeting notice. You can't achieve a conversational flow if you're reviewing questionnaire results-presuming anyone bothers to complete the survey.
- Interview questions prepared in advance are fallback devices, used only if uncomfortable lulls occur in conversations or to ensure key points are covered before ending sessions.
- Most good conversations tend to wander, so remember your session goals and steer conversations back on track if you stray too far from core issues.
- Stay at a relatively high level in the interview's early stages. Don't follow an early comment to a very low level of detail, only to run out of time and discover that you haven't discussed three other major areas of responsibility with important requirements for the DW/BI effort.
Listen, and expect to be changed: Good interviewers should be seen but not heard — well, at least not heard too much. Strong active listening skills are required.
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 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. During these data audit interviews, try to understand whether complete, reliable data is there to support what users are asking for.
There are several methods and resources for BIR, one of the best is "The Data Warehouse Lifecycle Toolkit by R. Kimball, ...".
.png)
Posts
