The year-one finish line for Churchill Downs Inc. (CDI)'s massive CRM initiative was in sight, less than a furlong away, when the project manager sprinted toward CDI Vice President of CRM and Technology Solutions Atique Shah with a stricken look.
"No matter how careful your preparation and planning has been," Shah says, "the day comes when the project manager enters your office in a state of panic and says, 'We're not going to make it!' " Shah admits, however, that there were sound reasons for the project manager's panic.
First, the initial 10 months of the multiyear CRM initiative, anchored by an E.piphany implementation, have given rise to more complex challenges and a greater number of deliverables than originally expected, including a recently completed redesign of the Kentucky Derby Web site (www.kyderby.com). Second, and more worrisome, "we got bitten badly by bad data," Shah says.
The problem affected a small minority of CDI customers, and related to the way in which the CRM system identified each customer. When a customer generated multiple transactions within the same source--the Kentucky Derby site, for example--each transaction generated a unique identification. That qualified as a problem for several reasons, including that it could weaken the company's ability to develop an accurate profile of its customers.
For example, a customer might opt in--agree to receive informational and promotional material from CDI--during one online transaction (e.g., registering for a sweepstakes), but opt out during a different transaction (e.g., purchasing a vintage lapel pin from the online store). That might perplex the marketing team responsible for following up with customers who opted in.
Shah credits Ascential's data-integration applications with enabling his team to purge the database of multiple customer identification tags and, ultimately, ensure that each customer can be identified with a single tag.
The CDI CRM team also replaced the multiple registration templates, which previously popped up whenever a customer conducted an online transaction, with the registration module that can be accessed from any customer channel. Now, a customer is only asked to register once.

This merge-purge process was unexpected by the team, but not entirely unanticipated by Shah. "I knew the customer-identification area would require some work," he says, "but I also knew we would address it at the right time. The important decision becomes whether or not you turn it into a complex project."
Given that all projects turn out to be more complex than originally planned, and taking note of his team's existing sensitivity to that dynamic, Shah solved the identification problem through a basic data warehousing exercise that identifies the duplicate customer-identification keys and removes them from the system.
Unlike those who view scope creep as taboo, Shah sees it as a natural component of large implementations. He says the trick is to plan and prepare for it as accurately as possible, and then strive to mitigate the size and impact of the additional work. Scrubbing a small portion of the system's total data is much easier to handle late in the game than, say, building a call center.
Small problems can also help focus project team members less on the logistics of crossing the finish line and more on the project's ultimate objective. "There was some discussion about moving ahead with the bad data, since it represented such a small portion of our database," Shah says. "You should never do that. But the suggestion helped us remind ourselves of the end goal, which is to generate accurate information to fuel better business decisions."
Eric Krell, a freelance writer based in Austin, TX, rarely needs a good reason to panic>