We now have nearly every department in the company using PDM to access documents. To accomplish this, I created a training document for PDM that has many sections. The beginning shows, with screen shots, how PDM is similar to Windows Explorer and how to use the added features/tabs. Following that is a clear explanation of the folder structure of the Vault so users can see where their work is to be done. Then each Workflow is discussed in detail using flow charts that show States and Transitions. This is presented in a simplified way so that complex Workflows are broken down into smaller steps (like mini-Workflows within a larger Workflow). These flow charts are especially useful to users as there is not a tool in PDM that visually shows where a file is going in a Workflow. You can look at History but that only looks back. I see these flow charts pinned to cubical walls for new users trying to make sense of it all. After that, I explain any special features like templates, add-ins and Dispatch actions. Finally, the powerful Search tools are discussed in detail. Also, in the preamble to the document, I give a list of specific sections that apply to specific types of users. An Operations user might only need the basic Windows Explorer stuff and the Search sections while an Engineering user would refer to the whole thing.
The document took some time to author, but it is the best training tool for new employees. I give them a 30 minute hands-on one-on-one session, refer them to the document and then follow-up in a few days to answer questions.
The main draw-back to this approach is that you end up revising the document often. I am considering breaking up some of the sections into smaller documents to minimize the review of a large document for small changes. I also keep the document in the Vault so users can always get to the latest version and I automatically notify everyone with each revision.
The last thing that seemed to help initially was that I formatted the document as a half-page size so we could print and comb-bind it. Because of it's smaller size, it is easy to keep handy and flipped open to a relevant page. I plan to reprint it again as soon as we convert to an XML ECO process that I'm currently developing (and update the training document, of course).
This is more or less exactly how I did things. The 30 minute (90 minutes for our users) sit-downs were vital. It also helps to have a throw-away area in the vault where you can use 'mock' files to show the user how things work, without the risk of using live data and files.
I foresaw the problem of having to frequently update the custom documentation I wrote, so I opted to create it via a piece of freely available project management software (http://trac.edgewall.org) on an internal web server. This system includes a wiki, a ticket system for users to submit problems/enhancements and a pretty good search tool. The wiki is much more of a living document that you can quickly tweak and not have to worry about out of date copies lying around on someone's desk.
Trac also includes several features geared more toward developers that I use to manage my custom add-ins. It integrates the ticket system with my Subversion code repository so that when I fix a bug in the code, the ticket system will mark it as fixed. Tickets can have a milestone associated and these milestones show up in a Roadmap page that lets you know how you are doing with fixing problems and implementing enhancements. It also incudes a timeline showing all the changes that have happened across all the components (wiki, tickets, roadmap, etc).
Here's a screen shot of the front page from my system:
We still use Workgroup so I can't talk to the features if Enterprise, but I have to train our users how to use system. And we do have a group that pretty slow to learn. What I've done is create some PowerPoints to show how they are to use the system then gather the team, go over it and answer any questions. Then this year I created a small test, I asked the users to check-out, check-in and few other things. I then held another meeting and went over the results. It worked pretty well, the users are getting better (some of them). My biggest problem is half my users don't think it applies to them or just don't care. And I'm only talking about the engineering group.
We originally started with large group presentation training. This was not useful since not everyone will be using ePDM the same way.
So then we had presentations that were specific to a department or group. Sometimes we did them over lunch and bribed folks with pizza. However it seemed only certain people would be actively participating/listening.
So after more and more requests for training we decided to make powerpoint video presentations on specific topics ( workflows, adding files to the vault, searching, history) We are trying to keep the videos under 10mins.
We use Brainshark to roll out the videos to everyone, and the presentations have a 3-5 question quiz at the end. Brainshark allows us to keep tabs on if people have watched the training or not. With the quiz we can determine if we need to do more training on a specific topic.
We are in the begining stages of this training, so far it has been the most helpful.
I started a weekly tip email that included a 1 or 2 page document as needed that was filed in one job folder within the EPDM system. The weekly tip / training emails helps new and existing users. The documents can also be printed out in a binder for new emplyees. Yes, you do need to keep it updated for each release but after two years, you kind of know what to add and not add so it does not become out of date to fast.
Sorry for the delay, but THANK YOU all for your insights on this!
It sounds like short presentations, either powerpoint or video or something like that, would be most helpful. And I think the test at the end of it would be a good idea, too. Maybe something that users can do at their desk, on their own time, and then call/meet if they need assistance...?
Like you said Aaron, most of our soon to be users don't think it will apply to them. We've been able to get our engineering group to pretty much accept this new way of getting models and model information (not without a little hesitation), but, other departments don't want to accept the change at all. I understand the frustration; most of the people this will impact are those who have been here for at least 10-20 years and they are comfortable and like the way things are now. That's why we really want to get this training correct the first time. If we don't do it in an understandable, easy way, we are only going to get more resistance to the whole thing.
Jim, is the project management software that you suggested a lot of programming? I don't mind programming, but I'm not the best at it. Do you think that is something a mechanical engineer without a whole lot of programming experience could handle? Or would you recommend a programmer for that software?