A Proxy for End Users

I spend a good portion of my time helping organizations choose the best technology solution to meet their specific business requirements. Part of this process, as you would expect, is determining the business requirements of the end users. In many organizations members of the IT group act as "proxies" for the end users. The question is, does this work?

Firstly a proxy can be defined as "an ally who can be relied upon to speak on one's behalf." This means that if an IT member is acting as a proxy for end users then they are expected to speak and act in the best interest of the end users. Which means they need to clearly understand the objectives and obstacles confronted by the end user. And this is where the problems start to occur.

IT professionals know technology, they work with technology every day and as such they often make assumptions about technology that end users do not. For instance, most IT professionals have a tendency to believe that most communication and collaboration applications are "easy to learn." End users on the other hand are most focused on solving business problems and often have little patience and little practice using so-called "easy to use" tools. I would argue, a tool is only easy to use if you know how to use it - pretty much a self-referential definition.

Over the years, it has become clear to me that without exception it is always better to talk directly to the end users.

Many times IT professionals suggest it will take too long to schedule meetings with the end users. They say we really need to "get going" and make a decision. When I am brought in they are often already behind their original schedule - perhaps they have been stuck in "analysis paralysis" for months. They are anxious and it feels urgent to have me help them make a decision. Sometimes in the initial meeting they ask me directly, "what do you think we should do?", hoping for an instant decision so they can move forward at the pace of a hare.

What I do know is that sometimes you need to go slow to get done more quickly. Sometimes you need to be the tortoise. Software development goes more quickly and is far more successful when you take the time to document an application's design. I guess you could build a house without plans but I'm not sure it would still be standing in a few months and it most likely would not please the owner. Similarly, implementing an effective communication solution works best when you take the time to meet with and speak to the end users. This way you have the best chance of meeting true end user requirements.

Often the IT proxies ask me, "do you have a list of questions you plan to ask the end users?" My real answer is "yes and no." Yes, there are some standard questions I generally cover to get the conversation started. Things like "Do the current communication tools meet your needs?" and the inverse "Do you have any trouble areas with the current tools?". But "no," I can't predict where the conversation will lead.

Each and every time I meet with a true end user I learn something important. Sometimes I learn a key fact simply by seeing their work area. I see that speaker phones won't work because they are in an open concept office. I learn "presence" between the boss and her admin isn't all that relevant because they sit next to each other. I might see the computer that has been equipped with a USB speaker phone is connected nowhere near the meeting table where it is to be used.

During my discussion with end users I get a feel for their perception and acceptance of the existing and future technology tools. I get a feel for the culture and its acceptance of change. I better understand the level of training they have received and their opinion on whether more training is needed. Often other individuals I should speak to are suggested.

My process is to capture the end user discussion notes and then to send the notes back to the end user to review and validation before passing them on to anyone - even the project sponsor (who is likely in the IT group). This way I'm sure the end user is "comfortable" sharing the observations I captured during our session. This is important because often end users suggest areas for improvement, things IT can do better. This type of important and insightful information is rarely captured when I am limited to speaking with IT proxies.

My best case situation is that I am allowed to perform end user interviews and also permitted to survey a broader sample of end users. The interviews provide excellent "deep" qualitative details. The survey provides broad, quantitative data - the type of data you can transform into meaningful and informative charts. Although sometimes reluctant, in the end the IT group, who are often logical, quantitative thinkers, is always happy having the concrete results from a survey.

A few years back, I worked for a large bank and conducted a survey of retail branch staff in a collection of job roles located all across the country as it related to communication needs. The results indicated key geographical differences and the scores were both higher and lower in unexpected and unanticipated areas. As I continued to do work over subsequent years at the bank, time and time again I saw graphs from my retail study used to support additional IT projects. Conducting a proper survey takes time but sometimes you need to be the tortoise to win the race.

Another argument I hear from IT proxies is that it doesn't make sense to talk to the end users because they do not know what is possible. The reasoning being that true end users will not ask for a specific technology because they simply are not aware that the technology exists or they do not know the functions their current tools can perform.

This argument makes the incorrect assumption that the intent is to ask end users about technology selection. The purpose of gathering end user feedback is to better understand "what" would make their business processes more efficient, that is to say, the business requirements. With clear, documented business requirements, the IT group, often with assistance from a UC expert, can help determine the "how," evaluating and selecting the technology tools that best meet the documented business requirements.

In fact, I have found it is often better to talk to people who do not understand the technology. Members of the IT group often blur the distinction between the "what" and the "how." They are much more likely to express the requirement as "we need to install this technology" which almost always is not a true business requirement. IT often jumps to "solutioning" before defining overall success criteria for the project. End users may not know certain technology exists but I have never had end users be shy about pointing out areas for needed process improvement or indicating "pain points" with existing toolsets.

While sometimes I am restricted to working with end user proxies, my experience has taught me that that the best "ally" who can speak on behalf of an end user is the end user themselves.

At the UC Summit you will have an opportunity to discuss different methods for gathering end user requirements with other consultants, resellers, vendors and industry experts. If you are looking for opportunities to learn new options to help grow your business, please consider applying to attend.