Uncovering Business Value

If youre going to be driven by business value, you need to go out and identify, understand, and prioritize the needs of the business. This is easier said than done if your focus has historically been on technology. Fortunately, the Business Dimensional Lifecycle provides the tools to work through an entire development iteration of a data warehouse, beginning with business requirements.

Where do you start with your business intelligence system? What is the first step? The consultant in us immediately blurts out the standard consulting answer: It depends. In fact, it does depend on a host of factors, such as how your organization works, what you already know about the business, who is involved in the project at this point, what kinds of DW/BI efforts came before, and many other factors. Lets talk about the most common scenario first, and then well address a few exceptions.

More often than not, the DW/BI system starts as a project hosted by the Information Technology (IT) organization. There is generally some level of business interest; in fact, the business folks may be the source of inspiration. But they are pushing for information in a form they can use, not specifically for a DW/BI system (unless, of course, they had access to a well-built data warehouse in their last job and they really miss it).

Most often, the IT-driven DW/BI project gets started because the CIO decides the company needs a data warehouse, so people and resources are assigned to build one. This is a dangerous situation. Please refer to the first point in this chapter: Focusing on business value is the most important determinant of long- term success. The problem with the IT-driven DW/BI system is that it almost always centers on technology. The team has been assigned the task of building a warehouse, so thats exactly what they do. They get some hardware and some software and start extracting data.

We know some of you are thinking, Oops, I already bought the ETL server and the user reporting tools. Thats probably okay, but put those tools aside for the moment. Step away from the keyboard. If you get sucked into the technology, youre missing the whole point. You can build a technically great DW/BI system that provides very little business value. As a result, your project will fail. You have to start with business value, and identifying business value involves several major steps:

• Recruiting strong business sponsorship

• Defining enterprise-level business requirements

• Prioritizing business requirements

• Planning the project

• Defining project-level business requirements

Well run through each of these steps in the following sections.

Obtaining Sponsorship

Developing solid business sponsorship is the best place to start the DW/BI project. Your business sponsors (it is generally good to have more than one) will take a lead role in determining the purpose, content, and priorities of the DW/BI system. You will call on them to secure resources and to evangelize the DW/BI system to the rest of the organization. This includes activities such as arranging for a planning meeting with senior staff, or speaking to a room full of business users at the project kick-off. You need to find at least one person in the organization who scores well in each of the following areas:

• Visionary: Someone who has a sense for the value and potential of information and some clear, specific ideas on how to apply it.

• Resourceful: Someone who is able to obtain the necessary resources and facilitate the organizational change the data warehouse will bring about.

• Reasonable: Someone who can temper his or her enthusiasm with the understanding that it takes time and resources to build a major information system.

Often, if youve been with your company for a while, you already know who these people are. In this case, your task is to recruit them onto the project. However, if youre new to the company, or you have not been out of the IT group much, youll need to go out and find your business sponsors. In either case, the best way to find and recruit these people is by conducting an enterprise business requirements gathering project. Its worth the effort. Good business sponsorship can provide the resources and support you need to deliver real business value.

Defining Enterprise-Level Business Requirements

From a technical point of view, one long-term goal of the DW/BI team is to build an enterprise information infrastructure. Clearly, you cant do this unless you understand business requirements from an enterprise level. It is especially important in larger organizations to begin with this broad understanding because it is rare for the DW/BI team to have such an enterprise-level perspective. Its also particularly important for organizations that are just starting their first DW/BI system (or starting over) because getting the enterprise perspective built into the initial project helps you avoid painful and costly redesign down the road.

In these cases, the high-level version of the Lifecycle presented in Figure 1.1 doesnt give you quite enough information about how best to get started. In particular, the little arrow that goes both ways between Project Planning and Business Requirements Definition actually breaks down into several subactivities, as shown in Figure 1.2.

Figure 1.2: Detail of sub-activities between initial scope and project requirements

ENTERPRISE VERSUS PROJECT

Many organizations weve worked with have a clear understanding of which business process is their top priority right from the start. In these cases, we often combine the enterprise requirements definition step and the project requirements definition step into a single effort.

This does not lessen the importance of understanding the full range of enterprise requirements for information. In fact, we almost always go through the enterprise prioritization process with senior management. However, because the top priority is clear early on, we make sure we gather enough detailed information about that business process and the data it generates in the same interview set so we can create the design for the first business process in one pass instead of two.

 

In this subsection of the Lifecycle, defining the business requirements happens in several distinct steps. The rest of this section describes each of these steps in more detail.

Note 

We use the term business process throughout this section but do not describe it in detail for another few pages, when it makes more sense in the context of the requirements definition process. For now, think of it as a subject area or data source.

Establishing Initial Project Scope

Begin with the creation of an initial project scope based on the teams upfront knowledge of the organizations business needs and its experience in developing DW/BI systems, along with input from the business participants . The scope usually covers only the enterprise-level requirements definition and requirements prioritization steps in detail, leaving the initial project implementation plan for later when you have a much better idea of what the project needs to accomplish from a business perspective. The initial scope usually involves only user interviews, interview write-ups, a few meetings, and the creation of the final requirements document. It usually takes three to six weeks (or more) depending on how many interviews you do.

Reference 

Additional information about project planning and management in the context of the Business Dimensional Lifecycle can be found in The Data Warehouse Lifecycle Toolkit (Wiley, 1998), Chapter 3.

Gathering and Documenting Enterprise-Level Business Requirements

The enterprise requirements definition step is designed to gather a broad, horizontal view of the organization from a business point of view. The process flow chart in Figure 1.3 breaks the Enterprise requirements definition box from Figure 1.2 down into its subtasks . As we see in Figure 1.3, the core part of defining business requirements involves gathering and documenting those requirements.

Figure 1.3: The enterprise requirements definition process flow chart

While the four steps that are circled on the left side of the figure are shown as separate subtasks, we usually do them in a pipeline fashion, conducting an interview, extracting its analytic themes, identifying their supporting business processes, and placing each business process in the initial bus matrix. Well describe each of the core subtasks in Figure 1.3 in this section, leaving the senior management prioritization session for its own section.

Preparation

Requirements definition is largely a process of interviewing business and technical people, but before you get started, you need to do a little preparation. Learn as much as you can about your business, your competitors , your industry, and your customers. Read your organizations annual report; track down any internal strategy documents; go online and see whats said about your organization, the competition, and the industry in the press. Find out what the big challenges are. Learn the terms and terminology the business people use to describe what they do. In short, do your homework.

Part of the preparation process is figuring out whom you should actually interview. This usually involves carefully examining an org chart with your sponsor and other key supporters. There are typically four groups of people you need to talk to early on: senior management responsible for making the strategic decisions for the organization; mid-management and business analysts responsible for exploring strategic alternatives and implementing decisions; source systems experts (the folks who really know what kinds of data issues are out there for you to trip over); and finally, people you need to interview for political reasons. This last group may not add any value, but if theyre omitted, they could cause problems. Increasingly, there is a fifth group of people who may need the data warehouseoperational decision makers needing real-time or near real-time access to historical and integrated data. Your initial interviews should sample the operational community to see if such interest exists, and if so, a representative group of these users should be included in the interviews.

Its easy to start the interview list with the CEO and his senior staff. Add the analysts and managers who are known as leaders in the business intelligence areafolks whom senior management and co-workers turn to when they need information. They are also usually the folks who bug the IT organization the most. If youve been at your organization more that 12 months, you know who these people are. They have their own Access databases, they write SQL against the transaction system, and they create reports and charts with whatever tools they have available (mostly Excel and Access). Finally, add on a couple of the key IT folks who can educate you about the nature of the source systems.

Note 

You are just making the list of whom to interview at this point, not the interview schedule. Start the schedule with a few people you know and trust before you turn to senior management. At the same time, make sure you get the elusive executives on the calendar as early as possible. Some of these folks can be tough to pin down.

A major goal during the interviews is to build positive working relationships with the business folks. These relationships will build on your understanding of the business issues your organization faces. In short, be prepared. Fortunately, gathering this information is not as difficult as it used to be, thanks to the Internet. However, you still have to read it.

Interviewing Business and IT

The next step in requirements gathering is actually talking to business users. Interview individuals or small groups (two to five people at most), rather than hold a large group design session. The individual interview allows each person to present his or her views on what the challenges are and what is required for success. It also gives the DW/BI team more opportunities to capture and clarify critical information. Finally, individual interviews are less work for the business folks. They take only an hour or so, rather than a whole day or two for group design sessions. On the downside, individual interviews collectively take longer and are more work for the DW/BI team.

In this first pass at gathering requirements, you will interview more senior level folks across the different departments and get a comprehensive list of the major challenges and opportunities your organization faces. We call these challenges and opportunities analytic themes . These themes often (but not always) line up with the strategic goals and initiatives of the organization. We talk about themes in more detail later in this section.

When you speak to the business users, you will often hear business requirements that sound really important and valuable , but end up being impossible to meet. A request such as Sales data for our competitors by SKU by retail store by day would allow us to increase our market share by at least 5 percent sounds great. The catch is that, for most industries, the data is not available. Even internal data might not be available, or it might be so dirty or poorly structured that it will take a major effort to make it presentable.

This is precisely why you need to interweave some interviews with source systems experts to understand the structure and content of the source systems and the nature of any data problems that might be lurking out there. You must also perform data profiling on all candidate data sources. (Data profiling is described in an upcoming section.)

At the end of each interview the interview team must take a few minutes to debrief. Review your notes, fill in the blanks, make sure you understand the terms you heard , and capture the key issues. The longer you wait to do this, the less you will remember. Weve found ourselves staring at a sentence that reads, The most important factor in our business is with no idea what came next. Debrief as soon as possible.

Tip 

Never ask the end user What do you want in your data warehouse? That puts them in the position of designing the system. Thats your job. Besides, there is only one right answer to this question: Everything. Instead, ask questions that help you learn what the end user does, and then translate this into what needs to go into the system. A question such as How do you know when you have done a great job? can get you started in the right direction.

Interview Summaries and Analytic Themes

Its a good idea to start writing up summaries of the individual interviews as you work through the interview schedule. This takes a bit of work because you dont want to simply transcribe the interview. Instead, summarize the various requirements and group them according to category or theme. This is where the analytic themes begin to appear.

Creating the list of analytic themes requires good categorization skills. Its like being able to look at each tree in the forest and group it by genus (and maybe even species). It gets easier with experience, but its never simple. Start by grouping related requirements as you write up the individual interview summaries. Often, these groups are actually higher-level themes that include several sub-themes. In some cases, theyre not really analytic themes at all, but represent a need for a new or improved operational process.

These are some example themes from a subscription business, such as MSN, grouped by the strategic goals they support:

1. Improve the effectiveness of the customer acquisition programs.

   1. Advertising

   2. Promotions

   3. Direct mail

   4. Online

2. Increase sales per customer by offering additional items of potential interest (cross-sell), or similar, higher value items (up-sell).

3. Improve margins by negotiating better prices and terms with suppliers.

4. Identify desirable profile(s) based on long-term customers and use them to create targeted acquisition programs.

This is a simple, enterprise list of goals and themes. Yours will need to be more detailed and extensive . Each theme should have examples of the specific analytic requirement you heard in the interview. It should also include some sense of the business value of meeting the requirement. In other words, how much is negotiating better prices and terms worth?

You may create an initial list of 20 or more major themes. Some of the themes on the list may represent new ways of doing business and will require new transaction systems, or at least significant changes to existing transaction systems. But even a quick review of the simple list provided begins to bring out ideas about how the DW/BI system can address some of these needs in the short term.

These analytic themes are a key input for the next step in the enterprise requirements processidentifying the supporting business processes. Well get to this in a bit.

Meanwhile, the last step in creating the interview summaries is to validate what you heard. This can be done by sharing the interview summaries with the interviewees and asking for comments. Do this before you start working on the final overall requirements document. That way, any misunderstandings can be fixed and additions included. This validation step sends a positive message to your business users. It tells them you listened and understood their issues. In many cases, this is the first step in repairing damaged organizational relationships. It may be helpful to hold a findings review meeting where you invite everyone who participated in the interviews and have your business sponsor do the introductions .

Data Auditing/Data Profiling

At the same time you are interviewing people and creating the summaries, you will also need to do some queries against the source system data to get a firsthand understanding of the data issues. This kind of querying has come to be known as data profiling or data auditing , and there are several tools on the market designed to support it. There are three major points in the Lifecycle where data profiling is helpful. The first is here, during the requirements definition process where you should do a simple red light/green light assessment of your organizations data assets. You arent looking for nuances at this point, but if a data source needs to be disqualified, now is the time. The second place to do data profiling is during the design of the dimensional model, and the third is during the design and implementation of the ETL process. You will want to do more in-depth data profiling once you select a specific business process and begin defining project-level business requirements. We describe data profiling in more detail when we discuss the dimensional modeling process in Chapter 2.

Identifying Business Processes That Support the Analytic Themes

As you extract the analytic themes for the interview summaries, you need to dig into each analytic theme to identify the business process (or processes) that generate the data needed to perform the desired analyses. You convert from themes to business processes because business processes are the units of work in building the DW/BI system. Each business process is usually measured by a single source system, which translates into a single pass through the Business Dimensional Lifecycle process. (See the related sidebar for more information.)

BUSINESS PROCESS: THE DW/BI SYSTEM UNIT OF WORK

We use the term business process to mean an operational activity the organization engages in to accomplish its primary goals. You can think of business processes as the links in the organizations value chain. Each business process typically has its own operational system or module that enables it, such as the order entry system, or the call tracking system, or the inventory management system. The information generated by these business processes measures only the business process itself, but that information usually has value well beyond the boundaries of the individual business process. Information from a single business process, such as orders information, could be of great interest to Sales, Marketing, Customer Service, and other groups across the organization.

Each business process is a unique, coherent measurement system implemented as an operational system. If you need data from a given business process, you need to extract that data in its business context. In other words, you need to pull the measures and all of the associated descriptors in a careful, systematic fashion. This makes the business process the fundamental unit of work for the DW/BI system. Unless you have unlimited resources, your DW/BI team will concentrate on designing and loading data from one business process at a time. The business process is the DW/BI system unit of work.

 

While many analytic themes require information only from a single business process, one challenge you will face is that some themes require data from multiple business processes to meet the overall analytic needs. Customer and product profitability themes are good examples. They sound like a single analysis (the customer scorecard), but they actually require data from many separate business processes. We call these consolidated themes because they cannot be completely built until all prerequisite business processes are in place.

Converting from analytic themes to business processes helps determine the level of effort needed to support a given theme. If a theme must have data from more than one business processes, it will take more than one pass through the Lifecycle to enable that theme. While these passes can happen in parallel, there is no way around doing the work.

Converting from analytic themes to business processes involves thinking about which business processes are required to support each theme. For example, it may be possible to support the cross-sell and up-sell theme (B) from the example list based on data from a single business process: orders. With a data mining tool and orders data that indicates which products are bought together (the order, or market basket ), you can identify the common relationships, which you can then use to influence sales. (Would you like fries to go with that shake?)

On the other hand, a theme such as customer profiles (D) might draw on data from most of the major business processes. A profitable customer uses the web to get product information (low marketing costs), buys a lot (high sales), keeps what he buys (low returns), and doesnt need much help (few customer service calls). In this case, youd need data from at least four business processes (or rows on the bus matrix, as described in the next section) to support theme (D). This is an example of a consolidated theme because it requires that data from more than one business process, such as orders or returns, be implemented first.

The worst case theme is often called a scorecard or executive dashboard. This deceptively simple application draws on data from almost all business processes in the organization. You cant create the entire dashboard until youve built the whole data warehouse foundation. Or worse , you end up building the dashboard by hand every day, manually extracting, copying, and pasting data from all those sources to make it work. It can be difficult to get business folks to understand the magnitude of the effort involved in creating this simple report.

Building the Initial Data Warehouse Bus Matrix

As you identify the business processes needed to support each analytic theme, you will also add those business processes to an enterprise data roadmap called the Data Warehouse Bus Matrix. This matrix maps your organizational business processes to the entities or objects that participate in those processes.

Each row in the matrix is a business process. Figure 1.4 shows a simplified example bus matrix for a retail company. Notice how the business processes down the left side of the matrix follow the organizations value chain. In this case, the company buys goods from their vendors and stores them in distribution centers. Then, as goods are demanded by consumers, they are moved out to the retail stores where theyre held on shelves until the customer buys them and the goods leave the companys value chain. These business processes generally correspond to individual source systems or modules in the overall Enterprise Resource Planning (ERP) system.

	Business Processes	Dimensions
		Date	Product	Vendor	Shipper	Dist Ctr	Store	Promo
	Purchase Orders	X	X	X		X
	Dist Ctr Deliveries	X	X	X	X	X
	Dist Ctr Inventory	X	X			X
	Store Deliveries	X	X		X	X	X
	Store Inventory	X	X				X
	Store Sales	X	X				X	X

Figure 1.4: Example enterprise bus matrix for a retail company

The columns in the bus matrix are the descriptive objects that participate in the various business processes, such as Store, Product, and Date. They contrast with the measurement-driven business processes that label the rows of the matrix. We call these objects dimensions in the dimensional model. Each dimension participates in one or more business processwe indicate this by placing an X in the intersecting cell in the matrix. For example, the Vendor dimension is involved in both the Purchasing and Delivery processes. The Store Sale business process, on the other hand, does not involve the Vendor or Distribution Center.

The bus matrix is essentially your enterprise dimensional data architecture. For each business process (row), you can see exactly which dimensions (columns) you need to implement. And for each dimension, you can see which business processes it must support. This dimension-oriented view is the visual representation of conformed dimensions a concept we define in the next chapter.

The business processes in the bus matrix, and the themes they support (and the value those themes represent) become the major inputs to the next step in the requirements definition process: a prioritization session with senior management.

Creating the Overall Requirements Document

Its best to wait until after the prioritization session to write the overall requirements document so you can include the resulting list of prioritized business processes. The overall requirements document includes the business process summaries, the bus matrix, and the prioritized results. You might want to include the interview summaries as an appendix for those readers who want all the detail.

Once youve completed the overall requirements document, the conceptual foundation of the DW/BI system is in place. The rest of the Lifecycle depends on what you learned in these initial steps to make decisions and set priorities for all three tracks that follow, and on into the deployment, maintenance, and growth phases.

The Prioritization Process

If youre a technical person, its safe to say the prioritization process is one of the most powerful business tools youll ever use. This is a bold statement, but we have used this tool many times and have been repeatedly successful. Weve conducted a few prioritization sessions where the client decided not to move forward with the DW/BI project right away. This decision is usually reached because the prioritization process helped senior management better understand the nature of the commitment or the size of the data problems. This is also a success because it means they will work to fix the problems rather than try to build a DW/BI system on shaky ground.

The prioritization process is a planning meeting involving the DW/BI team, the DW/BI project business sponsors, and other key senior managers from across the organization.

In this meeting, you describe the business processes you identified in the enterprise requirements gathering process so everyone has an understanding of the full list of possibilities. Go into this session armed with a PowerPoint presentation that describes each business process, gives a few examples of the associated analyses it will support along with a feel for the business value of those analyses, and includes an initial sense of level of effort needed to implement the business process (its feasibility). Be as crisp and clear as possible. Try to keep this presentation under two hours. As you describe each business process, you also describe the relative effort involved in supplying the needed data. Once everyone has an understanding of the business processes and terminology, take a break.

The second half of the session involves prioritizing the business processes. Lead the group in placing a sticky note for each business process onto a large version of a two-by-two grid like the one shown in Figure 1.5. This is an interesting exercise in negotiation and education and can easily take another hour and a half to two hours.

Figure 1.5: Example prioritization grid

The prioritization grid is deceptively simple: Study it carefully. The Y axis is about business value. The group needs to reach consensus on the relative impact of implementing each business process. The participants need to remember to take an organizational approach to assigning business value. There will always be someone who thinks any given business process is the absolute top priority. Gently remind them that theres more to the business than their little slice.

It helps to remind participants that the goal is to assign relative, not absolute, values on both axes. In Figure 1.5, we know that business process D is more difficult than business process A, but we dont need to know how many person-days it will take to implement either business process. The same goes for value. Figure 1.5 shows that business process A has more business value than business process B, but its significantly less feasible to implement.

The X axis is about the level of effort each business process will take to implement. It is stated in terms of feasibility so the easier business processes go to the right (high feasibility) and the harder business processes go to the left (low feasibility). The DW/BI team leads the assignment of feasibility because team members have a better sense about the technical difficulties involved in each business process (although feasibility is not just technicalthere are often organizational and political difficulties as well).

The true feasibility is not fully understood at this point. If you have someone on the team whos been in the organization long enough, she should have a good sense for the level of effort required to implement each business process. One obvious factor is when business processes must be implemented together to support a high value, consolidated theme.

The priority session is a good opportunity to educate the business folks about how bad things really are. You dont want to sound negative, but its important to explain the level of effort it takes to gather the data and make it useful. For example, integrating customer IDs from two different source systems is a grind.

A CREDIBILITY BOOSTER

The prioritization process uses a common business school tool called the two-by-two matrix. This matrix was popularized in the early 1970s by the Boston Consulting Group. BCG used a Growth-Share Matrix to compare different business units in a portfolio by comparing Relative market share with industry sales growth rates. A business unit with high market share in an industry with high growth rate was called a Star. By contrast, a business unit with low market share in a low-growth industry was a Pet (later referred to as a Dog).

The great thing about the matrix is the positive impression the DW/BI team makes by cleverly adapting a classic MBA tool.

Sources: The Boston Consulting Group, Perspectives on Experience and The Product Portfolio (Boston, MA: The Boston Consulting Group, 1968)

 

Once all the business processes have been placed and everyone agrees on their relative locations, convert the matrix to a prioritized list of projects. One way to do this is to start in the upper-right corner of the prioritization grid and move to the lower-left corner, numbering the business processes as you encounter them. The two-dimensional nature of the matrix makes this a little difficult. Use the concept of concentric circles to establish a priority order, like ripples on a pond, centered in the upper-right corner.

The output of the prioritization process is a list of business processes in priority order. This list is your DW/BI roadmap; it tells you which row on the matrix, and which dimensions, to implement first. Less tangible , but equally important outcomes of the prioritization process are senior management consensus around the DW/BI roadmap, and a general improvement in the relationships between IT and the business.

In most cases, you will make only one pass at the enterprise requirements. Once the priorities are in place, the next pass and all subsequent passes will be at the level of the individual row on the bus matrix, the business process. Each row essentially becomes a project in the overall DW/BI program. From here on out, you will update enterprise business requirements and revisit priorities as the business changes, but most requirements definition efforts will be at the business process project level.

Revisiting Project Planning

Now that you have a clear idea of your business priorities and how they relate to the business processes (data sources), you can lay out a more detailed and precise project plan. This process is not much different from project planning for any major information technology project. The DW/BI perspective on project planning is described in detail in the Lifecycle Toolkit book and does not merit repeating here.

The plan will continue to evolve as you get more detail about the business requirements in the next step. There is a two-way arrow between project planning and project requirements definition in Figure 1.1, but the backward flow is not as major because you gained significant understanding of the nature of the opportunity in the enterprise requirements gathering and narrowed your scope in the prioritization process.

Gathering Project Requirements

Gathering project requirements follows the same basic process as the enterprise requirements gathering process described earlier. The difference is that now you have selected a particular business process on the bus matrix to implement. The enterprise requirements definition process should be a solid foundation for the project requirements. You now will deepen your understanding of the chosen business process.

The project requirements gathering step is about pulling together the information you need to be successful in the three tracks that follow. Specifically, you need enough detail to create real, practical, flexible data models that will support a broad range of analytic needs. You need a solid understanding of the technical issues around data volumes , data cleansing, data movement, user access, and a host of other issues so you can create a capable, flexible technical architecture to support the warehouse now and in the future. Finally, you need a clear understanding of the business analysis requirements to build the initial set of business intelligence applications to demonstrate value from the very start.

The same three steps you followed in the enterprise requirements process apply to the project requirements process: preparation, interviews, and documentation.

As we described in the enterprise requirements section, preparation is the critical first step. If you havent already, do your homework. Study the particular business process in detail. Figure out as much as you can about how it works before you begin the interviews. Learn the business terminology, the steps in the business process, and how it is measured.

The goal with this round of interviews is to drill down on the selected business process in detail to understand the analyses, data models, and technologies required to make it work. This time you may take a more vertical slice of the organization, depending on the business process (some business processes have broader organizational appeal than others). Talk to the analysts, managers, report developers, and source systems people who can help you understand the intricacies of the business process in question. The actual interview process itself is generally the same as before.

ALTERNATIVES TO INDIVIDUAL INTERVIEWS

If interviews wont work in your situation, we have had success with group requirements gathering sessions, but they are more risky. If you must do group sessions, here are a few tips:

• Preparation is even more important. You have to know the business, and you also have to know what you want to accomplish and how you are going to go about it.

• Have a clear agenda with times listed for each section, breaks, and food and drink. Reserve a good room with plenty of space and comfortable chairs. Make sure you have all the tools you needflip charts, markers, white boards , overheads, computers, and a projectorwhatever makes sense for your plan.

• Get a strong, experienced design meeting leader to run the meetings. You have only a short time. If someone takes the meeting off course, you wont get what you need.

 

Depending on the business process selected, consider whether to interview your customers and suppliers. They are, or could be, business users of information in the DW/BI system. In fact, the need to offer information outside the organization is common enough that many of the front-end tool vendors include extranet access functionality as part of their product line. Listen carefully during the interviews to see if this is a likely source of significant business value for your organization.

Interviews with key source system people and data profiling play a bigger role in the project requirements gathering process. Strive to inform the dimensional modeling process as much as possible about both the business requirements and the data realities.

The documentation process for the project requirements is similar to that of the enterprise definition process, except it is more detailed. Where the analytic themes at the enterprise level ranged across all the business processes, at the project level, they should all be focused on the initial business process.

Although the project requirements definition task sounds a bit abbreviated here, it is actually the definition task you will repeat over and over, every time you iterate through the Lifecycle to bring the next priority business process into the DW/BI system. Lets hope you need to do the enterprise-level task only once, and then keep it updated.

Reference 

There is much more to the requirements definition process. For additional detail, please refer to the following sources:

• The Data Warehouse Lifecycle Toolkit (Wiley, 1998).

• Search kimballgroup.com for the topics Business Requirements and Business Acceptance for several related articles.