Taking CRM step-by-step. (Tech Topics).

Judith Kincaid is a former Hewlett-Packard executive with a business and technology background (including programming experience). At HP, she led the strategic direction of consumer and B2B CRM and oversaw the development of several major customer-facing projects. Since 2001, Kincaid went on

Here, she discusses her book, CRM--Getting it right, offering her observations on the factors that make customer projects succeed--or fail.

ABABJ: There are a lot of books about CRM. Why did you decide to add yours to the pile?

Kincaid: When I worked at Hewlett-Packard, I was fortunate enough to have a technical and programming background. So I knew from my own experience what software and systems could--and could not--accomplish. I don't romanticize applications and technology.

My team and I also benefited from a very supportive senior management and had the luxury of experimentation. We learned a great deal through all that trial and error.

This book is a kind of thorough record of everything we found to be effective in our own work with CRM with references to practices that we found problematic.

CRM -- Getting it right is also pretty comprehensive. I review strategy development; infrastructure and the tools of the trade; the process of analyzing customer information; and the process of measuring organizational results.

So, I wrote the book with the intention of offering a kind of users guide to organizations struggling with CRM projects. I like to think of it as a workbook approach.

ABABJ: Give me an example of a less-than-effective practice.

Kincaid: Sure. Doing too much at the same time during the implementation phase -- this is a common mistake that many organizations make. And, most of that frantic activity centers on building IT infrastructure without having evaluated the business problem or refined that analysis as the technology is getting built.

So what you lack is a solution informed by the issues posed by a clear set of problems.

Moreover, before this frantic activity, you often have a lack of what I'd call the "10,000 ft." perspective. That is, the company fails to get a synopsis of the problem. It hasn't defined what is trying to be accomplished generally.

This strategic work should be hammered out with all the major constituents of a project during a period of about six to eight weeks (no more) before any software is selected or implementation begins.

ABABJ: Such systematic problem identification is very important, then.

Kincaid: Yes. If a problem is amorphous in the minds of executives, how can they hope to develop an effective change management process or make the appropriate behavioral-change recommendations?

A big bang approach is lethal. But companies often lapse into it, especially in the conception phase. This is because people have high hopes for the technology and mistakenly believe all the "little problems" will sort themselves out during implementation.

To be fair to the executives, some software manufacturers tend to oversell the technology--actually, it's pretty typical.

This feeds a big misconception about CRM, which is the "software can do it" and that everyone wants "the same thing from CRM."

ABABJ: You mean, if you ask an executive, "why CRM" he'll say....

Kincaid: (Laughs) He'll say, "I want to get closer to my customer," or "I want to get CRM-ized because that's what my competitors are doing."

These are not sufficient reasons to delve into a major CRM project.

If you want to get closer to your customer, for instance, you might simply hire more branch- or call center- personnel or add money to the training budget so that those front-line individuals are facilitating better customer treatment.

I'm not saying these objectives are reasons to avoid CRM, all I'm suggesting is there needs to be a thorough review of the organizational issues and priorities to determine what exactly is needed.

ABABJ: In coming up with a priority list or possible source of projects, what do you recommend?

Kincaid: Look at the organizational problems that are causing the most pain or creating the biggest opportunity costs, then find some facet of that problem to work with. This may take input from a lot of line-of-business personnel to establish, by the way.

In the end an ideal candidate for a "proof-of-concept" project is a medium-risk yet fairly visible organizational problem. Medium risk, because, if you don't have instant success, the short-term failure is something the organization can live with and learn from. It needs to be high-enough profile, because you want the benefit to be tangible and something that touches the customer directly.

ABABJ: So you don't think "internal" CRM projects are valid?

Kincaid: It's not that as much as being "internal" is the default mode of most companies, which tend to assume they know what their customers want or like or need. The ultimate point of any project is that it reach and affect customers--even if that effect is being defined in the short-term as an internal process issue by the organization. Basically, any new program should change the customer's experience of that institution.

Presumably, you as a company executive want the customer to view you differently and/or behave differently because if that weren't the case, you would have no need for the improvement that an effective CRM project can bring.

ABABJ: Let's take something like a contact management system or, better yet, the installation of a campaign management system. That's not literally a customer-facing tool.

Kincaid: No. Not literally. But I'd argue that the new campaign management system that you've installed isn't completed until it yields a specific new campaign with a message that targets a specific customer segment and is designed to get them to behave differently. Moreover, the project isn't complete until you can measure the results in terms of response to that campaign.

ABABJ: Let's say that a regional bank wanted to tackle campaign management with a more customer-centric approach. 1-low might they "break that down" in line with your approach?

Kincaid: Well, they'd evaluate the business problem. As part of that they'd identify the existing process or processes along with the information that informs the decisions that are made and the actions taken to enact them.

What I mean by this is, they'd identify what information is needed, what data points are required, to enact process A. Then they'd do the same for Process B.

What someone wouldn't do, to offer a contrast, is work for a year or two, spend millions on merely building an elaborate tool set that they assume will create the message they're looking for at some later date.

That "build it first, then use it" approach isn't very useful in my experience. It's better to build the technology around a live campaign. The business process involved in that will inform the development of the technology and vice-versa.

ABABJ: With so much great advice out there about CRM from people like yourself, why do you think organizations still stumble over these issues?

Kincaid: Organizations are large, complex, and generally divided into silos. People tend to jealously guard their expertise. Depending on the company there's a real sense that sharing creates an intolerable loss of control or vulnerability to becoming irrelevant.

I don't find the banks that I've worked with, or used as a banking consumer, to be any more bureaucratic than large organizations in other industries. What I've seen in banking is an understandable culture of fear because after all, this is money and risk management we're talking about here. Obviously, nobody wants to make mistakes that can negatively effect reputation.

ABABJ: If you had to leave our readers with one thought on the subject of CRM, what might that be?

Kincaid: Remember the experience of being a customer. When you deal with your financial services provider you don't see, nor do you care about, that company's internal politics.

You think of it as a single entity. And you expect to, say, phone in once and get the question answered pretty quickly or at least have some clear sense about a possible resolution.

Try to design your organization so that your customer can make fewer phone calls, have common experiences however they contact your organization, and that the marketing and branding message is reinforced by the actual day-to-day experience of dealing with you.