Why Do Digital Transformation Efforts Fail?

Nov. 1, 2023
The reason could be in how they're implemented. Adopting the sprint implementation strategy from software developers may be the remedy.

Manufacturers face a dilemma. Digital transformation is critical to keep up in a rapidly changing market, yet it’s widely reported that as much as 70% of digital transformation projects fail. If manufacturers are to move forward with technology initiatives, they must take a long look at what’s gone wrong in the 70%.

The breakdown of these projects often begins right from the start with implementation. Many companies jump feet-first into a digital transformation project with multiple lofty goals. But with these big goals come long timelines, complete overhauls of existing technology and hefty costs. As a result, these projects are frequently abandoned due to overwhelming costs and slow ROI (return on investment).

To make digital transformation projects successful and accessible, especially for mid-size manufacturers, rethinking implementation is key. One promising method comes from the world of agile development—sprint implementation.

What is the sprint implementation method?

Put simply, the sprint method takes a large project and divides it into smaller projects that can be accomplished in a fixed period of time. The sprints are designed to target specific pain points with clearly defined KPIs (key performance indicators) and, critically, deliver a fully usable product at the end of each sprint. By breaking a complex project into a series of smaller deliverables, manufacturers can achieve ROI faster and use the ROI from each sprint to help fund the next.

In software, sprints are typically as short as one or two weeks. In adapting to the sprint methodology for manufacturing, we have found sprints that are too short cannot deliver the ROI that justifies a sprint. In our experience, a 60- or 90-day sprint is ideal for manufacturing use cases that involve not just software but also hardware and process changes.

Let’s look at an example. Suppose a manufacturer wants to implement predictive maintenance. Often, once a company is sold on a transformation initiative such as predictive maintenance, they want it everywhere all at once. However, achieving predictive maintenance across all your plants is a large, complex project that takes months, if not years, to accomplish.

The sprint implementation offers a different approach. The goal would be to start by adding predictive maintenance to one piece of equipment. This would help you create short feedback loops to test and iterate on an application before trying to scale it.

The sprint implementation timeline

Typically, a company will go through three sprints to implement a solution:

● Sprint One—Deploy: During this phase, the focus is on creating a workable solution. The goal is not perfection. Rather, in sprint one, you’re trying to get a workable solution in place as fast as possible to gain proof of concept. More often than not, you’ll need to address integration and data collection in sprint one because data is the fuel for digital transformation.

● Sprint Two—Evaluate and Iterate: The second sprint focuses on adjusting the solution. By rolling out the first solution in under 90 days, you’ve dramatically shortened the feedback loop. On a larger project, it could have been over a year before you could gather feedback. By moving fast, you can work out the kinks earlier. This also creates a collaborative environment that is conducive to gaining buy-in from end users. It’s well-known that change management is key to digital transformation, but many companies fail to recognize that delaying the opportunity for employees to give feedback is hurting their efforts.

● Sprint Three—Scale: After deploying, evaluating and iterating on the solution, it’s time to scale it to multiple plants. Here, it’s key to standardize your processes so that you can make implementation as repeatable as possible. In our experience, this often involves developing processes for data preparation and personnel training. With both of these in place you can scale quickly and effectively, delivering multiple plants within a single sprint. By focusing on only the items critical to deployment, we were able to scale one of our recent customer deployments across 18 plants in two 60-day sprints.

Where to start?

For sprint implementations to be successful, you need a suitable starting place. While it’s tempting to start with the most exciting projects, I recommend looking at the intersection of high value and low complexity. For instance, you may want to start with an ambitious machine learning project. However, if it’s unclear what the ROI will be and the complexity is high, you run the risk of blowing the budget and destroying morale after months without tangible success. Instead, you might start with something like digital forms. This project might not be flashy but it can dramatically increase data accuracy and improve conditions on the factory floor.

As you consider a starting place, think about how solutions can build on one another. For instance, if you want to achieve better analytics, look at your data sources first. Are there any integrations needed? Can you add new data sources, such as installing IIoT sensors? By looking further upstream, you can design your implementation roadmap so that one project lays the foundation for the next.

Jonathan Kaplan is COO of Americas FactoryEye by Magic Software, a part of the Magic Group, a global provider of proprietary application development and business process integration software solutions and related professional services, and a vendor of IT professional services.