I’ve had the privilege of joining or leading teams that implement new technology for an entire organization. This includes websites, web apps, internal dashboards, intranets, databases, and an LMS (learning management system).
In every case, the new software would be used by all or most employees. This means the opportunities for disruption were many.
Organizations are already using technology that does the job. Their core functions are often impossible without it. Changing software “just for the sake of change” is uncommon.
The new technology (whatever it may be) is meant to increase efficiency, add functionality, modernize, or upgrade. Leaders are trying to make things better.
The worst thing any implementation team or leader can do is undermine the confidence of staff members. Everyone should know the goal is improving their lives, not making them harder!
That’s why transitions of this sort must be done in a careful and systematic way. Here is an outline I have developed that might help.
Start with a Discovery Phase. There is one key mandate for this step: nothing happens until we understand.
Learn everything, every staff member is doing right now. Have them walk you through every click. Establish the deficiencies together. Write them down and agree on how they might be solved.
Only after you have outlined a mutual understanding, enter the Research Phase. This is when you identify and demo products.
Don’t consider options (no matter how cool they look) that won’t address the deficiencies and offer the kinds of improvements you have already discussed. Staff should receive this list too. They may have insights that will eliminate an option or two immediately.
If acceptable options are available, enter the Mock Implementation Phase. Choose the best product or products and study their effects on workflow.
Bother the vendor as much as necessary. Know exactly how this changes user behaviors and let everyone in on the potential challenges.
When decision-time is near, enter the Onboarding Phase. There is still time for changing course at this point, but not much.
Now is the time to hear and put to rest all the final objections. This is the key player’s official ticket to “get on board” and make the best of it.
The time for discussion (of vendors) is over when you enter the Purchase and Prepare Phase. Now you can choose a launch team that will make final decisions on optional features, subscription plans, and tech support contracts.
Everyone should be pretty excited by this point.
The vendor can probably help, when you Standardize Training Courses and Documents.
Even the most involved team members might struggle with the new system. Make sure they have really good troubleshooting resources. Don’t skip this step.
You should also Standardize Workflow, because not everyone has the same preferences. The launch team should decide how things must be done. Fortunately, earlier phases, when you conducted a click-by-click evaluation will help.
How should data be entered? How will folders be organized? Where should files be stored? How will things be labelled? Questions of this nature should be answered now.
Move on to the Trial Implementation Phase. This is when the real world testing begins. Your eager and enthusiastic users can finally get some work done. And if you have succeeded in previous steps, the benefits of changing should now be obvious.
Your project is almost finished when you enter the Full Implementation Phase. No one continues using the old software. The team is working without a net. Everyone rejoices!
Enter the Retire Legacy Systems Phase at the very end. Officially de-commission your old products. Cancel subscriptions and contracts. Remove software from old computers. Make a clean break.
There will be time for an evaluation later, but I would consider that a separate project.
Here are some final thoughts on this one.
This is not a popularity contest. The “industry standard” software may or may not meet your needs. Try or demo or buy a system based on its own merits for accomplishing the task. “Lots of other organizations” are not your organization. Choose what is right for you.
Don’t be ashamed to bail in the early stages. If you don’t find any technology that does what you want, stick with what works.
Avoid the “cool new features” trap. If you didn’t decide you needed them in the discovery phase, you probably won’t use them.