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.

In Conclusion

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

Related posts:

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

Related links:
• Articulate
• Atlantic Link
• PointeCast
• Qarbon
• Udutu


  1. RAD is a high risk, low cost solution. You need to know the audience and the budgetary point to create a RAD. RAD doesn't mean throwing text, graphics, images, and selecting some values that render an output. The success ratio is very less. So if you want a RAD, make sure you trust a company that knows the software and their advantages and e-Learning psychology of users.

    However, it is easy to say we will work on a certain time frame. But for business, it is always a "yes" and a challenge to innovate on your approach towards delivery.

    In some of my projects, we have been reducing the time to market for e-Learning courses drastically from 2 months to 15 days, from 1 month to just 4 days based on the relationship and understanding. This is a clear business need and we need to understand and make a compelling pitch to succeed.

    Good and Fast is the business success proposition required by customers.

  2. Too true... and most certainly a situation every e-Learning professional faces at some time or the other. While I agree with what you say, I also feel it is difficult to find a foolproof solution to this situation, seeing as it is, in reality, quite necessary to roll out the Learning Module with the application.
    A few good first steps, however, could be:
    1) Close working relationship between Application Development Team and Learning Development to raise a flag at the first instance of conflict
    2) Dedicated SMEs to guide and review the Learning Development effort
    3) ...and loads of contingency planning :)


Thank you for visiting my blog and for taking the time to post your thoughts.

Organizations as Communities — Part 2

Yesterday, in a Twitter conversation with Rachel Happe regarding the need for organizations to function as communities, I wrote the follow...