One of the most challenging parts of being a software trainer is keeping training content up-to-date on software that constantly changes. In a world of short sprints and rapid release cycles, the speed at which software changes is accelerating. It is almost demoralizing to spend so much effort developing a training course only to find it out-of-date the moment it is completed. And many software trainers have shown up to teach a class, only to find out that features have changed.
To make matters worse, there is evidence to support this problem. According to research by the Technology Services Industry Association (TSIA), there is a 68 day lag between the time a product is shipped and live training is released.
68 days.
The question is, “How can you shrink this lag time and keep training content up to date so customers can successfully learn and use your software?”
While there is no easy answer, there are ways to change software training development so you can keep up with the rapid pace of software development.
The first step in keeping software training up-to-date is integrating the software training development process as part of the product development process. One of the steps in the product development process should include creating training. For purposes of this process, I use the word "training" in its broadest sense to include anything related to communicating to customers that the software is changing and what they need to learn. Minor software updates may only require that you send release notes to customers. Major releases may require a full-scale, formal and integrated training course and communication program be developed.
If the training development process is part of the product management process, the training team will have more visibility into what changes are coming and can plan ahead for the changes. In most cases, updating training content can be started before the changes are released, giving the training team a chance to keep up.
Another thing training teams can do to keep content up-to-date with the speed of software changes, is to leverage release notes more effectively. It is common for release notes to be written as part of a software release. It is not common for a training team to know the release notes are coming or for a training team to use the release notes to create and/or update training content.
Training teams should use release notes as a means for keeping training content up-to-date. In some cases, training teams can just insert release notes into the beginning of a training course to explain what has changed in the most recent release. This may not require updating the content in the course, but at least it communicates to learners what changes to expect while taking the course.
We have all been in training classes that walk through each tab of a software’s product, showing each feature of every tab. The idea is to make sure nothing gets missed. The problem is that you don’t need to know every feature to get the job done. You only need to know the features that they would use most often to get their jobs done. The more feature explanations within the training content, the more often the content needs to be updated.
The more feature-focused software training is, the more difficult it is to keep the content up-to-date. The more training is focused on concepts and job tasks, the less need there is to keep the content up-to-date with software changes. Features will change frequently, but job tasks not nearly as often.
Take an example of teaching a feature of a CRM product. Instead of teaching every feature on the "accounts" tab, we should teach people how to merge contacts when a duplicate is found. Learning how to merge contacts is more relatable to someone’s job than learning merge record features. That slight tweak in what should be taught, allows us to focus less of the content on the feature and more on the workflow of merging contacts. The features may change, while the workflow and process of merging contacts does not.
One way to get away from content focused on features is for content to have more conceptual diagrams that show a high level picture of what users are going to learn, what the work process is, and how it will help them get their job done. A conceptual diagram frames the entire concept of your software (or a task), and is unlikely to change, no matter how often your software changes.
Yes, features need to be covered and trainers need to stay current, but not all of those feature explanations need to be in the content. Trainers can teach new features to show how a process is performed.
Screen shots are easy to use. After all, you just take a screenshot and put it on a slide. Done. The problem is that the screen shots will look completely different in a few weeks and will need to be replaced. Instead of using screenshots, training content can describe the work task that needs to be learned at a more conceptual level, just like we discussed above. You could list action steps or show a workflow diagram of a task, but don’t put a screenshot on the slide. Save yourself the hassle of updating screenshots every month.
There is no getting around the difficulty of keeping software training content up-to-date in a world of short sprints and rapid release cycles. However, you can keep up, if you just change how you design your training using the techniques above.
Contact us to learn more.
