By Brad Powell

When I speak with line of business leaders at credit unions, it's not uncommon to hear them say things like, "My IT shop is really hard to work with."

And when I speak with the IT department at credit unions, I often hear them say, "You know, the line of business doesn't really understand the complexities of what we have to do."

Sometimes, I share this observation with people I meet from other industries. They almost always shake their head and say, "I know, that's how it is at our company as well."

So it's clear to me that credit unions are not alone when it comes to the perceived misalignment between the line of business and IT organizations.

The good news is that the root of the problem can be explained easily, broken down into three simple parts:

1. Level of Detail

A common conflict I have seen develop in technology projects often plays out like this:

• A credit union launches a significant project to build a system, and the line of business stipulates, "We want members to use this new system to fill out new loans, as well as do these three other things."

• The project proceeds, but as it nears completion the line of business takes a look and says, "Hey, this isn't doing what we want it to do."

• The IT department responds by saying, "Well, you didn't ask for that," "That wasn't in the requirements," or "We would have never known that."

This happens because these two organizations offer and expect widely differing levels of detail.

The line of business side frequently communicates in terms of the big picture – high level goals, not point-by-point requirements.

The IT department, meanwhile, often doesn't understand some of the bigger issues. But they understand the details really well.

That causes a disconnect in the conversations – a disconnect that can end up being quite difficult to get past.

2. Desired Results

If you dropped into just about any technology project at a credit union and asked, "What are the results you're looking for?" you would probably get two different answers.

The line of business would reply with goals like "Reach more members," "Convert more touches into booked loans," "Increase our reach by using e-signatures," or "Be relevant in the marketplace for the next 10 years."

The IT department probably would provide responses like, "We need to complete all the steps in our process," or "We need to make sure we can support this system for years to come."

Why do the two sides define results so differently? Often, the primary job of an IT organization is maintaining the status quo of systems within the organization. You might define their role as security and stability.

So when the line of business wants something new and innovative, that creates conflict. IT wonders how it can maintain order while innovating, introducing new features without breaking things.

Both perspectives are legitimate – and both sides identify important results for a credit union's technology project. The problem comes when one of those results negates the other, or the process defines the result instead of the desired results defining the process. In the end, neither side gets the results they are looking for.

For example, as many projects near completion, the big questions all are expressed in IT's terms: "Did the work get done?" "Is it on time and on budget?" "Did we follow our process?" "Does the system comply with our coding, security, and compliance standards?"

These are all important elements to review, but someone also needs to ask, "Did the project actually address the business goals we were originally trying to achieve, and did we get those results? How are we going to measure those results?"

A lot of times, especially as credit unions near the end of a project, people stop discussing the bigger-picture results. It's just, "Get it done."

But both kinds of results matter. It's crucial to remember that at all stages of a project.

3. Language

Just a few days ago, a customer forwarded me an email, explaining, "I asked the IT folks a question and here's the answer I got back. I don't understand it. Can you tell me what this means?"

I read the email, then called her back and explained what they meant.

She had asked the IT department a perfectly legitimate question. And the IT people replied with good information. But the answer wasn't in a language that she, as a line of business executive, could understand.

I see this happen quite a bit. Sometimes during a project, the line of business will offer feedback to IT along the lines of, "Hey, this isn't what we want," or "This isn't working the way we want it to."

And the IT organization will respond by describing exactly what's going on with the project: "This specific part had a malfunction, but X, Y and Z are all fine," for instance.

The line of business usually doesn't understand that sort of reply.

The real problem is language. It's like one side is asking questions in French, but getting answers in German.

Not only do the two sides struggle to understand the language the other side uses, they often don't understand the context of the question or the answer, either. Many IT folks simply do not get business nor the terminology.

The same often can be said of the line of business's understanding of IT jargon.

In the example above, when a line of business representative says, "This isn't performing the way we want it to," and the reply from IT is that "there was a malfunction, but X, Y and Z are working," that is pertinent information. But doesn't actually answer the question in the context it was asked.

This is a problem that goes both ways – the line of business often replies to IT in a "foreign language," as well.

At root, there's a fundamental disconnect in the way both sides communicate with each other – their language -- and the context surrounding that language.

Detail, results and language: keeping in mind how the line of business and IT organizations view them differently can help reduce the disconnect that so many organizations experience so often.

The question this raises, of course, is "How does a financial institution address these disconnects?" Click here to read our follow-up post on "making peace" between the line of business and IT.

--

Compliance and Your Credit Union

• Face an daunting burden of regulatory requests?
• Struggle to manage the multiple experts inside and outside your organization who must respond to exam requests?
• Use email for regulatory communication -- possibly opening yourself to legal discovery?
• Receive the same request more than once but provide a different answer each time?

If these challenges sound familiar, Axiaware's new credit union compliance software product, Redboard, could help.