In Part 1 we identified two issues that plague many technology implementations: 1) Improper Training and 2) Resistance to change. In Part 2 we will look at techniques to build support for your technology implementation.

It is rare that you will receive the same degree of enthusiasm regarding new technology from all users, but it is possible to achieve consensus. Consensus is a “win/win” methodology that focuses efforts on reaching a point where everyone is at least willing to lend support to the final decision and help carry it out. You can greatly reduce the complaint snowball effect by putting a cross-functional group of stakeholders together during the planning and implementation of any new technology and working to achieve consensus.

To achieve consensus, each person must answer the following questions, either directly or indirectly:

1)   Have you been accurately heard?

2)   Have you listened to others?

3)   Why are you unable to support the recommended decision?

Based on the responses from the cross-functional team members, you can determine what facts or changes will enhance the team members’ understanding of the recommendation.

Building a cross-functional team with influential members from all departments affected by the change is critical. When bringing together employees from various departments, it is important to do three things:


Unite the Group

The chief danger here is aggression. The dominant or higher ranking members of the group will want to control the group. During initial team meetings it needs to be made clear that there is no rank in the room. Make sure the focus stays on the problem (aka “Focus on the pain”). Never appear to take sides, even if someone is blowing off steam.

Focus the Group

The chief danger here is getting off the point. Remaining focused on what the technology is trying to solve is key. Since you will have a cross-functional group of individuals, you will need to take time to test comprehension of the group. Do this by asking specific questions, not just saying, “everyone understand?” or “does anyone have questions?”.  If someone has an idea or pertinent input, be sure to paraphrase their statement and have them confirm your understanding.

Mobilize the Group

The chief concern here is squashing good ideas. This typically happens once the group becomes familiar with each other after several meetings and is hitting their stride moving toward the goal. You will begin to notice team members who are either not engaged or don’t give any input to the discussion. These people need to be protected and encouraged to participate. A common technique is to go around the table and ask for input.

Once the group has achieved consensus, the technology has been installed, configured, and put into production, you will have a group of people among the user community who will champion the technology and squelch the complaint snowball.

After many years of participating in and leading technology projects, I’ve learned that the most important part of technology is the human side. RJ Young recognizes that having a Project Manager to bridge the gap between the technology and the human side is essential and sets the company apart from most of our competitors.

Read a real example of how RJ Young helped a customer implement document management technology. 



Working in the Information Technology field since 1988, I’ve always been an early adopter of technology. I enjoy finding solutions to problems using technology, but I’ve never lost sight of the fact that people have to drive the technology.

While holding positions in IT management for various companies, I liked to employ a practice I called “MWA” (Management by Walking Around). I took time to listen to people vent about technology (or lack thereof) and made efforts to learn the job role of each person in the company. I always paid special attention to how information flowed through the company. I was shocked to find out that in most companies I worked for, antiquated business processes were still being used under the guise of  “that’s how we’ve always done it”, “if it isn’t broke don’t fix it”, “I just do what my manager tells me to”, “we can’t afford a solution”, etc.

Even after implementing solutions which streamlined processes, reduced liability, insured business continuity and disaster recovery, and showed a return on investment, my “MWA” visits would often reveal the same complaints. How can this be? The company just spent a good sum of money on improvements. A quick check of the newly implemented system would reveal limited or incorrect use. As a member of IT management, I was always careful not to jump to the conclusion that the issue was caused by the loose nut between the keyboard and the chair. Most of the time I discovered two things:

1)   Lack of training

2)   Resistance to change

Just as we have to show value to decision makers who approve the purchase of technology, we also must create value in the minds of those who will be living with the technology on a daily basis. Of the two root causes listed above, the second is perhaps the most serious and will require the most time and effort to rectify.

When new technology is brought into the business, there is typically a great deal of excitement on the part of those who will use it. However, after implementation, after all the money has been spent, after all the training has occurred, the grumbling begins. Users of the system begin to complain about specific functions of the software, or question why this feature or that feature wasn’t included, and the complaints take on a snowball effect. Soon, those who were instrumental in bringing in the software are seen as ignorant and out of touch with business practices. If possible, users of the technology will fall back to what they are most comfortable with, the old way, even if it’s an antiquated or broken process.  The reason why used to puzzle me. Wouldn’t it be easier to raise your concern with the system administrator and find a solution to the problem? Complaining never fixed anything. Why won’t those who are dissatisfied come forward with a suggested fix? What I learned was the problem had nothing to do with the software. It had to do with someone feeling disenfranchised, ignored, or just plain unimportant. And yes, even the big guy in accounting who used to play college football can get his feelings hurt and will find a way to submarine the use of new technology.

In part two, we will look at techniques to build support for your technology implementation, and how to empower stakeholders in the implementation process.