Data Warehousing Failures -

Eight studies of data warehousing failures are presented. They were written based on interviews with people who were associated with the projects. The extent of the failure varies with the organization, but in all cases, the project was at least a disappointment.

Read the cases and prepare a one or two page discussion of the following:

1. What's the scope of what can be considered a data warehousing failure? Discuss.

2. What generalizations apply across the cases?

3. What do you find most interesting in the failure stories?

4. Do they provide any insights about how a failure might be avoided?

Case Studies of Data Warehousing Failures - Government Research Laboratory

The Government Research Laboratory (GRL) has a finance department in each of the fifteen nearly identical laboratories that report to its national home office. As a member of the finance team, Bob was familiar with the monthly financial reports required by the home office. Although the financial reports themselves were not complicated, access to the mainframe where the data was housed was necessary, and an understanding of COBOL was needed to generate any report that differed from the standard. Once a month, reports would be distributed in paper form and each member of the finance team would sort through them and file them away. If the reports required any alteration, then someone from IS, or one of two people from finance familiar with COBOL, was contacted.

Because of these reporting difficulties, an IS manager made the suggestion that the company's first data warehouse be constructed, and that the finance department be the primary beneficiary. Two people from IS began to work full-time on the project and a financial analyst also joined the group. The IS manager then offered a bonus to the IS technicians if they could get the data warehouse up and running by the end of the fiscal year which was just four month away.

Both the IS and the finance members of the team, firmly rooted in reality, knew this would be a difficult if not impossible task. But they resolved to give it their best shot and attempted a full transfer of all available reports to the warehouse. When it became clear that this was too ambitious, they cut out all of the detailed reports and focused on just the summaries, assuming the more detailed material could be integrated at some point after the initial deadline.

The team was successful and had all summary reports transferred to the data warehouse at the end of the fiscal year. The fact that the necessary tables were up and functional, however, was not an indicator of future success.

The first problem involved changes to the mainframe database which were initiated at the same time, but uncoordinated with, the data warehousing project. At the same time the foundation for the data warehouse was being laid, the planning system on the mainframe was undergoing modifications not captured in the data warehouse. In particular, changes in cost accounting standards within the organization changed the number of key summary categories from the standard five used in the past to seven, rendering the traditional five next to useless.

The second problem occurred when the goal to establish the data warehouse became the end goal. As the GRL financial analyst for the team describes it, the feedback and modification period he had anticipated after September never came. The preliminary fix became the permanent solution. The analyst later learned that IS had always intended to set the system up but only funded its basic maintenance. Modifications were not in the budget and the finance department, only minimally included in the warehouse project, never had a budget that would fund the inclusion of more data and alterations to the system.

Essentially, GRL found itself with a data warehouse that contained too little data and data that was outdated because of format changes in GRL's cost accounting standards. Also, neither finance nor IS budgeted for changes necessary to create a fully functional data warehouse. Those two problems alone would have killed most data warehouse initiatives, but the problems did not end there.

The data warehouse was supposed to solve two accessibility problems. One involved the need for COBOL language expertise whenever a report required alteration, and the other involved the sheer mass of printed documents being disseminated and archived. Instead of providing a solution, reports theoretically available on a network were handled in much the same manner as the old reports. For one thing, the data access software installed on each user's PC was frequently incompatible with the mix of software already there. Many end-users, therefore, found access to the data warehouse difficult, and those who were able to access the data warehouse had such bad experiences with the new system they just did not use it. Also, the small minority that did not experience accessibility problems simply printed hard copies of the reports, which was no great change from how things had been done in the past. Additionally, the programming barriers in existence when COBOL knowledge was necessary simply changed form. PowerBuilder, very much a programmer's tool, was selected to build the user interfaces. Ironically, IS only had one individual with PowerBuilder skills, thus creating more of a bottleneck than had existed with COBOL.

The situation remained the same, if not worse, for three years following the first warehousing initiative. Finally, another IS project manager became interested in the idea of breathing life into the old warehouse. He was motivated by the organization's solution to the Y2K problem, which involved abandoning the old mainframe system and transferring the old reports to the warehouse. Fortunately, his interest was accompanied by funding that allowed the enhancements anticipated at the very beginning of the first project to finally be realized. Also, all users are able to access Web-based reports.

Several things should have been done differently at GRL: (1) The warehousing initiative should have been in sync with mainframe changes and other IT initiatives throughout the lab; (2) Planning and resources should have been projected much farther into the future; (3) A pilot should have been done which probably would have identified a number of technical and fine tuning problems; (4) Deadlines should have reasonable.

Still, given the most recent developments, GRL's financial analyst classifies his experience as a partial disappointment. "It could have been so much better," he explains. "It could have been done right...for the right reasons."