This group has been waiting for a long time to get these new machines. Their old machines are very long in the tooth. Planning has been going on for months, meetings, testing, back and forth.
The deployment was scheduled for the 4th quarter of last year, but supply problems from the vendor caused delays in the schedule, so it was pushed out. More testing, making sure everything was ready. Then comes the day of the deployment.
What follows are real world issues that happen on real projects. It’s not pretty, sometimes very frustrating, and leaves those running the project a bit worse off to say the least.
All these things can be mitigated by designing the deployment and testing it correctly ahead of time!
Having the Users Test on the Equipment That Will Be Deployed
This may sound simple, straightforward, even elementary but it is imperative to have the users test on the same kind of machines that you will be giving them to use long term. This deployment, due to the hardware shortages, had users testing on machines that weren’t the correct machines being deployed. The laptops being deployed were never tested by the users in a real-world scenario. When deployed, there was a bug with the docking station being deployed that wouldn’t allow the video to be displayed to the external monitors.
There was no fix for this situation! Escalations all the way to the manufacturer couldn’t get it fixed. This eliminated half of the machines to be deployed! It also meant you had to cut the techs that you had scheduled weeks in advance for this deployment (on the first day), not a good deal.
Testing Those Fancy New Monitors with the New Desktops
A technician has just spent more than an hour backing up the users’ data, replacing the machine, again with a new high end desktop in this case, installing one of the new monitors, and restoring the users’ data. Only to find that the new monitor will not work. Windows 10 doesn’t recognize it, but the old monitor works fine. The tech troubleshoots, goes through all the connections. Still no joy. After a bit of back and forth, it’s determined that this machine has Nvidia graphics. After downloading and installing the correct driver, the new monitor works great! All it cost was 30 minutes of the technicians’ time, 30 minutes of the users’ time, 15 minutes of the team leads’ time, and a lot of frustration. What’s the lesson? Don’t send hardware out that hasn’t been tested with all the peripherals and has all the drivers installed!
Test the New Equipment Before Sending It Out to Be Deployed
You waited months for these awesome machines. Wouldn’t it be a great idea to make sure everything works as expected before sending them out? Yes, you image the laptops and desktops, but they are never hooked up to the docking stations and new monitors prior to deployment. At least test one and make sure it works correctly before scheduling the deployment, lining up techs, and delivering the machines!
Users Available on Deployment Day
Usually these deployments start on Mondays. Due to the size of the deployment, the project team wanted to get a jump on getting machines done. So, they had the team come in the prior Friday at 8 A.M. Normally not a bad idea. Except this information either wasn’t relayed to the end users, or there was a failure in the communication somewhere. Either way, most of the section that was to be done on day one was not in the office that day. And the users that did come in didn’t start until 9 A.M. That left the team scrambling looking for users that could have their machines refreshed.
Users Not Following Pre-Visit Directions
I stated that wrong, they followed some of the directions, just not all. Prior to a refresh, it is standard that the user moves all their data to the server shared drive and delete it from the C: drive. Not only does this ensure that you have your backup in case a machine dies during the refresh process, but also makes the process of the refresh much faster. If this isn’t done, depending on the amount of data involved, an hour process can turn into a 3- or 4-hour marathon. These users moved their data yet didn’t delete it from the C: drive. The first user machine was just such a case, 3 hours for one machine. Technicians just do not have that kind of time to spend on one machine. Technicians are expected to complete 5 machines a day, obviously not possible under those circumstances.
Why Designing Your Deployments Are Important
As you can tell from these real-world examples, a little bit of work on the front end would have saved a LOT of headache on the back end! These things happened on a site that is part of a project that has been going on for over a year. Still these problems happened.
The surest way to smooth out the deployment process and save time, and in turn money, is to design the deployments from beginning to end before you ever to do the first deployment.
It may take a little more time to ramp up, but I guarantee you the results will be worth it!
With 30 years of retail management experience and over a decade of technology and field services experience, Jack has successfully blended his experience in both fields to give retailers an insight few others can offer. He understands the pressures of being in a leadership role in a fast paced, retail environment with superior customer service always being a primary focus. He uses his passion for computing to help retailers utilize technology to increase customer satisfaction and expand their brand. As Founder of OPL Technologies, he is positioned as an expert in designing and managing complex retail technology deployments.