![]() |
![]() ![]() ![]() ![]() ![]() ![]() | ||
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
|||
To order reprints of any article in its original format, visit Scoopreprintsource.com FeatureTeach First, Install Second ASSOCIATIONS NOW, March 2008 The biggest roadblock to success with a new technology in the workplace? Your own staff. As promising as your fancy new system might be, if you don’t teach your staff how to adapt, they’ll never fully realize those new advantages you’re trying to give them. By: Joe Dysart Applying a new technology or system in the workplace is more than just installing software. It’s really about change leadership. For your staff to fully realize the advantages of new technology, you have teach them not only what new buttons to push but also how to think about their work habits and practices in perhaps entirely new ways.
While a technology upgrade is often greeted with all the joy of a root canal, it doesn’t have to be quite so painful. Tech consultants, along with associations that have been through the wringer, say that accommodating the human factor behind a tech upgrade can go a long way toward making an upgrade easier—and possible. Specifically, seasoned pros say budgeting for the human factor is a must. “Many associations are willing to invest funds to obtain the technical architecture for their communities, but then take an ‘if we build it, they will come’ approach to publicizing, facilitating, and populating their sites,” says Pascal Kaplan, Ph.D., CEO of iCohere, a collaborative software company. “Unfortunately, it really doesn’t work that way.” A significant portion of that human factor budget, the pros add, should be earmarked for pretraining. “The typical process is for ‘superusers’ to be trained during the implementation process so that they can test the system as it is being installed,” says Wes Trochlil, president of Effective Database Management. “Then regular end users are trained just prior to go-live. Frequently there is ‘post-go-live’ training a few months after go-live as the users become comfortable with the system and develop more needs and questions.” Meanwhile, staff expectations regarding the new system and the migration process itself need to be brought firmly in line with reality. “Most organizations underestimate the difficulties they will experience with the implementation of a new system,” Trochlil says. “This is in part due to the natural overselling that comes from the software vendors during the sales cycle, but it is also due to organizations not managing the expectations of their users.” Additionally, staff must buy into an upgrade well before it gets underway. They need to know why an upgrade is being made and why the upgrade will make things better. In an ideal implementation, staff will actually become evangelists for a change—owning and assuming the initiative for the migration over to the new system. “Not only do users need to learn new ways of doing some things; they also need to understand the value proposition of new capabilities they may not have used before,” says Rick Johnston, CAE, a senior web strategist at Ironworks Consulting. New software must also be anchored to the business rules that run an organization. If that’s impossible, it’s imperative that some or all of the organization’s business rules change to accommodate the new software—and that staff buys into the need for the changes in those rules. “For example, the steps for processing an event registration will change with the implementation of a new system,” Trochlil says. “For some users, these changes won’t make sense, and will be perceived as a step back. Users need to be made aware of why a process is the way it is and how that benefits the customer, the staff, and/or the organization.” Also be on the lookout for foot draggers—staff that resist change no matter what. “What continues to surprise me is when technology will make a person’s job obviously easier, yet they choose not to adopt the technology,” Trochlil says. “In cases like these, you have to work with the individual to determine what it is they are holding onto. Is there something missing in the new process that was covered in the old process? Does the user not understand how to do the new process? Is the new process slower than the old one? Learning what’s in the user’s best interest can help you determine if there is a way to change their behavior.” And finally, know when to say “no thanks.” Sometimes, new technology—even with all its promise to make things easier, faster, and more productive—can be a bad move. “After 16 weeks of analysis in a multitude of arenas, I realized it was not the right time to propose live help be added to the Michigan CPA Association web experience,” says Cynthia D’Amour, MBA, a leadership strategist with People Power Unlimited. “The investment of training and monitoring needed was not worth the return on investment at that time.” Upgrade the Users’ Toolsets The Institute of Food Technologists (IFT) was able to leverage a number of these best practices in its move to a new association management system. By ensuring users completely bought into the new technology, offering substantial training before going live, and engaging in significant pretesting, the installation went fairly smoothly. “It is imperative that the project not be seen as an IT project but instead an upgrade of the users’ toolsets, where they have buy-in and decision making on the product, its design, implementation, and use,” says Marc Bernstein, IFT’s IT director. “In our case, we actually had users vote on which solution they wanted to adopt. “By allowing users to have ownership in the tool and the project, they become self-motivated to learn the new technology, because they asked for it and they want it,” Bernstein adds. Intensive pretraining on the system included several weeks of meetings with a business analyst, who helped IFT clearly explain how the new system could be customized for the association’s needs. In addition, IT conducted several data migration run-throughs. Users were also given the opportunity to write test cases, with the help of IT, before the system went live. This ensured they were comfortable with the system’s workings and provided some concrete examples of system concepts, which the system’s documentation lacked. Plus, IT created a SharePoint site for additional pretraining, which centralized the system’s documentation and any issues users had with the system. IFT did not anticipate, however, the turnover of critical staff during the rollout. “The project lasted eighteen months from start to finish,” Bernstein says. “During that time, we had some significant staff changes. For example, both exposition staff departed, leaving a challenge for new staff that had to navigate a new company, the legacy system, and the new Personify [software] system. This forced us to revisit areas of the system that had already been designed and tested.” In retrospect, Bernstein says he’ll be sure to avoid the staff turnover problem the next time around. “Had I known how long the project would run, I would have pushed to break it into phases,” he says. “I would have tried to keep each phase less than twelve months. And I would have separated the phases by at least three months to give folks a break.” Turn Staff Into Believers Peter G. Wacht, CAE, senior director of communications and public affairs at the National Court Reporters Association (NCRA), says he had similar success by sticking to many of the same best practices. “We’d been doing things the same way for a long time,” Wacht says. “With new technology coming in, we had to examine our current business processes closely and justify why we were doing things the way we were doing them. Virtually every existing business process was subjected to the question, ‘Should we even be doing this, and if so, how could we do it better?’” The association and content management systems that NCRA chose were brought in to rid the association of a DOS legacy system and improve its e-commerce capabilities. “In any technology transition, the staff involved needs to fully understand the process, the benefits, and the why: Why are we making changes that will affect how they’re currently doing things? Why are we trying to replace a comfortable process with one that seems foreign?” Wacht says. “If the staff doesn’t believe in the need for the transition—if they don’t support it, if they aren’t willing to put in the extra time and energy needed to make it work—then it simply won’t work.” NCRA also established a train-the-trainer program, through which core users of the new systems received intensive training prior to implementation and then took on the responsibility of training their respective staffs. The association also set up a test server prior to implementation, which staff could use to become familiar with software features, experimenting with functionalities and facets of the program that particularly appealed to them. Plus, IT also got a bit playful with the training, turning it into a “CyberSafari” competition. “Every two weeks we would send out 10 to 15 questions, and each team member needed to submit their quizzes to earn points. If you didn’t answer a question, you’d lose points, which gave you an incentive to at least give a question a shot and learn about the system.” IT made things more interesting by mixing up the teams so that top brass were mixed in with entry-level employees—a move that yielded some rather humorous results. “We had an instance where someone working in the mailroom took a director to task in the hallway for not getting a quiz in,” Wacht says. “The director never again missed a quiz deadline.” Constant communication and updates on the implementation also helped greatly. “I would send out regular email updates about where we stood in the transition and what would happen as we moved toward the go-live date,” Wacht says. “The face-to-face conversations, whether in the hallway or the lunchroom, were even more important. So I and the AMS team members made it a point to speak with staff about what was going on with the transition, and help answer any questions or deal with any concerns they might have.” Wacht’s only regret? “If I had the chance to do it again, I’d probably focus more on developing metrics of success so that we could have a better sense of what the return would be in transitioning to the system,” he says. “We had a good idea of what success would look like, but the metrics would have helped to clarify it.” Potential for Disaster Diane James, CAE, executive director of the Women’s Transportation Seminar, says her association’s transition to a new website and new association management system was pretty painful. Problems with staff buy-in, tough learning curves for a staff that often eschewed the technical, and high stress levels brought on by unforeseen glitches made for a rather bumpy ride. The systems WTS brought in were plagued by cost overruns. “We were constantly stressed over budget issues as we learned that we needed to include things that were not anticipated in the original scope of work and budget,” James says. There were also major problems with getting the staff to commit. “We have very engaged chapter leaders who have a fairly low tolerance for having to be inconvenienced,” James says. “Our systems were so inadequate that there was a history of great tension between the chapters and international staff. I knew that there would be lots of pressures and high expectations for changes and that lots of people would be quick to criticize if things weren’t improving fairly quickly.” Plus, staff found that the new technology was difficult to master and seemed to make work more complicated. “It was very tough. The system is far more complex than our previous one, and we do not have in-house staff that is skilled in technology, so there was a substantial learning curve just in the terminology of the new system and its structure,” she says. Eyeing potential disaster, James decided to add the human touch in every way she could imagine. “It was important to assess constantly why frustrations were occurring and what options there were to minimize them,” she says. “Sometimes, just screaming is a way forward; other times it took a good laugh. I was extremely fortunate to have a counterpart with my vendor who worked with his staff in the same way I was working with mine—to make sure that the people issues were addressed as aggressively as the technology ones.” She also improved communication with the systems’ vendors. “I engaged an outside consultant to help interpret the conversations with vendors about our goals and strategies and the technology solutions presented to accomplish them,” she says. “That helped significantly.” When it was time to throw the switch, James made the best of things. “At the time of our launch, everyone was exhausted and nervous,” she says. “Our consultant presented us with a bottle of champagne and encouraged us to celebrate. We were so stressed out that it hadn’t occurred to any of us to take a moment and celebrate. After we celebrated among the staff, I made sure the board also took time to enjoy the success. That was a very important recognition and helped to change everyone’s outlook. There were still ongoing glitches, but we took them more in stride.” As for hitting the “do-over” switch: “I would definitely have brought our consultant on board earlier. And I would have invested a lot more time with the vendor on the front end, determining exactly what is included in the scope of work and what is not,” she says. “I would immediately budget for 50 percent higher costs than those foreseen. And I would also build in more time to keep up with daily routines while learning new ones and working on the new system. “I’d conclude that often, we don’t know what we don’t know soon enough to avoid the pitfalls inherent in these major transitions.” Joe Dysart is an internet speaker and business consultant based in Bohemia, New York. Contact him via phone at 646-256-6602 or online at www.joedysart.com
More Articles From Associations Now, March 2008
|
|
||||||||||||||||
|
|||||||||||||||||