Hi Sarbjit,

The main thing on item # 3 (and related to item #2) is that the only differences/issues you should focus on are those which have to do with the user's tasks. So # 2 is very important in order to determine # 3.

What I would do is document (if not done already) what are the business processes and the tasks (even if just at the high level) that the users of this software are expected to perform. The process flow should include all the tasks in the process and not just the ones performed in the system. Then on step # 2 I would show how the software supports the desired business process and tasks.

Similarly, on item # 3, I would show how the new software supports the desired process (which tasks). I am assuming that the new software supports the desired business processes/tasks much better than the old one (or less we just wasted time and money).

Therefore, the differences between the software which have nothing to do with supporting the business processes and tasks are not relevant and do not need to be even mentioned in the training.

The users may also want to know:

Is there a training manual?
Are there any configuration settings which the users can/should manipulate?
Who would they contact if they have more questions on the software?
Is there an established technical support group?

Hope this make sense and it helps!

- Adrian

You are very welcome!

I was not suggesting that you explain the users their business process (they probably know it better than you since they do it day in and day out).  What I was suggesting is that you put the training of the new software in the context of the existing business process so that the users can understand why the new software is beneficial to them.

In addition - there are many users who have been doing the same tasks for a long time and they don't even know exactly why and how their work fits in the bigger picture.  Showing, at the high-level, the business process would be beneficial.  You don't need to spend a long time on the business process, just enough.

And yes, maybe they'll be happy to learn some new features however, while there could be many cool features, the only ones that matter are those which are going to make a difference in the user's day to day activities.  For example - if the new software has a feature which allows the user to view daily quotes that might be "fun" and "interesting" for a few minutes but the reality is that the end users probably don't need quotes (unless they are speech writers.)  ;-)

I would guess that you will probably get some resistance.  Most people tend to want to avoid change so you will get some complainers.  This is why it's even more important that you show your users what's in it for them.

If the software is customizable then you may even want to get and record the initial feedback your audience will have about the new software.

One more thing - consider starting your actual training with a high-level overview of the entire application (high-level) features without the users touching the keyboard or the mouse.  This way they will have a mental roadmap through the software.  Then you can proceed and jump into the details of how the software supports key tasks and processes.  If you have a training room/lab with computers for everybody you might want to go through examples first by yourself and have your audience pay attention.  Then it's their turn - give them exercises and activities to do while in class.

Best regards,

- Adrian