Software Upgrade Training and Support

BJ Schone just posted a great question about a particular situation. They are upgrading their PeopleSoft implementation. He tells us:

I don’t know much about the new system, but I understand that it is quite an overhaul; one estimate said we would need 80+ hours of face-to-face training. However, due to logistics, time, and money, it appears we will be training about 80% of these employees using a combination of self-study eLearning courses and webinars. Everything will be tracked in our LMS.

Applications training can be excruciatingly boring, especially when taken as a self-study eLearning course. These courses generally consist of step-by-step instructions where the learner watches a task as it is performed, and then they try the task on their own in a simulated environment. I’m worried that we’ll bore people to tears and that they’ll mindlessly follow along with the step-by-step directions…and then not retain anything.

How would you tackle this? What ideas do you have?

What a great question BJ! It's also an incredible example of something good to do in a blog post! I plan to mention this in future presentations. I hope you get some good ideas.

Some quick thoughts -

1. Are people changing just the software version and interfaces or are process changes happening also? Many times, upgrades are about changes in interface and less about process change and thus can focus on how you accomplish specific known/understood tasks in the new interface. This greatly simplifies the training and support needs. However, if you are upgrading from PeopleSoft to Oracle you may be looking at process changes which will require additional work.

2. Assuming you are talking about an upgrade as interface change then any training and support starts and ends with roles/jobs and tasks. Once you find the primary tasks that represent 90% of what people will do on the system, find out which tasks are likely to be problem areas, which are possible sources of costly errors and figure out who does which tasks in your organization and how often these are performed, then you have the basis for your learning design.

3. I agree that 80 hours is WAY TOO MUCH for a whole lot of reasons. I generally shoot to make any course as short as possible. See How Long Should an eLearning Course Be? In this case, it's identifying what the minimum amount of upfront training that's required to get various jobs/roles minimally proficient so they can start on the new system and then dribble additional information to them as appropriate.

4. The minimal training will include:
4a. Overview of the new system and interface
4b. Common interface conventions
4c. How you get help/additional training on specific tasks
4d. Training on minimum set of tasks

5. Provide a hybrid reference / course solution for the remainder of tasks. It explains details on any task and provides access to additional walkthroughs or simulations. I generally call these a hybrid reference solution.

6. More broadly I also like to see up-front communications, introductory sessions to the system (virtual classroom), minimal training, access to hybrid reference and support, and follow-on "office hours" that allow people to ask questions, tell us problems they've found. Office hours can be an amazingly effective tool. We can tell everyone going in that there will be challenges as you get into the system. If it's something you need immediate help on, here's how you get help. If you can hold it for offices hours and ask it then, everyone can see the issue and see how it's solved. Note: office hours need to be held based on job/role in the organization. They are held daily at the start and then slow down as it goes farther.

7. Pilot your solution with the pilots of the system.

You can also check out my post on: Software Simulation eLearning for some other thoughts and links to posts.

I know I'm forgetting a bunch, but as you begin to shape your solution, it will likely come to me.