Tony Karrer's eLearning Blog on e-Learning Trends eLearning 2.0 Personal Learning Informal Learning eLearning Design Authoring Tools Rapid e-Learning Tools Blended e-Learning e-Learning Tools Learning Management Systems (LMS) e-Learning ROI and Metrics

Monday, September 24, 2007

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.


Anonymous said...

Yowza! A new solution for self-service productivity and information that requires 80 hours of training? I reviewed PeopleSoft's original ELMS a few years back and saw the newer version, thought they were moving in the direction of usability... Apparently they haven't escaped the 'plain vanilla bend the users, your processes, and your systems to the will of our monolithic system' perspective:)

Perhaps one of the first questions to ask when buying or upgrading a Web-based self-service system is: So, Vendor X, how much training is the new system going to require to get my folks on the road?

An answer of 80 hours would raise some serious flags for me:)

Requiring all to choke down anything more than an initial orientation / acclimation component is probably unnecessary and definitely cruel and unusual:)

Categoric exposure to off-normal or rarely performed tasks is a recipe for wasted time IMO.

The first option / solution / performance vehicle I normally consider is some type of electronic performance support tool. Tutorials on demand work wonders, can grow over time, and generally take less time / effort / cost than full bore (normally crap) training series. Particularly when they are context linked to the task area (a 'how the heck do I do this?' button or link conveniently placed where needed).

I would guess the system also requires some common / frequent workflows. Maybe there's a top 10, top 5, top 3 tasks that can be put up as a simple 15 minute required module prior to registering for any courses.

Phil said...

80 hours of PeopleSoft trainig? Could that estimate possibly have come from someone with a vested interest in selling lots of training?... Some further thoughts on BJs question:

1) Complete agreement with the training design starting and ending with roles & tasks: don't make people sit through "general" stuff...engage them with what they actually have to do in the to-be world of new processes and new (or changed) technology.

2) Get off the Happy Path. Bj talks about how boring applications training can be. He's right and adding some random Nascar simulation doesn't make it any more engaging. Apps training that takes people down a single happy path where everything works perfectly is boring because learners understand as soon as they leave the training room and return to the real world, they'll fall right off that happy path. So, give em real-life scenarios where things get complicated and messed up and engage them in figuring out how to solve the real problems they'll have.

3)Dr. Tony talks about using hybrid/reference tools. If he's talking about what we call EPSS -- a system that allows users to view the process flowchart, find their swim lane, find their task, see its relationship to other roles and tasks, and finally drill down to a step-by-step work instruction he's right. The point is that no matter how good training is people don't retain much. So, they need help and reference systems, and the EPSS will serve as the single repository of all the process and application knowledge. We've seen them work great in big ERP, PLM and CRM implementations.

4) Plan for (as in save time and $$$) post go-live training. Pilots are a good start on getting the training right. But give people the first month of limping along with the new process/tech and then offer them more training. Devise the content for this post go-live training by reviewing help desk call logs, or by getting users to send in questions. Or just hold open labs where users can come in and work through real-life problems shoulder-to-shoulder with an expert. This training actually sticks because it addresses real problems that real users have, NOT a random, boring stroll down the happy path.

Tony Karrer said...

Great advice. Interesting that both of you called it EPSS. I haven't used that term for a long time because for a while that indicated some intelligence in the EPSS solution (think Turbo Tax interview as EPSS for the forms view). I'm thinking a well organized reference system (built on a Wiki for easy editing - possibly by end-users on some pages - think FAQ, issues found, etc.). But that sounds like what you are calling EPSS. Interesting.

BTW - love the "Get off the Happy Path" terminology.

Phil said...

Indeed. You say reference system, I say EPSS....Let's call the whole thing off.. We're talking about the same thing.

We don't yet have a case where users use wiki editing/collab tools to truly own content, but that's our vision too. We do have cases where the help desk people tell the confused users.."let's navigate together to the EPSS and see if we can find the answer to your question." That's the give someone a fish they eat for a day, teach em to fish they eat for a lifetime concept. Also, over time, help desk calls drop and everyone likes that.

Anonymous said...


Thanks for the mention! This has been an awesome way to gather feedback.

I’ll respond to your suggestions:

1. There will be some process changes in addition to application changes. However, I don’t know the extent of the changes at this point. Those details will be worked out in the coming weeks.

2. We will base our training on job roles and the tasks within each role. We’ll do our best to modularize the training for these tasks to promote reuse.

3. & 4. Agreed – 80 hours is a crazy amount of training. And just to clarify, nobody was trying to sell us 80 hours of training; this was an estimate from somebody within our organization who I trust. We will try to reduce this amount by designing similarly to your recommendations in 4a-d.

5. We have a great EPSS / reference hybrid tool that allows users to look-up information while working in PeopleSoft. We will depend on it heavily for this upgrade. I imagine our Help Desk will be our second line of support for users.

6. Interesting point about office hours. I'll keep that in mind. Good suggestion.

7. We will definitely pilot our learning solutions to gain feedback, measure success, etc.

Stay tuned. This ought to get interesting in the coming months... :)

(And thanks for your input!)

Anonymous said...

Just a few questions and comments...

In the past, I have developed 80+ hours of training for new software systems, but no one student would take more than 15-20 hours of training. Each role of user from the system administrator to the data entry person would take training specific to their role and responsibility. There was a core set of content that provided an overview of the system that everyone took and the rest of the content was role specific (with some overlap).

But when I hear someone talk about training their current staff on a new or updated software system, they usually think about the minimal amount of training possible. Their staff already knows how to create work orders and the related policies. For the training, they just need to know how to use the system to create the work order and submit it for approval. I like to ask them about expected employee turnover and how they plan to train their new hires. They need to remember that there are groups, current staff who need to know what has changed and future staff who will need to know how to use the system and the related policies and procedures.

I think that the training should be kept to the essentials. Show them how to navigate through the system and how to perform the functions they will use most often. Let them know that the system has additional features and show them where they can access reference material that will help them when they need to perform a new task.

Tony Karrer said...

Phil - okay interesting to know that I may be using terminology that's different, I'll have to be a bit more careful.

On "ownership" - it's funny because while I have end users (and help desk) edit the the content, in many of the situations the bulk of the content editing is still done by training. Thus, "ownership" is not something I'm looking for.

Further, there are always a couple of target pages, e.g., FAQ, issues, that I teach the users that they can change.

Completely agree about having the help desk show the user how to use the reference/EPSS. And, you can show the help desk how to edit it in cases where it wasn't quite what we'd want.

Tony Karrer said...

Mike B - I wasn't sure if you were thinking that 15-20 hours (which sounds really long to me) would be the "essentials" - my guess is that the essentials are more like 2 hours and then you've built additional 15-20 hours of content, but the expectation is that they get this over time and as needed.

It's interesting how many of us (including BJ) are landing on similar solutions.