When good things happen to bad trainers, TechRepublic members are prepared. I wrote about how to save face when things start going wrong during a class in a recent article, and in response, other trainers who have survived perilous times contributed their own suggestions. Making things work even when they don’t requires quick thinking, grace under pressure, and an inventive mind. These ideas should help you the next time you’re in a pinch while standing in front of a room full of students.
Here’s a new one: The server is down
Steve C. explains how he skillfully handled a problem that was beyond his control during the first Notes 4.x class he ever taught. The students were all from one company, and they were using their laptops to dial into their server in Boston (the class was in Washington, D.C.). As an extra bonus for Steve, the class also had had two different instructors on the previous two days and disliked both of them.
“About an hour into the class, the server crashed. Apparently, classes from all over the country were dialing in at the same time, and it overloaded the server.
“Rather than blame the company, or give up, I simply pressed forward, and told the class it was OK, because our discussion databases could also be accessed offline. At each point where something should be, but wasn't, I would stop and explain what it would look like if we were online.
“Afterward, the manager of the group came up to thank me for not panicking, because, as he said, ‘...our people were skittish enough as it was.’
“That class reminded me how important it is that the trainer know his/her environment, i.e., software, system, etc., and to have a backup plan in case something doesn't work.”
Solutions can come from unexpected places
Joe H. is a computer instructor for the U.S. Navy. During a lesson on formatting a floppy disk, a chief in the class used the DOS box and formatted drive C.
“As I contemplated restoring the system using our portable tape-backup drive, a student suggested using the UNFORMAT command, which we had covered during our DOS lesson on the previous day. I prepared a boot floppy with the necessary files, started the computer, and issued the UNFORMAT C: command.
“After answering a few prompts, we rebooted and were back in business. Everyone learned the importance of following directions, the power of the FORMAT command, and that the simplest method can come from an unlikely source.”
He tempted fate and won
Stephen M. wrote in with the bravest tale of courage under fire. He said his swiftest escape from disaster involved getting 15 machines networked during a class in the MCSE track. He decided that while teaching Networking Essentials and the Administration of NT 4.0 classes, he'd have them install it with him in class.
“All was going well until we went to start the network. I told them to install only TCP/IP to speed things along, and gave them the settings that they needed. The odd thing was that the class was divided in halves. I had forgotten that one half of the room was on one subnet, and the other half on a different subnet, due to the fact that I shared a classroom with the TCP/IP class, which took place after my two classes. After tension and frustration started to mount, I quickly had everyone install IPX/SPX and told them that this was a viable short-term work around and told them some of the benefits and detriments of IPX/SPX. The students said they learned a lot that day, and I was just glad I didn't look like an idiot in the face of adversity.”
Everyone is not so lucky
Msliz points out the unfortunate side effect of some classroom problems: students often blame the trainer when the computer fails.
“In my experience, most trainees blame the instructor for any computer problems. They believe that instructors should also be configuration whizzes and overcome the problems caused by any equipment failures. During a transition, one client had computers that crashed regularly for every software class. The evaluations were uniformly bad, because the instructor is the only person the student sees to blame.”
A larger lesson, and some exercise
Some trainers use hardware problems to try to get students to see the bigger picture. When faced with unexpected dilemmasduring class,J.A.J. rearranges his agenda to work out the problem with the members of the class as a team.
“With their input, we all come out with a better understanding of how to solve bad situations without coming unglued over small failures, whether it be day-to-day life or mission-critical situations.”
The other benefit of the team problem-solving approach is that it forces students to move around a little and get the blood flowing again. When software crashes or a workstationlocks up, Paul S. has the members of a small class group around a computer to watch how to solve the problem.
“Not only is it relevant, but the movement and involvement is a needed pace change for the learners.”
TechRepublic members have to face real-world disasters all the time and they are pretty resourceful when it comes to finding solutions quickly. Are these suggestions helpful? Can you see using them in your work? Send us a note and tell us what you think.