Tech Manager—Implementations Impact on Your Standard: When and Why
I want to focus on how implementing new tech impacts your standards. I suggest expanding or updating your standards from time to time. It might be a total revision, an update or expansion. But how often should that be? Your standards need to be stable, so folks know what is expected. They need to be flexible, so folks know they are not locked in processes from years ago that do not serve the current tech needs. They need to be up to date and changed to keep up with tools and talent. But what drives the changes and how often should you change them? Implementations impact standards, so I provide some guidelines for when these standards updates and expansions should be done and talk a little about why.
When to update or expand?
Bottom line on when, is generally this… I like to update my standard whenever there is a totally new tool introduced, or when a new feature of an existing tool is making an impact. I also update when the standard has not been changed or updated for an extended period. That period is defined by your company. Some are excited to bring in new tools and methods and others are resistant. You could make it a time frame, like every two years. Or you could tie it to the version upgrades you do with the tools. Either way, going longer than three years tends to have people settle into a rut and change is very hard. You probably have a cycle already. If you do not, you want to create one. If the cycle is not working, you need to break it and redefine it. Too short? Too long? Or just right? You decide.
Make documentation updates and expansions coincide with software rollout. Provide training as needed. Get the documents in the hands of the users and monitor the embrace of new tools or methods. Introduce changes at the proper time, like when a new project starts or when a new office is opened. Lingering old-fashioned ways of doing things can come back to bite you. If it is not a major change, you could issue amendments or addendum to your existing standard. Or just replace a few pages.
Why Update or Expand?
Why do you need to update or expand your standard? Some of the answers are embedded in the ‘When’ part of this article, but there are others. You need to update your standard to keep up with new tools and new features of existing tools. When your standard gets so outdated that it no longer serves the design team because it no longer covers what is needed, you need to update. When new features are added to existing tools, you need to expand your standard to address them.
Entirely New Tool
When something new comes along, you need to get out in front of it. It could be a totally new tool, or a major upgrade to an existing tool. I suggest that you let the design team wander around for a while. They need to try things out, see what works, what improves your output and what is not worth the trouble.
When implementing a totally new tool, hopefully you have investigated its use and proven that there is value in the new offering. Then you can bring others in. It might be a free version, trial version or a low seat count purchase so that you are not overextended if it does not pan out. You can escort them through the process or research by giving them specific things to try out, or you can just let them play around with it. There is value in both methods, and you can mix them up as needed. If one feature rises to the top and becomes the focus, encourage people to try that specific feature. If some have been playing, ask them for input on what stood out then encourage them to focus. If others have been focused, suggest that they play around a little. Usually, most folks will do both on their own.
Ready to lock down a method of use? If it is a totally new tool, I suggest a separate standard just for that tool. You end up with a focused standard that allows new tools to not be jammed into old habits and methods. You want to keep the general approaches in tack, but not handcuff a new tool with outdated guidelines.
New Feature added to an existing Tool
If it is a new feature in an existing tool, then update your existing standard to reflect the new features use. If you have old workarounds that the new feature addresses, through out the workaround and adopt the new feature. Don’t let people hang on to outdated methods.
Retired Features in existing Tool
Sometimes software developers retire features or do not continue support or development of those features. What do you do then. You document what NOT to use. You may need to add items to your standard that are not used any longer. You can continue to use them until projects that have used them are completed, but you need to move along. Write it down. Document it in new project kickoff meetings. Outline what is not to be used any longer.
Retired existing Tools
Developers may stop updating, selling, and supporting tools that your team may use. It may be something that you heavily relied on but is no longer versioning up. It is just totally gone. But wait – the version I have still works… When that happens, have a wake and call it a day. Get rid of the tool gradually, but totally. Uninstall it. Do not keep old copies alive that might still work. Migrate all data out of any repository dependent upon the tool. It is gone and you need to move on. Provide a departure schedule and remind people that the old tool is being retired. Then stick to the timeline.
Standards are meant to improve processes and production. If they are old, limited or outdated, they may hinder productivity. Take a fresh look at your standard and see if it is current and covers the needed processes that drive improved design. Finding a better way to be productive and drive it into your standards and staff.
