“We’re introducing something new,” your client says. “So of course everyone needs to be trained on it.”
Maybe your client is thinking this: “This new thing is so bizarrely new that no adult Earthling could possibly figure it out without formal training.”
Or maybe they’re really thinking this: “This new thing is a pain in my neck and I don’t know how to introduce it. I’ll have L&D train everyone and call it a day.”
Either way, the client is expecting you to unleash an avalanche of “training” on innocent people who would rather just do their jobs.
“Please train everyone on the new TPS software by June 1,” your client says.
The client expects to hear, “Sure. I’m on it!” Instead, offer an innocent “why?”
“Why are you installing new TPS software?” you ask.
“Because people were messing up their reports in the old software,” your client says.
“Why were people messing up their reports in the old software?”
“It was confusing to use,” your client says. “The new software walks people through the process a lot more clearly.”
“So the new software is easier to use?”
“Yeah, a lot easier.”
“And everyone who will be using it is already familiar with the old software?”
“Yep. They’ve all been entering TPS reports for years.”
At this point, do you agree with the client that everyone needs “training” on the new software? I hope not.
You might propose this: Give the new software to a few typical TPS report creators and watch them figure it out. Their struggles (or lack of struggle) will show what support they really need. A help screen or short reference is likely to be enough “training” in this case.
Use a goal to focus on performance, not training
In our example, the client’s first goal was, “TPS software training is 100% complete by June 1.” This goal is measurable, but it doesn’t show how the organization will benefit. It also gets way ahead of itself by assuming that training is the solution.
Your innocent questions help the client see their real goal. This might be, “TPS error rates decrease 35% by June 1 as all TPS staff correctly use the new software.”
This goal doesn’t assume that training is the answer, and it justifies the expense of the project in terms the organization cares about. It also leaves room for many solutions, including job aids.
What about new products?
“We’re releasing a new product,” your client says. “Please train all employees on it.”
What are the two biggest problems with this request? I’d say:
1. The client assumes training is necessary.
2. They think “everyone” needs training. They’re planning a sheep dip.
Your (polite! helpful!) questions should steer the client to this:
- The reason the product was created in the first place. What organizational improvement is the product supposed to achieve? For example, are we trying to snag some market share from a competitor? Help your client and SMEs focus on meeting that organizational goal, which may or may not require training.
- A breakdown of the “trainees” by job role (sales, support, repair…)
- The very specific tasks a typical person in each role needs to perform with the product (sell it using X technique, explain it when a customer asks Y, repair it when it does Z…)
- The real-world barriers that might make each major task difficult, including problems with tools, time, social pressures, communications, management support…
- The (many!) solutions that could be put in place to remove those barriers
Then, if some training does seem to be necessary, it will be far more targeted and useful.
You could use a similar approach for customer training for a new product:
- Why was the product released? What problem does it solve for customers? What does it do for us as an organization?
- Do we have different types of customers? How can we categorize them?
- What does each category of customer DO with the product? What are the major tasks they perform?
- What could make each of those tasks difficult? How could we make it easier?