Agile development, DevOps and the cloud have moved software development from regular updates and releases to a nearly continuous stream of changes. And it’s not slowing down. It is no wonder nearly 50% of all CRM projects fail and less than 40% have full-scale adoption. Contributing to this failure is a lack of training. Evidence shows that ERP projects that spend less than 13% of project costs on training are 3x more likely to fail, compared to projects that spend 17% or more.

If training is so important to software adoption success, why do so many enterprise software companies ignore it?

It is daunting to build customer training programs when you know training materials will be outdated in weeks. So daunting that, according to the research by the Technology Services Industry Association, there is a 68-day lag between the time a product is shipped and live training is released.

The critical challenge is, how can you shrink this lag time and keep training content up to date so customers can successfully learn and use your software? There is no easy answer. However, there are ways to change the way software training is delivered so you can keep up with the rapid pace of development.

Make training part of the ‘sprint’
When training design is part of the development process, content can be more quickly prepared and delivered. Going back to 1996, E-Trade was a SaaS cloud business before there was a cloud. The website changed every week, new products shipped every few weeks, and the site was completely redesigned about every 18 months. Customers would sometimes call in to ask questions about changes to products that customer service didn’t even know had occurred.

As the training manager at E-Trade at that time, we made training a part of the product development process so it could be ready when new products were shipped. This helped tremendously, and customer service was rarely again surprised by customers.

Understand workflow processes and concepts
Every training course should start with a diagram showing a high-level picture of what users are going to learn and how it will help them get their job done. A conceptual diagram frames the entire concept of your software, and is unlikely to change no matter how often your software changes. Too many software courses jump right into teaching the very features that will change dramatically over a series of weekly releases.

Focus training on getting things done
We have all been in training classes that walk through each tab of a software product, showing each feature in every tab. The idea is to make sure nothing gets missed. The problem is that learners do not need to know every feature to get their job done.