Most executives are afraid of digital transformation. And I don’t blame them–with the amount of undertaking required for such projects. Not to mention that it took a long time for companies to understand – that digital transformation projects are not meant to be technology projects (The initiatives that developers can code in their backyard. The ones that can provide a crystal ball that can solve all your business performance issues). In reality, digital transformation failure typically has more impact on your businesses than most other disruptions (Unless it’s a full nuclear war). So why are some projects more successful than others?
There are millions of variables that could be responsible for failure. Team. Technologies. Vendors. Project managers. Change Management. Also, with so many variables involved, everyone is likely to have their own theories. There is no clear consensus, which makes it confusing for first-time buyers. While it’s much harder to find why a specific digital transformation project may have failed, it’s much easier to analyze the successful ones. One thing that successful teams do differently is that they don’t underestimate the efforts involved with these projects.
That’s probably the reason why the larger companies with multiple ERP implementations under their belt are likely to be more successful than the smaller companies. There are smaller companies that are likely to be successful as well. However, in their case, the executives must have experience leading multiple ERP implementations at larger companies. While this is one factor, there are more layers to what makes them successful (as per our study done with more than 200 executives suggests). Excited to review the results?
1. Misalignement in scope
Misalignment in scope is perhaps the #1 reason for digital transformation project failure. Some people might blame the “invisibility” aspect of software development – to claim that there will always be surprises with software implementation. Also, there is a common misconception that there is no point in planning if there are going to be surprises anyway. Following this approach is an “extreme” thinking mindset where you don’t prepare for an exam – just because there might be a chance of failure.
Software implementation projects require the same amount of engineering processes. As much as manufacturing or construction. Sure, there have been advancements in methodologies – such as agile – to uncover risks earlier. However, the fundamentals of software engineering still apply. They require careful analysis and design by qualified ERP consultants (the consultants that regularly implement for various industries and business processes).
Also, unfortunately, analyzing at “100K-foot” levels (the mindset that going too deep into technical analysis may be a waste of time) approaches aren’t good enough to be successful with these projects. It’s a careful balance of high and low-level needs. A balance that will help you find the scope with an iterative process and a scope that will likely not have any misalignments. Or surprises (Don’t we like surprises?).
2. Unrealistic Expectations
The only reason why unrealistic expectations lead to ERP implementation failure is to underestimate the amount of effort required. In fact, unrealistic expectations and misalignment in scope are so interdependent that they could be each other’s cause (Wait, what? Have I confused you enough yet?).
The root cause for unrealistic expectations is the “mindset” that maybe there is an easier way. Maybe the “consulting companies” are in the business of overcharging their customers. Maybe consultants have a tendency to overcomplicate things so they can make more money. While, as with any profession, there might be some bad apples out there, the issue is typically with the companies who don’t have enough experience under their belt in leading digital transformation initiatives.
The best way to mitigate such issues is to be patient with the process and do as much research as possible to understand the core issues. Also, recommended is not ignoring the advice of your consultants. The more implementation you have under your belt, the more conservative you will be with these projects. And the higher chances you will have of success with such projects. The only way to succeed is to be realistic (and extremely conservative) with these projects.
3. Inability to re-engineer processes (aligned with the capabilities of new system architecture)
Constructing a house based on how your old house appears today is likely to result in the same “old” house – with not much improvement (Isn’t that what we all want? The constructive ways of wasting our money? For all practical purposes, no!). Constructing an improved house requires you to have a deep reflection on the old house as well as the root cause of each issue you had in the old house. Along with the “mental model” (I prefer a blueprint on a piece of paper) of the new house based on your new needs. This task is way harder than you would think.
Being successful with it would require a solid knowledge of several different ERP systems and implementation experience in several industries. So, you have enough data points to identify the right model that will be successful, given the constraints of this new house. Without business process reengineering, companies mistakenly assume “old and broken” processes as their needs. And hand it over as requirements to the technical teams.
Given the constraints, the technical team might spend months customizing these needs. And even after successful technical implementation, they might never work for users as they might deviate from the system’s optimal state. Skipping the crucial step of business process reengineering results in ERP implementation failure. Along with adoption and change management issues due to the limited understanding of the rationale for change.
4. Over-customization of the software
Most companies with limited experience with ERP implementation have a tendency to underestimate the effort involved in customizing software. The customization not only results in the core system’s sub-optimal performance. But it also causes user adoption issues due to the alteration of systems’ natural state.
Also, most organizations that may have promoted their developers to IT operations managers too early to a CIO role are likely to customize the software heavily (Also, they hate dollar conversations, which is perhaps the bread and butter for a CFO) The business rules in ERP are so nested that even if you implemented a feature successfully (for your own use case), it’s likely to break for other departments.
So, customization of software will always have a much higher chance of implementation failure. The best strategy to save an ERP implementation because of over-customization is to perform a thorough gap analysis during the selection and get recommendations from implementation architects in terms of the effort involved – in implementing each gap. If the effort seems too high, most likely, you have selected the wrong software. Or your process needs to be simplified further (You also have the option to pray. They always work with digital transformation). Thorough scrutiny and deep probing of each gap will help you understand that you are customizing only when it’s absolutely essential.
5. Usage of too many poorly written bolt-ons (impacting operational performance)
Most systems’ design assumes their natural state for optimal performance. While they all might allow customization, the system may have never been tested with the overlapping boundaries of add-ons. The add-ons might also be poorly written – and might cause performance implications.
There is also a misconception that no-code technologies can help you integrate anything and everything. Yes, that is true. But when it comes to mapping data flows and identifying sources of authority, the fewer variables you have in your model, the higher chances you would have with your digital transformation initiatives. (You want one thief to steal your money. So you kind of know who stole what)
Using too many add-ons is a major factor in digital transformation failure. This is due to the increased number of variables that are controlled by multiple vendors, their technologies, and release cycles. Having too many add-ons is a clear red flag that there might be better options out there. And a factor that you should watch closely while signing your software contract.
6. Organizational change management
Underestimating the importance of change management results in digital transformation failure. But change management is typically the first symptom (Like a fever is an expression of inner rage) that you might notice regardless of the underlying issues that might be driving poor adoption. For example, change management issues could be a result of poor training, suboptimal system design, and workflows – or misfit technical systems.
“Business consultants” with very little background in formal software engineering have a tendency to believe that you can solve all change management issues with superior training. Well, it’s almost like saying that you can solve all sales performance issues with the right “mindset.” Can you?
Sure, “mindset” and “training” play a huge role in change management. But it’s not just the training that is responsible for the success of digital transformation initiatives. It’s the synergy of systems, technologies, design, processes, and motivations that make digital transformation initiatives successful. But the most important factor for effective change management would always be the ability of change management consultants to work with the technical teams – to ensure that there is no misalignment in strategy and execution.
7. Lack of maturity of enterprise architecture
The lack of maturity in enterprise architecture is a leading cause of digital transformation failure. Most SMB companies don’t even understand the number of components that might be included as part of the software contract. Just like manufacturing, a critical part can halt your product line, and a weak component of your “software BOM” could lead to digital transformation failure.
Irrespective of whether you buy or build – or how many ever add-ons you have in your architecture – enterprise architecture is extremely critical. The enterprise architecture encompasses four different perspectives: 1) business architecture 2) process architecture 3) data architecture 4) system architecture.
When most companies think of enterprise architecture, they see it as a “technical” concept. But just like an org chart is to people, enterprise architecture is to systems. And the success of your enterprise architecture relies on having clear boundaries of systems and processes. Because they each play a role in defining cross-functional processes So not having a clearly defined enterprise architecture is the surefire way of failing your digital transformation initiatives.
8. Poor governance of master data
Master data forms the foundation of your enterprise architecture. Without having a clear interaction model of each dataset, the systems are likely to have duplicated data in multiple systems. The inefficiencies caused by duplicate data and data silos lead to more fragmented systems. Ultimately causing even more data silos. Tracing data dependencies in your enterprise architecture might feel like a confused mouse in a maze.
Even developers and technical architects struggle to understand the concept of sources of truth. The most common misconception is about the multiple sources of truth. Some people believe that multiple sources of truth mean keeping duplicate data in multiple systems. Sure, are there any systems that can be implemented by completely decoupling data dependencies? Yes. But is that architecture going to be appropriate for every single dataset? Probably not. And most certainly not for the architecture containing financial systems and processes.
Implementing event-driven architecture with completely decoupled datasets works when the reliability of data is not as important a concern. Think of social media messages or error logs published by remote devices. What’s a big deal if we might lose an error or social media message? No big deal right? But with financial data where the books need to be reconciled to pennies, the reliability of data is extremely critical. And the data architecture that allows you a high degree of relatability and traceability is a crucial requirement.
9. System selection gone wrong
Selecting appropriate systems requires you to have updated knowledge of architectural patterns – and several enterprise software categories, including ERP, HCM, CRM, and eCommerce. The software systems available in the market have extremely overlapping boundaries – with substantial duplication in code bases. And this is only going to get worse! Also, it is equally critical to have profound expertise and advanced knowledge of your industry and business model.
Without a comprehensive knowledge of systems and processes, your gap analysis is likely to miss critical gaps that command the highest amount of dollars — and lead to ERP implementation failure. Also, prior to investing in technology, you need to invest in defining the other three legs of the stool: 1) business architecture 2) process architecture 3) data architecture. Selecting a poorly fit system will lead to over-bloating of processes and systems, resulting in serious adoption issues. Don’t sign a software contract without performing an exhaustive search of all systems available in the market.
10. Past results = Future success (With digital transformation initiatives)
You might never be proud of the first home that you bought. As you develop deeper recognition of your own needs, you are likely to do a lot more planning and “sketching” with your next purchase. The same principles apply to digital transformation. First-time executives are likely to be most optimistic about finding “cheaper” and “smarter” approaches to digital transformation (unfortunately, poker strategies don’t work very well with digital transformation initiatives).
As you implement more systems, the deeper will be your analysis. And more conservative will be your approach. The conservative approach to system design and planning leads to digital transformation success. So make sure you don’t cut corners in hiring the right expertise to lead your digital transformation initiatives.
11. Ability to work with technology vendors
Just like an engineer must be able to connect and relate with your shop floor workers, your ERP core team must be able to connect and relate with your developers and technical consultants. This relatability requires you to speak their language in the format they understand (and with digital transformation implementation, God will not translate for you).
Not listening to their concerns or ignoring their advice with the attitude of “too much into weeds” will lead to ignoring critical issues that might have disastrous consequences on your enterprise architecture. They also require translating business vision and priorities into technical architectural components that will help them connect the dots. Several years of experience working with technology vendors helps in building the right rapport with technical teams – and leads to digital transformation success.
12. Poorly written test scripts (and the missing framework for test compliance)
Writing good test scripts takes years of practice. With ERP systems, it’s even harder. Because you need to segment the functionality that is pre-tested and provided by OEMs – from your custom configurations and customizations. To do this, you need to have a deep understanding of the core ERP functionality. And The more lines of code you own – the more testing you need (like the more money you own, the more stress you will have).
The main issues with enterprise-grade systems are data dependencies and the length of enterprise transactions. That makes documenting and tracking test cases and results much more difficult. It takes years of practice for ERP testers to identify the right test scripts. That will help uncover critical issues early in the process. And avoid showstoppers later in the release cycle. The showstoppers that typically lead to digital transformation nightmares.
13. Uncontrollable issues
Because of the “invisibility” issue of software implementations, you will always find uncontrollable issues. However, it is the thorough planning and early detection of critical technical and process issues that help minimize uncontrollable issues. It is also the research that has gone into each issue to minimize the impact on time and budget.
But sometimes, finding a fine balance between the time required to perform research and the budgetary implications of showstoppers is key. Investing too much time in issues that might never surface may be a pure waste of time and resources. This is why consultants who have deep experience in executing large programs are better equipped to identify these issues much earlier in the process – and save digital transformation nightmares.
14. Not having a dedicated internal skilled project manager
The most challenging part of a digital transformation project is the missing cross-functional link. Typically, in SMB organizations, the CEO has the most cross-functional understanding. And the only person who is qualified to negotiate with each department in executing or organization’s vision. The problem may be more difficult with organizations with multiple subsidiaries.
And unfortunately, the CEO very rarely has time to get into the “weeds” of the project (who cares for a neglected weed anyways?). Or mediate conversations when there is a conflict among functional or BU leaders. This is where the project mangers’ role is absolutely critical for the success of the project.
The project manager must have several ERP implementations under his/her belt and have a formal educational background in business or supply chain. Also, one of the most critical skills of a project manager is to be unbiased (except when it comes to preference for their coffee) and spend time working closely with executive teams. Hiring an intern or a “generalist” project manager with no formal background in Supply Chain and software engineering is a sure recipe for disaster.
15. Treating digital transformation projects as a technical implementation
While the major component of digital transformation initiatives is technology, it alone can’t solve all your problems (with solitude, it’s independence; with digital transformation, it’s interdependence). It has to be the synergy of processes, data, organizational structure, compensation plans, and systems.
Treating your digital transformation project as a technical project typically leads to over-customization of workflows, overengineering of processes, and data siloes. They all lead to poor adoption – and, ultimately, digital transformation failure. Involving your business users from day one through the process of business process re-engineering will help them understand the technical challenges and articulate their needs in a technically feasible manner. This will also help forecast the challenges they might expect when they are live on a system.
Final Words
There are several factors that could lead to digital transformation failure. It’s never one vendor. Or a system. But one surefire way to fail your digital transformation would be – to underestimate the amount of effort involved with digital transformation and ignore the pre-selection phase. This sets the tone for how badly the digital transformation initiative will fire back. Because they always fire back unless carefully planned.
Digital transformation initiatives are like going for heart surgery. The first time will always be the most painful. As you get used to surgeries — and how to mentally prepare for the surprises with each one – hopefully, you won’t be as afraid with your next surgery.