Overcoming Resistance to the New System
Billy G. Griffin South Carolina Electric and Gas Company Electric GIS 246 Stoneridge Dr. Greystone II Suite 101 Columbia, SC 29210 Abstract IT projects are often proposed, developed and implemented without much regard for the end users. However, the project’s success depends on their acceptance and usage. As we play our roles in the development and implementation, we know that it is in the users’ best interest to support these systems. Sometimes we are blind to the many changes this will require on their part. They will resist and we must respond. The author will share past experiences and lessons learned. These will include many things often taken for granted, such as a convenient training facility, a friendly, knowledgeable and patient trainer, methods for addressing user suggestions, and strategies for scheduling around busy work loads. This paper will also explore ways to minimize the negative impact of resistance and improve user buy-in as the project grows. Topics such as establishing an active user committee to address user issues, setting up an enthusiastic “help desk” to quickly handle the snags and glitches they will encounter, and providing an easy to use Training and User Manual Readers should get a good idea of where to expect resistance and have several tools to handle the resistant user and possibly turn him into an advocate. Introduction IT projects are often proposed, developed and implemented without much regard for the end users. However, the project’s success depends on their acceptance and usage. As we play our roles in the development and implementation, we know that it is in the users’ best interest to support these systems. Sometimes we are blind to the many changes this will require on their part. They will resist and we must respond. How we respond may be as important to our users as our response itself. Objectives of this presentation The primary objective of this presentation is to recognize and respond to the resistance that will come with new technologies. This is a multi-phase process that can be broken down into manageable parts. First, know the players and be prepared for resistance. Minimize the resistance by gaining acceptance proactively, and involve the user community continuously to promote ownership. Know the Players Before any change management or resistance management can take place, we first must know the players in the game. The primary player, of course, is the user community. The other side consists of the project team, primarily the Trainer and subordinate support personnel. In the middle of the ring is the Project Champion, the management representative to moderate the differences and calm the waters when necessary. The User Community will be a diverse group of employees. Some will be new to the business and some will be the veterans of many “new” systems. Some will grasp new technology and some will have difficulty. All will have an opinion on how things should work. Of the User Community, the newbies will embrace the technology the easiest. Others will be like sleeping dogs and accept the changes thrust upon them. Some will be loud and vocal on the downfalls of technology. Try to enlist them. Feed them ownership principles and convince them that they are valuable. Turn them into the Super Users and make them feel like they are the smartest people in the company. The Trainer and other project support personnel are really sales and promotions experts. As an application trainer, my own observations indicate that about 10% of my time is spent actually training. Of the other 90%, the vast majority of this time is spent promoting the applications. Answering questions like “How is this going to make my life better?” or “What’s in it for me?” A good Trainer will have the patience, knowledge, and personality to handle these issues. What is the Project Champion? He is the player in a position, Vice President level if possible, to encourage development of new processes and promote, encourage and enforce their use among his subordinates. He is the person who can make or break an Information System project. He must be kept well informed on the purpose and progress of each application so he can answer to President and/or CEO. Be Prepared for Resistance (why do they Resist?) Resistance is basically “fear of change”. Why are people afraid to change? We have all heard reasons like ‘We’ve always done it like this.’ ‘The new way is too slow’. ‘I can’t’. ‘I’m too busy to learn more stuff’. Sometimes the user doesn’t understand the reasons for progress. Misunderstanding the goals of a project is one of the biggest contributors to fear of change. If the user community is given a benefit analysis early in the project, they may see more clearly the need for change. But a general rule says that the last system is the best technology and the upcoming system is to be feared. Until another comes along, this new beast will be hated. Then the cycle repeats itself. People tend to love the last big change and hate the next big change. Acknowledge that resistance to new systems comes in many forms from quiet refusal to use new tools to the hostile, vocal and sometimes uneducated reactions and undermining of a project. Minimizing Resistance or "Heading it off at the pass" By knowing resistance is coming, it will be easier to strategize a path to overcome it. I have eight basic steps to accomplish this. Involve the User Community – Prior to and during development Secure the Project Champion Test the product thoroughly Answer the Why question early and often Train the users Involve the User Community – During implementation User support Involve the User Community – After implementation Involve the user community - Prior to and During Development Experience with a previous product implementation told us that if we were to develop and implement an application that the users were going to have to use, there would be widespread dissent. Nothing about it would be satisfactory and the tool wouldn’t get very good reviews up the corporate chain. With that knowledge, and the encouragement of management, a steering committee was formed. The purpose of this committee was to bring the end users’ ideas and experience to the development table. A steering committee should be a diverse group of users who bring a full spectrum of methods and business rules to the development team. Each member needs to have his own manager’s support to be 100% dedicated to the outcome of the project. They also need to have all users interests in mind and no personal agendas. Meet with them often during the development process. When modules of the product are conceptualized, show them. Find out their likes and dislikes. Make sure they know how the system works. Secure the Project Champion Have a Project Champion – an executive who is 100% committed to the success of the project. This person should have the authority and willingness to promote, support, and enforce the use of the product. The Project Champion, by having ownership in the project, should provide support to the project team both up and down the corporate chain. This person should also be willing to dedicate the time and effort to learn about the product and have the knowledge to answer basic questions about it. The Project Team must be able to dedicate the time to keep him/her informed. Test the product thoroughly Prior to release, make sure the product performs. As each member of the development team brings different skills into the team, each may be responsible for a module or process within the product. Make sure each team member does his or her part to insure the application works as advertised. If it doesn’t, there will be a high price later. If their time permits, this is also a good place to bring in the Steering Committee and let them perform some of the testing. They will be finding out what is going on in the background and preparing for their future role as a Super User. Answer the "Why?" Question Early and Often In each IT project, this question looms very large. ”Why are we doing this anyway?” It may be consolidation of work functions, building a clearinghouse for corporate data, or a simple tool to reduce time and effort. Every time, this question must be answered to the end users. Tell the truth. If consolidation of work functions means eliminating jobs, tell them. If the data was poor before and the new process will improve the data quality, tell them. If the new process is going to impact other processes they have grown to love, tell them. Prepare them for each new thing early and often. It will make it easier on everyone if the change is digested slowly. Train the Users Training is a major issue and has many components. These components include the Trainer, training environment, documentation, class structure, and scheduling. The Trainer must have a thorough knowledge of the product and all of its quirks. He/she must also be a person with excellent “people” skills and a soothing personality. Much of the trainer’s time will be spent advocating the product so he or she must also possess a persuasive and convincing demeanor. In order to have a successful training program, the trainees must be comfortable. The Training Environment must be convenient and familiar. Equipment used in the class should be similar to that used in production. The data and examples demonstrated in the classroom should reflect the nature of the work of the end user. If possible, a mirrored training system should be used where the data and application are identical to that in production. The trainees can use this environment to practice without the fear of corrupting production data. Finally, there are the personal issues. Is parking adequate, are restrooms available, is it handicapped accessible, what about snacks and meals? Make sure these issues have been addressed before scheduling the first class. Documentation used in training should be professionally done. It should be written with the most elementary user in mind. The use of familiar data and illustrations, copied directly from the production system, provides a comfortable setting for learning a new way to perform old tasks. Care should be taken to include everyday work illustrations and exercises the users can relate to their specific work duties. Examples that can be used as “cookie cutter” jobs will give the user a resource other than the “Help Desk” when a problem arises. Insure that the training is relevant to their work area and job requirements. The class should be manageable. Depending on the application being taught and the hardware resources, the size of the class is important. If more than seven or eight trainees are in a class, an assistant will be beneficial to the Trainer. Have the sessions structured so that certain milestones can be reached during each session. Keep the sessions on track. Don’t schedule so tightly that unexpected problems greatly impact the projected finish. If things go smoothly, the extra time can be used for user practice or one-on-one attention. Try to keep trainee cross-discussions short and to a minimum. If they persist, it tends to degrade the training session into a gripe session and emphasis becomes avoidance rather than usage. Scheduling the classes should be the Trainers responsibility. Scheduling the participants in each class should be the responsibility of the User Community. The front line management should get a master copy of the class availability and fill in the slots with their personnel. In this manner, daily workload can be balanced and the managers have a personal stake in the training process. When establishing the master schedule, the trainer should make sure that adequate time is allowed for formal training as well as to accommodate the unexpected glitches, such as software, hardware or database problems. Time should also be allotted for relevant questions from the trainees, both complex and simple. Involve the user community - During implementation As in the development phase, getting the end users input during the implementation phase is critical to the success of the project. By now, they have had training and some exposure to the product and have formed opinions on things they like or dislike. When a change is made, let them test the workflow and find out where it wrinkles and causes headaches. Get the Steering Committee together and listen to their comments. These are people who have looked at the product from a different perspective than that of the Project Team. Find out where difficulties lie and where they have found shortcuts. This information can be used to make enhancements to the product, future user training or improve the quality of the user documentation. By accepting and using their input, within reason, the end users’ sense of ownership will increase. Since these are people who are willing to share their experiences with the product, develop them into the Super Users. When having difficulty, many people will seek help from their peers before calling the product support team. With the Super Users in the work place, help is close by. End User Support It is impossible to teach every scenario in a training class. There are going to be situations where the user gets confused or is unsure of what the next step needs to be. There are going to be undiscovered “bugs” in the software. There will be unique situations that require more expertise. There are going to be users who are just confused. When these situations arise, the resources need to be in place to help the user get over the obstacle. End User Support comes in several different formats. The use of a “Help Desk” can be a way to track trouble calls. These can be sorted and recurring problems can be categorized and solved on a large scale rather than on an individual call basis. Make the Project Team accessible to the user community. This builds good will between the user community and the project. Use the Super Users developed by involving the user community in steering committees or user groups. Involve the user community during production Encourage the development of a Users Group within the user community. These are trusted coworkers who will be in the same boat with them when the change is evoked. Arrange to have the project team be an invited participant in their discussions. Encourage regular meetings and agendas that are driven by the users, not the Project Team. This committee needs to be focused on the improvement of the product and data and operate professionally and positively. As a participant, the Project Team needs to accept ideas for enhancement as well as criticisms and play a support role within the committee. Encourage communications within the Users Group. Suggest ways to share information about shortcuts, user tips, and problems encountered. Offer support services such as newsletters or bulletin boards to get information circulated. Conclusion Applying these principles will not stop resistance but maybe it will soften it to a manageable state. The corporate world is no longer a family affair but can be a dog-eat-dog atmosphere. In this time of corporate uncertainty, the focus is on the bottom line and our associates are uneasy if not afraid of what the future might hold. It is my feeling that as long as we practice patience, understanding, compassion, and help each other through the learning curve, basically just care for one another, the bottom line will take care of itself. | ||
|
|