Building Collaboration Between IT and End Users

“I’m afraid I can’t process that for you right now. It’s the system.” That was from a retail clerk at a large box store. I looked at my watch, thought about the day’s to-do list, and tried not to show my frustration while definitely understanding hers. Was it really the system? Or was she having trouble understanding how to use it because she was a trainee? In the end, it didn’t matter. Whether or not she was encountering a system problem, not being trained to use a new system is also problem, and both issues arguably belong to IT.

As an ex-CIO, I didn’t always think this way. Earlier in my career, I believed (like many in IT) that if the system was working as it was designed, but a user didn’t understand how to operate it, it was the user’s responsibility to learn it. I quickly learned from several missteps in projects that this was anything but true. The truth is that if anything goes wrong with system processing, whether it is in the software or a user’s lack of knowledge, the problem is still the system, and IT owns the system.

How does this fit into today’s collaborations between users and IT?

Think about cafeteria food.

Remember your high school days, when everyone had different opinions about teachers and classes, but there was universal agreement that the cafeteria food was bad.

Systems can be a lot like cafeteria food. Whenever anything goes wrong with a business process, there is a rush to blame the system. Invariably, the blame reflects on IT. This can adversely impact relationship building and collaboration with end users, because the natural, human impulse is to defend your work, especially if the problem isn’t the system at all.

Making Relationship Building the Primary Goal

The blame game between users and IT can be reduced, and even eradicated, if there is a sound working relationship. Sound working relationships are built when communications are open and straightforward, and when everyone focuses on getting the business processes and systems optimized for success, not upon blaming each other.

To focus on and to optimize the performance and reliability of business processes and systems, it helps to take these steps:

How to Fill a Tall Order

These steps are pivotal to relationship building but taking them isn’t easy. The most common break point in the process isn’t technical, it’s human.

What happens in project planning is that IT and end users tend to short-change the time and tasks that are needed to train the people who will be using the system. When business process and system revisions go live, these users might not know how to handle certain exceptions that come up in business processing. In other cases, it might prove difficult to navigate the system, or there might be bugs in the business processes and systems themselves.

One way to minimize these sources of end-user confusion and frustration is to pilot a new business process or system for usability, as well as for technical soundness.

Here is an example:

As part of the business process and system definition, end-user managers define a set of business rules that IT codifies in the application. One of these rules is that any purchase that a customer returns that costs over $1,000 must be approved by a supervisor. IT codes this business rule into the software, and it is anticipated that a transaction like this would seldom occur.

The users then test the new business process and system in normal operating conditions where merchandise returns don’t exceed $1,000 and everything works fine. The system and the business process go live. It’s working great until a customer walks into the store with a merchandise return that is over $1,000, and the clerk can’t execute it. “It’s the system,” the clerk tells the customer. “It won’t let me do this.”

This is not a case of the clerk blaming the system, because the clerk was never made aware of the $1,000 limit that required a supervisor’s override. Instead, this is failure in user education.

If instead, the business process and system pilot test run had included a script of user exception processing that addressed exception handling based upon the defined business rules as well as routine processing, it is likely that the clerk would have known what to do.

This may seem like an obvious testing technique. However, in my experience, I have seldom seen a pilot test of a business process or system that was testing for user knowledge and ability to execute exceptions. Instead, the focus is on the workability of technical aspects of the business process and system.

A more holistic approach is to pilot-test both the technology and full usability of business processes and systems.

Focus on Continuous Improvement

A business, business processes, systems, and humans undergo continuous change. It therefore makes sense that IT and end users should emphasize both change and continuous improvement in the work they undertake together.

The CIO and IT leaders can take the initiative by regularly visiting with end-user managers to see how things are going. Just stopping in the doorway of an end-user manager and saying hello can go a long way in keeping communications open.

What to Read Next:

Bridging the Digital Dexterity Skills Gap

Protecting From the Threat Within: How To Manage Insider Risk

Building a Chatbot That Humans Will Actually Like