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

Once Upon a Time … in a cold land on the River Rouge, there was an empire known as FoMoCo. In the empire there was a kingdom called Information Technology (IT), and in the IT kingdom there was an e-Learning village that produced Web-based training courses at the pleasure of the IT kingdom. The e-Learning village was made up of ISDs, developers, a graphic artist, and a project manager. The village, formed in 2003, was an in-house solution for e-Learning, which had previously been outsourced to other empires.

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.”)

Figure 1 “Fluff” as identified by the SME

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:

  1. Action: Design a new course shell for application-only training. Slogan: KEEP IT SIMPLE.
  2. Action: Adapt the current process to meet an aggressive timeline. Slogan: DIVIDE and CONQUER.
  3. 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.

Figure 2 Example of the new course shell

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

  1. SME drafts script content based on task experience.
  2. ISD adapts and edits script content to match task in new application, while following writing standards.
  3. SME approves final script for development.
  4. ISD (using Adobe Captivate) records application screens according to final script.
  5. Developer builds information and action captions with appropriate click or text boxes using the script as a guide.
  6. QC Tester and ISD test the Tour simulation.
  7. SME reviews and approves the Tour simulation.
  8. Developer builds Practice simulation by removing all information captions and leaving all action captions.
  9. 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.
  10. QC Tester and ISD test Practice simulation.
  11. 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

(Implementation and evaluation)

"We lived happily ever after"

The e-Learning village and the Finance kingdom experienced many challenges throughout the project, not least of which was trying to keep the eight cross-functional team members working as one mind by communicating standards, things that didn't work, and better ways of working. Because they were customizing the PeopleSoft application for FoMoCo, flexibility was an important quality for the team to possess. Overall, the project was a success:

  • Each of the six WBTs launched on time.
  • Calls to the PeopleSoft Help Desk were significantly reduced.
  • The accounting books closed accurately and on time that year.
  • The WBTs and their new format received rave reviews from the customer and the learners.
  • The new process and templates served as a model for future simulation-based application training.

The e-Learning villagers and their customers benefited from the new process and new templates as numerous opportunities arose, both from new and existing customers, for which this new model was a perfect fit. We discovered that many software application-training projects didn't need to provide business process training. Instead, we could include "best practices" and "tips & techniques" in the simulation while teaching the task, and the e-Learning villagers continue along that path to this day.

The Moral of our re-Learning e-Learning Fable (otherwise known as lessons learned)

A proper fable includes a moral to the story. Our fable has three morals or lessons learned to pass along. Referring back to our three key actions with motivational slogans, we uncover our lessons learned:

  • KEEP IT SIMPLE – Focus on the end product's vision.

Having to work within the new course shell's template provided challenges. At the time, the shell template was unique; it simply included one page for each task and was no longer using the traditional linear structure. The e-Learning villagers had never before seen this new structure in production. A working prototype was developed, but the ISD remained responsible for explaining and promoting a vision for the end product to all team members. When an idea was offered that didn't fit with the vision, it was summarily dismissed; every segment of training had to be designed with the end product in mind.  

  • DIVIDE and CONQUER – Continue to educate team members throughout the project.

Effective and productive cross-functional teams develop trusting relationships with one another. Honest and open dialogue among team members is critical to developing trust. Two teams working in parallel, using a new process and templates, necessitated numerous, mutually educational, conversations. These conversations covered a lot of territory, including laying the ground rules for how to work well together, how to maintain the same standards, how to educate each other on the evolving process, what is being learned (good and bad) from working with the application, and committing to upholding the teams' shared decisions and values. This continuous, internal education effort proved to make the difference between meeting and missing the aggressive timeline.

  • BREAK WITH TRADITION – Remember to communicate, communicate, communicate.

The e-Learning villagers had found a faster way to communicate, which facilitated knowledge transfer from SME to ISD to Developer, by breaking with tradition and creating a new type of Web-based training course. The new script template and storyboard template gave structure to our cross-functional team communications. In addition, the communications vehicles (scripts, storyboards, document sharing, and project management scorecards) provided the much-needed discipline that kept everyone on task. According to the head SME, a key success factor for the project was the open and honest lines of communication that existed between the Finance kingdom and the e-Learning villagers. Having such transparency (and very little "red tape") allowed for quick issue resolution throughout the process.

We now reflect back on our original business case and see that it was possible, although challenging, to quickly produce new software application training for a global audience while maintaining quality instructional standards with limited time for knowledge transfer among team members. What was our secret? Some might say that luck had a part. We did experience some luck by having an abundance of professional, talented, and committed team members. Others might say we made our own luck. We also agree on that score; the new storyboard and simulation script templates guided us through the project to a happy ending.

Thank you for reading our story. We hope that our experience will give you constructive ideas and be useful as you practice your ISD craft in your village, or as you travel among kingdoms throughout empires.

The End