I absolutely love retail technology deployments! Why? Because they are so challenging. I've been in IT for almost 30 years and have done just about every type of deployment you can imagine — business application rollouts, infrastructure replacement, upgrades, bug patches, new installations, desktop refreshes, software upgrades, and on and on.
All of them are challenging in their own way, but there is just so much more to retailer deployments because there are so many sites involved. I love designing logistics and figuring out how to implement technology while the business continues to operate.
Many times, this involves replacing or upgrading POS devices, which obviously are the heart of the operations. Plus, I have to figure out how to schedule and manage a team of deployment technicians in the field. You have to be incredibly detail-oriented and have superior communication skills at all levels of the organization to be successful with these types of deployments.
I didn't always love it, though. When I first started working with retailers back in 2000, I really had to learn the specific dynamics of this type of customer. I came from the other side of the house — retail property management. I understood what it meant to be the landlord of a mall, but no clue what it was like to run a retail organization, especially a national retailer with thousands of locations.
With nearly 30,000 retailer deployments under my belt, I've learned a lot about how to make these successful and trouble-free. While there are lots of details to be managed for every project, here are my top nine tips to a successful retail technology deployment.
1. Test the install script again and again and again.
I never do any size install without an install script that has been tested so many times that I have it practically memorized by the time I approve it. My basic rule is very simple: Retest the script until it can be fully executed without issue. That could mean five times or 50 times, but after you've performed this exercise for a few projects, you will understand the requirement to document every step in the process — never assume anything.
I usually have the original script written by a technical person (or technical writer). Then I execute it myself and update the script as I go. I will repeat this process until I feel like it is solid. Then I will have someone who is not familiar with the script execute and update their results. If they have to ask me even a single question in the process, I know it will have to be repeated.
I will continue this process until the person executing the script does not have to ask any questions and completes the installation correctly. Obviously, this can be a very tedious process if it is a lengthy install (e.g., full-day or multi-day install), but you will see the payback when you are executing 20 or 200 deployments on the same day. There is nothing that will stop a deployment faster than an inundated help desk because technicians cannot complete the script.
2. Develop a process for every possible scenario.
Yes, this sounds impossible, but it's really not. Once developed, these scenarios can be used over and over with minor tweaks for future deployments. Some examples of scenarios are what happens when the technician is kept waiting to gain access, when they are asked to perform out-of-scope (or off-script) work, when they run into a technical issue when there is no equipment, when the technician arrives on-site, etc.
Each scenario should include the following components:
- a description of the scenario,
- the action to be taken in said scenario, and
- the associated escalation process, which should include a secondary (and potentially a tertiary) escalation process.
In other words, think about all the things that the deployment technician may encounter and provide them with the details to properly handle in a manner that does not put the installation at risk. Just one rescheduled installation can cause mass havoc to your deployment schedule and project as a whole.
3. Fully understand scheduling requirements, parameters, and expectations.
Believe it or not, scheduling can be the most complicated aspect of the deployment design. The most important thing to understand is if the schedule will be based on deployment technician availability, the site's need/choice, geography, or some other aspect.
You must understand the start and end dates, the time of day during which installs can be completed, blackout periods (e.g. holidays, not on Fridays, Christmas period, regional events, etc.), and a maximum number of sites per day and/or week that can be scheduled.
Along with the installation schedule itself, an associated milestone schedule should be used to track and monitor all milestones that must be successfully completed prior to the install date. By closely tracking, you can quickly escalate to get resolution if any milestone is missed or even jeopardized.
While there will be events happening that you couldn't plan into the schedule (I had to reschedule six installs because of a hurricane and have had to reschedule numerous installs because of early morning robberies), I can't stress how important it is to avoid reschedules. It just never turns out well.
4. Track and document EVERYTHING.
I use this rule for every single project I do, whether it's a deployment project or a software development project. After almost 30 years of IT projects of every type and flavor, the biggest lesson I've learned is that I have to document absolutely everything. I can't tell you how many times I didn't think a data point would be important to anyone, and it turned out to be the one thing that someone (usually in a high-level position) asked me to provide.
If you have a system to track all aspects of your deployment, that is awesome, but I find that 99 percent of the deployments I've worked have been done in Excel spreadsheets. While not the most efficient way, I've created project trackers that work really well and allow me to track everything in one place.
You may have to develop this on your own in a way that fits your style, but I can't stress enough how important it is to track absolutely everything about your deployments all the way through the entire workflow of the installation.
5. Maintain the right balance of checkpoints.
One of the things that I find that trip up a lot of deployments is not completing call aheads, requiring check-ins by deployment technicians, and not following up post-installation.
However, don't insert a checkpoint where there is no value. It's about balancing communication and risk mitigation. You don't want a technician standing around for an hour waiting on a call back from the help desk, but you also don't want them to call while they are waiting on software to complete the install.
Prior to the installation, I will have calls made to the site to confirm equipment arrival and to confirm the date and time of install. Be sure to capture the name of the Manager On Duty (MOD) that will be meeting the technician upon arrival and immediately escalate if there is any issue that arises from the call ahead.
I also conduct a call ahead with the assigned technician to ensure they have the confirmed date and time, the name of the MOD and confirm the version of the script. On the day of installation, I require the technician to call in upon arrival, at specific points in the script, and then upon completion to be released from the site. Any issues should either be resolved before the technician leaves the site or a ticket opened by the help desk and provided to the MOD prior to the Technician's departure.
Finally, at least one follow-up call should be conducted with the MOD a day or two after install to ensure there are no problems. If any tickets were opened, these should be carefully tracked, and the MOD should be communicated to on a constant basis until all issues are fully resolved. Trust me when I say that an unhappy site never reflects well on the project team. Treat the store employees as you would the executive sponsor.
6. Manage deployment technicians closely and respectfully.
It is a no-brainer that the deployment technicians are the ultimate key to the overall success of the project. They are the face of the project to the retailer, and any negative feedback can have a devastating impact.
Unfortunately, I've had to deal with some not-so-great technicians that made passes at store personnel, showed up drunk, or violated a security policy, I've been able to recover quickly by immediately removing them from the site and from the project (and at times from the organization).
Humans are humans, and sometimes they do really stupid things which are out of your control. The only thing you can be prepared to do is to handle as gracefully and quickly as possible to manage any collateral damage.
Beyond these distasteful events, you should have a process to properly vet and qualify deployment technicians that will be assigned to the project. This includes complete background checks, criminal checks, driving records, and full drug screens. You should have ongoing performance monitoring and an established feedback loop to provide learning opportunities.
Remember the touch points discussed earlier? These can be easily translated into a grading system for your technicians (e.g., did they always call upon arrival or did they have to be contacted, were they late to an install more than once, did they call in at the appropriate points in the install script on a consistent basis, etc.).
Never be afraid to remove a technician if they are not performing or receive negative feedback. It usually doesn't get better, and you want to get control of the situation and minimize risk.
7. Implement a solid deployment support environment.
With a lot of deployments I've worked on, the deployment technicians are instructed to call an organization's existing IT help desk. Without proper preparation, this will undoubtedly fail. Either the help desk agents won't know how to address the issues with the installation, or they will be overwhelmed with the call volume, which then puts the installation schedule at risk — especially if multiple installs are scheduled for one day.
There are several approaches that can be used to address installation support. For large deployments, I usually recommend establishing a command center (or war room) where subject matter experts all sit together in a centralized location, and any issues come in through this team.
If you want or need to use an existing help desk or call center, identify and train specific agents to take these calls. They should be assigned to the project team and participate in all aspects of the project, so they are very familiar with the install.
It's also critical to have a process to monitor call volume (especially in the beginning), a feedback loop to incorporate lessons learned into future installs, and a mechanism to quickly scale up the support team in the event that call volume exceeds expectations. You want to do everything possible to keep the install schedule on track, but without proper support planning, the whole project can grind to a halt very quickly.
8. Utilize installation reviews and checklists to confirm installation readiness.
Depending on the size and scope of an installation, there can be 100+ tasks that must occur before the installation can even be started. If you have 100 stores to complete, that's 10,000 tasks. For one project, I had 8,000 stores with 25 scheduling milestones — that's 200,000 tasks that had to be completed — just for scheduling alone.
It can be very easy to miss something and cause the site to not be ready when the deployment technician arrives on the day of install. Which causes what? A dreaded reschedule! Develop a process to review each install to ensure readiness early enough so that steps can be taken to keep the install on track if issues are found during the review.
9. Make sure you tell the deployment technician what to do with all the garbage.
Wait! What? Yes, you read that right — garbage. This is one of the most overlooked things I see with virtually every deployment I've audited. What happens to all of the boxes and miscellaneous contents in the boxes of equipment?
Even if the devices are pre-configured and placed back in the box before shipping to the site, no one tells the deployment technician how they should dispose of the boxes. In a retail setting, this can be tricky. The store does not want additional, unexpected trash in their dumpster because they have a lot of boxes to dispose of on their own.
And don't ever leave the boxes and materials for the store staff to handle. Not only does that tick off someone, but it potentially costs the retailer money because they most likely will have to pay someone overtime to handle the additional work.
I always make sure to account for every box, box inserts, pallets, and any additional peripheral equipment in the deployment script. Don't forget to add time to the deployment for the technician to handle these cleanup and disposal tasks.
I hope you find these tips helpful and will employ them with your next deployment, if you aren't already. Even if you aren't doing retailer deployments, you can apply these concepts to any type of deployment and gain the benefit. Ultimately, diligence must be maintained throughout every project — never take your eye off maintaining a quality deployment, and everyone will be pleased with the results.
This article originally appeared on LinkedIn.
