Learn how to overcome the resistance of business leaders to new technology projects through more effective communication.
As IT managers and CIOs, our businesses charge us to identify new technical trends and IT tools we can use to achieve a competitive advantage. At the same time, many of our organizations resist the introduction of these new tools with ferocity. Sometimes this resistance springs from budgetary, interpersonal, or political concerns. Other times, though, we come face to face with a kind of resistance we are ill-equipped to deal with: the deep seated belief that computers, "technology," and everything that goes with them are nothing more than foolish fads that will, in time, pass along with all of the rest of the business gimmicks in the last fifty years.As agents of technology, we in IT rarely sympathize with this point of view. We engage in malicious gossip about executives who refuse to read their e-mail, call decision-makers who cancel new technology products "Luddites," and say those who want to fund their projects over ours "are stuck in the past." This contempt, born from our culture and our beliefs, further exacerbates an already complicated situation. However, as my mentor once pointed out to me, a bit of listening and a dose of understanding goes a long way toward defusing fear and even hate.
Why people say "no" reflexively
Assuming that budgets exist and we have a clear business case, conventional wisdom claims we can move forward with whatever technology plans we dream up. Yet in reality, non-technical decision-makers often stop us short without even hearing our case. Why? More importantly, how can knowing why help us break though these barriers in order to bring the benefits we dream of to the business?
Over the years I've encountered, to varying degrees, the following non-political reasons for people to resist projects: lack of trust in the outcome, resistance to uncontrolled change, and a feeling of powerlessness in other areas.
Although we think mostly about IT, since it forms the core of our business activity, managers and decision-makers outside of IT confront a world where computers form a relatively small part of the overall business equation. In that world, fads come and go with regularity the tides would envy. Each of these fads promises to make the manager's life easier by somehow magically transforming their people, process, and technology into a newer, more effective configuration.
Unfortunately, most of these fads fail to deliver on their promises. Why this is, and indeed how to solve it, dominates academic debates worldwide. On a practical level, it means that any manager with a modicum of common sense develops an instinctive distrust of anyone or anything claiming to provide them with an easy solution.
Similarly, most managers with any level of experience have long since lost their tolerance for the seemingly random changes inflicted on them by today's "fast paced" business environment. Change, usually thought out in some unrelated part of the business, bombards them from every side. Nine times out of ten these changes do nothing to help any individual manager's business unit. Instead, they appear, inflict some amount of stress, then vanish in another cycle of change.
Together, these cycles of change contribute to a feeling of powerlessness we try to change with-yes-yet another cycle of fad-based "process and empowerment" changes. Many of these fads stem from valid management and psychological theories that we simply never invest enough time in to make them work. Others really are just pop-psychology wrapped in a fad's wrapper and foisted off onto us by people trying to make a quick buck. These later "methodologies" might have a handful of good ideas in them that will reappear sometime later in a stronger methodology.
Older managers, who have suffered through dozens, if not hundreds, of these cycles, tend to feel this distrust the most strongly. One particularly articulate manager I know explained his feelings this way: "Shannon, what you just proposed sounds great. I've heard it before, though, in the 1970s. You people failed to deliver on it then too. Why should I think it'll be different this time?"
Listen and learn
That last question-how will it be different?-provides us with both our greatest opportunity and our most common point of failure. Most IT managers I know launch into a detailed explanation of the new project plans and cool new technologies, hoping that both will somehow answer the question.
As "different" as the project plans and technology may be, though, they don't really tell the questioner what he wants to know. His question is not "how are the tools different" or "how will you do the implementation for less money and in a shorter period of time," but rather "how will you deliver the promised business improvements despite the track record of failure?"
As tempting as it would be to launch into a long, detailed explanation of business process change enabled by new technologies, the situation provides us with an even more powerful opportunity. That opportunity, to shut our mouths and listen to what our customer has to say, can slip by if we try to display our knowledge.
Instead of engaging in ritual display, I've started to ask the following questions:
* Why do you think this project is the same as all of the others to come through?
* What, in your opinion, caused the other projects to fail?
* Does anything about this project strike you as being unique or interesting?
These questions usually start off a conversation that can last for hours, if not days. During this conversation your new information source can give you unique insights into his aspect of the business, the leadership style of people completely unassociated with your department, and a history of the business's evolution you can't find anywhere else. More importantly, so long as you listen, you can continue building a rapport with the speaker. Even if you can't get him to come around to your "point of view," that rapport may give him enough trust for him to lift his opposition.
Often, as you listen, it becomes obvious that the "innovations" promised by your project really were promised in the 70s and not delivered. Worse, the things preventing the original project from succeeding (e.g., business process or management failures, lack of clear understanding about actionable information vs. meaningless data, etc.) continue to exist in the environment. What you do then depends on your situation, your own experience, and the environment in which you operate.
Sometimes, though, after listening, we discover something in our own projects we never realized was there: a clear value proving beyond a shadow of a doubt we want to deliver a real innovation, not just a gimmick. However, that value, for our clients and users, will not be what we think it is. It will likely come from some seemingly trivial innovation in interface or system design that opens up an entirely new way for our client to approach a problem we did not even know existed.