The question about the pros and cons of using a business/IT liaison person came up at a meeting I attended last week. I’ve got to admit some bias on this issue. Long ago I tried using a business/IT liaison person for one of my software development groups, and I wasn’t happy with the result.
The person typically assigned to a liaison job seldom has enough technical savvy or in-depth application experience to fairly represent IT to the business. As a result, the liaison person will often make inappropriate technical assumptions that create unrealistic expectations for the business. That’s what happened when I tried using a liaison, and I ended up getting rid of the position.
Here’s the Problem
In theory using a liaison person sounds like a good idea. We know that many IT people have difficulty communicating with business people, and so it seems reasonable to put a “translator” in place. But while language translators like those in the United Nations mostly translate what’s being said in an unbiased way without having their own agenda, the same cannot be said for liaison people. Invariably I’ve found that over time the liaison people gravitate toward either the business or IT camps, and begin to take sides in disagreements. Often their job turns into more of an expeditor function than a translation function — they badger the IT people to get the business people what they’ve asked for, and usually do little to clarify requirements or to help negotiate a smaller set of requirements that can be delivered faster.
Eventually a two-way disagreement between business and IT evolves into a two-way disagreement through an intermediary. This magnifies the problems rather than solving them, since all of the interactions take longer, and it’s much less likely that personal relationships will develop between the business people and the IT people. Often the business people will feel better using a liaison person, but the IT organization will lose touch with what’s really going on in the business. The net long-term result will drive a wedge between business and IT.
Why Do Companies Use a Liaison?
So if liaison people are so likely to cause problems, why do so many companies use them? There are a number of scenarios:
- The business forces the position on the IT organization. This is a sure sign of imminent IT organization failure, and usually precedes the search for a new CIO. The business is essentially saying, “I’ve given up on dealing with you — give me someone new to talk to.”
- The IT organization is so caught up in constant interruptions that they create the liaison position to keep the business people off their back — kind of like setting up a complaint department. Again, this is not a good sign. Why are the interruptions occurring? You should solve the problem instead of trying to cover it up.
- The IT organization has done a poor job of hiring project leaders and analysts with business communication skills, and the liaison position is created in an attempt to work around the hiring problem.
- The business organization has abdicated their own responsibility for designing and improving business processes, and the liaison position is created to fill the gap. In some cases this means that the liaison person tries to design systems (usually with limited success due to lack of experience). In the worst case (I’ve seen this happen), the liaison person can get so frustrated with the IT group that the liaison person tries to outsource the systems design or even purchase an outside system directly without going through the IT organization at all. But guess who ends up inheriting the support and integration of the outsourced system? The IT organization, of course.
Is There a Solution?
If you’ve already fallen into the liaison trap — or if you’re seriously considering it, then here’s my advice:
1. First, get the support of your CEO (or lower-level senior executive if you’re trying to solve this problem at a lower organization level) for integrating process and system responsibility into the business organization. I’m not talking about the technical responsibility — that stays with IT. I’m just saying that business processes (how a business operation is carried out) are a part of the business — not something that should be handled by IT.
2. A business should be responsible for the processes it uses — you can’t delegate processes to another organization like IT. Bring in a process consultant if necessary, but some way or another, get a basic understanding of the fundamental business processes that you use in your business, and how the computer systems fit into those processes.
3. Get an overall picture of the status of each of your business processes. Are they working well? Do they need improvement? Are they broken? Can they handle the current and future volumes that are required by your business? Are they cost effective? Where deficiencies are noted, what plans exist for corrective action? Joint meetings between business and IT people are required to plan and implement the required corrective action.
4. Eliminate the liaison position(s). Replace them with regularly scheduled get-togethers between business and IT people. Hold joint training sessions if necessary to improve communication between the two groups. It’s not important for business people to understand all of the technical stuff in IT, but it is a requirement that IT people understand the fundamental aspects of the business processes they support, and are able to communicate with the business using business language. If your people can’t do this, then find someone who can (as a replacement — not as the totally unnecessary liaison position).
5. Prioritize your business needs so that IT can focus its limited resources on the most important things. Many liaison positions are really just ways of coping with a lack of business priorities. When everyone in business wants everything at once, how do you expect anyone to successfully perform? Having a liaison doesn’t solve the problem — it just gives you a full-time person to hear complaints.
6. If you don’t have an IT strategy to help you prioritize your IT effort, then get one. See some of my other articles on strategy, or take a look at my book or white paper on the subject.
There are situations in life where a liaison person makes sense. You typically see the liaison position successfully used when two independent organizations want to share information. For example, the liaison job is widely used to coordinate the sharing of information between different parts of the armed forces, or between different government agencies. The key to success in these situations is that there are no critical dependencies and few time-critical issues.
That’s not the case between the business and IT organizations, where there are many dependencies and tons of time-critical issues. Using a liaison person forces you to do partial delegation — something that’s almost impossible to control. To the IT organization, the liaison person is representing the needs of the business users, but you can’t get user buy-in through a liaison, so a project failure is much more likely. To the business organization, the liaison person is representing the collective technical expertise of the IT organization, but the nuances of design choices often get lost in the translation. To both organizations, the liaison person creates a barrier to trust — how can you trust the members of the organization when you don’t ever spend any time with them?
The net result is that using a liaison person is a short-term way to postpone dealing with a longer-term problem. You’re better off facing the problem directly and helping your business and IT organizations work together to achieve a good day-to-day trusting relationship.
How Does Your Experience Differ?
I have heard no stories about the successful long-term use of business/IT liaison people. I occasionally hear about a short-term success, but invariably the stories have an unhappy ending in the long term. If you have a story of long-term success, I’d like to hear it.