General but important stuff:

I'm not intending to teach any grannies how to suck eggs here; all I hope to do is provide some food for thought to inform your own practice, having observed and talked with many polished trainers.

• Know your audience: what do they want to know? Some need strong commercial skills which means they have very specific needs, others will be terrified of breaking the computer. Balancing each person's needs can be tricky, especially if you know what will help them but they can't yet see the application of what they're learning. You have to be able to sell the features of the software as much as train, because lots of people think they already know the software inside out, and many people will come with prior negative (and often inaccurate) assumptions about MS software, in particular.
• Know your product: It's not really enough to have learnt a feature, but also knowing where it can go wrong and how you can apply the knowledge in different situations. You will only really learn a piece of software from training it, that's for sure! So don't feel bad if you don't know everything, just know enough to help yourself find the answers.
• Know the different versions: It's well worth knowing the differences, and teaching general principles that can be applied regardless of version. Generally speaking, there are no core differences between MS Office '97/'98, 2000, 2002/XP, 2003 and 2007, although the 2007 environment takes a radical departure from the previous versions in terms of appearance. Mostly what gets put into newer versions are extra features; the essential principles remain unchanged.
• Know the log-in and password details: simple, but amazingly easy to forget this!
• Know your technical terminology: Know the difference between a toolbar, the menu bar, the task bar, the sys-tray/notification area, right- v. left-clicking, screen tips and so on. Why? Two reasons: You can communicate problems to helpdesk/tech support teams far more effectively (which means your problem gets fixed quicker!), and you can actually make use of the Help files to progress your product knowledge. Excel, for one, is totally underpinned by such terminology as 'cell', 'range', and 'function' so it is very important to let the learners know this information. They need to know that you, as an expert user, can lead them forward as much as feed their immediate needs, and they will appreciate your guidance in this. (Note: this can work two ways: learners can either be delighted and flattered to be let into the mysterious world of techspeak, or they can get overwhelmed and bamboozled. You're there in front of them: your call.)
• Know where to go for advice: It's fine not to know stuff. Your students will appreciate an honest 'you know what, I don't actually know' and will see straight through an attempt to pretend knowledge you don't have. This relies as much on you knowing where to get the help you need if you need to answer a query, though. There are plenty of web forums which help you figure out why stuff is misbehaving. I've found the About.com range of courses and forums very good.
• Make the learners learn: don't teach, let them discover for themselves. For a start this encourages the group to interact more and secondly new learning is far more likely to be retained this way. Ask questions, provide clues, give hints, by all means ('I'm talking about something in the top left-hand side of your screen', or 'it's a feature from a drop-down menu'), and open up questions from one member to the rest of the group, such as 'Jane's just asked an interesting question, has anyone else come across this before?/does anyone know where to go?' Give demonstrations only if it's easiest (for instance I do this with charting in Excel). Intervene as a last resort.
• Don't dictate a single way of working: Some trainers and teachers tend to take the attitude that 'my way is the only way'. If the learners prefer using the mouse, show them. If they prefer using the keyboard (especially touch-typists and those that use laptops), show them. I tend to take a quick poll at the start of a course to find out who prefers which, and will often call for attention and say 'mouse users! This one's for you!' then 'keyboarders! This bit's yours!' so they can focus on the bit that's most relevant.
• Keep your learners on track: don't let learners ask questions that are irrelevant to the topic at hand - for instance, if you're teaching Word, don't get distracted by email questions. It's not fair on the other learners. If necessary, reserve a space on your whiteboard for questions or keep a notepad handy, and make it obvious that you value their queries and will remember to answer them at a later stage. Then you MUST answer them if at all possible.
• Speak up for Tech Support / HelpDesk staff, Sys Admins, DBAs and all the other techie bods behind the scenes. Their apparent lack of patience is invariably down to a) users swearing down the phone at them, yelling vaguely about 'the thingy at the top of the thing' and b) managers (usually from other departments) changing the goal-posts (usually financial corner-cutting) every two weeks on that 'mission critical' swishy new net-based client database to replace the old product that's not actually broken in any way to start with. You know what? If you befriend your techie team, appreciate that your priorities may not be the same as the college's/company's, thank them politely and include them in the interdepartmental Christmas card circulation, it will pay off.