Learning objectives: Our frenemy

Frenemies“Never design anything without first writing the learning objectives.”

We all know this. It’s a useful rule, but only when the objectives are useful.

And there’s the problem — conventional learning objectives can work against us. They’re our friends, but not always.

What do I mean by “conventional learning objectives?” This sort of thing:

  • List the three steps of widget certification.
  • Explain the difference between widget certification and widget approval.
  • Describe the widget supply chain.

Here are three questions that will help you set boundaries with our frenemy.

1. Do people actually need to “learn” something?

Conventional learning objectives might be your friends if both of the following are true.

  1. A knowledge or skill gap clearly exists.
  2. Closing that gap will help solve the problem.

Is there really a knowledge or skill gap? Maybe the problem is mostly caused by bad tools, an inefficient process, lack of incentives, or some other environmental issue. With your client and SME, first identify what people need to do on the job, and then walk through this flowchart before agreeing to develop training.

Will closing the gap solve the problem? Maybe it’s true that people don’t know the intricacies of the supply chain, but installing that information in their brains won’t make them better widget polishers. Don’t deliver content just because someone told you to.

(In the Asia-Pacific region? This workshop on Jan. 23 will help you stand up to content-obsessed clients.)

2. Are we writing useful objectives for the formal training bits?

If our analysis shows that we really do need to design a learning experience, then, yes, we need objectives. Are the actions we wrote earlier good enough, or should we let learning objectives elbow their way into our project?

Here’s an example from my book.

Let’s say that we want firefighters to educate the public about preventing forest fires and quickly put these fires out when they occur. Our official goal is, “Fire-related losses in our region will decrease 10% by next year as firefighters prevent and extinguish brush and forest fires.”

Which of the following do you think I’d accept as actions to reach this goal?

a) Identify the techniques used to extinguish a brush fire
b) List the principal sources of combustion in a deciduous forest
c) Describe common public misconceptions about campfires
d) Quickly extinguish a brush fire in a dry mixed forest
e) Define “incendiary device”

If you said that only d, “Quickly extinguish a brush fire,” was an action by my standards, you’ve gotten my point.

An action is something you see someone do as a normal part of their job. It doesn’t take place in their head or in that abstract world I call Testland. The action should be the focus of our analysis and design, and it should be the statement we use to “sell” the material to the stakeholders and learners.

“But the other statements are good objectives!”

In the world of conventional instructional design, the other statements are also observable objectives.

For example, we can watch a firefighter write a list of the techniques used to extinguish a brush fire, and we can point at that list and say, “See? They know it.” And that’s the problem — we’re just measuring whether they know it. There’s no guarantee that the firefighter will actually apply this knowledge, which is what we really want and what we should be helping them do.

“Identify the techniques” is an enabling objective. It describes information necessary to perform the action. It goes in the information part of the map — I’d list “techniques to extinguish a brush fire” as required knowledge that’s subordinate to the action about putting out fires.

Our goal is to create realistic, contextual practice activities. We can do that only if we focus on what people need to do. If instead we let knowledge-based objectives distract us, we’ll create the usual information dump followed by a quiz, which is the approach that helps make us irrelevant.

3. Who needs to see the objectives?

The client

If you’re using action mapping, your client helped create the list of actions, so they’re already familiar with them. If you need to submit a formal document, I recommend an outline rather than a big design-everything-at-once document. (See this big interactive graphic of the action mapping workflow.)

In that outline, you can include your action map, which shows the actions and the information required by each. The actions are your main objectives, and the bits of information represent the knowledge that supports those objectives.

If your client wants to see conventional learning objectives, consider listing your actions as “performance objectives.” Then, indented and subordinate to each performance objective, list its enabling objectives.

I resist writing the enabling objectives using test language (“describe, explain, define…”) because that sets the expectation that there will be a knowledge test. Maybe some of the knowledge doesn’t need to be memorized and could instead be included in a job reference. It won’t be tested, so there’s no reason to write a test-style objective about it.

Or maybe people do need to memorize some stuff, but a separate knowledge test would be artificial. Instead, you could assess with the same type of activities you provided for practice, which would test not only whether people know the information but whether they can apply it.

The learners

Briefly tell people what they’ll be able to do as a result of the activity, and focus on what they care about. Put those over-eager learning objectives on mute because they don’t know how to sound appealing.

  • Not this: “When interacting with a dissatisfied customer, appropriately apply the five steps of the Abrams-Martinson Dissatisfied-to-Satisfied Customer Transformation Model” that no one has heard of but a consultant convinced us to use
  • This instead: “Turn an unhappy customer into a happy one in 5 quick steps”

Again, I’m not talking just about courses. This applies to activities, which could (and maybe should) be provided individually, on demand. Each activity that stands alone should quickly make clear what people will practice doing and how they’ll benefit.

For more on the distinction between an action and an enabling objective, see Why you want to focus on actions, not learning objectives.


Online workshop Jan. 23

Jedi Mind Tricks for learning designersIn the Asia-Pacific region? Learn to control your clients’ minds (sort of!) on January 23. In this 90-minute interactive workshop, you’ll change how you talk to stakeholders and manage the initial project meetings. You’ll stop being an order taker and instead steer clients toward solutions that solve problems and improve lives.

Learning Technologies UK

I’ll present a shorter version of the Jedi Mind Tricks workshop in my Feb. 23 session at Learning Technologies UK.

 

How to make mandatory training relevant

Compliance training sheep“How can we make mandatory training more than a tick box exercise?”

That’s the top topic voted by blog readers, so here’s my take.

For “mandatory training,” I’m picturing any material that says some version of “Follow these rules.”

It’s sheep-dip training. Everyone must be “exposed” to it, and a checkmark records that they have been exposed.

How can we make it more relevant?

1. Disobey

A client who says “Everyone must be trained on X” needs our resistance, not our obedience.

Help the client by asking questions, such as:

  • What problems are you seeing? Has something happened? Has someone sued?
  • Was this problem caused by one rogue employee, or is it a bigger issue? Is it limited to a group of employees, or is it really a problem that all employees are causing equally?
  • What are we currently measuring that will improve when everyone is “trained?”

If there’s really no problem, we shouldn’t create a solution. We need to focus on improving performance, not guarding against problems that experience has shown aren’t likely to occur.

2. Set a goal

If it’s clear there really is a need for “training,” or some force far outside your control insists on “training,” then put on your action mapping hat and push for a measurable goal. Here’s one model to follow.

action mapping goal template

For details, see How to create a training goal in 2 quick steps.

3. Narrow your focus

Make sure your audience is specific. “All employees” is not specific.

If you’re required by forces beyond your control to create something for all employees, you can at least break down the audience by major job roles as described next.

4. Do the analysis. Really. DON’T SKIP THIS.

Focus on one job role in your audience. Ask your client and SME what these people need to do, in specific, observable terms, to meet the goal.

“Follow the data security policy” isn’t specific. This is specific:

  • When you must physically transfer data to another location, put the data on a BrandZ thumb drive using HakrPruf encryption and chain it to your left ankle.

Prioritize the actions. Choose a high-priority one, and ask, “What makes this one thing hard to do?” Use the flowchart.

Again, you’re doing this for a specific group of people in a specific job, and you’re focusing on specific, observable behaviors. You’re not asking this once for the entire “course,” and you’re not talking about all employees in every job everywhere.

If those forces far beyond your control insist on applying the same solution to everyone, do this analysis for the major job roles. You probably won’t have a ton of time to do this, but even two hours can save you and everyone else from a much bigger waste of time in the form of irrelevant and ignored materials.

Then, if training is part of the solution, you can have people use only the activities that apply to their job.

Don’t skip this.

If you skip this analysis, what do you have to work with? Generic rules that are guaranteed to become an information dump.

Instead, if you look closely at what people need to do and why they aren’t doing it, you get:

  • Ways to fix the problem that don’t require “training”
  • Ideas for ways to help people practice the tricky parts
  • Respect for the intelligence and experience of the people currently doing the job (notably lacking from most compliance training)

5. Base your design on job tasks, not information

Yes, people need to know stuff. But they need to know stuff in order to do stuff. Design first for what they need to do.

Provide the need-to-know information in the format it’s used on the job. Let people pull the information just like they will on the job.

Here’s a fictional example. Extraterrestrials have landed and are being incorporated into earthling families. As a result, employers have created alien leave policies. Here’s a mini-scenario for managers.

Mini-scenario for alien leave

To answer this question, what information does the manager need? The alien leave policy. How should we provide it?

The traditional approach would be to first present a bunch of slides about the policy. Then we’d give people a chance to “apply” what they’ve “learned” by having them use their short-term memory to answer the question.

Lots of slides followed by activity

But why design slides to present information that’s already in a policy on the intranet?

Instead, we can plunge people into the activity and let them use the policy just like they will on the job.

Instead of presentation, just an activity that links to info

Same activity with link to policy

And now that we aren’t developing lots of information slides, we can create more activities. Since they aren’t trapped inside an information presentation, they can travel alone. For example, we can provide them individually over time (spaced practice) as described in this post.

6. Sell it with a prototype

Create a prototype of one typical activity and show it to the stakeholders. Make clear that people will see only the activities that apply to their job. They’ll pull information rather than recognizing what they saw three slides ago, and they’ll learn from the consequences of their choices.

You’re letting the stakeholders see for themselves how you plan to provide the “training,” because then you’ll be in a good position to respond to the following common concerns.

“But everyone must be exposed to all the information!”

Give each option unique feedback. In that feedback, first show the consequence of the choice — continue the story.

Then show the snippet of information they should have looked at, as described in How to really involve learners. Do this for all consequences, not just the poor ones.

See more ideas and examples in Scenario mistakes to avoid: Eager-beaver feedback.

If you have a stakeholder who’s determined to expose everyone, you can point out that they are now exposed. They’re just exposed after making a relevant decision, rather than in a forgettable presentation.

By not presenting information first, you’re helping people see their own knowledge gaps. They’re not pulling stuff out of short-term memory, because you haven’t put anything there. They have to rummage around in their existing knowledge, look at the policy just like they would in real life, make a choice, and learn from the consequences. They get deeper learning, plus they’re dutifully “exposed” to the correct information.

“But they have to prove that they know it!”

Which approach is more likely to avoid lawsuits about misuse of the alien leave policy?

A. Present the policy over several slides. Then require a knowledge test to see if people can recognize a bit of information that they saw 5 minutes ago. If they can, they “pass.” If they can’t, they must put those same slides back in their short-term memory and try again.

B. Present challenges in which people need to make the same decisions they make on the job. Provide the information in the same format that people will have it on the job. Start with easy-ish decisions and increase the challenge. If people make good decisions in enough activities, they’re free to go. If they make not-good decisions, they get more activities and optional help until they make good decisions.

My point

Don’t design for “They should know the rules.” Design for “They should correctly apply the rules on the job.”

For lots more, see my book and just about everything in this blog, especially the following posts.

Credits

Photo of Jorge: David Boyle in DC via Compfight cc

All other images: Cathy Moore

On Time, Resources and the Desired Experience

Sitting by a tree in Myersville, MD talking about trip/project planning.

Now that I am back home, here are the actual numbers:

If I went by plane (one way):

  • 1.5 hours for the actual flight between DC and Toronto
  • Take taxi to airport (anywhere between 30 minutes and 2 hours – dependent upon DC traffic)
  • Arrive at the airport at least 3 hours before the flight
  • Pick up luggage and rental car – about 1 hour
  • Get to destination in Southern Ontario – 2 hours
  • Total travel time – 8 – 9 hours

Going by car (one way direct to final destination):

  • 10 hours, including stops.

Then there is the experience in a car vs. the plane:

  • I don’t have to worry so much about packing toiletries
  • My seat is significantly more comfortable
  • I can listen to whatever I want without getting interrupted
  • I am free to stop whenever I want
  • I am not disturbing anyone or climbing over people to use the bathroom
  • Even with gas prices, food, and wear and tear on my car – the car is significantly cheaper.

Fundamentally – I spent 1-2 extra hours for significantly more satisfaction and happiness.  I think that’s a great ROI.

Really, the only “disadvantage” of driving myself places is that I am not able to work (or at least do stuff in front of my computer).  Honestly, I don’t see “not being able to work in front of a computer” as a disadvantage.  I managed to get a lot of work done during my road trip – the videos are my evidence 			</div><!-- .entry-content -->
	    
	<footer class=

#52books Why Simple Wins

———–
Format: Kindle
We have a culture of “more is more.”
We struggle to let go of things.  The pet processes that we so carefully designed.  Tasks that we have made our own.
If we want to let go of things that no longer work or are outdated or didn’t need to happen in the first place, we hesitate to go through the grief of dealing with all of the people impacted by the change, nevermind our own grief and feelings of loss.
Lisa Bodell provides a compelling argument for simplifying processes, a recognition of the challenge in front of us, and some instructions for how to go about doing it.
For the how-tos, all you need to read is Chapter 8, then use the Appendix of 50 questions.  She has tools throughout the rest of the book, but the last chapter really talks about the process.  Because, when done right, any business process improvement NEEDS to be a process itself.
The rest of the book is also worth your time.
She provides exercises for teams and organizations, as well as structural and hiring strategies.
She describes characteristics of both leaders and staff, as well as supportive behaviors that will help with creating a simplification culture and discourage the development of complexity.
Bodell talks candidly about the struggles she encountered when providing simplification consulting.  What worked and what didn’t.  Where she found the most resistance and why that resistance appeared.  I get the feeling that this continues to be a work in progress. As it should be.

Scenario design: The process

Process for designing scenario-based trainingI’m kicking off a series of posts about scenario-based training. Let’s start with the big picture: The design process.

Many people start writing a scenario too soon. They invest a ton of time only to find their work rejected by the client or learners.

Use the steps below to make sure you’re writing a challenging scenario and going in a direction everyone will like. It’s far easier to adjust a few notes than it is to throw out a story you spent hours writing.

The main takeaways:

  • Analyze the problem! Make sure you understand why the task is hard to do properly.
  • Prototype first! Write one decision point and get approval for that before you write another word.
  • For a branching scenario, sketch and test the plot before writing the story.

Here are the details, mostly copied from my book Map It. For lots more about every step, see the book.

1. Analyze everything. Don’t skip this!

  • Write a project goal. Identify how you’ll measure success for the project as a whole.
  • List the specific, observable actions people need to take on the job to meet that goal. Prioritize those actions.
  • Will training help flowchartFor the high-priority actions, ask, “Why aren’t they doing this now?” or “What might make this difficult?” First consider the environment (tools, systems, and culture), to avoid assuming that the problem comes entirely from a lack of knowledge or skills.
  • Note the non-training solutions you’ve probably discovered from the above discussion, and identify the behaviors that will probably benefit from practice activities.
  • Identify the best format (live, elearning, etc.) for each activity idea and the best time for the person to use the activity (such as right before performing the task, in short sessions spaced out over time, etc.). Don’t assume a “course” is the best solution, because it rarely is.
  • If the skills addressed in the scenario are complex or controversial, determine how you’ll provide a debrief or other way for people to discuss issues and see the larger picture.

2. Prototype one decision point

First, draft one challenging question.

  • Pick a typical behavior that will be addressed with a scenario activity. You’ll turn it into a prototype decision point. It can be a standalone mini-scenario or one decision point in what will become a branching scenario.
  • Interview your SME for the prototype activity. Get the understanding you need to create a believable question, tempting options, and realistic consequences for those options. Capture the common mistakes and why people make them in addition to the best choice and what makes it difficult to make.
  • Example of a scenario prototypeWrite a stem. The stem is the setup and question for your decision point. Use the insight you got from the SME to recreate the real-life issues that tempt people to make the wrong choice.
  • Write the options. Include the common mistakes that the SME identified and make them sound like good choices.
  • Write unique feedback for each option. Show the consequence of the choice by continuing the story. You might also provide instructive feedback (“You should have done X”), possibly as an optional explanation, but first show the consequence.

Next, add any supporting information, and make it optional.

  • Decide what is the minimum information the player must have to make the decision in your prototype.
  • Decide when and in what format you’ll provide the minimum supporting information. My usual recommendation: Put it in a real-world job aid, if that’s appropriate, and have people refer to the job aid when they’re considering the question. Don’t present the information before the activity; let people pull it if they need it. Also provide a snippet of the information in the feedback to reinforce or correct each choice.

3. Test the prototype before you write another word

  • Create a mockup of the prototype decision point and test it on the SME, client, and a group of learners. If the prototype is a decision point in a longer scenario, describe the bigger story that the question is part of, but don’t write it yet.
  • Your prototype will help determine how people will choose options, what information they’ll have available and when, whether they can go back to make a different choice, how they receive feedback, and what the feedback contains.

If you’re creating one-scene mini-scenarios, once your prototype is approved, you can confidently crank out several more scenarios using the same format. Consider sending them to your SME in batches, so the SME can consider one batch while you write the next.

If you’re creating a branching scenario, you aren’t done yet.

4. Branching scenario: Additional steps

Once your prototype is approved, you’ll:

  • Identify the story endings. You might have one “best,” some “fair,” and a few “poor” endings. Decide in general what decisions a person would make to reach each ending.
  • Write a high-level plot as a The flowchartflowchart or in a tool like Twine. Use notes only; don’t write a script. (I use Twine because I can complete all remaining steps in it, it’s flexible, and it’s free).
  • Consider writing the best path first and then filling in the less-good paths. Connect paths so players can realize that they’re heading toward a bad ending, make a better choice, and end up on a better path.
  • Get feedback on the plot. Consider including future learners in the review. You’ll probably need to describe what happens, since you’ve written only notes. Make sure the plot is realistic and complex enough to be challenging. Most first drafts are too simple.
  • Once the plot is complex enough and approved, flesh out your notes to turn them into a story.
  • Write debrief questions as you flesh out the plot. You’ve probably chosen a branching scenario because the skill to be practiced is complex and full of grey areas. Help people see the big picture and process what they’ve learned by planning to ask thought-provoking questions during a debrief.
  • Get feedback on the complete story. Again, I recommend including learners in the review.

See chapter 13 of Map It for detailed questions to consider at each review. And for lots more about scenarios and to get my help in writing your own, consider signing up for the next scenario design online workshop.

#52books The Phoenix Project

View on Instagram http://ift.tt/2EW7Rsk
———

#52books – The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win

Format: Kindle

It’s a luxury to sit and consume a book in one sitting.  Having the time to do that is half of it.  Finding a book you can’t put down is the other.

Gene Kim, Kevin Behr, and George Spafford use storytelling to share a way to think about DevOps and IT as a key business driver.

They have obviously spent time in the trenches.  The stories ring true, the characters seem to be modeled after people they have encountered, and I get the sense that some of the situations are thin disguises for real-life episodes.  Admittedly, they also try to cram those characters into typical IT and corporate stereotypes (the guru/mentor, the politician, the “CEO,” the savior engineer, etc). They also follow the hero’s journey as the framework, so you pretty much knew how things were going to end.

Thankfully, I was not reading this as a novel or expecting much of a plot.

I could have easily read the back of the book and get what I needed out of it.

Reading the whole book, however, helped to provide context to the ideas in the back of the book.

I also found myself going on the learning journey with Bill, the main character, as he tried to parse what Erik, the guru/mentor, told him.

It’s impressive when a book gets my attention enough to make me engage like that.

 

Let me help you visualize your work-in-process!

Subscribe to the newsletter and I will send you a free PDF to help you with personal prioritization.
The first newsletter will be coming to you by the end of this week!



I hope you can join me on this journey!

Action mapping book now available

action mapping bookMap ItMy new book, Map It, is now available in print and Kindle from Amazon sites around the world. Learn more here.

The book walks you through action mapping in way more depth than I’ve been able to use in this blog. You get 418 pages of detailed how-tos, examples, and even scripts for specific things to say (and not say!) to your client. Plus, of course, some gentle snark.

It’s all written with Cathy’s characteristic dry wit and humour and with a running story of a couple of learning developers in content hell. It’s as entertaining as it is informative. — Norman Lamont’s review

Free stuff

You can read a big chunk of the book for free on Amazon by using the “look inside” feature.

You can also download some action mapping job aids and see activity examples that relate to specific chapters in the book.

Lessons learned

In the interests of working out loud, here are some advantages I enjoyed from writing a book instead of, say, a series of blog posts.

  • Freedom to dig deep: I enjoyed having the room to write in depth. When you create blog posts, course modules, or those other quick snacks we’re expected to produce, you can feel pressured to simplify too much and smooth over too many rough edges. Expectations for a book are different. For example, I was able to dig way deeper into client management and problem analysis than I’ve been able to go in my other materials.
  • Freedom to take risks: In the book I felt freer to say things that could irk some people, because those statements are surrounded by a ton of context. A blog post or slide in a presentation is easier to misinterpret.
  • Freedom from a publisher: Some years ago, I sold a non-fiction manuscript to a publisher and it was turned into a book in the usual way. I also wrote a lot for trade magazines. These weren’t terrible experiences, but there was no doubt I’d be publishing this book on my own. I wanted to use my natural voice, which in my experience publishers want to tone down, and I wanted to make sure that the marketing fit my brand, not theirs. This meant that I had to learn about book publishing, but it wasn’t too painful. (Interested in publishing your own book? Patti Shank has been presenting on this and sharing resources, as well as publishing useful books for learning designers.)

I also confirmed a couple of lessons.

  • Reinforce the base before you add any more weight: The book was late in part because I needed to overhaul how I process the many emails I receive. I knew that a book would inspire more emails, and I was already unable to deal with the current amount. This required experimentation with several solutions and policies.
  • Seek professional help: I wanted to focus on writing, not production. So I hired this excellent book formatter to create custom Kindle and print designs, and this professional, responsive cover designer to make the outsides pretty. They both have far more skill than I could ever develop and left me free to write. (That’s one reason why I say that instructional designers should analyze and design, and someone else should produce the materials.)

Thanks, everyone, for your patience while the book slowly crawled out onto the market. I hope you find it useful.

New action mapping job aids available

Action mapping job aidNew, prettier job aids for action mapping are now available for free download. They include:

  • Overviews of action mapping
  • The “Will Training Help?” flowchart, new and improved
  • A “Job Aid or Memorization?” mini-flowchart to help your SME see that people don’t need to memorize everything

The job aids are designed to accompany my new book, which is now available on Kindle. The print version will be available in mid-October through Amazon in many countries.

Finally, there are still some seats available in the scenario design course that starts October 4. In four weeks of sessions, you’ll apply action mapping and scenario design to a project from your job.

There are online sessions for time zones in the Americas as well as Europe, the Middle East, South Asia, and Africa. Check them out!