Manage Learn to apply best practices and optimize your operations.

How to define business requirements for data warehousing projects

Using the Business Requirements Definition, the authors define the process of gathering business requirements, which begins with interviewing IT and business professionals, in order to organize and analyze data into a DE/BI system strategy to make better business decisions on data warehousing projects.

This is an excerpt from Chapter 1 of The Microsoft data warehouse toolkit by Joy Mundy, Warren Thornthwaite and...

Ralph Kimball, copyright 2006 by Wiley Publishing, Inc. Click here to view the full Chapter 1: How to define business requirements for data warehousing projects.

The most important determinant for long-term success

There is one common factor in successful business intelligence projects: delivering business value. Your DW/BI team must embrace the goal of enhancing business value as its primary purpose. This seems like an obvious statement, and we almost always get a chorus of agreements when we state this principle to the DW/BI teams with which we work. But most DW/BI folks are technologists at heart. We like the certainty of computers and programming. It works or it doesn't; if it doesn't, we can debug it.

More on data warehousing projects

Listen to this podcast on how to avoid data warehouse performance killers

Read about applying Agile methods to data warehouse projects

Find out what the big data era means for data warehousing architecture

You can't deliver business value unless you work closely with business people. You need to understand their language and learn to see the world from their point of view. You'll be working in a non-technical, highly ambiguous, politically sensitive environment. Are you feeling queasy yet? Many of us went into the computer trade specifically to avoid such discomfort. But this unsettled environment is what the DW/BI system is all about. You must develop the business knowledge and people skills right along with your technical skills in order to meet the needs of your business users. We realize the entire team will not become smooth-talking MBAs. However, someone on the team must have strong business and communications skills, and everyone will be more effective if they work to develop some of these skills.

So, while many DW/BI teams and consultants pay lip service to business value, the reality of their day-to-day behavior is that technology rules. Do not let this happen to you. Technology is important; business value is mandatory.

As you read this book, you'll encounter recommendations that may seem unnecessarily complicated or just plain unnecessary. Every time you're tempted to dismiss the authors as overly fond of their design methodology, or just overzealous, consider whether your reactions are driven by your technical convenience, or by the business users' needs. Never lose sight of the business.

Uncovering business value

If you're 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. Let's talk about the most common scenario first, and then we'll 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 that's 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." That's probably okay, but put those tools aside for the moment. Step away from the keyboard. If you get sucked into the technology, you're 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

We'll run through each of these steps in the following sections.

About the authors

Joy Mundy, a member of the Kimball Group, has been developing, consulting on, and speaking and writing about business intelligence systems and technology since 1992. Joy began her career as a business analyst in banking and finance as one of the power users we talk about in business intelligence. In 1992 she joined the data warehouse team at Stanford University, an effort that was both educational and character building. She next co-founded InfoDynamics LLC, a data warehouse consulting firm, and then joined Microsoft WebTV to develop closed-loop analytic applications and a packaged business intelligence system. Joy graduated from Tufts University with a B.A. in Economics, and from Stanford with an M.S. in Engineering Economic Systems.

Warren Thornthwaite, a member of the Kimball Group, has been building decision support and data warehousing systems since 1980. Warren co-authored the best-selling Data Warehouse Lifecycle Toolkit (Wiley, 1998). Warren worked at Metaphor Computer Systems for eight years starting in 1983, where he managed the consulting organization and implemented manymajor data warehouse systems. After Metaphor, Warren managed the enterprise- wide data warehouse development at Stanford University. He then cofounded InfoDynamics LLC, a data warehouse consulting firm. Warren joined up with WebTV to help build a world-class, multi-terabyte customer-focused data warehouse before returning to consulting.

Ralph Kimball, Ph.D., founder of the Kimball Group, has been designing information systems and data warehouses since 1972. In 1972 he joined the Xerox Palo Alto Research Center as a research scientist. Over the following ten years at Xerox, he became a development manager and the product marketing manager for the Xerox Star workstation, the first commercial product that used windows, icons, and the mouse. For this work at Xerox, he received the Alexander Williams Award from the IEEE Human Factors Society for user interface design. Following his years at Xerox, Ralph was a vice president and member of the founding team at Metaphor Computer Systems, the first data warehousing company. In 1986 Ralph founded Red Brick Systems, which developed the first high-performance relational database for decision support. Since 1993, Ralph has designed data warehouse systems, written bestselling data warehouse books, and taught data warehousing skills to more than 10,000 IT professionals.

Dig Deeper on Business intelligence technology platform