Milner’s Peer Assist, Thursday, July 20, 2006

Question: How can I make my training manual more engaging? (Like the hands-on practical session)

• Keep existing manual as a reference next to the hands-on training (and focus on the hands-on training)
• Separate budget for development of manual (as it is very different from the practical training, and requires quite a different input)
• Put in as much as possible about what the software can do, but focus on the audience’s daily use.
• Use less diagrams, and more text
• After theoretical introductions put in exercises to put that theory into practice.
• There’s nothing wrong with the manual, just think of it as something that grows, work in progress. Get a documentalist to look at questions asked in the hands-on sessions, so these can be captured for the manual.
• How is the manual being used; look at the trainers using it and document this. Use this experience to adapt the manual.
• Don’t think you made the manual once; it’s ongoing work. Invite feedback, also from other people than the ones involved (e.g. a consultant expert in writing manuals, but in a completely different field of work).
• You can give the manual to the people working with it, saying; I let you have this, it is not perfect or final yet, so please keep giving input for improvement. But do not give your manual away to anybody, please ask me first so I can make sure it is actually the latest version.
• Actually the manual should consist of 3 different parts: Technical manual, Installation manual, User’s manual; These sections are all relevant to different target groups, and you should be aware of that.
• Keep those sections in 1 publication, don’t split it up, but make very clear which audience a certain part is meant for.
• Incentive: tell people when the next version is due to be published and if they want their name to be mentioned in it, all they have to do is give input.
• Know the context in which the manual will be used, tune it to local circumstances.
• Make the manual activity-based and contextualised, so people will feel involved because they recognise materials or situations (e.g. country, or province – Ghana, Tamale, Accra, or specific type of NGO).
• Include a section on the manual in the overall evaluation. The feedback is important for adaptation.
• Make linkages to knowledge which is already there, e.g. SPSS6, and explain what is different but why this is useful for this application.
• Make structure, define objectives, also for every chapter separately.
• Use trainer notes (see ITO).
• Send email to Tonny; he has an example of a good Linux manual.
• State clearly in footer or at the cover of the manual which version it is.
• The manual has to follow the practical training (not the normal step by step approach)
• It is not advisable to write a manual on something you didn’t develop.
• Follow a step by step approach, although some audiences may be bored.
• A good index is always very useful (you only want to read the part you need at a certain moment).
• Add Frequently Asked Questions to the manual.
• Have the training session videotaped, so you can see what worked, what didn’t and use this in combination with the feedback to adapt.
• Combine diagrams and text, but make sure it is balanced.
• Put in more practical exercises.
• Use symbol to package and give structure to the extra’s you want to add (think of Elizabeth’s drawings)
• Of course you will have to have the objectives stated, but also explain how the manual is supposed to be used and by whom.
• Keep in mind; It’s just not possible to write everything you know. And; those that know best, don’t write best!
• Have plenty of white space, for pupils to write notes.
• Look at standards, templates etc. for writing manuals. Beware that standards differ per country.
• Size of the manual itself is important (500 pages is not good), but also the layout, the fonts used etc. To make it user-friendly.
• Use simple language, even when very technical content.

Background to Peer Assist

Milner's Peer Assist Info

PEER ASSIST ON DEVELOPMENT OF USER GUIDE FOR A COUNTRY RESPONSE INFORMATION SYSTEM APPLICATION PACKAGE DEVELOPED BY UNAIDS

1. Background

I was contracted to Train Trainers in African Countries on ‘Country Response Information Systems’ (CRIS) by UNAIDS- Geneva through Realtime Africa and also help out in end-user training. Part of the Terms of reference is to develop or customise Training manuals.

I should first confess that I have never developed Training manual for an application package for Trainers based on reference material provided by application developers. Despite a lot of user manuals I have made for office productivity software like Word for beginners etc, M&E was so unique and led to my realisation that I was too raw that by mid break, I had to discontinue using my manual on the power point presentation and resorted to practical hands on which student enjoyed for the rest of my training period. However, they finally demanded for manuals and I had to use the training reference guide. But I still feel I need the skill to develop manuals and people use it even on their own

The first training involved training Trainers from Ghana, Botswana, Zimbabwe and Zambia.

2. PURPOSE OF MANUAL (The one I used to develop User manual)

The manual has been designed for the use of training CRIS trainers and should not be used as an end-user training guide or hand-out. It should be used as a reference tool to teach prospective trainers to both use and teach CRIS to end-users

3. PURPOSE OF TRAINING

The purpose of this training is to equip prospective CRIS trainers to teach the following to end-users:

4. TRAINING METHODOLOGY

The overall training approach to be used in the CRIS Training of Trainers Workshops will be based on the following:

5. RECOMMENDED COMPUTER SKILLS

The following skills are recommended for all participants attending the CRIS training workshop:

6. TRAINING RESOURCES PRESENTED TO PARTICIPANTS

7. PRE-INSTALLATION REQUIREMENTS

Specific problems I faced;

• I produced training material based on the reference tool and experimenting with the software. I had and still have limited M & E knowledge hence practical examples were limited especially when participants gave live examples and wanted the Trainer to demonstrate.
• I developed one User Manual for Trainers but could not make a different Manual for end-users. I did not know how different the user manual for Trainers would be and whether it was necessary to have two manuals for the same application package.
• I put a lot of Trainer Tips from previous experience and lesson leant. I was wondering how many versions I will end up with in my training from country to Country. Trainer trips were mostly installation problems (technical) and these were live issues as I faced them, but kept on promising to get with developers in Geneva to give specific answers to newer situation. Is it necessary to include Trainer tips on almost every page?
• How detailed my user manual should be? I had 100 pages and temptation to write a Booklet was much there especially with users who are not well versed with windows application who could not understand differences between one window to another.
• During the presentation, I had a challenge of whether to start with my User Manual or theory presentation. I used the power Point presentation I made, and participants looked bored and later realised that using the live system proved effective leaving me wondering the relevancy of my PowerPoint presentation. So I did not give them a copy.

Milner Makuni

IT Consultant

Zambia

 Create your own educational wiki!Support CommunityPublic, not yet premium Privacy Policy RSS