Here’s how Joe Harless helped me figure things out.
When I took his Job Aid Work Shop, he recommended a technique for analyzing tasks. Joe called this paradigming. It works best on procedural stuff, though I’ve also used it to find my way around very complicated systems.
Section 1: complex theoretical discussion
Each step in an on-the-job task has two parts. (I like to say I’m a Reform Behaviorist, so you might see some behavioral-psych roots here.)
The stimulus, meaning the starting state.
The response, or what you do when you perceive the stimulus.
As in:
S: email from Queen Elizabeth (notice: it’s a noun–a thing)
R: open email (a verb–an action)
The response leads to a new stimulus (opened email) which calls for a new action.
S: opened email (mail that has been opened—Ss are always nouns)
R: decide next action
“Decide?” Yes; I use that a lot. It’s a good launch pad for chains of activity or decisions.
S: “Read text” (the quotes show it’s a decision—a noun)
S: “Open attachment”
S: “Forward message”
And so on. More later; one more complex theoretical idea awaits:
In paradigming, there are only three kinds of steps:
the basic chain, the discrimination, and the generalization.
Section 2: three examples
The basic chain is simply a sequence of actions with no decision making.
At a higher level, of course, you might collapse a lot of behavior into a single step:
S1: Vacant land — R: purchase land.
S2: Purchased land — R: construct 12,000-square-foot house.
S3: Completed — R: furnish tastefully.
Sometimes, you need to distinguish between different stimuli that each call for a different response. That’s a discrimination.
Remember, this is a step in a larger process. In the example, the previous step might have been “receipt from purchase” and the response might have been “identify form of payment.”
What you’re discriminating among here are the different possibilities for form of payment. I left some out because the image would get too large, but you’d put in as many stimuli as exist: check, debit card, form not legible, and so on.
The third kind of behavior is generalization: you have more than one stimulus and they all lead to the same response.
Section 3: So what?
For me, paradigming offers several payoffs:
It’s a great way to track down loose ends and uncertainties in a complicated process.
It ensures that I don’t forget about something that puzzled me.
It magically becomes the scaffold for job aids.
I’ll create an example or two of paradigming in action, and of that scaffolding, in another post.
This post is my contribution to the March 2009 edition of the Working/Learning Blog Carnival, a more-or-less monthly collection of posts about learning at work (how learning happens in the workplace) or working at learning (how professionals manage their own learning). Click that March link for a list of all the participants in this month’s session, or learn more about the carnival in general.
(Want to take part in a future edition? Let me know.)
In an earlier post, I described some basic elements of paradigming, a tool for task analysis that I learned from Joe Harless. Today, I’m sharing an example of using a paradigm to figure out a complex task.
You build a paradigm out of steps. The graphic at the right shows the three kinds of steps (click to enlarge). Each step has one or more possible triggers for action (the stimulus) and at least one action to take (the response). Those three kinds of steps:
One stimulus leading to one response (the basic chain). If the stimulus is “telephone rings,” the response is, “Answer and say, ‘Oligarch Lumber; how may I direct your call?'”
More than one possible stimulus, each leading to a different response (the discrimination):
If the customer asks for millwork, transfer the call to millwork.
If the customer asks for order status, transfer the call to sales.
If the customer asks about installation, transfer the call to the service desk.
More than one possible stimulus, each leading to the same response (the generalization):
If the customer has a billing question, or if the customer wants to cancel an order, transfer the call to the service manager.
You can combine these steps–in fact, that’s a key reason for paradigming: to identify the steps and decisions in a complex task. In this post, I want to show examples of this kind of analysis. Here’s a paradigm based on an actual task in a complicated inventory-management system. (You can click the image to have the full, 800-by-1200 version open in a new window.)
“Done” can be a stimulus
When you want to review and adjust any forecast exceptions:
You start from the main menu (S1 in the paradigm) and select option 2.
That displays screen QR12 (S2), where you enter the SKU and store code.
When that’s done (S3), you select option 7.
I use “done” as shorthand for the result of the previous response. Much faster than “SKU and store code entered.”
What happens here? No idea.
Picking up at S3: when the SKU and store code are entered, in the Restrict Record field, you enter I2. According to the documentation, the response should be a list of forecast exceptions (S5.2 in the sample).
But what if there aren’t any exceptions?
I have no idea, and the documentation (or the subject-matter expert) hasn’t said. So I note a possible stimulus and circle it for follow up (S5.1).
Maybe there are always exceptions. Maybe there’s an error message. Maybe there are several. When we find out, we’ll update the paradigm. Now, at least we know what we don’t know.
“Decide” as a response, a decision as a stimulus
Many times a stimulus leads to a number of different actions depending on the decision or choice the performer makes, as with S6 in the sample paradigm. To underscore this, and to break out the possibilities, I often use “decide” as the response.
One principle is that a response is always a verb–and that’s true here. “Decide” is an action (“hey, Dad, watch me decide how to handle this exception forecast”).
Another principle: a stimulus is always a noun. It’s a thing. S7.1, S7.2, and S7.3 (call them S7x) represent the possible choices–the things you can do–when you’re looking at an exception forecast: see the next one in the queue, see the previous one, or work with the current one.
Notice that S7.1 ( “see next” ) isn’t an action; it’s a decision, the result of the “decide” action to the left. The action that this decision triggers is “Press PF7.” And S7.3 ( “work with the current forecast” ) triggers another “decide” action, which leads to the most complex discrimination in the paradigm. But first: what if there’s a loop?
Here we go again
Especially in computer applications, there’s a lot of looping back. S9.x results from trying to see either the next or the previous forecast. You can’t tell if there is a next or previous until you press the appropriate PF key. Then you either see another forecast, or you get a message (the full text: “Roll Up / Down Beyond Last Record,” a model of engineering obfuscation).
In either case, you’re at the same situation as at S6: you’ve got a forecast on the screen (either a new one, or the last one you were looking at). So you have to decide what to do. For example, if you’d asked to see the next one, you now know there isn’t a next one. You can decide to work with the current one, or go back to the previous.
“Man, that’s complicated!” Yep.
S8x is a dense cluster of stimuli. It contains a three-item discrimination (S8.1, S8.2, S8.3), since each of those items leads to a different response.
S8x also contains S8.4 and S8.4, a generalization within the overall discrimination. Whether you have spiky history or large standard error, you take the same action.
(For simplicity, we’re assuming that only one of these conditions applies to any forecast. In reality, if you could have more than one of them, you’d have to figure out (a) how do I know I have more than one? and (b) what do I do?)
I’ll jump ahead a bit here: Notice that after you respond to any of the first five S8s, you will (apparently) update the forecast, and something will happen. All this time you’ve been working on the current forecast, and we know (from S6.x) that there’s a way to ask the system to show the next one.
But what happens if there isn’t a next one? My real question is: how can I tell if there aren’t any more forecast exceptions to work with?
I don’t know, and so for the time being I have a placeholder — S8.6. The question mark, the comment in parentheses, and the highlight circle all remind me, and anyone I’m working with, that this is a question we haven’t yet answered.
More loose ends
You see more unanswered questions at S11 and S12. I’m going a bit beyond simply the technique of paradigming, because the point of the post is not so much the tool as the analysis it support.
At S10, I’ve just tried one of three actions (S8.1, S8.2, or S8.3). Now I press PF9. What happens then? Does the forecast remain on the screen? Do I get a confirmation? Does the system display some other screen?
I don’t know, and so S12 is a placeholder. Even if the right answer is “Forecast Adjusted,” I’ll need to know whether there are other forecasts waiting (and how to get back to them).
In the final example, the generalization that includes S8.4 and S8.5 is stated in very general terms. How large is a large spike? How high is high standard error? What do I do if I need to “adjust history and remodel?”
The answers could complicate the paradigm–I might have to provide guidance like “if standard error is over 0.8…”
The thing about complicated tasks is: sometimes they really are complicated. At the time I worked on the forecasting system, this was the way it worked. Nobody was going to become skilled at forecasting inventory on his own, except through trial and error that would be very expensive for the employer.
Developing the paradigm helped the client to understand the complexity of the job. It also convinced them that a lot of this stuff didn’t need to be learned (as in, committed to memory). In the next part of these series, I’ll talk about paradigms as potential road maps for building job aids.
An aside: if you need a little Irish diversion to get through the day, try last week’s side-trip post: No ‘Danny Boy’ and Not Much Guile.
One of the most productive uses of a paradigm (the task-analysis technique this series of posts has dealt with) is to suggest the content and even the form of a job aid for the task in question.
Here’s a paradigm that was part of a large inventory-management system. The task involved setting a a code to kick off a data extract that in turn would generate an electronic data interchange form. (You can click the image for a larger version.)
There’s a simple chain, then a discrimination between four possible choices. You chose one code depending on the type of output you want. Regardless of the code you type, you press enter to put the new status to in effect (which, in the less-than-clear language of this system, meant you’ve finalized the replenishment order).
Here’s the job aid. Notice how it reflects the analysis in the paradigm. (Click for a larger version.)
The simple-chain steps become cookbook steps. The discrimination becomes a decision table (if X, then do Y).
I’m working up a more complex example based on a more complex paradigm. For the last post in this series, I’ll highlight how different patterns of activity result in different kinds of job-aid steps.
So: if you’ve got a complicated job, could you end up with lots of job aids? Sure.
It’s not a given that you’ll want to build job aids–but it’s pretty likely, and it’s more efficient (as I noted here). Doing the kind of analysis that the paradigm calls for, you learn enough about the task to look for the usual create-a-job-aid suspects:
Infrequently performed tasks,
Tasks with many steps
Tasks with complicated steps
Tasks with a high penalty for error
Tasks likely to change,
Tasks without a significant need for speed.
Job aids don’t necessarily take the cheat-sheet form you see above. In the real inventory project, yes, they did–a bunch of job aids in a spiral-bound book the inventory manager kept near the computer. They could just as easily come in digital form, like embedded, context-sensitive help.
The real point is that you can’t decide whether to teach the task (try and have people memorize the steps) or to support performance with a job aid until you know what the steps are, including discriminations and generalizations. One way to capture those is through a process like paradigming.
When you want to review and adjust any forecast exceptions:
Picking up at S3: when the SKU and store code are entered, in the Restrict Record field, you enter I2. According to the documentation, the response should be a list of forecast exceptions (S5.2 in the sample).
Many times a stimulus leads to a number of different actions depending on the decision or choice the performer makes, as with S6 in the sample paradigm. To underscore this, and to break out the possibilities, I often use “decide” as the response.
Especially in computer applications, there’s a lot of looping back. S9.x results from trying to see either the next or the previous forecast. You can’t tell if there is a next or previous until you press the appropriate PF key. Then you either see another forecast, or you get a message (the full text: “Roll Up / Down Beyond Last Record,” a model of engineering obfuscation).
S8x is a dense cluster of stimuli. It contains a three-item discrimination (S8.1, S8.2, S8.3), since each of those items leads to a different response.
