In part one we looked at the process and culture changes necessary to adopt a new tool. This week we look at the next stage.
You can do everything right with a new plant: prepare the ground; enrich the soil; choose the best location; add fertilizer; water the root ball before planting, but all these activities will count for nothing if you ignore it after it’s planted; there’s still a good chance it will die. The same is true of new software tools. You can prepare the users, provide instruction, make the tool easily accessible, have a big roll-out, do everything right leading up to implementation, but if you don’t continue to monitor and adapt, a new tool can easily wither and die.
Providing initial training for a new software tool is essential, but it is equally important to encourage continued learning so that you can turn competent users into product experts. Apathy and ignorance can be the death of a new software tool. People proficient in a tool, as opposed to merely capable, are able to do their jobs faster and find ways to get better results. Most people can write a letter using MS-Word, but someone with real knowledge of a word processor can create a professional looking document, and do it faster. Continued education will give you better results and save you money.
It is perhaps obvious that people learn at different rates, but do you ever take advantage of this natural phenomenon? The faster learners can help bring others up to speed if they are given a forum with which to do it. Encourage short, informal meetings about new tools which will:
Many products come with an initial phase of free support and maintenance, (Inflectra provides a full year) which can be of great value, especially during those first few weeks. There is however, the temptation to reason that by the time the free period ends most, if not all, of the problems will have been ironed out and support is no longer required. This is a false economy. While it may be true that any problems that are going to show up will do so early, it is also true that when a problem does occur, it will be at the most inconvenient and costly time for your project. Having support and maintenance with the vendor is the best insurance against project delays due to tool failure.
The maintenance aspect of the contract usually, but sadly not always, includes all future upgrades which are essential not just to receive patches and defect resolutions but also to keep the software current with new releases of the operating system and other environmental changes to either software or hardware.
A new software tool cannot be cultivated and maintained without clear responsibility being allocated for that task. It’s not enough to simply have IT specialists check that everything is working every now and then. To really succeed, create a small team to offer help and support to those who may need it. Crucially, give a single individual ownership of the product and make sure they have the time to do it properly; it should be an essential part of their job, not a task given in addition to their regular duties. To think that engineers or managers will just find time to fit it in with everything else they are doing is pure folly. It’s no different to expecting a child to keep his room tidy while he’s playing with his toys; it’s just not going to happen.
Declaring a new tool the corporate ‘standard’ is no different to declaring that you will only grow Cherry Roma tomatoes from now on and expecting that alone will help them grow and thrive. The idea is preposterous, and yet it happens. The reality is that you must be proactive after tool implementation if you hope to have any degree of longevity.