Used at scale, AI-driven systems that continuously monitor machine health can transform industrial maintenance — but like every new technology, there are hurdles to clear before their full value can be harnessed. In part 1 of this four-part guide, we addressed the need to plan your full-scale rollout from the beginning. In this post, we’ll look at how to handle the number-one challenge to rolling out anything new at scale: getting everyone on board.
The success of any new technology implementation hinges on end user buy-in. This is especially true in industry, where the introduction of new systems will disrupt a complex web of operating procedures and interfaces across many critical departments. The key to getting everyone on board is to speak to them as partners in the process, in the language that matters to them, at the right stage of the process — which is early enough that their feedback can actually change the project.
Communicate the benefits that matter to each person
Management cares about financial and regulatory benefits; everyone else wants to see how the tech will have a positive impact on their day-to-day work. (Which is also why financial and regulatory benefits appeal to management.) So spend time crafting a distinct message for each group of stakeholders. For example, present maintenance teams with concrete case studies on the asset failures the system is preventing at the pilot site, where you highlight the reduction in wasted time, repetitive work, emergency repairs and other common headaches. For every group that will be affected by the rollout, give them more than just a few hard, cold numbers on a sheet — tell them a story they can relate to in their own work, so they can say “hey, this is something I want to use here, too, not something I’ll have to use because my boss said so.”
“When one of our wastewater customers first started using our system, they were in a transition phase where they couldn’t prioritize a fix based on our alerts yet. So they sent someone to the site every day to check that things weren’t getting worse.
That made the system’s value very concrete: if they can rely on its alerts to prioritize their maintenance, then no one needs to spend mindless hours traveling to check on things just in case. Not just this one guy in this one situation, but the tens of thousands of check-see visits they make each year to pumping stations.
For the site manager, too, the benefit was clear: if he can rely on our alerts, he’ll rarely have to call his team out of bed for a midnight emergency to get a replacement asset up and running. The money saved is a good thing, yes, but for the people doing the work, the reduction in hassle is a hundred times more compelling.”
Let local teams sit in the driver’s seat
During a pilot project, end user resistance is generally low and enthusiasm is high. It’s motivating to feel like part of a select team on a special mission that matters to the top brass. But no one else will feel this way once the pilot is over. For the rest of the company, using the new technology is likely to feel like a mandate from above.
The remedy is to encourage individuals and teams to adapt the solution to their unique circumstances and make it their own. In How to Scale a Successful Pilot Project, Ron Ashkenas and Nadim Matta provide several real-world examples of organizations that put their local teams in the driver’s seat during a multi-site rollout, with excellent results. If you give local teams true authority to drive their own implementation, they effectively become a pilot project of their own, with the attendant motivation and enthusiasm. So spend some time up front planning how you’ll concretely delegate control when the time comes.
Add PEOPLE to your implementation plan
In the first post in this series, you gathered a core team and took the first steps toward writing a flexible, resilient implementation plan. Now we’ll expand that plan to address the human side of the rollout.
Round 2: add in the human element
- Identify each person who will be affected by the CBM project, and collect their biggest concerns, hopes and frustrations in their day-to-day work. Surveys, focus groups, and one-on-one interviews are useful tools here.
- Identify 10-20 common themes among those concerns, hopes and frustrations. Using your list of expected outcomes from steps 3 & 4 in the previous post, identify how each outcome will affect each theme. How will outcome X resolve concern Y? How will outcome W move us closer to hoped-for change Z? If there are any major themes that aren’t addressed by one of the expected outcomes, see if there’s a way the rollout can be adapted to address them. (It’s fine if the answer is “no” — some things can’t be fixed through technology.) If any of the themes are process-related, make a note to revisit those while you map out how workflows will change in the next post.
- Group people in a way that makes sense for your organization: by team, by site, etc. Using the information you worked out above, develop a custom communication plan for each group. Each plan should include a high-level vision of the future state, after full rollout, that will excite everyone in the group. It should also cover the practical details: what results from the pilot you’ll share with them and how often, how they can get more information and address concerns before the rollout, and how they’ll play an active role in planning and implementing the rollout in ways that make sense for their team. The details of each plan will vary, depending on the hopes, concerns and frustrations it needs to address.
Download the full 18-point checklist
English 
Español 
Português 
Italiano 