One Simple Rule to Avoid CRM Failure, Comrade.

A research organization dealing with customer issues recently interviewed this writer, and the questions they asked got me thinking about how we can learn about CRM from nearly any field of human endeavor, but we learn the most through the most exciting, spectacular, idiotic ideas crashing and burning, like... socialism.

The Common Good vs. My Own Good

One question they asked was "What are the most important obstacles and pitfalls to be aware of in trying to integrate customer data in large bureaucratic companies and organizations? Imagine a large, older incumbent organization with entrenched fiefdoms, or a traditional regulated monopoly, or a large company that has grown through numerous acquisitions."

Good question. Of course the main obstacle is that people regard data as power -- and frequently they're right. If they control the data they have their little fiefdoms, they're players. The pitfall companies usually tumble into when integrating data is the one countries usually hit when they try to adopt socialism -- they assume people see some abstract concept called "our common good" as in their own personal interest.

Wrong. Unless people are incentivized to cooperate, either to produce or share data, there's no reason for them to do so. Right or wrong that's just human nature and there's no getting around it. Efforts to get around human nature will always, always, always fail. Look at the Soviet Union's economy and society if you want a particularly grisly example.

Because the fact is, unless it's more to an employee's advantage to share data than hang onto it she won't do it just because it makes life easier for somebody who's making more money than she is. The reality is that, frequently, people hoarding data are correct when they surmise that if they lose their grip on it they lose standing and leverage within the organization, and the pitfall is that companies refuse to see the issue from this point of view.

The Three Principles: Incentive, Incentive, Incentive.

If a company's data integration project requires some people to change the way they do things, the company has two choices: It can simply demand cooperation, which rarely gets even the sort of sullen, perfunctory, foot-dragging "cooperation" such projects need, or it can look at the change from the point of view of the employee being asked to give up his data, see what it means to that guy and incentivize him to get with the program.

For some reason I've never understood few companies do that, they oddly assume that because it's good for top management it's good for everyone down the line and that this notion is self-evident at all layers of the organization. Nothing could be further from the truth. Everybody in reality is a freelancer -- employees are working for their own good, not the company's. Realize this, make it in the employee's best interest to contribute to the company's best interest, and you'll get all the compliance you want.

Because management looks at "company" and defines it as "the people working for me who need to do what I tell them to," while employees hear "company" and define it as "the place where it's worth my time to work for the money they'll pay." Note the difference.

Deal with people as they really are, not as you'd like them to be, and you'll succeed. Ignore human reality and you'll end up frustrated, because human nature ain't gonna change to please you.

Because Your Employees Are Also... Well, Human.

The research firm also wanted to know what should be the elements of a successful data integration project for such situations?

Again, simply think "How can I incentivize people to do what I want them to do?" If you're trying to pry information loose from someone who's dragging his feet on giving it up the only way to get a smooth flow is to incentivize that guy. I can't think of any other method that really works. Oh it's possible to draw up flow diagrams and charts and all whatnot, but in reality if people in an organization don't want to share information they're either not going to or do so in a manner that rather defeats the purpose of the integration project.

Everyone will look out for themselves first, as is natural, as the C-level people do and whoever's pushing the data integration project is doing, nobody's going to place themselves at a professional disadvantage just to help with a project that doesn't personally benefit them. Structure the project in such a way that it benefits those who are asked to change the way they do things.

"In this case," the researchers told me, "we are particularly interested in knowing how such projects can help senior management get access to useful information and insight for purposes of strategic management and decision-making (besides the conventional goal of improving customer relationships). What can you say about how customer-data projects should be structured with that management purpose in mind?"

Again, I hate to sound like Johnny One-Note, but I have learned that there are a few basic principles that are simply never abrogated in business, and one is that employee loyalty, crucial to customer loyalty, is tied almost 1 to 1 to employee self-interest -- the companies who have the greatest employee loyalty are those who treat their employees the best, period. Get a list of the Ten Best Places To Work, the Ten Companies With The Most Loyal Employees and a list of the ten companies with the highest customer loyalty rankings and note the striking overlap.

How Hard Work = Profit

These are places that look at the company from the employees' point of view -- they start from "what profit would I need to give these people to work hard?" instead of "How can I use these people's hard work to profit?"

In such cases it's fairly clear to employees how what's good for the company is good for them. If the claimed benefits of data integration projects actually benefit the people who are being asked to give up some of "their" data they'll see that, and they'll agree wholeheartedly and give the kind of proactive cooperation such projects need to succeed.

Soviet Policies = Soviet Results. Duh.

Look, you can stick a whole lot of farmers on a Soviet collective and tell 'em they'll all be shot and their families banished to Siberia if they don't produce 100 bushels of beets and you'll get -- exactly -- 100 bushels of the lowest-quality tubers that ever qualified as a "beet." As the history of the Soviet Union proved.

Or you can show them how much money they'll make per bushel of beet, and that better quality beets will get better prices at market, and that they'll get to keep the rewards of their labor and sacrifice minus a reasonable tax and you'll get more beets than you know what to do with. As the history of capitalism proves every day.

Socialism failed because it failed to take this basic human nature into account, that working for the glory of The Workers' Collective wasn't enough of an incentive for people who weren't making any money to work harder, and data integration projects fail for the same reason -- people who aren't going to benefit from a project aren't going to work any more than the absolute keep-my-job minimum for it.

If companies take a Soviet-style mentality to customer data integration projects -- do it for the glory of Acme Anvils, comrades -- they'll end up with Soviet-style efficiency results. If they do it with a capitalistic mentality, recognizing the reality that people do well what they're incentivized to do well, they'll have a successful program.

And when the researchers asked me "can you think of important resources or other experts we should consult for more insight on this topic," I said sure, Josef Stalin. Ask him why collectivized agriculture in a place with the greatest acreage of the most fertile land in the world was such a crashing failure.

Make "Good For The Company" = "Good For Me."

It's no secret that most CRM projects, well-intentioned and with demonstrable ROI waiting in the wings, fail. Why? It's good for the company, so why don't workers all work together to make it work?

Because "good for the company" doesn't mean "good for me, Joe Employee." If it's good for the company to fire me I don't care about what's good for the company. If it's good for the company that I get transferred from the office ten minutes from my house in White Plains to lower Manhattan then I don’t care about what's good for the company. If it's good for the company to implement some CRM, data-sharing project that dents my standing and influence then I don't care about what's good for the company.

Make what's good for the company good for the employees of the company and your project will work. Otherwise, well, get used to Soviet Union standards of success in your company.

Article originally appeared in the author's TMC archive.