Store Tech Rollout Troubles: Don't Let This Happen to You

26 Mar 2018

Retailers are investing in the in-store experience in a major way: During the next two years, according to RIS News, 54% will install mobile devices for store associates or managers, 49% are deploying digital devices including signage and kiosks and 51% are adopting shopper tracking capabilities, which often include cameras and sensors. That’s on top of all their routine store tech projects, like replacing printers or swapping out POS units.

That’s a lot to get done. It can be tempting to rush through tried and true projects such as a register scanner upgrade without the rigorous best practices that ensure a smooth install.

But retail IT lore is full of stories about that small project that went wrong in a big way. Here’s why sound project management is critical at every step of a store tech installation:

  1. Forming a planning committee. A simple scanner swap seems so straightforward. But there are still a million questions: What type of bar codes does it have to read? What’s the ordering lead time? Will installation happen during store hours? How will you deal with the self-serve registers? Any miscalculation up front can have a domino effect across a tight rollout schedule. By forming a planning committee with representation from all affected retail departments, as well as the integrator’s team, retailers can coordinate all the moving parts. A planning committee can head off uncertainties and surprises, and govern the rollout until it reaches steady state.

  2. Performing integration work. Increasingly store tech integration work is co-located; the integrator does some steps such as loading the mobile device management (MDM) and some of the software, while the retailer or a third party manages highly secure steps such as loading passwords via a secure VPN tunnel. Splitting this work requires careful project management orchestration to avoid delays and miscommunication.

  3. Proof of concept and pilot testing. Commonly retailers wanting to speed a project skip at least one of these. That can be costly. A solution that worked great in the lab can get thrown off when pilots reveal unexpected variations in real store conditions. One retailer in a hurry to update security settings on PET scanning guns without a pilot quickly encountered dead batteries in several units in each store, sending the tech scrambling to swap out batteries to get at least some units updated on schedule.

  4. Managing network impact. A classic network-related error is installing the hardware and then attempting to download the images over the store network. That inevitably takes more time, if it works at all, and degrades network performance for everything else. A good project plan — created with input from network experts — anticipates these situations and builds the process into prep stages.

  5. Keeping accountable to the plan. It’s easy to imagine the impact of a shipping delay on a project. But what if the MDM is not ready? Or support is not prepared yet to respond to techs when they’re out in the field? Accountability for missing targets in the plan starts with the project committee and a solid plan; without those troubleshooting quickly gives way to finger pointing and delays while everyone tries to figure out who is responsible to address it.

  6. Dealing with unexpected problems. Even the best planned project will encounter surprises, such as a bar code that won’t scan. Solid project planning includes an escalation matrix, so there is a clear process to follow to identify root causes for each potential problem area. Without it, techs lose valuable time on diagnostics rather than moving forward.

  7. Noting and addressing gaps. A plan that looks fine close up may have gaps only an overview from a cross-functional committee can reveal. For example, someone decides there’s no need to capture MAC addresses. But they don’t have visibility to the whole project, so they don’t know there is a wireless component that will require the serial number and the MAC address of each device.

  8. Documenting the project. Most people think of store tech project documentation as field documentation — the site-specific document that tells you where the seven registers and five APs are located and how far cable has to run. But it’s a lot more. Projects need procedure manuals, support documentation, the escalation matrix, a communication plan, issue logs, knowledge base articles and the project plan. As things change, all must be updated to eliminate defects and provide the foundation for future work. It’s tempting to skip some of these — but doing so often costs time, money, and even the failure of the project.

Meetings, process-writing and documentation can seem like time-consuming extras when management is pressuring IT to get a promising new store tech in place and working. But without them, projects can go south in a hurry, and that helps no one. The best bet to ensure solutions deliver on their potential is thorough, well-executed project management guided by experts like Level 10.