Things go wrong every day:
- Support calls are flooding IT for help with what is a relatively simple program
- Employees routinely ignore an important company policy.
- Few employees are using the costly equipment that was supposed to revolutionize your organization.
Sound familiar? Chances are high that you’ve been called in to design training to solve one or more of these problems. And chances are also high that the content owner has a vague idea of the problem, a firm idea of the solution, and a conviction that the “A” in ADDIE is unneeded in this case.
When you suggest conducting a needs assessment, the sponsor agrees that it could be valuable in different circumstances, BUT – metrics aren’t available, the only outcome data is a thin stack of Kirkpatrick Level 1 evaluations, and thus it would take too much time to start from zero.
Don’t give up the analysis! Help is available!
Before you resign yourself to giving analysis short shrift, consider: you have more data than you think you do. The users are communicating, the messages just aren’t neatly packaged for easy tabulation. Five practical tips can get you started on an informed design that addresses real problems.
1. Turn up the noise
A manager once responded to my questions by identifying the goal of a requested training as “turning down the noise.” Instead of avoiding complaints, crank up the dial. Open forums (online and in person), micro polls, and targeted surveys are good. Meeting one on one with the most vocal critics and resistant groups is even better. Make it clear that you are there to understand, not to soothe—and take copious notes.
2. Go with your gut, but don’t stop there
After conversations with the sponsor, critics, and stakeholders, you may feel you have a good handle on what’s going on. Realize that if they had a complete understanding of the problem, they probably would have already solved it. Keep an open mind until the complexity shows up. Change champions, laggards, those who’ve attempted and failed, and successful users each have a piece of the puzzle. Don’t base your design on a single perspective, even your own.
3. Seek out the workaround
If end users are bypassing the policy, the process, or the system that management wants them to use, it means they’re using something else. Leave your judgment at the door and discover the appeal of the workaround. Is it immediacy? Familiarity? Chunking? Personal contact? Simplicity? Users are wonderfully creative so you want to make sure your solution will do at least as good a job of meeting their needs as their current workaround. The only way to do that is to acknowledge its advantages.
4. Codify the suffering
This will require a time investment, but will yield by far the most valuable data. Who feels the pain? Who hears first-hand from unhappy users? Chances are it’s the Help Desk, Service Center, and other front-line workers who pick up the phone when an end user hits the wall of frustration. Ask, “What have you heard a thousand times?” “What gets people angry?” “What have they given up doing?” If there is a ticketing system, pull the logs, but don’t stop there. End users are notorious for calling or emailing instead of using the sanctioned system. Harvest that electronic crop. If time is short, dump phone logs and emails into a document, and identify the most frequently occurring words. Entering the result into a word cloud tool like Tagxedo or Wordle will yield a powerful visual for your report to the project sponsor, as well as valuable direction for your design.
5. You are unique, like everyone else
Whatever the issue, you can bet that somewhere, someone else is already dealing with it. Mine online tutorials, user communities, forums, blogs, and FAQs. Even if your system or policy is homegrown, there are similar ones out there. Find them and generate a bulleted list of reported outcomes and issues, then distribute it to users and stakeholders for a reality check. Reacting to a draft often clarifies hits and misses in a way that a blank slate can’t.