In the good old days, users feared computers. We intruded into the cube walls, left a strange device, and then walked away. Sometimes they used them. Mostly they stared at them with morose fascination then eventually went out to surf the Web. A few organized and motivated users founded users’ groups to help “develop technology decisions based on the user perspective”. As computer literacy became more prevalent, these user groups also grew, until we now find them at nearly every client site.
These groups take on many forms. Sometimes they are informal organizations run by a handful of confident users. Occasionally they start out as “focus groups” and end up becoming a permanent part of the IT decision-making process. A rare few come from groups of interested users drawn from all aspects of the business to inform technical design. Regardless of their composition, consultants need to work with them without getting bogged down.
All of the user groups I have encountered over the years fall into three broad categories: groups headed by confident users, formal groups brought together by management for specific purposes, and groups of decision makers attempting to exert influence over critical decisions outside of their own area of expertise.
Confidence is not competence
My first encounter with a user group threw me headlong into one of the most difficult situations these groups present. My client desperately needed to upgrade his workstations from the existing clones to anything that was more stable. My company arranged a good deal on the new hardware and threw in the deployment at a relatively low cost.
After planning the upgrade and buying the equipment, we began to encounter unexpected resistance. Many people were not happy with the new computers replacing their five-year old clones. They stared at us resentfully as we took away their barely functional machines. Finally, I brazenly asked one of them about his problem with the new computers. He told me that “John” told him that his new computer was a piece of cheap junk.
Now, I was pretty upset. We sold those desktops at cost to get the deployment work. They were nice machines for the time. So I started asking around. It turned out that everyone knew and trusted this John. He was the informal technical guru of the shop floor. He went so far as to organize his own computer meetings after hours. Obviously computers interested him.
After I eventually tracked him down, something else became abundantly clear. He had no knowledge of computers. He definitely had interest in computers, but he never really worked with them before. Nonetheless, he knew more than his compatriots and that gave him the confidence to make declarations. Once he made a declaration, he would not back down. Try as I might I could not get him to change his mind.
From the perspective of experience, I should have taken a friendly approach with him. Instead I proved him wrong, time and time again, in front of his boss and peers. Humiliation eventually drove him to shut his mouth around me but it did not solve the long-term problem.
This kind of user group appears in all organizations. People look to their cube-mates and coworkers for help with technical problems. They ask around, and eventually find someone who can help them. The ringleaders can be competent, but they are almost always overconfident in their own abilities. We can most effectively deal with these groups by being friendly and open with the primary influencers. This allows us to turn the group to our advantage, using its informal communications network to gather and distribute information.
Focus groups and the aftermaths
My first encounter with the aftermath of a focus group met with a similar level of disaster. As in the first situation, my company was working on a simple desktop upgrade. During the deployment we encountered resistance from several key employees who seemed to have an inordinate amount of influence over their coworkers attitudes about IT.
It turned out that these individuals had participated in a focus group about messaging and electronic communications six months before our project started. During the week-long session, upper management honestly listened to their opinions. They did have an excellent understanding of their business requirements, and most were articulate individuals who wanted to help the company succeed.
However, after the focus group, the situation turned negative. Participation in such a high-level activity gave their opinions a patina of official legitimacy among their peers. They stayed in touch with one another, sharing ideas and insights. These three factors combined to give them tremendous power within the informal social network of the company. When decisions were made that did not agree with the focus group’s recommendations (like our deployment schedule), the formal and informal organizations of the company came into conflict. The resistance we experienced was just one symptom of this overall conflict.
I have found that I can most effectively deal with these groups by asking for management assistance. As outsiders, consultants simply do not have the social capital to defuse these situations. A friendly and open demeanor can negate individual problems but does not address the underlying tension.
Authority does not mean knowledge
The third type of dysfunctional user group occurs when a manager or group of managers, competent in their own areas, decide to drive basic technology decisions. This is usually a phenomenon that comes out of large companies; smaller organizations tend not to have enough people to support them.
My first encounter with this kind of group defined the archetype. My client, an international manufacturing firm, wanted to deploy a new messaging server backbone. The senior, our engineers, and I worked away for several months testing various configurations. Eventually we found a reasonably priced set of servers that could do the job and would support the company for two years, based on their expected growth.
The project sponsor asked us, as a courtesy, to present the new design to the guidance group composed of interested function/site managers. We were happy to do so. Nothing in our plans involved a desktop configuration, or even service interruptions. Letting users see the inside of our design did not seem like it could cause difficulties.
How wrong we were. The guidance group declared that our design was not technically satisfactory. They lambasted us for not going with a big iron solution. Eventually the senior got the meeting back under control. He very politely began to show them why their suggestions were not cost effective based on the corporate situation and overall IT goals. After their eyes glazed over at the discussion of CPU architectures and memory utilization, they continued to argue for their preferred solution.
It finally dawned on me that they were afraid to admit that they did not understand the situation. Not knowing something is an admission of weakness in the corporate world. In order to deal with this situation, we should never have brought up the technical design. Instead, we should have asked them pointed questions about their business’s interaction with the messaging system. Answering these questions would allow them to demonstrate competence in front of their peers, saving face for them and causing us far less trouble.
Obviously, the three categories I describe above derive from dysfunctional experiences. However, I have in the past encountered functional user groups that have helped the project tremendously. Some are formal structures called together by the company to assist the IT department. Others exist in the informal corporate structure. In either case, they provide us with extremely useful information about the business that we could not otherwise access.