The COVID-19 pandemic has left manufacturers with an unpredicted cultural change: a newfound readiness for M4.0 projects. According to the Manufacturing Leadership Council, “the COVID viral firestorm has made manufacturers acutely aware of the need to continue along that M4.0 journey,” and many manufacturers are predicting that “the recent changes in their corporate culture will now be permanent.” The innovative growth thrust on the manufacturing industry thanks to a year of pandemic and M4.0 culture is exciting—but not without its cautionary tales. 

As a seasoned technology implementation partner with a specialty in manufacturing organizations, Simplus often finds that manufacturers will have great success with a small-scale or pilot project, but as soon as they try to scale, the obstacles begin to mount quickly, resulting in wasted effort and proven concepts and ideas struggling to find traction. Scaling a comprehensive technology revolution, like many M4.0 projects aim to be, is no easy task, but its challenges can be mediated with best practices designed to bring any project to the enterprise level.

An expert in implementing successful pilot programs within manufacturing, high tech, and other industry verticals, Kevin Willemse recently addressed this pilot purgatory too many organizations find themselves in when embarking on M4.0 projects with a session during the Manufacturing Leadership Council’s Rethink event. Over the course of two blog articles, we’ll highlight the key takeaways on both how to avoid purgatory and how to scale during M4.0 initiatives. First off, let’s take a look at how pilots end up in purgatory and how you can avoid the same fate. 

Failing to align on objectives → Apply strategy

Purgatory pitfall: Many manufacturers will fall into pilot purgatory because they didn’t start with embedded strategic objectives in mind or without executive commitment. This creates pilots that are viewed as tests or small investments and experiments to try and determine value rather than prove a measurable outcome; the project often falls into a pattern of narrow, siloed focus on fixing one specific challenge or process rather than addressing a key business challenge or opportunity. These pilot projects may check all the boxes and meet the technical or functional goals to prove value, but are not clearly defined in terms of the definition and use of value, because there was no top management support to guide the pilot alongside company-wide strategy with a measurable result that “makes things better”. 

Simplus solution: To truly prepare for the impact of success, your decision-making team has to be aligned on what success looks like. This will be different for each company, maybe even different within each department, and certainly different depending on the scope of the technology transformation you’re enacting. Whatever success is for your particular project, know this: it’s not just widespread adoption and sighs of “phew, nothing broke, and the hard/software didn’t fall over.” A strong technology pilot program is, rather, tied to strategic business objectives—not just a functional checklist. You’ll know your organization is aligned on objectives and prepared for success when 1) you have all executives on board with clear, stated goals and 2) you have a detailed roadmap and accountability matrix in place for long-term scaling. 

Not preparing for success → Design for scale, not fail

Purgatory pitfall: Your pilot is bound to spend some time loitering in pilot purgatory if you didn’t plan for it to succeed to begin with. If you’re not expecting success, that means you’re also not prepared for the changes success demands in order to capitalize on it quickly. You will face a mountain of questions and decisions you’re not prepared for when the time to scale arrives. These are the pilot projects that don’t know what comes next, who the implementation team will be or if it exists, where the allotted resourcing or budget for the scaled project will come from, or how to measure benchmarks or set meaningful project KPIs. These pilots also very often have not even considered the requirements for change management or training to accompany the rollout. You know your pilot is in this particular purgatory if you find your program’s barometer for success is simply “It works, so what?”

Simplus solution: Design the pilot with success (in other words, scaling and preparation) in mind. Don’t plan and design it with the intention of remaining small-scale or as a “dead end”. You’re not just hoping the pilot will take off—you’re expecting it to and preparing resources, capital, and operations accordingly for the anticipated scaling down the line. Ask questions and make decisions that cater to a fully implemented and large-scale end state. What teams will have to weigh in on the pilot program? What processes will need revision or streamlining to integrate with the new program? Who will own the pilot program’s expansion in each relevant department? And, most importantly, how will we know it’s working (establishing pilot outcome performance metrics that clearly signal go, no-go, or adjustments along the way or during implementation)? 

Misplacing focus on functionality → Use proven technology

Purgatory pitfall: Many M4.0 pilot projects wind up in purgatory because of too much tunnel vision on what technical functionality is needed to meet their specific needs. While there’s certainly a place for that attention, it can get in the way of real progress and scale if left unchecked. The fact is that, however you perceive AI, IoT, and the associated HW/SW around it, the maturity level has proven itself ready for almost every application, including yours. Don’t spend time on developing new devices, hard or software, or go into projects claiming to be a “unicorn”—wherever possible, use best-in-class, proven, off-the-shelf components to quickly build your pilot (knowing it has a scale path) rather than getting locked into bespoke designs and hardware that starts to become redundant the day it is implemented, or software that gathers technical debt and requires inordinate maintenance and cannot grow with your company. Of course, this may mean potential and even significant changes to certain aspects of your business to realize the scalable end state, but not doing so will simply cost you more in the long run and cripple transformation goals.

Simplus solution: Put your energy into making sure the technology is fit to purpose and your implementation partner has a great track record and is a partner in your M4.0 success. The functionality of any technology can (and should) be continuously evolved and refined over time—and with the right team on your side, those changes can be done with relatively little disruption if you have opted for the right partner and product. Rather than concern yourself too much with technical capabilities, an M4.0 pilot is the time to evaluate how technology will deliver business value according to your defined goals and strategic objectives. This is also a great opportunity to research, engage, and develop relationships with industry peers, technology partners, and similar M4.0 “think tanks” and experienced resources that can help guide your project from their learnings. 

Making cultural missteps → Level the human nature playing field

Purgatory pitfall: It’s instinctive for your employees at large to be skeptical of change, especially if it will significantly alter their daily tasks and work expectations. You have to be careful about how you present change and training (across processes, technology, or tasks/outcomes and measures) in order to get the most accurate results. Consider the Hawthorne effect; people will change their behavior if they know their responses are being observed and expect some change to happen. This happens with surveys, clinical trials, and—you guessed it—your pilot technology program. Broadcasting the pilot too casually or narrowly, or being too overt about feedback collection may lead to a pilot promotion done in vain. You’ll find yourself either nursing negative reviews and poor adoption from your team because you didn’t set proper expectations in the messaging or let your users test out the pilot naturally, or conversely, you could skew your results to the positive, where highly invested stakeholders and ambassadors are determined to have a pilot that is successful. The main lesson here is simply that a fine balance must be struck between understanding your pilot goals and intent, appreciating the effect it may have on those charged with running it or impacted by it, and carefully but clearly messaging the progress, outcomes, and next steps throughout.

Simplus solution: To mediate this, level the playing field of human nature. Approach and frame your pilot in a way that lends itself to the least amount of bias: instead of naming it the “pilot”—a term that may frame it as a project without much consequence—give it a weightier name, such as “first application.” You want to suggest to your end users that this is a long-term effort, and it’s not going anywhere—there’s a non-negotiable permanence to these changes, but you still want your team’s help making the change the best it can be. Additionally, make sure you have strong advocates and messaging outside of the pilot team to create a good word-of-mouth effect on your adoption levels. Do not back away from tough conversations (for example, the topic of M4.0 and associate job losses/creation is still a hot topic) and build proactive feedback and input sessions into your pilot program.

Finding oneself in “pilot purgatory” may be a common experience in manufacturing, but it doesn’t have to be. With the right approach and parameters in place, big changes can be incorporated successfully into the larger enterprise with lasting successful results. In the next blog, we’ll move on from pilot purgatory defensive measures and learn how to take the offensive approach towards scaling M4.0 projects. Until then, you can reach out about starting a discovery call with Simplus’ expert advisory services team and register for our upcoming virtual event with the Manufacturing Leadership Council.