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.