Reason #5: The End User - Why Your Training Project Is Doomed to Fail… and How You Can Make It a Success Instead

Why Your Training Project Is Doomed to Fail… and How You Can Make It a Success Instead

Welcome to what I plan to write as a regular column over the next few months. Shockingly, over 70% of all business projects fail. Fortunately for me, I have a lot of material for this column because there are more than enough reasons why a training project can fail, which means that not only are the odds stacked against you, but the challenges are numerous and sometimes not so apparent. The purpose of this column is to identify these issues and challenges and offer concrete solutions to mitigate the risks associated with each.

Feel free to check out prior posts in the series:

·        Reason #1: It's Not a Training Problem

·        Reason #2: No Metrics

·        Reason #3: Your Training Program only Addresses Training Issues

·        Reason #4: The Project Sponsor

Reason #5: The End User

Sometimes we get so focused on the training, we forget why we are doing the training; or to be more specific, for whom we are doing the training: the end user.

Three stories to illustrate my point.

1. They Need to Know How to Use It

We have already discussed metrics, so it would make sense that at a kickoff meeting for software training I would ask: “What metrics are we using to determine the success of the project?” The answer I repeatedly received was: “We have bought this system and they need to know how to use it.” Let’s ignore that there are no metrics in that statement and instead focus on the fact that the end user is not considered in any capacity.

2. End User Feedback

The next story is a bit better. We had created a training program and prior to launch we brought in some end users to evaluate the program, and were we surprised. As we ran through it, they repeatedly pointed out how procedures were dated, obsolete, had been replaced by others, or in some cases were borderline illegal. And this after the client had signed off on all of the content. But to be honest, the fault was principally mine. If I had done things properly, I would have involved that sample group of end users much earlier on in the process.

3. What Do You Think?

In the third case, I was brought on by a manufacturer to create a certification program for each role. In this case, the end users were involved at the onset, as were other groups. I worked with management to create the learning objectives and performance metrics, and then met with employees, the union rep, and supervisors, showed them the lists and asked two simple questions: “What do you think?” followed by “What did we miss?” We didn’t miss much, but their input was invaluable.

Sometimes training is guilty of tokenism: we need to do training on x, so let’s just do it and force it upon the end user. In other words: “We have bought this system and they need to know how to use it.” And the end users know it. They know they have to endure a training session that usually has no impact on them. They click or sit through the training, take the necessary tests, and the training outcomes are never incorporated into the “real world” because they never bought in to the training. They saw no clear benefit, so they endured it and then filed it away in some distant filing cabinet deep in the recesses of their brain.

Don’t just design training for your end users. Make them feel like they have a vested interest. Make them feel like they own a part of it, that their success depends on it. Take the time to find out what their interests, needs, and concerns are. You may or may not be able to build it into your training, but at least it is on the table. If done properly, you have an opportunity to make your sample group of end users into a small unit of evangelists who helped shape the training and are now actively promoting it.

Training is not simply about telling others what to do, but a vehicle to collectively achieve a common goal that everyone buys into.