Q&A: Tips and Techniques for Gathering BI Requirements (Part 1 of 2)
Unlike more traditional systems development, BI projects are driven by data. This requires a distinctly different approach to requirements gathering, as TDWI faculty member Jonathan Geiger explains in this two-part interview.
- By Linda L. Briggs
- January 13, 2015
Gathering the requirements for a BI project requires moving at the speed of business (very quickly, that is) while remaining flexible and accepting that the first pass won't be perfect. In this first of a two-part interview, Jonathan Geiger of Intelligent Solutions explains how to hone your requirements-gathering approach.
Geiger is executive VP of Intelligent Solutions, Inc., and an internationally recognized leader on BI strategy, information management, and quality management. In a 40-year career, he has worked with companies in many industries and has co-authored three books and several courses. He speaks frequently at national and international conferences.
BI This Week: In a recent TDWI Webinar, you discussed how gathering the requirements for a BI project differs from traditional projects, and you outlined techniques for requirements gathering specific to BI projects. Let's start here: how do BI projects differ from traditional projects?
Jonathan Geiger: One major difference is that the ultimate target is much better defined for traditional projects than for BI projects. Regarding the projects themselves, BI projects are data-centric, which creates issues around getting the appropriate people involved. A more traditional project is generally organized along basic organizational structures or functional responsibilities.
A second difference is that with BI, the requirements are often discovered as the project goes on. One method of getting requirements, in fact, is to put up a sample -- a prototype -- and then use that to discover additional requirements.
A third difference is that BI projects simply are not as well defined, even once users understand what they want. The specifics of navigation, the specifics by which data will be solicited, is typically not well defined ahead of time.
Finally, the justification for the projects differs. With traditional projects, it's usually fairly easy to identify business savings and benefits. With BI projects, ... it takes a human being to actually use the data before value is realized. Hence, we need a combination of BI capabilities, and people using those capabilities, to attain value. Furthermore, it takes time -- value isn't obtained immediately upon implementation. When we implement a BI initiative, we provide the needed data, but someone needs to collect it, perhaps over a period of time, then do the analysis, make decisions, take action, and eventually, at some point after action is taken, we see the ultimate value.
What are some leading characteristics of BI requirements?
BI requirements have some characteristics that are common to all requirements -- they should be as clearly stated as possible and they should clearly convey the requirement. Also, we need to be able to trace them back to the source and to be able to verify whether or not we've achieved them at the end.
For a key characteristic that distinguishes the BI project, look at the ultimate deliverable. Note that the ultimate deliverable is not actually what we deliver -- we deliver information. The ultimate deliverable is really the business benefit attained as a result of getting the information. The requirement really needs to focus on what needs to happen in the business, and work back from that to identify the specific information that needs to be delivered, the timeliness, the approach, and so on.
When it comes to requirements gathering, what issues arise around data centricity -- the concept that data is at the center of the business?
A key issue with data is that it is cross-functional in nature. You need to distinguish between what are essentially two types of organizations -- those that have data governance in place and those that do not. For those with data governance, responsibilities for the data are assigned to data stewards. There is a mechanism for getting the appropriate people involved, for getting decisions made in consensus, and for compromising if necessary.
However, for organizations without data governance, there is a major challenge in that the responsibility for data is either not assumed by anybody or is assumed by multiple parties with no single entity as the final decision-maker. For those organizations, steps toward a data governance program would be very helpful. That doesn't mean putting a full-blown program in place, but at least considering getting data stewardship functions assigned to the people who are dealing with the data. Stewardship functions can be assigned without calling people data stewards; they can be called business analysts or data analysts -- ultimately, we want to convene the right business people so that we can get decisions on the data.
When that is difficult or simply cannot be done, support from the sponsors or the steering committee may be necessary.
What are some tips and suggestions for analysts as they approach the job of requirements gathering?
Perhaps the most important thing is to listen when the business user is talking. For example, if we're using interviews to gather requirements, the analyst should have a list of questions prepared in advance. They also should be flexible and really pick up on nuances expressed by the business person -- it's really the follow-up questions that get at the requirements. If the business user isn't volunteering all of the needed information, then once the analyst hears a basic requirement, a key follow-up question is, "Why do you need it?" Of course, we need to be careful to ask that question in a way that doesn't question the validity of the requirement. The purpose is to develop a synergy between the business person who knows the business, and the BI analyst who knows the capabilities BI can deliver.
Is it challenging to do that interview correctly?
The nice thing about BI environments is that the BI architecture, when it's done right, is fairly resilient to discovering additional requirements later. That's assuming that we have captured the right level of detail. The difference with a really skilled analyst is that we'll get more of the requirements up front, and can thus provide more business value quicker to business users who did not anticipate some of the requirements.
What about requirements that evolve as the project progresses? How do you recommend dealing with that?
You simply continue on; it's part of the process. Change is the nature of BI requirements -- it's very common that business analysts don't know in advance what they need.
A prototype is an excellent technique for dealing with the challenge of evolving requirements. We can build a prototype based on what is initially asked for, perhaps using data virtualization technologies so we don't have to physically move the data. That can be done fairly quickly. As they use the prototype, business analysts will discover those additional requirements. Using a prototype with data virtualization, you can get to that stage very quickly and uncover more requirements before actually building the physical data movement facilities.
What specific knowledge and skills are needed for gathering the requirements for a BI project?
In any requirements gathering, we need to have good analysts, meaning that they have to be able to ask the right questions, discern if they're getting good information, figure out follow-up questions, and know how to conduct interviews, facilitate sessions, or use whatever other techniques might be appropriate.
What's extremely important in these projects is really knowing the business -- the competition, business goals, business drivers, and the business environment. If we read in the news that an issue is about to hit our industry, it's a good time to talk to executives to figure out how we can help deal with it. A critical skill is having the knowledge to understand the factors for which BI can provide some aid to the business moving forward.
The analytical skills and the data skills -- those kinds of things fundamentally are similar to any other requirements gathering process. You need to know the basic data subject, the major entities, the processes, quality, the application -- those types of things are largely the same.
Because we're talking about a BI initiative, we need to go up and down the scale of BI capabilities -- everything from queries and reports, to OLAP, data visualization, scorecards, dashboards, analytics, data mining, and data exploration. Essentially, the analyst needs to recognize what's appropriate to the company at this time, based on the company's maturity as an organization, its technological capabilities, and the skill set of the business people who will handle the data.
You've been a BI consultant for many years. Have you found that finding the right people for the analyst position is a challenge?
Sometimes it's a challenge getting the data analyst to understand the business sufficiently so that they can expand on the questions they are asking. It takes experience to do that. However, I've encountered some very good data analysts in virtually all of the organizations I've dealt with.
The problem we have run into -- and it's the business that has identified this problem -- is that many business organizations are not yet prepared to deal with what BI can deliver, particularly in the areas of business analytics, data mining, exploration, and effective application of dashboards.