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, upgrade, bug patches, and new installations, desktop refreshes, software upgrades, and on and on. All of them are challenging in their own way. Yet there is just so much more to retailer deployments because there are so many sites involved. I love designing the 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. With no clue what it was like to run a retail organization, especially a national retailer with 1,000’s 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. There are lots of details to be managed for every project. Here are my top 9 tips to a successful retail technology deployment.
I never do any size install without an install script. One 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 with their results. If they have to ask me even a single question in the process, I know it will have to be repeated. 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.
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. Or when they are asked to perform out-of-scope (or off script) work. When they run into a technical issue. Or when there is no equipment when the Technician arrives on site, etc. Each scenario should include the following components: 1) a description of the scenario, 2) the action to be taken in said scenario, and 3) 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.
Believe it or not, scheduling can be the most complicated aspect of the deployment design. The most important thing to understand 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 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 you can quickly escalate to get resolution if any milestone is missed or even jeopardized. While there will be events happen 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.
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% 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. They 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.
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. 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 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, name of 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 (which is a whole another article on its own), 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.
It is a no-brainer that the Deployment Technicians are the ultimate key to the overall success to 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 record, and full drug screen. 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.
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). This is where subject matter experts all sit together in a centralized location and any issues come in through this Team. If you want / 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.
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. Causing 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. Do this early enough so that steps can be taken to keep the install on track. If issues are found during the review.
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. 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. 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 clean up and disposal tasks.
I hope you find these tips helpful and will employ them with your next deployment, if you aren’t already. You can apply these concepts to any type of deployment and gain the benefit. Even if you aren’t doing retailer deployments! 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.
With over 30 years of experience in the technology field, Lisa Cook is a thought leader. Specializing in overcoming the challenges associated with complex, multi-site technology deployments, especially with retailers. Her proven approach of designing deployments, rather than just planning them, has led to over 30,000 successful deployments for national and global clients such as Walgreens, Ulta Beauty, Office Max, Walmart, American Eagle, Blockbuster, Chrysler, Simon Property Group, and CBL & Associates.
As Founder of OPL Technologies she is focused on helping Retail Technology Leaders eliminate the challenges of multi-site deployments by creating Deployment Designs that save money and ensure the deployment is done right the first time. She is the author of the recently released book Designing Retail Success: A Blueprint for Designing Retail Technology Deployments.