Last-minute quality assurance headaches are nothing compared to the grief you’ll buy yourself with a poorly planned end-user rollout of a new application or version upgrade. My own deepest migration scars come from the frustration of seeing a new product not being used to its full potential—in business parlance, I believe that’s called non-actualized ROI. And in almost all cases, I’ve been able to trace these shortcomings back to a few miscues on the personnel side of the launch. In this article, I’ll share seven tips that will help you avoid these personnel missteps.

A success, despite it all
To jog my buried and painful memories a bit, I asked some of my old colleagues at TechRepublic about their impressions of the rollout for the company’s custom-built content management system, which I helped spearhead a few years ago. The CMS—best described as a Web-based workflow and data-capture application—encapsulates the work of about 30 TechRepublic employees, and we knew going in that it fit at least one functional definition of “enterprise software”—it changed the way we did business.

All in all, I’d have to say the rollout was a success—the system is still in use today—but it was not painless. Some groups of employees felt that it was overly restrictive and that it infringed on their autonomy, which of course it was designed to do, at least to some extent. Others found our documentation to be a little shoddy, which I suppose it was to some degree. Still others just wanted to complain about seemingly minor details, a tendency that is, after all, human nature, and I’m certain in some cases quite justified.

At any rate, here are the main tips that came up during my review of the rollout process. The recurring theme here is that if users don’t take advantage of the new benefits that drove the decision to upgrade, you’ve basically wasted a lot of your time.

Oddly enough, my recollection synchs fairly closely with the feedback I got from users who were on the business end of the rollout, for better or for worse.

1. Fully budget training expenses as part of the rollout
My biggest mistake, unquestionably, was not locking in a budget for CMS training. Since it was a highly customized system, we figured we could just handle the bulk of the training ourselves, and the few resources we did have allocated were gobbled up by swelling development costs. If you have a corporate training department behind you, work with that director closely to make sure you have a full program mapped out. If you’re in a smaller shop, outsource some aspect of the training, if at all possible.

2. Identify beta user groups
This was a big winner for us. Before migrating or rolling out a new app, identify about 10 percent of the affected user base and let them start playing with the toolset a few weeks before launch. This will let you tweak some technology, but far more importantly, it will help you identify sore spots from the users’ perspective for which you can prepare.

3. Identify power users to help with post-launch support
This is a natural outgrowth of tip 2, but I can’t repeat it too often. We were able to identify one or two power users from each of the workgroup roles identified with the CMS. Relying on those users to answer the same question for the 500th time was a real lifesaver for the core rollout team.

4. Be a salesman, even if it hurts.
Enlightened self-interest is the greatest motivator, and it’s certainly the easiest way to get people to try new things. One of my bigger missteps in the CMS rollout project was simply telling users outright that a main value point of the system was that it would help managers shuffle resources and keep a better eye on the content that we were creating for our members. This statement was, of course, true; it also was immediately translated into a somewhat skewed impression on the part of many staff members that the CMS was simply a way for their bosses to keep an eye on them.

One user actually told me that she appreciated being told this “truth” about the system up front, but clearly I screwed up here if users thought that this was the main reason we implemented the CMS. More painfully, users never actively adopted several of the system’s business process improvement (BPI) features—such as low-fi collaboration features. I should have spent a little more time hyping the upsides from the users’ perspective, even though such efforts initially might have seemed a little extraneous or even annoying.

5. Don’t be so nice with recalcitrant adopters
Users who I spoke to in preparation for this column recounted that some employees took their criticisms of the new system to the highly inappropriate level of discussing how they were going to circumvent the machine altogether. That comes as no real surprise, but I was (along with other managers) probably a little slow in dealing with such extreme instances of heel dragging.

With an OS migration, of course, you won’t encounter such problems, but I’ve repeatedly run into file and message compatibility problems stemming from users clinging to their beloved, outdated client software. My best advice: Give business managers a drop-dead date of when support for an old system will be dropped, and create some channel (your boss would be a good place to start) to record that breakdowns beyond that date are a failure on the business end.

6. Give users a macro-level view of the product
We began training/rollout preparation for the CMS by getting together large groups of users and giving them a general, conceptual overview of how the system worked, at least from a workflow perspective. This was a winner, I think. Again, with an OS rollout, there’s little need for such a buy-in exercise, but if you’re changing the toolsets users work with on a daily basis, I highly recommend such sessions.

Change is unnerving, and employees can tend to be grouchy about tasks that don’t seem to have an underlying business imperative. Be careful not to slip into manager-speak here. We used some very simple whiteboard diagrams and fielded just a few questions, but I think the process ultimately did ease the transition for many users.

7. Give users a micro-level view of the product
This one is a gem, and I think it was one of our most successful tricks during the CMS rollout, based on user feedback. Create or distribute a role-specific cheat sheet, one or two pages in length, that focuses on common and essential tasks the user will need to do every day. Even if you’re buying training for a large, out-of-the-box system, be sure to make such a resource available, even if you have to create it yourself. Most canned training materials are extremely generic—how anybody can make sense of an Exchange/Outlook manual is still beyond me. So be certain to acclimate users to the immediate impact of the rollout on their daily function. The nuisances of sharing administrative rights to distributions lists can wait for later.