Go Live Quietly and Fix the Bugs

When Purington secured final buy-in from the CEO of the company, our team had all of our front-end pieces in place. Because we were in control of the training budget, our team was able to buy and install the technology, purchase the courses, and load them on the server. When we flipped the switch, giving every Rockwell Collins employee access to 300 off-the-shelf training courses from SmartForce and NETg, our primary Year One goal to transform 30 percent of our training content to alternative delivery methods was achieved. But, as a team, we didn't draw attention to ourselves , at first.

It was June 1999 when Project Oasis was launched, quietly and without fanfare. Our team marketed it within the organization as a "coming soon" event even though it was live and accessible through the company's intranet. Embedded in the Rockwell Collins home page was a hyperlink to the courses, but other than that we didn't mention the launch to anyone . For two months the e-learning library sat, slowly being discovered by employees who happened upon it while browsing the intranet. They started taking courses and telling their peers about the system.

By going live quietly, our team was able to iron out the remaining few kinks in the system while it was still relatively invisible. The programs had already been put through rigorous testing in the lab, which houses several computers modeled on the Rockwell Collins PC-user environment. That testing process allowed our techs to pinpoint and fix all of the major end- user problems before the rollout, but you never know what's going to happen when you really go live. The first Rockwell Collins end users encountered an expected number of glitches and errors, usually attributed to hiccups with various interfaces or software incompatibility . There will always be employees who load illegal software on their computers or ignore directions and take unexpected paths through your content. Until you see what they are going to do and how the system will react , there is no way to know what errors will result. As the problems were reported , our technology expert fixed them, without the publicity that might have accompanied a highly public launch.

If it's not possible to go live quietly and wait for your users to test drive the system, at least do a pre-launch beta test with real live users in your corporate environment. Approach a division or workgroup and ask if its members would discreetly test drive your courses before you make them public to the whole company. Choose a political ally who supports your cause and will not use any errors against you later on. Let those employees work through your training offerings for a few weeks and offer them incentives for their time and honest feedback. No e-learning implementation will be flawless, but the more time you spend refining your system before the launch, the fewer glitches you'll run into when success matters the most.

For two months we monitored the first quiet wave of end users, and then on August 7, 1999, the learning and development team publicly announced the launch of Project Oasis. This grand opening was a huge success. Most of the bugs were gone, so end users were able to focus on the content and not on system problems. Because we had done so much up-front work during the research phase and had rolled out the courses so quickly, the two months our team spent quietly testing them seemed like no time to executives, who assumed we had started the e-learning installment process from the point of final approval. They were amazed that Project Oasis was up and running so soon.