What CRM Should Have Taught IT (although not getting the message is not entirely IT's fault)

Featured Author - Dick Lee - May 1, 2003

Introduction

Sort of unsettling statement, "What CRM taught IT," no? Almost preposterous to think that CRM, the trouble-making, technology low-life that's made so many messes, could have anything to teach IT. After all, CRM isn't real technology. Or only barely so. Heck, lift the hood on half these systems and you'll see a whole farm-load of hamsters furiously peddling just to keep the belts moving. Hardly more sophisticated than the timing cams we once used for automation. Garbage—or as the French say it, garbage.

Well, more than a little hyperbole there. But, I'm just mimicking what we hear so often from those who think CRM technology, as bad as it supposedly is, is too good for sales in particular, "Why give those lazy low-lives anything good? Whatever they get, it's going to wind up scheduling golf time and tracking the bass bite, anyway."

So, if CRM is supposedly such tricycle technology, what on earth should IT have learned working with it? You may be surprised to find out.

Actually, CRM offered IT two key learnings—one obvious, one much less apparent. The obvious one that's been nearly gummed to death by now, but still many in IT give only lip service to, is a twist on former President Clinton's famous campaign message—the yellow sticky note reminder that he stuck to his forehead. "It's the economy, stupid." Actually, many IT folks walking around desperately trying to avoid blaming themselves for their loss of budget are muttering the same thing. But the key learning I'm referring to carries a different descriptor. "It's not the software, stupid."

Turns out that CRM wound up being more about customers than technology. And to add insult to injury, CRM is more about the people who use the technology than the technology itself. And the fact that CRM is not, at heart, a technology didn't occur to many companies, particularly companies with IT-led CRM implementations, until they started the process of adopting CRM by first buying software. Singed by the flames of failure, these folks. More like fried, in many cases.

CRM is About Doing Business

But there's another learning IT should have taken from the whole CRM debacle—which never was as bad as reported, but looked just awful thanks to pyrotechnic quality of the flameouts. Beneath the "not software" message that too many in IT unfortunately still miss is a more subtle learning. Subtle—but with much deeper implications for business and IT both than CRM not being centered around software.

Actually, now that I think of it, this "new" learning is not going to sound so revolutionary—or even so new. But it's one of those facts of business life that hangs around in the background noticed but unheeded—until companies start violating it so badly that it rears up and bites them where it hurts the most. On their bottom lines. The learning I'm alluding to is a very simple concept:

The value of any technology to business is a function of

its alignment with present and future business requirements.

Pretty non-controversial statement, eh? Non-controversial until you realize that had the gee-whiz technology biz heeded this credo several years ago, not more than one in fifty of the companies populating the dot.com bubble would have ever seen the light of day—or the darkness at the end of the bubble. And if many CTOs, CIOs and IT managers had paid heed, they wouldn't have lost their budgets—or their credibility, and in some cases their jobs, either.

"But," you may fairly ask, "doesn't the principle of aligning technology with business requirements apply to all technologies—ERP, ABC, XYZ—and not just CRM?" And right you are. The alignment principle applies across the board. However—CRM, with its complex set of unfamiliar, cross-functional business requirements, demonstrates this principle far more visibly and vividly than any preceding wave of new technology. With CRM, the misalignment issues are right out there, front and center, for all to see—including CRM implementations blowing up in Technicolor because the technology does not begin to fulfill the business requirements of sales, marketing and customer service. Or worse yet, because the technology tries to dictate the business requirements. But this time, instead of having compliant back office-types semi-amenably changing workflow and work process to suit software—or grumbling barely out loud as they adopt new software that screws them up royally—now we have rebellious sales people saying, "If you know how to do my job so well, come out here and do it, jerk." Or, "Hey buddy, you can take this software and shove it." Actually, they mean "shelve it." Which they routinely do, often at a waste of three grand or more a license.

Can we agree that we need to perform better aligning business requirements and technology? Hope so, but we still haven't reached one critical facet of this second, more subtle learning. To extract the kernel of understanding we're after from the endemic CRM business-technology misalignments, we have to dig way down to the root cause for the extreme degree of misalignment so often achieved. And this underlying cause is something we should have recognized—and remediated—some time ago.

IT Has To Be About Business

More so than during any of the successive waves of technologies that have damn near drowned us over the past 10 years, when CRM broke, IT's difficulties communicating in any language other than IT came home to roost. When IT came face to face with sales and marketing types that didn't have a clue—about IT—poor communication with business-types degenerated into little or no communication, or outright miscommunication. Small wonder there's a gaping chasm between the front office business requirements for technology support of so many CRM implementations and the technology support IT winds up providing. And we're not just talking about IT pushing selection of inappropriate CRM software or limiting adaptation of the software, but more importantly about not fulfilling data integration requirements or not providing portals or developing essential infrastructure support.

Now, what's the lesson here for IT? Don't ever deal with sales and marketing people? You wish. No, the learning here is that the present method commonly employed for collecting business requirements for technology support—not just for CRM, but for ERP, SCM, portals, data warehouses, whatever—is broken. IT hasn't properly supported CRM because it hasn't understood either its importance or its requirements—just as IT has been experiencing increasing difficulty grasping increasingly complex business requirements for technology support generated by supply chain management, Six Sigma, lean business and a host of other types of business initiatives. The advent of CRM exacerbated a serious, pre-existing condition, rather than CRM creating the condition.

In this context, think about how we gather business requirements. Does it make sense to send IT business analysts running around to collect requirements for technology by interviewing business-side people—ever more specialized people pursuing ever more specialized goals using ever more complex processes and speaking totally unrecognizable languages as well? Absolutely not. In fact, it's so illogical in today's environment that we clearly missed a critical transition point somewhere back down the road.

But that's the way we're still doing things. So what's a poor IT department to do? Well, turnabout is fair play.

Technology Exists to Support Business Requirements

What IT should learn from its increasing difficulty comprehending business requirements in so many instances, especially complex requirements of the type CRM and other new methodologies generate, is that it's not IT's fault. Bottom line—gathering business requirements for technology support should no longer be IT's problem. It's up to business to gather and communicate business requirements for technology support. And business-siders don't need to understand technology to accomplish this, either, because this is 2003, not 1993.

Today's technology can accomplish the vast majority of what users ask of it, unlike 10 years ago when the need to stay within confining technology boundaries virtually forced us to express business requirements in technology terms. If we couldn't say it in technology-speak, obviously we couldn't do it. But that was then. This is now. And we have to change our business requirements gathering methods to keep pace with information technology's dramatically increased capabilities and adaptabilities. Especially because these greatly expanded capacities are only encouraging the business side to up the ante by expecting IT to support dramatically more complex sets of business requirements—requirements we can't reasonably expect IT professionals to understand, on top of understanding the escalating complexity of their own tools. No more abdication of responsibilities—and bitching afterwards—for business. Business has to start taking care of its own stuff.

The Implications

Now, one last twist. If you'll reflect a bit on the shifting of requirements gathering responsibility from IT to business, you'll realize this isn't an entirely IT-friendly shift. Because what it says between the lines is that business will determine what it needs—and IT will be left figuring out how to provide it and budget for it. That's the opposite of the current state—business trying to live with what IT wants to provide, and IT able to control what it has to provide by controlling the requirements gathering process. So IT still only gets half a loaf.

PS: Not to forget, business still has to learn how to gather its own requirements. But that's easier than you think, thanks to new methodologies I'll describe in a near future article.

About the Author

Author Dick Lee is practice leader for Minneapolis-based Caribou Lake Customer-1, which helps clients align business and technology. Mr. Lee is the originator of the "Visual Workflow" methodology for parallel design of workflow and information flow. He has authored and co-authored several books on CRM, including Strategic CRM, and he speaks globally about CRM and about achieving customer-centricity through business/technology alignment.