In the past, we would possibly upgrade every few years, maybe every second version. Now, with software (and hardware) developing so quickly, we have to follow the trend and remain current - which means loading new software every year.
By not remaining up to date with the latest versions of the software, you run the risk of quickly falling behind. Skipping versions greatly lengthens the learning curve of any new software and can result in a greater loss of production when you eventually do upgrade to the newer version.
Autodesk has made the transition to new software easier, but there are still some protocols you should follow when making the transition. Here are some tips on making the transition as smooth as possible.
Make sure the new software, add-on, or update is a viable option for your organization.
Evaluate the functionality and usability of the new features, and be sure to verify that it is indeed something that you can use. Unless the new tools do what you currently do better or include features that improve your deliverable, it may not be the best investment of your time and money to set it up within your office.
Evaluate the potential use of the software and how it will be used within your work environment. Go around and do a quick survey of your users as to whether or not they feel this new tool has benefits and would be a valuable addition to your arsenal of available tools.
Use your own judgment. You know your office and its type of production. True, you can evaluate its use within your office as well as anyone else. However, it is always a good idea to get a second opinion. If it is not going to add productivity (even though it looks cool), don’t implement it.
Test and Retest
Depending on how you distribute the new product, whether through a deployment from the server or simply loading the software from a DVD (or a USB flash drive), go through the configuration carefully and map any drives for specific folder locations. Take notes and screen shots of your configuration so you know what you did so that you can refer back to this area to tweak it if required later on.
Load or deploy the software onto your test computer and then run it through a few typical processes. Make sure your test computer meets (or exceeds) the minimum hardware specifications of the software developer. You cannot properly evaluate software if its not performing how it was designed due to inadequate hardware. Try it out for period of time, not just a hour or so. You will never pick up all the issues during the first go, so it is better to come back to it periodically. Once you are comfortable with how the software is set up, hand it over too a couple of your power users for them to evaluate and run it though its paces. Your users will then test the software as they would in a production setting. Ask them to write down their questions, likes, and dislikes for your information and assessment.
If after all the evaluation and testing it passes with flying colors, it's time to deploy the software to the users. Verify that the stations meet or exceed the minimum hardware requirements and make any changes before deploying the software.
If possible, deploy the software to all stations at once or over a short period of time – don’t drag it out over days or weeks. This will lead to issues such as incompatibility with earlier versions or the appearance of favoritism between your users.
Learn to Teach
There is nothing more frustrating for your users than opening a new program or add-on and not knowing where to begin. You don’t need to become an expert; you just need to know enough to get your users started and they'll do the rest. Find out the basics of the program, become familiar with its tools and essentials. Your users will quickly find out all the secrets, you just need to be familiar enough with the new features to show them the ropes. Hold a “Lunch & Learn” to teach your users, create a handout with a brief summary of the new features, and be sure to use lots of screen shots, as images are far more descriptive than words.
Get feedback (particularly useful if you’re using a trial version). Find out what your users like and what they don’t like in detail. Keep in mind: you may have to modify the deployment if required.
Give Permission to Learn
One of the biggest challenges that I typically face when it comes time to introduce updates or new software is resistance from some of my technical staff.
This is understandable, as your typical technician prides him or herself on the speed that he or she accomplishes a task using the familiar tools. One thing that I have found I have to do to assist them on making the transition is giving them permission to “Take their Time”.
I find that users will get frustrated when learning new software, as they feel they are not as efficient as they are used to being. Explain that the process of learning new software - or any new tool - will take some time, but the gains far outweigh the losses. In reality, the relativity short period of time it takes to learn a new tool is easily gained back in product efficiency and benefits that the tool enables, once you are familiar and comfortable with using the new features. People just need permission to learn.
The weeks following any new release will be busy for you as you answer questions and troubleshoot any problems or issues that arise. These issues should be minimal, though, if you are well prepared. After a short period of time, your users will be quite familiar with the use of the new features. Follow up with a couple more ‘lunch and learn’ sessions where you can share technical tips and tricks, create and distribute hand-outs as required, or use social media, such as blogs, newsletters, emails, and tweets, to get the word out.
Scott Chatterton is currently the BIM Manager for CEI Architecture, an architectural firm with offices located in Vancouver, Kelowna, and Victoria. Scott has more than 20 years of industry experience and is currently the president of the regional BIM Users Group. http://www.linkedin.com/pub/scott-chatterton/16/438/729