Talking the talk

Over the years, I’ve become a frequent traveler in the no-man’s-land between IT and business groups. In most cases, both sides cannot talk to each other.

This isn’t much of a revelation; it’s just the way things are. Most business people talk in terms that relate to their core interests, discussing issues of time, money, process and turf. Of course, techies have their own interests and priorities, and they talk another language altogether.

For IT management, this presents a problem you must learn to overcome. It’s imperative that you can speak with your business counterparts and superiors who are not going to learn to “talk tech.”

Fortunately, this isn’t as hard as it seems. By applying three simple rules, IT managers can greatly improve communications with their business contacts. I’ll draw on some specific IT projects to help explain. The names of the people involved have been removed to protect the reticent.

Simplify

About three years ago, I was consulting on the selection and implementation of a desktop management  system for 3,000 PCs. This was a multimillion-dollar project.

The IT group wanted something with a lot of bells and whistles but couldn’t agree on the details. They argued among themselves. Topics ranged from which products should be evaluated to what types of reporting would be needed to whether servers and mainframes also should be managed. There was no clear agenda, scope or focus.

They were also upset with business management whom they said were “stupid” and “weren’t listening.”

Meanwhile, business management said the IT people were “too impatient,” “too free with money” and didn’t “understand the issues.” They wanted to know why the project was worthy of discussion and what benefits it would provide.

In truth, the technical people had done a poor job of explaining the project, such as the purpose and requirements.

Management was thinking of canning the project.

To get things rolling again, I organized several sessions in which the technical staff and I distilled the many issues, standards and technical details down to a clear set of requirements and actions. Next, we worked out anticipated costs and a realistic schedule for the project.

Finally, we identified the principal benefits and risks of the project, linking any technical gain to a tangible business benefit. For example, implementing a new desktop management services suite and remote diagnostics were linked to leveraging of prior investment and a reduction in annual help desk costs.

When we presented the plan, details were supplemented with figures and diagrams. Business received a full explanation of project goals, scope and cost. And while there were some more questions, the project got the nod and work started.

In essence, we focused our message, removing extraneous technical details. Simplify all aspects of communication with your business counterparts.

Listen

On a more recent project, the client was rolling out a Web-based application for more than 4,000 users. Management wanted IT to develop a robust network and security architecture in order to replace a mix of dial-up, ISDN and LAN  services.

The client had tried for months to explain its goals and requirements to IT. Unfortunately, its explanations were vague and didn’t provide the type of information that IT management needed for planning.

For example, the client wanted the architecture to support aggressive user response times but didn’t know how much traffic the application would generate. On the flip side, IT hadn’t asked important questions.

Both groups were frustrated. Business management suggested that IT was being dismissive and wasn’t listening. Coincidentally, IT management wondered if their business peers knew what they wanted.

So on behalf of IT management I met with business management and asked questions about the project – who, what, where, when, why. We also discussed their ideas and concerns for the future of the project and how they felt that IT could help. When I reported to IT management, the group sent me back with questions of its own.

This went on for about three weeks. In the process, IT executives began to listen to what their counterparts had to say (and vice versa). The needed information was collected, requirements were defined, and I completed the architecture.

To get the information you need from business management, ask cogent questions and really listen to the answers.

Quantify

For another project, I worked on an IT audit and upgrade plan for a national agency with a central office.

Before the plan was finished, an internal group decided to make greater use of their Graphical Information System, which meant an increase in GIS traffic on the corporate Ethernet.

The GIS group was a minority among the hundreds of users on this network. Just the same, they wanted the network upgraded from 10M to 1G bit/sec so they would have improved turnaround on their GIS queries.

Naturally, this idea did not sit well with IT management, who felt that the requested upgrade would disrupt operations, at great cost, with little justification.

Things heated up when the GIS group got business management to endorse its plan as a strategic imperative. IT management’s concerns were insufficient to dissuade their counterparts.

So IT management monitored the GIS traffic and used the collected data to calculate realistic bandwidth requirements and formulate a new upgrade plan. They compared the new plan with a full upgrade, on the basis of cost and effort.

Armed with real measures, calculations and costs, IT management convinced business management that a full upgrade was unnecessary. As a result, the GIS group was content in getting a 100M bit/sec virtual LAN , and business went back to normal.

To help make your case with business management, quantify the details and focus on the facts.

Naturally, there’s always more to the interaction between IT and business management that hasn’t been mentioned here. But if you remember to simplify, listen and quantify, you’ll find that no-man’s-land isn’t as tough to cross as it used to be.