Throughout this book, we looked at the essential qualities of successful training courses. We looked at a systematic process for creating successful training courses and covered the first six of the seven steps from setup to delivery. We now reach the last stage of the process namely, delivering the course.
A complete course in public speaking is beyond the scope of this document. However, there are a few important points to remember when presenting a software class.
|
There are many excellent web articles that deal with general presentation skills. For some clear, punchy articles on the subject try the Marketing Professionals web site (www.marketingprofs.com). |
First, keep the tone of the class consultative. Instead of assuming the attitude of "I am the instructor and I am teaching these students this material", assume the attitude of "I am a consultant who is teaching my clients to solve this business problem". You’re not teaching a class; you’re leading a work session. This consultative attitude is very effective at winning over your students. It conveys a sense of professionalism and caring about their needs.
Second, don’t be afraid to answer a question with, "I don’t know. I’ll research the answer and get back to you." If possible, find out the answers to questions you don’t know during the next break in the class, and tell the students in the class. If you can’t do that, research the question immediately after class and follow up. Collect the e-mail addresses of everyone in your classes, and send them all the answers to any questions that you could not answer in the class. This kind of follow-up builds credibility even better than knowing all the answers in class. No one will be surprised to discover that there are limits to your knowledge. But almost everyone will be pleasantly surprised by a prompt, thorough follow-up to his or her unanswered questions.
Third, avoid unexplored territory in the software. Sometimes we are so eager to please a class that we take on a question that we have not prepared for. We look for the answer to a question under menus that we have not studied, or by trying program functions that we have not rehearsed. Do this kind of exploring during a break or after class. During class, stay on the path that you have planned. Don’t risk damaging your credibility by floundering in unexplored areas of the application.
Fourth, don’t allow students who insist upon following your demonstrations on their computers to slow the rest of the class. Many times, students want to duplicate the steps that you are demonstrating on their computers. That is fine, except when they continually interrupt to ask you to repeat the last step.
The problem is that while you are demonstrating step two, instead of watching you, these students are performing step one on their own computers. They miss the instructions that you are giving because they are too busy duplicating the instructions that you just gave. As a result, they repeatedly ask you to repeat the last step that you demonstrated.
You should encourage these students to stop duplicating your demo on their computers, and instead to watch closely and take notes. Reassure them that they will have a chance to practice during the in-class exercises.