Members Only Logo  

or Subscribe by Email by entering your address below:

Powered by FeedBlitz
Learn about Subscriptions Follow me on Twitter!

The topics discussed here grow out of the bread-and-butter issues that confront my consulting and software clients on a daily basis. We'll talk about prosaic stuff like Membership Management, Meetings and Events Management and Fundraising, broader ideas like security and software project management, and the social, cultural, and organizational issues that impact IT decision-making.

Sunday, June 03, 2007

Five tips for software systems training

My good friend Adriano Pianesi, the former trainer at Members Only Software, has taken the bull by the horns and announced the creation of his own training consultancy, Participaction. Take a look at this site - you'll see his approach goes way beyond drilling users on what button to click when. Adriano and I have had some long conversations over the years about how to best provide the training organizations need to make effective use of their information systems, and he led us in experimenting with a lot of different ways of doing training. We've led some awful sessions and some great ones. Eventually, we found that traditional classroom training was rarely the solution. Here are some of the things we learned:

1. Information Systems training needs to focus more on organizational policy and business practices than on technology. It's easy to teach someone how to issue an invoice. But who is the customer? When are invoices issued? What should you do if the system warns that an account code was not set up properly? Without this kind of knowledge, your users will have a long slow climb to productivity on the new system. But its not the software guys who know this. So the training needs to be a collaboration.

2. Information Systems rollout trainings need to include a change management component. Mission critical software rollouts have broad implications for the way people work. Otherwise, why bother? But to say "this will make our work easier" or "these tools will help our teams collaborate" just skims the surface. The users know the new system will alter their day-to-day lives. They may be eager for the change, afraid of it, or just plain resentful of the disruption. The training is a time to prepare for procedural upheavals.

3. Training needs to be active and interactive. Presentation and drill on the workings of the system are boring and ineffective. Training sessions need to actively engage the user from the first minute. We found, for example, that a treasure hunt -- plopping the users in teams in front of the new system and asking them to figure how to find things was far more effective than a presentation of where key information is to be found.

4. Your organization needs a plan for ongoing training. This is an area we see most organizations neglecting. Everyone knows they need new system training. But how will you deal with staff turnover? After a couple years, some of your key users will move on, and you will have new staff members who come in and find the system already in place. You need to create sustainable plan to train these new staff members without constantly paying someone from the outside to do it. You need ongoing training for other reasons, too. Staff forget things they learned but have not been using. And the software has seen a few updates by now - are you sure you are getting the full use out of your applications?

5. The answers to most of your ongoing training needs are already in your organization. The ongoing training is not as difficult to organize as you might imagine, because someone in your organization knows the answer to almost every question someone else has. The challenge is to make the knowledge accessible to your users. We did an advanced users training a few years back at one of our YMCAs. People were asked to submit questions in advance - and we got 56 of them. At the training, we broke the sixteen participants into tables of four and randomly distributed the questions to the tables. Each table was to present to the group the answers to the questions they'd been dealt. If no one at the table new the answer, they'd solicit help from other tables. On only 6 out of the 56 questions was our help needed at all. So the real issue had not been training in the traditional sense - but simply setting up a structure for sharing the information.
image originally uploaded as

Labels: ,

Comments on "Five tips for software systems training"


post a comment