Establishing a Autodesk Continuing Education Program

[Phaeax]

Hi there! I am a frequent reader and researcher of AUGI information for several years; however I am now submitting my first posts.

I am currently pulling together a training program/initiative to keep the partners of our regional office up-to-date and well versed in a variety of design applications; which is essentially my role. I am taking a well trained group of Reviteers to the next level. They have a range of skill levels in Revit but hover in the can produce what they need to get their job done range. I am looking to elevate that even more as well with our supplemental design applications AutoCAD, Photoshop, SketchUP, etc

I will be using a weekly or biweekly session to discuss tips, tricks and new ways to use different design applications to get the results you want. As well with coaching, mentoring and shadowing opportunities.

What I am really looking from this forum is input on different ways to keep these short hour sessions lively, discussion based, back and forth, fun and to the point. I have a few good ideas thus far listed below.

Terms and Definitions, this would be some simple exercises that would be a match the term with its definitions, or write the definition for the term etc. Usually would result in a small prize or gift to the person who gets a hundred or something.

Youtube videos of more complicated projects and review their model and what the program is capable of doing.

Review projects we have done and the issues we encountered, how we overcame them or how we could have done it better / differently in relations to the technical application.

My list goes on, but I would like your feedback on what has worked for you in the past and what you think might work to keep these groups engaged and learning in a practical and hopefully fun way. My groups are going to range from 5 to 12 and might be inter-office.

Thanks for the input!

[Jmurphy]

Use a training room that does NOT get cell phone reception and the door locks from the inside. Interruptions are training killers.

Get the group involved by making them part of the training by having them do the demos or show the tips and short cuts. Example: If you have someone that can place doors right then have that person do that part of the training, next time have the person that can do walls correctly do that part. When I was training I always tried to think back to what I was bored with in class and what got me excited. Stay away from what bored me and did the fun stuff. Handouts are good if they are short and easy to read, the 20 page screen capture handouts end up in the trash.
Questions, questions and questions, both you and them, ask them questions as well. Last don't make any of them feel inferior no matter how dumb or stupid they may be.
Door prizes work well too,

[Phaeax]

Haha, having door door prizes, wonderful. Unfortunately we all know we can't block the radio waves.

I agree with everything you have said. I conduct my training in as much of a conversation as possible and it is good when you have a team who participates, even if it is complaining. I limit the amount of handouts in my training to those few that they can post at their workstations. Everything else is placed into a pdf on a network drive and or uploaded to a intranet for reference. I cite these locations, chapters and pages when I receive questions which have answers posted.

Where I could improve is the amount of questions I ask. I could also put some more thought into the examples I have made. I tend to practice examples which show the ideal way to use a tool or function and then I apply it to our projects or process when time allows.

The larger areas of improvement I see are basic understandings of the software. "I didn't know it could do that." "Where is that tool?" etc.

I can't help but think when designers and managers see designs or models from other firms and companies that they think "That is such a great design!" "How did they arrive at it?" "They could have done this." "Why didn't they do this?" Often they leave out the questions of "how did they make the software do this?" "In what program did they create it?" "How long did it take to produce it?" I suppose the last few comments are wishful thinking or they simply expect that portion to be created for them through the organization.

Of course, thanks for your input!