Even though GeoMetrick Enterprises does not supply training services, most of us do eventually have to take part in training, whether assisting trainers to understand a new implementation or in taking training, ourselves. Some training is better than others and people learn in different ways, but some ideas work for very few people, regardless. Here are the ideas that are ineffective in training, but are actually seen all too frequently.
1. Training Too Early
Timing training is tricky. You obviously want to get training done before a person needs to get involved with whatever they’re being trained on. That way, they’ll have a better idea what the terminology means and how things fit together. At the same time, if you train a person too early, they will forget absolutely everything.
Most of us have taken training we’ve never ended up using. Today, we probably remember absolutely none of it. But even if we probably WILL use it, there is only so much refreshing you can do before it all starts to fade away. Then, by the time a person needs it, they need retraining not refreshing. Yes, you have to retrain, not just tell the person “Go back to your desk and refresh your memory with your notes” because too much time as passed for that to work. You might feel money was wasted with the training. Maybe it was but it is what it is and chewing the person out won’t make them remember anything.
Lesson: Training too early is almost an entire waste of money and equal to not training at all, in most cases.
When I was at the University of Michigan, and even after being there almost six months, I only knew the basic business process. I never could remember the details of how each customer used the process in their own unique way, such as who used what types of containers for shipping (because different container types had different processes for shipping). On the other hand, I quickly figured out where things were at in the database and was able to tie them together quite early in my time, there. Why is that?
Let’s just take a moment to recognize that memorizing processes is somewhat different from memorizing how data fits together, although the two relate to each other since data represents the process. There is some synergy between them.
In any case, the reason I could remember the finer details of the process is because I never worked with a customer on their business process. For me, it was just a diagram I was trying to memorize. As hard as I tried, only the basic process stuck with me. In this respect, I was luckier than the people who get trained early and remember nothing at all when they do eventually need it. On the other hand, I did actually work on occasion with the database to build or change reports or make fixes. In that, not enough time passed that I forgot what I knew about the database and how it was organized. In fact, I worked with it enough that, even today, I remember how the patients tie back to the samples, data-wise, and we’re now more than a year past the end of my time with that project.
I thought of this only because I happened to be speaking with a friend having the same problem. He’s got a new job with a system and processes he’s not previously worked with and, while he waits for customers to be assigned to him, is sitting just learning the system and finding it difficult to get it to stick in his head.
By the way, you can do this over-and-over and still not remember. There’s nothing to make it stick. It’s better to let people get the basic information, start visiting with customers, then come back to review the finer points of the process. Those smaller points begin to make more sense and we begin to understand WHY different groups do things differently, which helps us better retain the information.
Lesson: Even in college, we didn’t remember much of what we memorized for long. We shoved most of it into short-term memory to get through exams and forgot almost all of it soon afterwards.
3. Hiring Someone Who Knows the Process (and Stopping, There)
Some people recognize the first two problems and think there’s a way to get around them by hiring someone who already knows the process. They still need training on the software and how it fits into the processes. Even with expert process knowledge, they need to learn the software. Even if they come from a company that used the software there might have been modifications for their implementation. As such, they need training on the basic process so that they’ll know the baseline of how it’s intended to be used. They can then use their expert knowledge to think of ways to improve it but they need that baseline.
But you don’t really save time if you don’t spend the time to both teach them the software and also the process behind it. If they’re expected to come up with new solutions for problems, they have to have a good handle and the software package, itself, not just the knowledge of using it on their previous project, as well as its intended use so that they can understand how to make minimal changes to that.
Lesson: The idea that “they’re the process expert so they’ll just figure it all out” doesn’t work. It puts undue pressure on the person to do things they don’t know how to do and they’re never fully effective.
2 Thoughts to “Three Ineffective Training Ideas”
Along the lines of training, I hope you will write a blog post on the different types of training needed such as:
1. LIMS Admin training
2. LIMS Developer Training and the different types
3. LIMS Consulting training and the different types
4. LIMS user training and the different types
5. Executive / Stakeholder training
Well, for one, John, that’s a nice list you’ve included. It’s a great starter for anyone with a new implementation. Thank you for sharing it.
Comments are closed.