From describing to applying – user training taken seriously

It still is one of the most common mistakes made ever… Implementing new or updated software without providing user training as the reasoning is: “Oh, we don’t need to train our users. They have been using this (or similar) software for years, surely they know by now how to use it“.

Well, do they really? I’ve recently been involved in several adoption projects where we trained both new users as well as users who had been using collaboration tools for years on how common features in everyday tools like mail, calendar, task lists and contact books can help them become more effective. One of the comments we got back a lot was: “I was aware of most of it but never really applied it to how I could use it in my own job, now I see how it can help me I wish we had gotten this training years ago!“.

The thing is that to those implementing the software it often all seems so straight forward. “It’s mail? How hard can it be?” or… “Come on, everyone knows how to autosum a column in Excel!“. Reality is though – users often don’t.

“I didn’t even know it could do that!”

Often users simply don’t know all the functionalities that the software they get offers because nobody ever showed them. Most times they use only a small percentage of it’s capabilities, not because they don’t want to use more of it but because nobody took the time to set them down and show it.

“I know it can do that, I just don’t have a clue how ‘I’ can get it to do that…”

Without training most users simply won’t know how to use half of what they have.  “Well they can use the Help can’t they? Or ask?“. Yes they can. But asking often implies inadequate knowledge of something and a lot of users don’t feel comfortable admitting to their coworkers not knowing something that others seem to think is such implied knowledge. And Help files? Well,… Ever tried using MS Excel Help to figure out how to create a pivot table?…

The most important one though in my opinion, and one that is often the biggest culprit of failed user adoption is:

“I don’t see how it can help me do my job better”

The mistake made here is that often implementers and trainers focus on showing users HOW to do things without explaining to them WHY this could be beneficial to them. Expecting users to be able to make the leap from seeing a ‘feature’ into applying it to their daily job without helping them to do so is often one step too far for a lot of them. Especially with the wide variety of software and functionalities we have nowadays.

For instance: If you talk to users about the ‘awareness’ functionality in instant messaging software like Lync or IBM Sametime you can simply explain that they can change their status to “not available” or “do not disturb” or you can start a discussion and address the topic of constant availability, where IM stands in the array of options we have nowadays to contact each other (mail, phone, face-to-face, etc), why and where it can be handier to use one over the other and how users can – and should – make choices about their availability to be contacted in that way.

Last but not least:
Enablement, education and training should never be seen as temporary things. Good adoption of technology and methodologies requires repetition and involvement so don’t stop after you’ve implemented the software; done your training sessions and provided reference materials. Reiterate the knowledge by regularly posting small tips & tricks on bulletin boards or intranet sites, by uploading videos, by having users interviewed  – or better yet – stimulating them to write blogs and wiki’s themselves about how it helps them to do their job better and by offering over the shoulder support.

So….

  • Never assume
  • Involve the user to train the user
  • Start with addressing the ‘why’ before going into ‘how’
  • repeat & reinforce

But most importantly have fun doing it… Nothing is more satisfying then seeing that ‘light bulb’ go on in someones eyes when they learn that one thing that will make all the difference to them in their day to day job… 🙂

 

Tags:

2 thoughts on “From describing to applying – user training taken seriously”

    1. I won’t lie, getting a time commitment from senior folks can be tough. You need to position it strongly. We never say we do a course on “software X” or “Program Y”. Instead we use theories like David Allen’s Getting Things Done to do courses on improving effectivity in collaboration. I explain the theory and then show how you can use certain features of the software to help users work more structured according to the theory. Makes it much more hands on and we score high with that among all levels of seniority.
      Also never position it as an “IT” project… The software is just a tool, you are not teaching them to be an expert on the software/program. You’re showing them ways to incorporate collaborative tools into their work so they can do their work better/faster/more effective.
      In general we find that word of mouth after one or two of these courses then often does the trick of pulling in the rest.

Comments are closed.