New Employee End-User Training

Day one.
Chances are good that during the new employee's acclimation/orientation to his or her new job, they will be learning the use of applications related to their job. Thus, it would lower the learning curve of the job related applications for the position if they had at least a basic understanding of the system and O/S.

This is sometimes a very political issue. However, I see so many users that have learned the worst possible way to do something in a program because they learned it from a co-worker. If I had my way, computer training would be second only to filling out the tax forms, etc. in personnel after a person is hired. It is very hard to break a bad habit, it is so much better to teach a new employee the right way at the very first.

I just began a new job, and after spending the first half of hte day in orientation (which only dealt with benifits issues and things of that nature) I was immiediately thrown into setting up my environment and starting to work. After about a week,the company offered training on the software. I went to that, but by then had already taught myself almost everything I needed to know. After two weeks, I found a copy of a powerpoint presentation that explained in detail how to set up the dev environment...that would have been useful to read before the first time.

I would personally have preferred to have had the software introduction within a day or two of having been hired, and been told where to find resources such as the powerpoint presentation.

Immediately! I'm a Training Coordinator and have been responsible for setting up a training program for new Help Desk analysts. It's starts on the first day that they arrive and continues for 4 straight days. The 2nd and 3rd weeks, we use a mentoring program -- the new analyst listens in to a tenured analyst so that they can begin to understand and put to use the training they recieved the first week. The 3rd (and final) week the new analyst takes to the phones themselves with their mentor listening in.

In any case, I would suggest starting the training immediately in order to get the new employee up and running quickly. More importantly, make sure you have a strong, step-by-step training agenda in place.

I hope that helps!

- Mark

I used to set up new employees with a limited access "temp" account and after about a two week orientation, they would start the official training and receive a unique password and accound. This worked to limit access and allow the E/U to get a feel for the system and job while allowing them to work independently if needed.

Everyone here goes into training on all the software we use, what particular sections of the OS's (win95/98/NT/2k/Me and MAC-OS 8.5+) they will be dealing with on a regular basis, and some training on job ethics.

After that they listen in on calls for a few days, back into training to go over questions about some of the calls they listened to, more training on the finer points and/or things they still aren't sure of, then they start taking calls themselves.

To answer your question, I would start as soon as possible.

I would say on the first day. We currently test our potential canidates before hiring them. This method seems to keep the skill level high, resulting in less training. You can always rename the user accounts.

Recently we went through a hiring spurt and I couldn't keep up with the new employees. I created an orientation handout that gave them all the FAQ's of new employees. ex: how to log into the computer, where should you store files, how to change passwords, etc. It includes pictures of the screens they will see and step by step instructions. The new employee usually gets more out of this than to have someone sitting over their shoulder. I also include at the end a list of support people and numbers depending on their need. Because I was the first person they were dealing with, I got every support call. Now, they know exactly who to call. It's much more pleasant now then when I started and was just thrown at a desk.

This question was closed by the author