It’s a classic business case. You may have heard this story before with a different cast of characters:
- Need software application training fast (within a few months), and the application is not stable.
- Only limited Subject Matter Expert (SME) resources are available.
- Need to reach a global audience, including English as a Second Language (ESL) users.
- Need to incorporate the current instructor-led training, together with the new application content.
You may also have experienced these challenges:
- How do you quickly transfer knowledge from a SME to an Instructional Systems Designer (ISD) and produce a Web-Based Training solution (WBT), while maintaining quality standards?
- How do you quickly build the training, and make it instructionally sound?
- How do you make the training simple, yet useful for an audience with a wide variety of skill levels?
- How do you build and maintain customer satisfaction throughout the project?
This is our story about an efficient and effective method to facilitate knowledge transfer from SME to ISD to Developer, and the production of a simple WBT format that both promotes learning and maintains our quality standards. For our story to have a happy ending, we needed to do the following:
- Modify our current ISD process for knowledge transfer.
- Create an interactive simulation script for ease of communication among project team members.
- Modify our interactive simulation design and development processes.
- Maintain customer buy-in and satisfaction through sharing project information and progress.
Our story begins …
The Fable of re-Learning e-Learning
The formation of the e-Learning village was considered a cost-saving measure. Our e-Learning village's charter was to create Web-based training courses for the IT kingdom as new software applications were developed or updated (and there were literally thousands of applications in the land of FoMoCo), as new IT business processes were put into place, and as instructor-led training (ILT) courses were converted to Web-based training courses.
One day, another kingdom in the empire, called Finance, sent a distress call to the e-Learning village that went something like this:
- "We are launching a PeopleSoft upgrade of the financial applications (for example, General Ledger, Accounts Receivable, Billing, Project Control, and Asset Management)!"
- "We have a global audience of 5,300!"
- "Our training staff is being reduced, and it is no longer practical to send classroom trainers around the world!"
- "We are less than six months from the PeopleSoft application launch!"
Since 1999, the Finance kingdom had used PeopleSoft applications to manage its financials. Prior to dispatching a distress call, the Finance kingdom had its own training team of four members who provided instructor-led classroom training and training documentation for 22 countries in the FoMoCo empire. But now, times were tough and cost-cutting measures were needed. With a major PeopleSoft application upgrade on the way, traveling bands of training staff needed to be reduced rather than expanded. Additionally, the Finance kingdom needed to have the books balanced and closed six months after the upgrade was implemented. Throughout the empire, everyone recognized this scenario as a big business need.
Needs Assessment and Analysis
Verily, a meeting was arranged, and members of the e-Learning village visited with members of the Finance kingdom to learn more. Here is what they learned:
- The Finance training staff recognized that people wanted hands-on training.
- Now, unable to travel and deliver classroom training around the world, the Finance training staff would only produce training documentation, quick-reference guides, and communications for the application upgrade.
- The global audience consisted of both new and existing PeopleSoft application users; therefore mere application upgrade training would not suffice.
- The training content consisted of five finance courses and an overview course.
- The Finance kingdom wanted application training only – no "fluff."
The e-Learning village had not heard the "fluff" term before, and needed to discover its meaning. We learned that our head SME from the Finance kingdom had recently taken one of the e-Learning village's Web-based training courses, "Compensation Planning," which was also PeopleSoft training, but for the Human Resources application. In this course, we used a standard linear Web-based training template that included the following content:
- Business process information and concepts
- Virtual coach
- Application examples with explanation
- Application simulations (guided and practice simulations created using Adobe Captivate), with no audio due to the global audience
In referencing this course, the head SME explained that "fluff" meant everything except the simulations, which cover task-based skills. Because knowledge-based content was covered in a separate "Key Financial Skills" curriculum, it was possible to provide purely task-based training in this case. (See Figure 1 for an example of what the head SME considered “fluff.”)
With great haste, the e-Learning villagers returned to the IT kingdom to brainstorm a solution. The villagers all agreed to these challenges:
- Limited time
- Limited resources
- Need for fast knowledge transfer from SME to ISD, and then from ISD to Developer
Design and development
As a result of the brainstorming, the e-Learning villagers resolved to take three key actions, each with its own motivational slogan. These actions impacted the design and development process:
- Action: Design a new course shell for application-only training. Slogan: KEEP IT SIMPLE.
- Action: Adapt the current process to meet an aggressive timeline. Slogan: DIVIDE and CONQUER.
- Action: Design new templates for the new course shell and the new process..Slogan: BREAK WITH TRADITION.
Following is the detailed information for each key action.
Action: Design a new course shell for application-only training. Slogan: KEEP IT SIMPLE.
The e-Learning villagers put together a new course shell that simply stated the following outline-type structure: Course title, Module title, Lesson title. (See Figure 2.) Each lesson covered a specific application task, and each module was a logical grouping of tasks. The shell differed from our traditional courses in that we removed all of the "fluff." Including a course menu on the left panel, each course, module, and lesson was given only one page (right panel) on which to write learning objectives and from which to launch both a guided simulation (called a Tour) and a practice simulation (called a Practice). The course was no longer the traditional linear WBT. The learner could move around the new shell in a linear fashion (suitable for new users) or in a non-linear fashion based on locating a task of interest. The shell was built with Adobe Flash and was XML driven, which increased its flexibility and simplicity.
Action: Adapt the current process to meet an aggressive timeline. Slogan: DIVIDE and CONQUER.
In the current process, the ISD was responsible for capturing SME knowledge, writing the storyboard content, and recording and building simulations as needed. This process was time-consuming, as the ISD mostly worked alone to create the simulations. The e-Learning villagers realized that, to meet an aggressive timeline, additional villagers would need to share the ISD's workload.
The current process included a phase during which the ISD created storyboards. We decided that a storyboard was useful to represent the learning objectives for the new shell, but a traditional storyboard would not help us to communicate the simulation content. We needed something else, and created a simulation script to include all of the simulation content with action steps to complete a defined task. (See Figure 3.)
Figure 3 The simulation script
Armed with a simulation script, we divided up the work of creating Tours and Practices into two PeopleSoft teams to work in parallel. After all, we had to create almost 100 simulations for the final total of six Finance WBTs. Each team consisted of a lead ISD, a customer SME, a Developer, and a Quality Control Tester. (See Figure 4.)
Figure 4 Two-team structure to support creation of 100 simulations
This type of team organization meant that the Finance kingdom and the e-Learning village both had to commit to assigning the appropriate resources and allowing for their time to work together. Additionally, at the beginning each team was given responsibility for two WBTs.
Having two cross-functional teams meant that clear communication of the process and standards was critical. The ideal outcome of the project was to deliver six courses that looked and felt like one person built them. To facilitate this, we drafted writing standards and created an Adobe Captivate template. In addition, each simulation had to follow a creation and development process.
Tour simulation process
- SME drafts script content based on task experience.
- ISD adapts and edits script content to match task in new application, while following writing standards.
- SME approves final script for development.
- ISD (using Adobe Captivate) records application screens according to final script.
- Developer builds information and action captions with appropriate click or text boxes using the script as a guide.
- QC Tester and ISD test the Tour simulation.
- SME reviews and approves the Tour simulation.
- Developer builds Practice simulation by removing all information captions and leaving all action captions.
- ISD edits all action captions to provide "clues" for the learner to successfully complete the task, along with feedback for mistakes, while following writing standards.
- QC Tester and ISD test Practice simulation.
- SME reviews and approves Practice simulation.
Practice simulation process
The simulation script gained in value as we worked through our new process. It became increasingly clear that if the text in the script was accurate, and included ISD and Developer notes, each team member could use the script as the master communications vehicle to perform their part of the process. In effect, with a respectful nod to Henry Ford, we formed an assembly line of workers for the creation and development of the simulations.
Action: Design new templates for the new course shell and the new process. Slogan: BREAK WITH TRADITION.
The e-Learning villagers used Microsoft PowerPoint to design the storyboard template for the new course shell. (See Figure 5.) Our graphic artist designed the basic layout and colors for the shell, and copied that to a PowerPoint slide. Then the ISD supplied course, module, and lesson titles; learning objectives; and other pertinent information in the template. The resulting storyboard looked like the finished WBT, only without any functionality. This template was used early on in the project to communicate the look and feel of the final WBT product, not only to the SME but also to other members of the Finance kingdom and the e-Learning village. Because this course shell was very different from our traditional WBT shell and had not yet been built, the only way to communicate the new design was through the course shell template.
Figure 5 Example of new course shell template
The other template that broke with our traditional way of doing things was the script template. This template, which was in a Microsoft Word table format, included the following four columns:
- Slide # – Each numbered row in the table matched with a recorded slide in the simulation file.
- Information – Each information cell became a yellow caption that displayed on a specific slide in the simulation file.
- Action/Direction – Each action/direction cell became a green caption that also displayed on a specific slide in the simulation file.
- Developer/ISD Notes – We added these notes to a specific row that required additional information to either record or develop that slide in the simulation file.
Figure 6 Example of the final simulation script and its use
In addition to using templates to communicate with the Finance kingdom and other members of the e-Learning village, we incorporated two more communication vehicles. For example, we used Microsoft SharePoint to share documents for viewing and editing purposes. We used Microsoft Excel to build a "project management scorecard" in order to keep track of which team member had current responsibility for a simulation at any given time. (See Figure 7.) We did this because each simulation changed hands many times throughout the creation and development process.
Figure 7 Example of the Project Management Scorecard
