Wasted time. Squandered resources. No consensus on business requirements. That’s right, we’re talking about a flawed data warehousing initiative.

According to the results from last year’s survey which polled reader’s CRM priorities and concerns, readers requested more articles about the CRM and data warehousing initiatives of actual companies. Not success stories, but the real war stories behind company initiatives. The real nitty-gritty, "How the West was won" type of stories.

What readers wanted was a step-by-step account of true failure – the inside story about fatally flawed CRM and data warehouse projects.

In the survey, readers commented that success stories often make an implementation sound too easy or unrealistic. I agree. So, in this column, I’ll share with you one company’s experience implementing a data warehouse – including the errors, the poor decisions and the mishaps during every stage of the project.

Because it is so hard to do data warehousing well, the things that went awry in this example could affect any implementation in any company in any industry. It is important to remember that technology alone is the not the only culprit in a failed implementation. Lack of clear business objectives and poor management can be equally, if not more, devastating to the success of a project.

So, read closely. Chances are you may even recognize some red flags...

The marketing organization within a services organization sponsored a data warehouse project to address some common problems services companies typically face: customer retention, acquisition and profitability. The company was a subscription-based service that was billed monthly.

The data warehouse project was intended to help the marketing team develop a segmentation scheme, increase customer retention, develop acquisition campaigns and be able to better understand and profile customer behavior and usage patterns. Although the organization expended considerable amounts of time, money and effort, at the end of the day, there were no results to speak of. Below are a few of the missteps that led to the project melt down.

The marketing department’s initial request was to be able to track and count renewals. With this mandate, the IT department began to build the programs to extract information from the customer service application and put the renewal transactions into the data warehouse.

Misstep 1: Don’t Begin a Project Without a Clear Understanding of the Business Objectives or Requirements

Though the marketing department felt that the creation of the data infrastructure was strategic to the business, nobody seemed to have enough time to spend with the systems and business analysts on the data warehouse implementation team. The result was the collection of scattered business requirements with no consensus. Marketing personnel did not have the time for follow-up meetings, so issues concerning actual requirements were never resolved.

Data warehouse requirements are not nearly as time-consuming as developing an operational system, but gathering user and business requirements is a critical first step. Though the common answer from marketing may seem like "We want all the data, all the fields and as much history as possible," requirements must be tailored more than this. Is the first iteration of the data warehouse project more list-selection oriented or analysis oriented? If analysis, is reporting sufficient or more sophisticated statistical analysis appropriate? What are the key subjects of the analysis?

Data warehouse requirements are iterative. Typically, high-level requirements are gathered, source systems are investigated and requirements are revisited based on data availability. Three things are key to making this process successful: the users must be informed of the iterative nature, the users must make themselves available to this process and the project manager assigned to collect business requirements must know when to stop the iteration.

Misstep 2: Overlapping or Confusing Data Definitions

The poor business requirements methodology had a cascading effect. Renewals, retention, churn and all of its brothers and sisters have as many different definitions of CRM, all natural or money back guarantee. Though it was obvious from the cursory meetings that renewals were an important concept, the issue of multiple definitions did not surface. The customer service application had a transaction called renewal, and the IT department determined that use of this transaction would be the basis for counting transactions. However, there turned out to be many types of renewal, transactions: automatic rollover renewals, manual renewals, manual updates of records that meant a renewal, and product additions that were meant to be renewals. In fact, the renewal transaction itself was more a function of the technology and not really considered a renewal by the business users.

Some of the promise of data warehousing is that the organization will speak according to one set of vocabulary and definitions. Though it sounds nice, and you could probably dance to this, in reality things are a little more complicated. Multiple definitions do not always mean people are using words incorrectly. Many times it means that the same word is being used for slightly different concepts. Though some of these issues will be resolved, it may be impossible to resolve all of them in any reasonable amount of time. Experienced analysts will know which terminology can be resolved across and among business units and which terminology will just have to coexist for a while.

In this case, not enough time was spent on definitions and, when the system went live, the metrics and numbers associated with the data warehouse’s definition of renewal were of no use to the business.

Misstep 3: Populating the Warehouse with Unconfirmed Data

Every picture tells a story and so does every transaction. Experienced designers try to find out the reasons and events surrounding the transactions. Under what circumstances was this transaction created? What evolution does a transaction go through? Most importantly, can the original transaction be changed causing the system to forget its original meaning? Consequently, significant information about customer behavior may be lost since the only record of the transaction is the most recent picture.

The designers of this data warehouse merely moved the data from the source system (call center) into the data warehouse. They did not really investigate the types of events that can occur to create or modify the transaction. This type of source system analysis is crucial to really understand what was happening in the business at the time. In fact, especially with call centers, we recommend actually getting a demonstration (or observing for an hour) of the software to understand how users interact with a system. This analysis will show all of the alternatives in handling certain situations, misuse of certain features of the technology or creative use of features. For instance, using a cellular example, is a deactivation of a phone with an immediate reactivation considered a renewal?

In this case, with a dozen different ways of doing renewals, simply looking at a back end data model will not clue you into the various different ways a renewal can show up. You need a user to step you through the process to understand how the different types of renewals will show up in the database.

As a result, renewals were severely understated and the reports and analysis being generated were not useful.

Misstep 4: Start with Plan that is Supported by the Executive Team

The general approach to building this data warehouse was flawed. I think many of you may have heard that building a data warehouse is a journey that never really ends. This means that you must build your projects as a series of smaller components. This phased approach ensures that you are consistently adding new value to the project. These phases must be short in length (no longer than three months) to mitigate the risk of a potential change in the project scope or business needs that cause the current phase to no longer be a priority.

Without a 12-18 month high-level plan (no matter how much it may shift or change), data warehouse projects become stale, disoriented and directionless. The right project management and executive sponsorship (technical and business) must make sure that the data warehouse is constantly aligned with the business goals. Program management offices overseeing the entire initiative must be built, respected and adhered to.

In the case of this project, there was no plan. So, basically, you had Phase 1 with nothing afterward. There was no structure on how to solve all the missteps labeled above since, from a project-plan standpoint, the project just ended, the people were redeployed and the users had an unusable system.

Conclusion

The result is the development of a data warehouse that could not be leveraged for analysis or campaign management. To be effective, a marketing data mart had to be built that met the initial business and user requirements, which was an extremely difficult effort. With a clean, well-designed data warehouse, data mart creation should be a rapid, painless approach. Without a solid data warehouse foundation, the marketing data mart had to perform all of the complex transformations and duties that the data warehouse should have done. This makes the marketing data mart complex, hard to maintain and difficult to react to changing business needs.

At the end of the day, what went wrong?

  • First, the sponsors of the projects would not spend enough time articulating their requirements and current issues.
  • Second, the IT department took partial requirements and ran with the ball without circling back to the user community. They created definitions in a vacuum that were way off the mark.
  • Third, inexperienced data warehouse designers did not know the art of interpreting the transaction. Transactions were taken at face value without understanding the business process surrounding them.
  • Fourth, without a program management office in place, the data warehouse team was directionless.

Little things add up and tend to cascade. Looking back on the project, it is easy to see how just a few changes to project management, program management and methodology could have turned a failure into a success.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access