Data-warehousing projects are prone to failure. How prone is subject to debate. Various studies show wildly different percentages of failure. For example, according to the Data Warehousing Information Center article "The Case Against Data Warehousing" (http://www.dwinfocenter.org/against.html), the failure rate is between 10 and 90 percent. Failures are variously defined as cost or time overruns, inability to deliver key objectives, or cancellation of the entire warehousing project. Regardless of how you define failure, data-warehousing projects frequently fail, and when they do, the failure can affect more than just that project. Often the cost of failure is high, not just in terms of money and lost productivity, but in the loss of the IT department's credibility with the rest of the organization. Given these risks, why would anyone want to implement a data warehouse? The benefits of warehouses, such as the ability to support faster, more informed decisions and to let knowledge workers answer their own questions, can far outweigh the costs of building the warehouse.
I can't offer you a silver bullet to ensure data-warehousing success, but I've set up data warehouses at more than a dozen companies. From this experience and interviews with several other data-warehousing consultants, I've assembled this description of common problems that cause data warehouses to fail. If you're aware of these problems, you can work to mitigate their effects before they derail your data-warehousing project. Although this article doesn't cover every problem that can occur, you can use it as a checklist to gauge risks in your data-warehousing project.
Politics
Corporate politics is a major reason for data-warehouse failure and unfortunately also one of the toughest problems to resolve. For example, some organizations can become enmeshed in turf battles over not just resources but also the vision of the project. As Don Awalt and Brian Lawton explain in "Data Warehousing: Back to Basics" (February 2000, InstantDoc ID 7833), warehousing projects work when they support a clearly established vision or mission that the organization defines from a business perspective. As you define this vision, some members of the organization might not support the vision because it conflicts with their groups' agendas, requires resources from their groups, or they feel the vision somehow threatens them. Sometimes the solution to this conflict is more politics—you might work with managers to rebalance the resources the data-warehousing project requires.
Other times you need less politics. You might cut through red tape by enlisting the support of a business champion. Good business champions often come from an organization's sales, manufacturing, finance, or human resources areas. These business areas typically have the most pain and therefore the most to gain from warehousing. For example, manufacturing organizations are always looking for better ways to identify and track quality problems by differentiators such as product, shift, and assembly line. Data warehousing can provide rapid access to this kind of information. Champions can help by acquiring proper resources and coordinating end users and people outside IT to answer questions and work on the project.
To get a champion's support, you need to clearly define the problems the warehouse will solve. To do this, target a real problem that is causing pain for someone high up in the organization. If you can show high-ranking people how the project will alleviate their pain, you can enlist their support as business champions for the project. Business champions who have sufficient clout in the organization can knock down many barriers. Champions are also less likely to see a data-warehousing project as a budgetary black hole if that project is going to relieve real pain for the champion's business unit. For example, if you have a plan to eliminate a specific financial problem and the CFO is your business champion, you can surmount nearly any barrier. Warehousing projects that IT champions alone are rarely successful. Simply put, a data warehouse shouldn't be an IT initiative—it should be a business initiative. Focusing on solving a real business problem helps narrow the scope of the project and motivate business users to participate in the project, from defining the warehouse's goals to evaluating client tools.
Inadequate User Involvement
Although it might be hard to believe, some IT departments think they can build a warehouse without user input because they believe they know what the warehouse should accomplish. Some IT departments view data-warehousing projects as database projects—which is partially true—but data warehouses are useless if end users can't work with the data. IT departments don't always build warehouses that users can easily access or that meet crucial business needs. Unless you understand exactly what questions users will be asking, you can't design a cube that provides the right answers.
To make sure you're building what users need, involve them early in the process and keep them involved so that they can verify the warehouse is meeting those needs. Have users evaluate client tools, then choose the tools that will deliver the proper mix of power and flexibility.
As part of involving users, you must also establish a proper training plan. Training should cover how to use the client tools, include education about cube design, and show users how to navigate cubes to answer ad hoc questions.
Before turning users loose in a data warehouse, teach them how to formulate questions. Ask them to figure out what they want to see and how they want to see it. The structure of the question should be: "I want to see <what> by <this> and by <this>." The <what> they want to see is the fact or measure, and anything after the word "by" is a dimension. For example, a user might ask to see the sales for 2004 by product and quarter. This simple exercise really helps users understand how to navigate a cube. Remember that you're likely to have various kinds of users, including developers, analysts, and end users, and the training will be different for each group.
Prev. page
[1]
2
3
next page 
