Project Management

Recognize user-created consulting traps

Some user groups are poised to pounce on IT consultants who go against their recommendations. Learn how you can avoid falling into their traps.

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.

Moving forward

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.

Note: This article originally published on TechRepublic on December 15, 2003.

Get weekly consulting tips in your inbox
TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!


You said: `Authority does not mean knowledge` Now, in my mind, you have described the functioning of many larger companies; where a brain dead MBA is put in charge of IT. Stupid ID10T doing stupid things all because `he is management` (or as many would say: `damagement`). In the perfect world, a CIO should be well versed in tech, and should have budgetary experience; a CIO whose experience is primarily finance, and little tech is going to cause some serious problems.Those are the companies that you should avoid at all costs. If the `proverbial substance` hits the rotating blades, I will bet that the damager, will not be standing it its path.


Good reminder to look for stakeholders everywhere.


This is typical of most consultants. they come in with a job to do and fail to check with the actual end users. If you had included these "problem" groups during the study and design phsase, then they would have been assets instead of problems. I see this happen way too often. People look down from the top and forget that the bottom is where the actual utilization occurs. Its not an IT problem. This includes Mechanical Engineers, Business managers, Social scientist, and all others that have a complicated issue to resolve.


Rykerabel, You are not taking into account the possible terms of engagement in these cases. I have been in the IT industry for over 30 years and have lost track of the number of times I have been thrown into a situation wherein the project sponsor defines the project scope and there is no opportunity to discuss the project with rank & file employees. Often, in large companies, the decisions about IT projects are made in-house by 'managers' and committees which may or may not include consultations with the other employees. Equally often, the consultant involved is given a framework to work in and has no option to talk to ordinary employees or understand the 'political' aspects of the project they are consulting on. I can think of several large multi-national companies in which any consultant attempting to intrude on the decision-making process would be signing his/her own death warrant as far as any further work for that company is concerned. In fact, in some cases decisions made at the CxO lever are unpopular specifically because they are 'intruding' on something the rank & file consider to be a prerogative of their position. (for example, locking down outside access to the Internet except for company business.) This is a viable concern when employees abuse that access, but anyone changing their open access is still going to be extremely unpopular with everyone except the project sponsor. Aside from this, as one of the examples in the article explains, employees are often completely unaware of business impacts; security impacts or costs of implementation restrictions that make their suggestions impractical. Unfortunately for the consultant, as an outsider they are going to bear the brunt of the criticism and/or blame for the changes. Regardless of this, it is the project sponsor that sets the frame of reference for ANY project as is their right; after all THEY are the ones footing the bill!! Regards, BillT


I work for the person who's signing the check. Sometimes that person needs something his/her employees don't care for. Will the consultant get thrown under the bus? Sure. But I've stopped living the fairy tale land where people are always rational. If that were so I'd only have unhappy clients when I made mistakes and I'd always get paid on time.

Editor's Picks