Design Tip #110 More Business Requirements Gathering Dos and Don’ts

Successful data warehouse and business intelligence solutions provide value by helping the business identify opportunities or address challenges. Obviously, it’s risky business for the DW/BI team to attempt delivering on this promise without understanding the business and its requirements. This Design Tip covers basic guidelines for effectively determining the business’s wants and needs.

First, start by properly preparing for the requirements process:

• Do recruit a lead requirements analyst with the right stuff, including confidence and strong communication and listening skills, coupled with the right knowledge, such as business acumen and vision for BI’s potential.
• Do involve the right business representatives representing both vertical (cross management ranks) and horizontal (cross department) perspectives. Don’t rely solely on the input from a lone power analyst who’s a pseudo-IT professional.
• Don’t presume you already know what the business wants because you’ve supported them for the past decade.
• Don’t accept a static requirements document from the business which lists general items such as “we need the ability to quickly drill down into a single version of integrated data.”
• Do differentiate between project and program requirements. While the mechanics are similar, there are differences in terms of the participants, breadth and depth of details collected, documentation, and next steps.
• Do get face-to-face with business representatives (or at least voice-to-voice). Don’t rely on non-interactive static surveys or questionnaires; don’t think producing a 3” binder of existing reports equates to requirements analysis.
• Do prepare interviewees in advance so you don’t spend the first 30 minutes of every session conceptually explaining DW/BI. Secondly, spend your time with the business representatives wisely:
• Do show up at the appointed meeting time. Don’t allow your cell phone to ring (or casually try to figure out why it’s vibrating).
• Do ask “what do you do (and why)”; don’t ask “what do you want” in the data warehouse or pull out a list of data elements to determine what’s needed.
• Do ask unbiased open-ended why, how, what if, and what then questions. Do respect the lead interviewer’s or facilitator’s role in steering the sessions; don’t turn it into a questioning free-for-all.
• Do strive for a conversation flow; don’t dive into the detailed weeds too quickly.
• Do listen intently to absorb like a sponge; don’t allow the requirements team to do too much talking.
• Do conduct some sessions with source system experts to begin understanding the underlying data realities.
• Don’t schedule more than four requirements sessions in a day; do allow time between sessions to debrief.
• Do ask the business representatives for measurable success criteria (before thanking them for their brilliant insights).
• Do set reasonable expectations with the business representatives about next steps; don’t leave it to their imaginations. Finally, bring the requirements gathering activities to an orderly conclusion:
• Do synthesize the findings into business process-centric categories which represent manageable units of design and development effort for the DW/BI team.
• Do write down what you heard (along with who said it and why it’s required), but don’t attempt to reinvent an alternative Dewey Decimal System for classification and cross-footing. Detailed project requirements can often be classified into three categories (data, BI application/report delivery, and technical architecture requirements) which correspond to downstream Lifecycle tasks.
• Don’t allow the requirements gathering activities to be overcome by analysis paralysis or process perfection.
• Do present your findings to senior executives to ensure a common understanding, reach consensus about an overall roadmap, and establish next step priorities based on business value and feasibility.

Focusing on business requirements has always been a cornerstone of the Kimball approach; I first delivered a presentation on the topic at an industry conference in 1994. Much has changed in our industry over the past fifteen years, but the importance of effective requirements gathering has remained steadfast. Good luck with your requirements gathering initiative!