Kimball University: Overcoming Obstacles When Gathering Business Requirements

For nearly two decades, Kimball Group has stressed the importance of focusing on the business and its requirements for data warehouse/business intelligence success. We've provided specific requirements-gathering tips and techniques in previous articles and our Toolkit books, but what happens when things don't go according to plan? This article describes seven common challenges you may encounter during the requirements-gathering process along with Kimball Group's recommendations for overcoming these obstacles.

Abused User Uncooperative business executives and managers who claim "we already told IT what we want" are typically abused users. These folks have been interviewed repeatedly in the past for DW/BI initiatives but have yet to see anything result from their efforts. They are frustrated by past false starts and may even refuse to meet with a requirements team again.

You should proactively determine who was involved and interviewed in earlier DW/BI attempts. Any requirements documentation from the prior project should be reviewed. Unfortunately, documentation is seldom sufficient to take the place of a face-to-face meeting with the business representatives again. When scheduling meetings with these abused users, it's helpful to acknowledge their participation in previous efforts and let them know that you have already reviewed the resulting documentation. The new session can be presented as a validation, rather than as another back-to-the-beginning interview.

Naturally, users will resist rehashing previously covered territory, but they may be more willing to meet if you are focused on understanding current priorities. Finally, this is probably a good time to select an alternative forum for gathering requirements. If interviews were conducted previously, use the earlier requirements documentation as a baseline for a session focused on gather details on changes within their business.

Overbooked User These disengaged business users are simply too busy to meet anytime soon. They may agree to a scheduled time but then not show up or send a substitute in their place. An e-mail message from the program sponsor to all the participants about their importance to the initiative will often nip this disorder in the bud. However, if this is a contagious malady and executive management is unwilling or unable to address the condition, stop before you waste more effort. It's a safe bet that business users who don't have time to meet to share their requirements won't have time to attend education sessions and incorporate new information and analyses into their daily jobs, resulting in a never-ending, uphill struggle for the DW/BI team. Get off this slippery slope before further damage is done. You may be able to locate a more cooperative business partner elsewhere in your organization.

Comatose User These business users respond to your classic, open-ended questions with monosyllabic, one-word responses. Fortunately, this is a relatively rare syndrome. Most often, their apathetic responses are due to external distractions totally unrelated to the DW/BI project. It's sometimes effective to ask these people questions from a more negative perspective. For example, rather than trying to get them to envision life outside the box, these users sometimes find it easier to tell you what's wrong inside the box.

If you have to pry information out of interviewees like this, it's senseless to prolong everyone's pain as these interviews quickly become no fun for anyone involved. Make a valiant attempt, but if it is still not working, abort the interview and schedule a replacement representative if the user is in a critical function or position.

Overzealous User You're expecting to interview two business users, but seven people arrive in the designated conference room instead; these overzealous users are excited and want to be heard directly by the DW/BI team. It's great that the users are so engaged and enthused, but that won't last long if you try to interview seven people in a one-hour meeting. Quickly assess the homogeneity of the crowd. Are they all doing the same job and could build off of one another's ideas, or more likely, do they represent different jobs and functions? It's almost always the latter, so you should break them into smaller groups and give them separate slots on the interview schedule. This ensures adequate time is allocated to gather the details needed.

Know-It-All User Folks in this category often sit between IT and the real, ultimate business users. Know-it-all users sometimes act as gatekeepers, rationalizing that there's no need to bother the other business folks for their requirements when they already have a thorough understanding and can represent their needs. Sometimes the know-it-all does know it all, but other times, their perspective is skewed. Even if their understanding is 100 percent accurate, bypassing opportunities to bond with the rest of the business community via requirements sessions is a blunder that can be difficult to recover from. You can engage the know-it-alls and even elevate their perceived role and importance, but don't fall into the trap of over dependence. This potential political quagmire may require some finessing and feather smoothing on the part of the business sponsor.

As an aside, be aware that know-it-all users are sometimes IT wannabes. In addition to limiting access to the rest of the business community, they sometimes also want to perform IT's design duties by thoroughly specifying the data layouts for their proposed system solution. In their defense, IT wannabes have sometimes been forced into this role because IT has traditionally underperformed and under delivered.

Clueless User Do you have users that just don't get it? Do you feel it's a worthless exercise to schedule requirements interviews with them because they don't have any requirements? From our vantage point, 99.9 percent of the time, clueless users are a figment of an IT professional's imagination. Users may not be able to articulately convey precisely which data elements in which source systems interest them, but nearly all the time, they can clearly describe what they do, why they do it and what they want to be doing in the future. It's then IT's job to translate this information into data and functional specifications for the DW/BI system. Asking the right questions is critical to obtaining relevant, useful guidance.

Nonexistent User The final obstacle is typically fatal to a data warehouse initiative. This condition results when members of the IT organization say they know what the business users need - "in fact, we know it better than they do." These IT organizations attempt to model their data warehouse based on source-data layouts exclusively, and then don't understand why business users aren't clamoring to use their deliverables. The good news is that this obstacle is totally within the ability of the IT organization to overcome by losing the attitude and interviewing the real users.

There you have seven common challenges you may encounter during your requirements-gathering initiatives. Hopefully our suggestions will keep these bumps in the road from becoming debilitating program/project show stoppers.

Margy Ross is president of The Kimball Group. She has focused exclusively on data warehousing and business intelligence since 1984. Margy teaches for Kimball University and co-authored The Data Warehouse Toolkit, 2nd Edition (Wiley 2004) and The Data Warehouse Lifecycle Toolkit (Wiley 1998). Write her at [email protected].