Wednesday, July 29, 2009
Application Training Programs: What's the Big Deal?
The following para from Karl Kapp’s post called Yes, We Should Keep ADDIE, HPT and ISD Models is the trigger for my post. His post is an old one—almost 3 years old—yet extremely relevant in our situation today. I have pasted the para below:
“Products typically aren’t designed, built and marketed in a day. Why should training for that product be designed, built and marketed in one day? Same with software systems that take years to develop and then they want training created and delivered in a week...? What are they thinking and what are we thinking when we AGREE to the unreasonable demands?”
This was further ratified by a detailed post by Sreya, a co-blogger, called Challenges and solutions to technical software product training: Gathering Information. Through the details, the post illustrates the time that would be required to understand an application and gather relevant information before a training can be designed.
Currently, I am in the middle of creating a simulation-based training program for certain applications for a well-known organization. The application itself is and has been in the process of being designed and developed for quite a few months now. The organization wishes to roll out the application along with the training modules—a noble endeavor and a logical one, no doubt. Users need to know how to move around within the application before they run amuck on the live system and wreak havoc.
Wherein Lies the Problem
1. This need for a training module was not identified earlier and the training design team, i.e. us, came into the picture a week or so back.
2. The client is sadly under the impression that capturing screenshots of the application using a Rapid e-Learning Authoring Tool like Captivate and putting those inside a UI is what goes by the name of sim training modules.
3. The application is large, complex, and will be used by users of multiple roles performing varied tasks for very different business reasons.
4. This mean, the technical team developing the application cannot always provide business reasons behind all the tasks. They do and can explain the usage without necessarily knowing the logic.
What is the way ahead?
The onus, I think, is squarely on us to explain the following to the client and other stakeholders:
1. The training design team MUST be given time to understand the application from the following angles:
a. Different user profiles (Roles)
b. Tasks that each profile will perform
c. Business need for each task
d. Business need of the application
e. Whether the application is a new rollout or an upgrade (this defines the design of the training which would be a Product Upgrade Communication in the latter case)
2. This first step analysis has to be followed by the design team going through the application themselves. This helps a designer understand where separate Instruction Tips will be required to explain the logic of the step or set it in a larger context for the users.
3. A set of users needs to be identified who can be the test group for the first few modules. Based on this user feedback, the modules and program can be revised.
4. All of this can happen smoothly once the application design and development is over. If the logic of the application changes in the interim, this will directly impact the design of the training as well—not only from the perspective of different screen grabs being needed but most importantly, Instruction Tips would change.
Going back to what Karl Kapp began his post with—the need to have our fundamental models in place, ADDIE, ISD and HPT—I firmly agree.
Without thorough analysis, it would be foolhardy to claim that we can design a training program that will work. A badly designed training program is as likely to wreak havoc as zero training.
Today, when the need to justify every cent spent is HIGH, an organization stuck with a training program that does not work—read no/below average User Adoption—will not be a happy client. User Adoption = ROI + improved efficiency + greater productivity
Therefore, it is time we put our foot down and claim the time it will take us to deliver effective training programs based on sound instructional designs. The client has to be a partner in this and provide organizational support post implementation to drive adoption.
We cannot “throw away good design in favor of fast design.”
What are the Results of Following an Instructional Design Process? by Karl Kapp
Rapid eLearning Tools: eLearning Technology by Tony Karrer
Rapid E-learning Authoring Tools from Kineo
• Articulate www.articulate.com
• Atlantic Link www.atlantic-link.co.uk
• PointeCast www.pointecast.com
• Qarbon www.qarbon.com
• SCATE www.scate.com
• Udutu www.udutu.com
Yesterday, in a Twitter conversation with Rachel Happe regarding the need for organizations to function as communities, I wrote the follow...
I love this definition of MOOCs by Ignatia Inge deWaard in her e-book, MOOC Yourself: “A MOOC is a non-defined pedagogical format to or...
“A QUESTION NOT ASKED IS A DOOR NOT OPENED.” ~ MARILEE GOLDBERG, THE ART OF THE QUESTION Powerful questions are viral. A powerful qu...
Pedagogy had always established an unequal relation between the teacher and the taught. Andragogy stepped in to rectify this and foster a...