How do you design a training session?
BIRGIT: How I approach a topic has changed for me in the last four or five years. I have become much more focused. I rather think about what to leave out.
I structure my training as a series of how-tos and I teach one solution. The theory and background part might come in later when concepts are not understood or when there are no clear one-size-fits-all answers, but hands-on training is about learning to get your work done.
There is a real danger that I am going too fast. Sometimes we can trip up because I use ancient techniques such as keyboard shortcuts for copy/paste or I move windows around my screens. Then people will ask, “How did you just do that?” and we’ll have to stop and discuss the shortcuts and the concepts for that particular task.
How much can we accomplish during a two-hour hands-on session?
BIRGIT: It depends on the topic, of course, but I would restrict it to not more than three maybe four multi-step processes or major concepts. Each process might be a 10 to 12 minute show-and-tell, a couple minutes for Q & A, then one or two exercises.
The amount of preparation required really varies.
If the training is part of a larger technology implementation that impacts multiple areas of the organization, I segment the audience into two groups. One group needs to learn how to use the software and make decisions on screens, workflows, and automated tasks. The second group needs to learn how to get their work done with the software.
The first group will need to make configuration decisions for the whole system and be in charge of maintaining the system for the organization. They need concepts and strategy and in-depth knowledge of the new software. Learning how to troubleshoot is also important for this group. I’ll want to show them how to read the manual and how to connect with a support group or peers. Most software solutions have multiple ways to approach and reach the stored data. This first group needs to learn the different methods, their ramifications within a larger context, and the advantages and disadvantages of each method.
The second group is likely to get overwhelmed and confused by the many paths to discovery. Often they’re barely able to master the current technology to accomplish their tasks, so they won’t be ready to venture out into a new world unless you can show them a straight 1:1 translation from the old to the new system.
Overall, people need a seamless transition and a clear way to accomplish their tasks. They want to be able to replace one thing stored in their brain with a different memory.
When should the training happen for those people who just need to get their work done and don’t need to be involved in the configuration decisions?
BIRGIT: A prerequisite for the successful training of the second group is that your implementation team and the department heads have already put standard operating procedures in place for the new system and finalized data input screens and workflow for various sections of the software. Schedule technology training for the second group at the very end of your software implementation process.
Should people be trained on the live system?
BIRGIT: No. Use a sandbox instance of the active application so people are not afraid to make entries on a CRM. Ideally, they should be able to submit test donations that trigger real “Thank you” emails. Despite the fact that no actual donation occurs, you can still walk them through the process of what happens next.
Any final thoughts?
BIRGIT: For best retention rate, your team should leave the training and be immediately empowered to apply their newly acquired knowledge to their daily workflows. There will be enough adoption friction as it is, don’t let the enthusiasm of learning a new skill go to waste by delaying the usage of the new software.
Also, keep in mind that you can reuse the curriculum (with small changes) for onboarding training for your new employees or volunteers.