You’ve known this time was coming for a long time. You thought about it for months, maybe years. The old equipment the users in your stores are using is getting old. It is now out of warranty. The costs of keeping it going are becoming a growing concern. Add to that the fact that the OS you are using now is eight or nine years old, and its end of life is only a couple of years away.
The decision has been made; as painful as it may be, new machines are to be purchased, configured, and deployed to all the stores and in all the different departments in your corporate office. Now you put your trust into the IT Team to meet with all the different user groups and get requirements for each. Then the machines are configured and deployed. Sounds easy, straightforward, and painless, right?
As good as your IT team may be, they are not deployment designers. Steps must be taken on the front end to avoid certain to appear pitfalls on the deployment side of the project. As an experienced deployment technician, here are some of the most common issues I see when deployments are not designed properly or not at all.
Did One of The Members of the Project Staff Scan a Machine in Each Store and Department?
This is a critical step, as it allows the machines to be customized with the software needed, so it is included during the imaging process. This not only saves the technicians time deploying the new equipment, but it also gets the user back to work sooner.
This gives you the opportunity to find any one-off software that may be hard to find, so you know which user machines those are prior to deployment. You may need to skip these users if that software is hard to find, then go back and update them later when the new software is available.
Has the Network Speed been Checked and Addressed?
When doing a refresh deployment such as this, you must be able to back up the user profiles and bring them back to the new machines. How quickly this can be done depends greatly on your network speed.
This is especially true if saving the profiles to central servers. In some instances, such as stores with significant network latency, you may use a local storage setup or even external hard drives. Only by checking in advance will you have the answers and the solutions in hand on the day of the deployment, keeping the Technicians working and the users happy.
Has the Deployment Been Designed to Happen at the Right Time?
Designing the project means looking at everything, including the calendar. When do you want to deploy these machines? You want to have as many users there as possible since their profiles are being backed up and then restored to the new machines. To verify that the profile was successfully restored, you need the user to log into the machine.
There certainly are times of the year that you want to stay away from that are traditionally family vacation times. The week of the 4th of July comes to mind, the week of Thanksgiving, and the week before and the week after Christmas. Certainly, there are some exceptions to this rule, but you want to have as many users in the office as possible, so you don’t have to reschedule deployments or send technicians back for revisits.
Is the IT Staff Prepared to Support the Deployment?
Is the IT staff ready to take care of any issues that arise on deployment day? This can cover anything from users that have static IPs that need to be released so the new machine can be deployed, to users that have that one-off software that IT must come install so they can go back to work.
It may also include deciding on incompatible peripherals—do we have replacements or a plan to get them to work with the new OS? Must we leave the old machine as a temporary fix? These items must be addressed in real-time. You can’t leave the person in finance with no way to print checks just because the new computer doesn’t recognize the old printer.
Dealing with Legacy Hardware — Time to Upgrade?
In every business, there are scanners, printers, etc., that have been around forever. There has been no need to replace them because they have never broken. By some miracle, there were drivers available to get them operating on your last OS. Has anyone tested them with the new OS before the deployment?
Those 20-year-old relics have given you no reason to move away from them. They have just worked. Testing them before the deployment will let you know if you need to rethink that. If they do not work with your new OS solution, then you must come up with a fix. Leave the old PCs? Buy new equipment?
If you don’t design the deployment, you have both technicians and users spinning their wheels trying to come up with answers on the fly, and it still won’t work. All that does is cost you money. Then you still have the same problem.
Fixing the “This is Always the Way it Happens During Upgrades” Mentality
There is nothing more disheartening to a technician when working on a user’s machine, and running into issues than hearing the phrase, “this is always the way it happens during upgrades.” If those same problems have always cropped up on every deployment or upgrade, then someone isn’t doing their due diligence to rectify that on the front end designing the deployment to avoid those issues.
No user should have to dread having new hardware installed because it’s always a long drawn-out mess. A software scan in each store and department and a trial machine in critical departments before bringing in the deployment team would go a long way to alleviate these headaches ahead of time, making both the technician's and users’ lives much easier — and save the company money.
Designing your technology deployment will not only help you avoid these common pitfalls but also will make the transition to the new technology much smoother. Also, if designed well on the front end, it will most definitely save you money and leave you with happier users on the back end.
The time spent designing your deployment will most definitely pay off in reduced downtime for your users and less time per machine for the technicians, ultimately saving your company money.