Action Mapping: Less Content, More Impact

Action Mapping: Less Content, More Impact
eamesBot/Shutterstock.com
Summary: If there is one trick that helps you achieve less content and more impact, it is Cathy Moore's action mapping (adapted to your organization).

Action Mapping And Impact

What's action mapping, and how does it increase impact while saving you from drowning in content?

It's a mashup of performance consulting and backward design, with a focus on real-world behaviors rather than assessment questions.
- Cathy Moore [1]

If I had to pinpoint one single thing that made a big difference in my 20+ years in L&D, it would be action mapping by Cathy Moore. I adopted and tweaked it for learning consulting, but overall, I credit to Cathy my success in "less content, more impact!"

This backward design methodology magically aligned with Amazon's "working backwards" approach as well. This article is about the first part of action mapping for impact: needs assessment and identifying barriers. The second part of action mapping, coming up with meaningful activities to practice, deserves its own article.

Illustration of the working backward approach to learning design, based on Cathy Moore's action mapping

Action Mapping Conversation

To illustrate action mapping, I asked ChatGPT to simulate a conversation between a business stakeholder and a learning experience designer (who could be an Instructional Designer (ID)) using Cathy Moore's action mapping approach for needs assessment. What came out initially is a badly written Hollywood scene. So, read the following conversation and try to identify elements that are totally BS (no pun intended) and do not happen in real life:

Business Stakeholder (BS): "We're facing a complex issue in our organization. It's not just about lacking skills or knowledge; it also involves inadequate tools, motivational challenges, and some process inefficiencies."

Learning Designer (LD): "I understand. Let's start by identifying the core business problem. What specific performance or results are we looking to improve?"

BS: "Our main goal is to enhance overall efficiency and productivity in our project management (PM) teams. We're falling behind on project deadlines consistently."

LD: "Got it. What are the Key Performance Indicators (KPIs) we should focus on? For instance, project completion rate, time management metrics, or client satisfaction scores?"

BS: "Exactly those: completion rates, adherence to timelines, and client satisfaction. We need our teams to perform better in these areas."

LD: "To achieve this, what specific behaviors do you want to see in the teams? For example, more effective use of project management tools, or better communication within the team?"

BS: "Both are crucial. Better utilization of our project management software and more proactive communication are key behaviors we need."

LD: "Understood. Now, let's talk about the barriers. What's holding your team back from exhibiting these behaviors? Is it a lack of knowledge, skills, motivation, or are there environmental factors like technology limitations?"

BS: "It's a mix. There's a gap in skills, especially in using the software efficiently. Motivation is another issue; there seems to be a lack of engagement. And yes, we have faced some tech limitations."

LD: "For the skills gap, we can design training that focuses on practical application of the software. For motivation, we might explore incentives or gamification. Regarding tech limitations, we'll need to collaborate with the IT department. Does that approach align with your expectations?"

BS: "It does. I'm particularly interested in how we can make the training engaging and directly applicable to their daily tasks."

LD: "Absolutely. We'll use real-life scenarios and hands-on exercises in our training. We’ll also measure the impact of our interventions on the KPIs you mentioned. This will ensure that our solution addresses the root causes effectively."

BS: "That sounds like a comprehensive plan. I'm looking forward to seeing how this unfolds and impacts our team's performance."

LD: "Great! I’ll start drafting a detailed action map and get back to you with a proposed strategy soon."

What Happens In Reality?

Your conversation with business stakeholders depends on your relationship with them. Action mapping doesn't work without trust and mutual respect. And those come from long-term relationships (internally) or hiring a consultant (externally). When a stakeholder requests training at the eleventh hour, it is not the time to start building trust by asking lots of questions.

Be flexible with the process and show the value, not the steps. For large projects, we had one- or two-day kickoffs with clients, mostly doing action mapping to ensure impact. All stakeholders said at the end that it was worth it (and yes, they were skeptical at first).

Does Action Mapping Always Work?

No. I had to abandon the process once in my 10+ years doing this. It was clear that a) we didn't have the right people in the room, and b) they could not make a single decision without the missing person. Now, let's get back to the simulated conversation above.

Problems With The Conversation Flow

The business stakeholder clearly articulates the complex problem. This would be called on-the-nose dialogue in a script. These words are put into someone's mouth for the sake of the conversation.

BS: "We're facing a complex issue in our organization. It's not just about lacking skills or knowledge; it also involves inadequate tools, motivational challenges, and some process inefficiencies."

In real life, BS would most likely come with a "solution" in mind (sometimes, they even name the delivery method and the length) for the symptoms (as opposed to the root cases)... which would make the LD's job much more difficult, of course.

LD: "I understand. Let's start by identifying the core business problem. What specific performance or results are we looking to improve?"

  • "My audience is very technical. They don't do well with talking. How do I convince them to try action mapping?"
    Don't try this unless you know your audience well, but what about this approach: "When you see unexpected results or undesired outputs in the system, what's one of the first things you look at on the server?" The answer is clearly the logs. Logs can identify the culprit. So, once they agree on that, you can say that this process is like looking at the logs: it involves identifying the potential sources, instead of trying to patch the problem.

What Else Is "Illusionary" In The Conversation?

Maybe they should hire the ID to run the PM function... But seriously, in real life, experts have something called a curse of knowledge. They know so much, they have so much expertise in the domain, that they can't break it down into elements anymore. They combine multiple steps, apply unconscious bias, answer questions without even thinking about it, and eliminate "obvious" noise that novices struggle with.

Most likely, a problem like that would start with a request for PM tool training. Additionally, an ID would be unlikely to name all the KPIs the business is focusing on. This is so obvious for experts that sometimes we really have to ask them the obvious question: "how do you know they're falling behind project deadlines?"

Sometimes not knowing (or pretending not to know) anything about a process helps you ask fundamental questions that otherwise would be "too obvious."

BS: "Our main goal is to enhance overall efficiency and productivity in our project management teams. We're falling behind on project deadlines consistently."

LD: "Got it. What are the Key Performance Indicators (KPIs) we should focus on? For instance, project completion rate, time management metrics, or client satisfaction scores?"

BS: "Exactly those: completion rates, adherence to timelines, and client satisfaction. We need our teams to perform better in these areas."

Another issue with bad screenplays is telling, not showing. If someone is a bad guy, you don't just put a sticker on his head saying "he's bad." You show the guy doing something bad. Same with action mapping: don't just settle on words, ask for specific actions.

LD: "To achieve this, what specific behaviors do you want to see in the teams? For example, more effective use of project management tools, or better communication within the team?"

BS: "Both are crucial. Better utilization of our project management software and more proactive communication are key behaviors we need."

Let me tell you, when you say "better communication with the team," I guarantee everyone has a different idea of what that means. Be careful with assumptions. Ask for specific behaviors, desired and undesirable. Elicit examples when they see bad communication between the team. Ask about the circumstances. How does the manager even know that? Spying on them? Micromanaging them? Do they have clear guidelines?

The exact details will help to identify barriers. A single "communication" issue could have tens of root causes, and each of them may require a different approach. That's the point of action mapping and that's how it ensures impact: you will map the minimum content people need in order to practice certain skills in a given scenario.

Let's Talk Barriers!

One of the most revealing parts of doing action mapping is discussing why people are not showing the desired behavior and what they are doing instead. Breaking down the business problem to (at this point, assumed) root causes elicits systems thinking. Without knowing the type of barrier we're facing, a course would be spaghetti on the wall: let's see what sticks. However, again, the script is unrealistic and shows that ChatGPT has never done this for real.

LD: "Understood. Now, let's talk about the barriers. What's holding your team back from exhibiting these behaviors? Is it a lack of knowledge, skills, motivation, or are there environmental factors like technology limitations?"

BS: "It's a mix. There's a gap in skills, especially in using the software efficiently. Motivation is another issue; there seems to be a lack of engagement. And yes, we have faced some tech limitations."

First, don't ever rely on a single person's view. Even if this stakeholder is an expert, or even worse, a leader who used to do this job, but now they're sort of detached from the daily trenches! Bring in multiple views: from an expert to a novice, different department representatives with a stake (for example, in a call center: quality, operations, supervisors, and IT). Why?

They will solve half of their problems in the room! All you need to do is facilitate the process well. Many of the barriers have nothing to do with training. Facilitating a discussion around barriers and sources of issues can be solved by simply talking to each other.

There is one trick to this, though. If you ask them for a barrier type, they will likely agree with the most senior person in the room. I use a deck of cards to solve that. Everyone in the room has the same five cards (knowledge issue: they need to memorize; knowledge issue: they need to tool on the job; skills issue: they need practice; motivation issue: they need some nudge; and environment issue: things we don't have control over (politics, legal, tech, etc.)). I ask them to think about a problem and, on a count of three, show one card they think is the main reason. They never show the same cards. The point is not even the card, but what happens after:

"Tell me why you think this is an X issue?" They have a dialogue. As they listen to each other, they learn new aspects of the problem.

Stop The Urge To Solve!

And finally, this is one of the most difficult behaviors for learning designers. You have to ignore the urge to solve individual issues when they come up! The worst you can do is this:

LD: "For the skills gap, we can design training that focuses on practical application of the software. For motivation, we might explore incentives or gamification. Regarding tech limitations, we'll need to collaborate with the IT department. Does that approach align with your expectations?"

The moment you bring up learning solutions, you're making multiple mistakes in one move:

  1. You refocus the room from digging into what really matters to the illusion of solving (mostly about content and delivery methods).
  2. Your SMEs light up and start talking about content. You've lost your chance to even think about authentic activities.
  3. Your ideas may stick. Later, when you realize they are not the most effective, it is too late.
  4. You're going to stay an order taker. Action mapping is a chance to provide more value than course content.

Are You Responsible For Training Only, Or Are You Responsible For Solving Business Problems?

About #4: if your goal is to filter out what's training and what's not so you can say "no" to things that are not training, this is already probably a win. However, this is a chance to step out from the "if it's not training, it's not my problem" box. This session can create a map of issues with their barriers.

Imagine all the barriers and mistakes written on the wall or a virtual collaboration board. You can then ask participants to help categorize them. Prioritize by impact. Some will be training problems you own. Some will be learning problems that need collaboration between parties. Some will be communication issues. Some will be organizational issues, process challenges, tech barriers, etc. You can even get so far that some stakeholders volunteer to own the barriers.

A Final Takeaway From Action Mapping

Your output of the session can be a map of issues that you provide to them afterwards, with a priority and owner. They can work on some of the issues on the list while you get into designing a strategy, storyboard, or whatever. That means you're a problem solver, not an order taker. That means you already provided value to the leaders, and they don't have to wait weeks for some course content. Finally, don't forget the "more impact" part of the title: you also need a measurement and evaluation plan.

References:

[1] Action mapping: A visual approach to training design

Image Credits:

  • The image within the body of the article was created/supplied by the author.