By Brad Powell

In a blog post last month, I broke down the three reasons that the line of business and IT departments at many credit unions can't get on the same page. Those reasons can be summed up as:

• The vastly differing level of detail each side offers and expects when discussing a project;
• The different ways the two organizations define the desired results of a given project; and
• A difference in the language each side uses when talking about technology.

Given that these differences exist, the next logical question is "How can a credit union solve them?" 

What follows are my suggestions on fixing each element of the disconnect between the line of business and IT:

1. Acknowledge the Difference in Detail

I have seen several technology projects get sidetracked in debates over details.

The line of business will check the status of a project, see a shortcoming and say, "But I expected it to work this way."

IT's response often is "But you never said you wanted it to work that way. You should have told us."

The line of business then might respond "When we set out Goal A, it should have been obvious that it would work this way."

IT expects the line of business to figure every little detail out in advance. The line of business expects nothing to get lost in translation when they set out high-level goals and leave the IT department to figure out how to achieve them.

That problem isn't going to go away. The line of business can't be expected to figure every little detail out in advance. IT can't be expected to read minds.

The key to solving this difference is simply admitting it exists.

The line of business always is going to know the results they want, and they're probably going to know a little about how technology will achieve those results.

But will they grasp every little detail? Do they know how fields are supposed to work? Do they know what's supposed to happen when a certain button is clicked?

They don't. They're probably never going to, either (not without a lot of training or study – which, frankly, isn't practical).

So I would suggest that both sides just come to expect this difference. It doesn't make sense to insist that decision-makers outline their goals in extraordinary detail before the project starts. And it's not productive for those decision-makers to harp on every detail they perceive to be missing as the project progresses.

Instead, both sides need to accept that details are going to get missed, changes are going to come, and the smart approach is to expect and plan for it.

It's really more of an attitude: being adaptive throughout the project instead of trying to get everything perfect to start with. Getting everything perfect at the beginning may sound great, but it's unbelievably hard to do in reality.

Just accept that there's no such thing as a perfect plan – and keep moving forward anyway (this applies to other industries as well, here's an example).

The sooner both sides acknowledge and accept that, the sooner they will be headed toward success.

2. Create a 'Rulebook' for Results

As I explained in my previous post, the line of business and IT departments define what they're looking for in a project differently.

One big reason they have different perspectives is that IT's job of ensuring systems' stability and security naturally conflicts with any effort to innovate (many tech entrepreneurs, in fact, like to say innovating requires "breaking things").

Mitigating this difference starts with identifying the key results a credit union wants from a project and making them the guiding principles of the project.

Those principles will govern everything that happens in the project from start to finish. It defines how the competing desires for innovation and stability will be balanced. And it gives everyone the background and context needed when it comes time to make hard decisions such as, "Should we add features and extend the project timeline, or should we stick to the timeline and sacrifice functionality?"

The key results, defined ahead of time, become the "rulebook" for how the project will proceed.

It's important to note that both line of business and IT department goals have a legitimate place in the rulebook.

When a project lacks such guidelines, IT values – about process and long-term support – often get overlooked or pushed to the side in the planning stages.

And then later in the project, those desired results start to become more important while the results that line of business prioritizes tend to get swept away.

Once the project "machine" gets going, the people working on it are apt to lose sight of why they're working on it in the first place. "Getting it done" becomes the only thing that matters.

That's why you need to set out guiding principles. The "rulebook" (at Axiaware we call it a "Project Charter") makes it clear what results the organization as a whole is looking for, and explains "This is why we are doing this project."

It's crucial to make sure all parties involved with the project know what's in the rulebook. Talk about it all the time.

3. Find Translators and Time to Talk

When line of business and IT organizations have a hard time understanding each other, the fix is fairly obvious: find someone who can speak both languages and create a common understanding.

Sure, there are some executives in the line of business who understand technology, but when get into the nuts and bolts, it's asking too much of them. That's not what they are good at, and that's not what they were hired for.

Similarly, there may be people in the IT department who grasp the high-level goals the line of business sets out. But in the end, they will be predisposed to see things from a technical, detail-oriented perspective. That's why they're in IT.

Neither perspective is wrong. But they make it hard for the two sides to truly connect when they communicate.

So a credit union needs people who can understand both sides – people who can look at a problem from either perspective, understand the context both organizations bring to a project, and speak both languages. Find those people inside the organization our bring them in from outside – but use them.

Additionally, both sides need to make time to talk throughout the project. Schedule ongoing, iterative progress meetings, attended by all key parties. In those meetings, insist on two-way communication and immediate feedback.

Both sides should verify what a message is by repeating it back in their own "language." That goes a long way toward surfacing "reading between the lines" issues and reducing unanticipated consequences.

These regular meetings need to feature a lot of questions like "Here's what I'm hearing you say ... is that what you mean?" and "If we do this, does that mean X?"

If there's one common thread in solving these three problems, I would say it is the need for establishing a great customer-vendor relationship inside your credit union.

The line of business needs to be treated as the customer, and the IT organization needs operate as the vendor. (An outside tech organization could be the vendor, but the same principles still apply.)

As the vendor, the IT department needs to see the line of business as an important customer. That means they need to be ready for any surprises the line of business might throw at them, and they need to work through them and try to deliver as much value as possible to their customer.

On the other side, the line of business needs to look at IT as a key strategic vendor. That means they need to understand the unique issues and circumstances IT faces, and work through them so both sides win.

That stronger that relationship is, the better the final product will be.

--

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.