Develop a Training Scenario

Now it is time to develop a training scenario that you can use to teach the process.

What is a Training Scenario?

In software training, your goal is to develop competence in a specific process or set of tasks. The exercises that your clients practice these skills on are what build their competence. The slides, handouts, and lectures support the exercises. For each class you need to design a training scenario that is appropriate for the process and tasks to be taught in that class.

This scenario should simulate a business situation that the students will face. In our auto insurance claim example, the scenario could involve processing several different types of claims. When designing this scenario, we would describe each type of claim and list any special features of the application that the claim uses.

Your scenario design will read almost like a narrative of a day in the life of your student. Remember that the scenario is a summary, or description, of a business situation. It is not step-by-step directions for using the application.

The following example is a part of a training scenario. In this scenario, the course teaches users how to process insurance claims. Notice that the scenario covers variations of one task: processing a claim. Notice also that the scenario addresses the workflow for these claims. It states what tasks the user will do, in what order, without telling us how:

  • "The student will process a variety of in-state and out-of-state claims, involving both at-fault and no-fault claims. Some claims will require investigation. The student will identify these claims and, using the softwares process control features, hand them off to the appropriate parties..."

Don’t confuse the overall scenario with an individual exercise. The scenario is the setting for all of the exercises. Each exercise teaches one of the tasks, or learning objectives.

The following example describes the usage of a new online requisition system. Notice that this scenario tells us where the requisition system fits into the larger business process of purchasing supplies for a given company. The scenario takes the users through the entire process of using the software, from entering a requisition to receiving the requisitioned items:

  • "The student will enter and track several purchase orders through the system. Using their own user ID, a fictional vendor, and a fictional training fund, the user will enter a purchase order for a large capital purchase that requires approval at both Departmental and Finance levels.
  • The instructor will provide the approvals in class. After approval is granted, the student will be instructed to log into their account and check the status of the purchase order. They will then use the online fax capability to order the item from the fictional vendor. The instructor will then change the status of the order to Delivered, and instruct the student to check the status again.
  • The goal of this scenario is to simulate the entire purchase order process, from placing the order through approval to final delivery."

During this scenario, the instructor plays the role of other people involved in the requisition process. On the job, the requisitions entered by the users require approval from the Department and from Finance. To simulate this approval, the instructor will play those roles. Notice also that the instructor will "change the status of the order to Delivered". The software must be set up so that the instructor can give these approvals and change the status during the class. The scenario designer must consider how many requisitions the students will create in the class, and how long it will take the instructor to simulate the approval and delivery of these requisitions.

The following example is another training scenario:

  • "The training scenario used in the class will simulate the process of retrieving sales data from a database. The students will search for regions whose sales exceed or fail to meet projections by a given percentage, for a given time period. They will then drill down into these regions and locate the individual locations that are responsible for the variances. Finally, they will extract the relevant regional and location sales data to spreadsheet files and present it in graphical form."

A Special Case: Software Toolkits

If you’re not teaching a software toolkit, you can safely skip this section. Software toolkits present a special training challenge. When teaching a toolkit, you’re not teaching a predictable process. You’re teaching a set of tools and techniques that can be used in many, unpredictable ways.

An Application Programming Interface (API) is one example of toolkit training. A programming language is another. In these courses, each function or group of functions would comprise one chapter. The question is how do we design the scenario for our in-class practice so that it flows logically, and gives the students experience with the many possible ways of using the functions?

End-user training is like teaching someone how to build a wooden box. You might need to teach how to put the hinges in different places or how to attach different clasps, but the basic process is very predictable.

Software toolkit training is like teaching someone how to use the woodworking tools in a shop. It’s difficult to predict how your students might want to use and combine those tools. How do you ensure that they leave knowing how to build whatever they desire, whether it is a box or a table?

This unpredictability makes scenarios for software toolkit training very difficult to develop. You have many options for developing scenarios for a toolkit course. As usual, the options that are best for your students require the most work from you.

Developing a toolkit course around the single most probable usage of each item you are teaching is the easiest option. Design each in-class exercise to demonstrate the most probable usage of the function or group of functions. Don’t make the output of one exercise become the input for another, or make all the exercises part of a common scenario. Instead, design each exercise to stand alone.

Leave time to discuss more exotic usages in the class. After each exercise, encourage the students to ask about how the function(s) can be applied to their situations. This usually gives satisfactory results...if the course designer leaves enough time in the schedule for discussion, and if the instructor prepares for questions by learning the students’ situations before the class.

When using this option, student satisfaction can be greatly increased if you give them a choice of exercises to work through at the end of the class. Each exercise can simulate the situation of one type of client.

Here is how the flow of the class would look:

  1. You lecture and demonstrate one function or group of functions.
  2. The students complete an exercise for that function. The exercise demonstrates the most probable or popular usage of that function. The exercise also stands alone: it does not depend upon a previous exercise for its input and its output is not used in any other exercises.
  3. After all functions have been taught and practiced, the students choose from a variety of exercises that use multiple functions. Each exercise focuses on a unique business situation. Youll need to develop several kinds of end-of-class scenarios.

The Scenario

Why are we talking about the scenario before we’ve even written the course outline? Because the practice scenario is the outline.

Checkpoint

At this point, you should:

  • Know what tasks the students must learn in your class
  • Know that a structured training class or classes really is the best way for the students to learn these tasks
  • Have listed learning objectives, and obtained the stakeholders agreement upon them

Action

Now it is time to write a training scenario that simulates the business situation that the students will practice in class.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.218.127.141