Software Application Rollout Training (Part 1)

This is the first installment in a three-part series on responding to the challenge of software application rollout training. Or as some may call it..."What to do when the house is on fire."

Resource ArticleThe Flame: Your company is releasing brand new software in a few months and you just found out about it. It's your job to create the training materials for a worldwide audience.

The Inferno: The software, its functionality and the interface are not yet stable. The requirements, design and testing documents are nonexistent or out of date. Subject matter expert availability is limited.

Does this sound familiar? How do you respond to this kind of four alarm fire? Well, put on your firefighter's suit and get ready to douse these flames with some practical tips and guidelines.

Did you know?


An October 2012 McKinsey & Company article states that, on average, large IT software projects run 45% over budget while 56% of all application software rollouts deliver less value than predicted (at the cost of millions to billions of dollars).

Although McKinsey & Company attributes 11% of the issues to unrealistic schedules and reactive planning (and another 6% to unexplained causes), Michaels & Associates consultants have observed that part of overrun chaos is also attributable to late involvement of Learning & Development professionals for developing the related training.

How to Bring Order to Chaos (Build the Fire Wall)


Let's face it, even the most optimistic training developer wants to avoid a conflagration like this. By embracing the challenge, however, you can contain the flames and assist your company and your learners. Before you jump in, take a deep breath and acknowledge that although you can't control your environment, you can control what you do with it. You can come out a winner by using a methodical approach to analyze, design, develop and deliver great training in a hurry. Success is within reach if you follow these guidelines:
  1. Set expectations and clearly define what success looks like.
  2. Determine the priorities.
  3. Determine the 'good enough for now' bar.
  4. Reduce, reuse and recycle.
  5. Use placeholders for unstable or 'in progress' elements of the software.
  6. Develop in small(er) chunks.
  7. Use rapid prototyping to ensure alignment early.
  8. Regularly report your progress.
  9. Don't sweat the small stuff.

Set Expectations and Clearly Define What Success Looks Like


As soon as you become involved in a software rollout project, meet with your stakeholders to ensure they understand what is humanly possible for training, and clearly define what you can and can't do. During this meeting:
  • Get a feel for what is most critical to the stakeholders.
  • Offer your stakeholders options in approach and methods that are quick and informative. Keep these options modest, with the intent to produce a little better than you promise.
  • Inform your stakeholders that the subject matter experts (SMEs) must review training materials for technical accuracy and business applicability. Present the reality that you'll need to tap SMEs and business leads regularly and in a controlled timely manner to add to the content you'll be gathering.
  • Ensure you know what the approval and review processes will be. During design, develop a graphic that shows these processes clearly and how they'll fit in an approximate timeline. Update and distribute to stakeholders as needed.
  • Educate your stakeholders that post-training support and reinforcement will probably be necessary and that the help desk should be prepared for heavier than usual calls. Advocate for 'Deployment Champions' as part of the pilot group. These people can bridge the gap caused by multiple software iterations, and content that might not have caught up with them all.
Make this meeting a conversation in which you acknowledge that, although your expertise is in doing things 'the right way,' you are able to adjust to the situation and can assist the business.

Determine the Priorities


Work with stakeholders and/or SMEs to determine the priorities in this project. In these meetings, you perform a condensed analysis of sorts:
  • Establish the time and budget constraints and hopefully, a 'fall back' deadline.
  • Determine which portions of the software must be trained for the rollout and what can be follow-on training.
  • Identify the target audiences and which audiences have the highest potential usage once the software rolls out.
  • Determine which audience groups adversely impact the business most if their training isn't available or if they can't quickly become productive.
  • Use the Pareto Law (80/20 Rule) to determine which 20% of the software will actually be most heavily used.
Once you determine these things, you can start to plan which training components to develop first.

Determine the 'Good Enough for Now' Bar


Instructionally sound training that is engaging and truly improves employee retention takes time to produce. You have limits in time and resources, but you want to have the best instructional integrity possible. Evaluate what you can do. The most basic bar of 'good enough' is:
  • The training meets the needs of the audiences.
  • The components are complete, clear, concise and understandable.
  • The components have actionable learning objectives so the training focus is performance, not just knowledge.
When you're in a rush, you don't need to spend time or money on sexy formatting or graphics unless it adds specific value to the learning.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Next Time: The discussion continues with repurposing content, handling unstable software elements and developing content in smaller chunks.

Continue reading:
Software Application Rollout (Part 2) →
Software Application Rollout (Part 3) →

comments powered by Disqus