Many times, IT is overly eager to roll out new software and moves too quickly without adequate testing or a well-thought-out plan in place.
In 2016, Alameda County, California introduced new software for the Alameda court system in an effort to replace an over 40-year-old system. Long overdue for an update, the county rolled out the new software over their entire district of more than 50 courts.
Unfortunately, the new system, Odyssey, was rolled out without testing and with virtually no district-wide training. Though Odyssey itself may have been an overall good choice for the court system, the bad rollout resulted in unwarranted arrests, extended jail times, and the mislabeling of sex offenders.
It was a disaster that could have been avoided if the Alameda County IT department had taken more time and been more methodical in preparing for the rollout, ensuring that everything had been tested and was in place before going live.
Security threats have evolved, and users want new features. New software rollouts and upgrades are more crucial than ever. Companies are looking to upgrade their security apps, embrace systems that are more compatible with the hybrid-cloud model, and upgrade to Windows 10 for the most up-to-date malware protection.
To avoid making the same mistake as Alameda County, here are some easy tips for your IT department on how to make sure your next software rollout goes smoothly.
As an IT manager or systems administrator, no matter what type of software rollout you’re handling for your company, following these best practices will minimize disruption of day-to-day operations and reduce overall stress in your IT department.
Test on a Virtual Machine
Thanks to virtual machines, system administrators can now test new software in a safe environment to identify compatibility issues before they become a problem.
Virtual machines are operating systems that imitate dedicated hardware. Testing new software on a virtual machine gives you the same experience as running the software in the real environment in which you plan to use it.
Using a service like VMware gives you the power to test new software in a safer, more cost-effective environment before it is rolled out companywide. You can discover problems and fix them before the software goes company-wide.
Confronted with a disastrous onslaught of incompatibility? Testing on a virtual machine is your first line of defense. Rollouts can be rolled back with absolutely no consequences to the company.
Test With Power Users
After testing new software in a virtual environment, it’s time to try it out on a segment of the employee base. Think of it as a focus group of users who can give you valuable, authentic feedback and point out any problems, giving you a chance to fix things before the software goes live.
Be warned: most users will not want to use the new software or disrupt their workflow with testing. The best strategy is to involve only a select group of “power users” in the first round of testing.
What defines a power user? These are employees who use the existing software the most and who, hopefully, are most enthusiastic about improvements. They use the current software daily and can tell you the most about what is good and bad with the new system.
It’s a good idea to define the power users’ workflow and clearly understand how they use the software before and during testing so that you can get the most value from their feedback. This round of testing is also a great opportunity to learn about any complaints, negatives, or potential security issues.
Communicate Effectively
Before rolling out any new software, it is important to communicate openly with those who will use it and be affected by the change.
Take the feedback you get from the power users’ testing and use it to shape how you train others in the company. If there are people in your company who won’t directly use the software, but who will notice a change in procedures or outcomes as a result of the rollout, give them a heads up. Outline what kinds of changes they can expect to see.
You should also involve department heads before implementing anything new. Keep them informed throughout the process and share with them what you learned from the power users’ testing. That way, when it comes time to deploy the software to the entire company, you will be able to clearly communicate any changes to daily workflow as improvements that the entire workforce can get behind.
Deploy in Batches
Depending on the size of your company and IT department, there are different deployment approaches to consider when it comes time to roll out software.
Canary Deployment
Canary deployment gets its name from the mining practice of using a canary to detect dangerous gases. In this case, the new software is the “canary.” It is released to a small number of users who can be selected randomly or intentionally. To ensure an authentic assessment and experience, you may choose not to make the users aware of the new software rollout.
If there is an issue during canary deployment, you can route the test users back to the group that is still using the old software and rectify any problems. The interruption to daily workflow is limited.
Unfortunately, to minimize potential downtimes, canary deployment requires a lot of careful planning before it is safe to proceed. This approach is generally best for organizations with larger IT staffs rather than those with a single system admin.
Phased Deployment
A phased deployment is exactly what it sounds like: software is rolled out to the company in several phases.
Choose the first few groups of employees to receive the software rollout wisely, as they will be the ones to experience any issues that were not found during testing. Consider senior employees who will use the software the most and are invested in the software rollout’s success. You might then set up a dedicated process by which they report issues specific to the rollout.
Deployments will get easier as subsequent phases are conducted.
Rolling Deployment
A rolling deployment rolls out internal software on one server (or one subset of servers) at a time. This process works well for software and applications that require downtime to be installed.
By using a rolling deployment, the company experiences minimal downtime. The previous version of the software or app remains available on servers not affected by the rollout through session sharing. Once the server has been tested successfully with the new software, it returns to service and the process is repeated on the next group.
Blue-Green Deployment
Blue-green deployment runs two product environments simultaneously — one labeled “blue” and the other labeled “green.” One environment remains live while the other is idle.
Production traffic is sent to the older, still-live environment while deployment and testing happen in the other, not-yet-live environment. Once testing is complete, the router is switched and traffic is directed to the now-live environment with the new software.
This method reduces risk with the flip of a switch. If any major bugs occur in the new software after release, traffic can immediately be sent to the idle, old version of the software.
Instead of rolling new systems out all at once, these deployment methods roll out changes in a measured way, giving you a chance to quickly fix any problems.
Choose Deployment Wisely
When rolling out new software, remember to take your time and always have a plan.
When evaluating deployment strategies, always fully assess the resources and time you have available. Jumping into a rollout without the proper planning can backfire, leading to security issues and even user backlash.
Test on virtual machines and with power users, and then deploy slowly. Also, remember to always make department heads fully aware of your strategy. Communicating effectively across the company will make your rollout go smoothly.
With appropriate consideration and testing, your software rollout and chosen deployment strategy will be successful. You’ll minimize disruptions and downtime across the company, reduce stress, and make your IT department the rockstars of the company.
| Published on Java Code Geeks with permission by Tifanny Bloomer, partner at our JCG program. See the original article here: Some Best Practices For Rolling Out New Software Opinions expressed by Java Code Geeks contributors are their own. |
