by Dov Rosenberg –
One of the biggest challenges with digital transformation projects is figuring out how to fundamentally change the core business processes of an organization without slowing it down or causing the organization to go bankrupt in the name of progress. This blog will look at the key challenges and provide some strategies to help overcome them.
Unlike fine wine and bourbon, hardware and software do not get better with age. The business environment that most software was originally designed to support is under a continuous state of change from many factors; customer’s needs change, pandemics happen, laws change – the list is endless. The original value proposition for creating a programmable layer on top of hardware platforms was to allow the “software” part of the computing platform to adapt to change easier than re-wiring the hardware platform. The reality is that the cost of change has risen dramatically over the years, and it takes longer to recoup the cost of the investment. The cost of change is driven by several factors:
The words “Digital Transformation” can have a lot of meaning to C Suite officers of a company. On one hand, CEOs and CIOs can use them as a catalyst for initiating substantial change to existing business models of an organization. On the other hand – they scare the heck out of the CFO trying to avoid having the Digital Transformation effort bankrupt the company.
Digital transformation is not typically reserved only for the IT infrastructure, it also includes the business processes that are run on the IT infrastructure. In most cases – what the Business folks want versus what the IT folks can support becomes the ultimate driver for Digital Transformation programs.
Over the years, the general IT infrastructure has evolved from mainframes to cloud-based capabilities. Within a specific organization – it is highly likely to have every iteration of IT infrastructure in use at the same time. The resulting mish mash of technologies is wired together with the modern-day equivalence of duct tape to get everything talking to each other. The cost of keeping this hybrid infrastructure up and running can be large and the impacts of any portion of it failing can be widespread.
There are 2 main types of applications that come into scope when talking about digital transformation projects: monolithic legacy applications and older API based applications. Each have their unique challenges that need to be overcome as part of a successful transformation.
Older applications were traditionally built in a very monolithic design where the database logic was tightly coupled with the business logic and user interface designs. These types of applications were intended to “own” the complete business process, to make any changes to the system – a deep understanding of the entire system was required. Breaking complex processes is very common because the systems are usually not well documented – especially the home-grown ones. In many examples of these Type 1 applications, they were never designed to interact with other business processes using APIs, instead providing data files, or executing batch processes were the preferred means of integration. These could be mainframe applications, third party applications (ERP platforms, accounting platforms for example), or homegrown business applications built using 3GL types of languages or frameworks.
The concept of building applications from reusable chunks of code is not new. The ability to create application programming interfaces (APIs) that can be consumed by other applications has been around for a long time. Over the past 30 years there have been several technologies that have been introduced – CORBA, SOAP, REST are just a few of the protocols. On top of the protocols, a near infinite number of business services have been created covering every aspect of every business. While all of this is great – it has introduced the need for constant consolidation of APIs as the proliferation of standards continues to increase. It is common for each business application to have its own definition of core concepts like User or Customer that are similar but different. Acquisition and mergers always require a reconciliation of systems between organizations to provide proper interactions. We recently engaged with a client that had 4 similar portal systems that they had acquired via mergers that now need to be consolidated into a unified customer portal.
Redesigning inefficient business practices from scratch is generally easy. You can look at your current systems and map them out and then work an improved process based on what is already in place today. You have the benefit of hindsight – you know what the result is supposed to be, and you can change the things that make the process harder. Actually implementing the changes can be considerably harder to accomplish. Consider the following scenarios:
Most organizations do not have the ability or desire to undergo multiple major transformations in the span of a typical employee’s tenure. When a decision to embark on a digital transformation journey is made, it is a highly recommended that an organization work with groups that have experience guiding a major business transformation effort to minimize the risks and costs involved rather than trying to figure it out as you go on your own.
“Dream in Years
Plan in Months
Evaluate in Weeks
Ship Daily” – DJ Patil
DJ Patil was a Data Scientist during the Obama administration who was talking about how to fix big problems. Here is a link to the back story behind this quote1. The important part about this quote is that in order to have a successful transformation – digital or otherwise, it is important to make sure that while you are thinking of the “Big Picture” you also keep in mind that it is important to figure out ways to drive change as quickly as possible and not wait for the “Big Bang” at the end. This is a key component of Lean approaches – figure out how to deliver value EVERY DAY versus at the end of an undefined period of time.
In the course of solving a big problem via Digital Transformation, it is quite likely that you will need to fix a lot of other things as you move forward. Planning on incremental solutions allows you to pivot as needed to accommodate the unplanned change while at the same time continuing to make progress toward the larger goal.
Figure 1 Cone of uncertainty2
The idea behind the Cone of Uncertainty is that large undefined problems are hard to estimate. Until the details are understood to a large degree, the estimates will not be accurate. When your digital transformation effort is large in scale and scope – the cone of uncertainty is large and drawn out. For example – if your Digital Transformation project is focused on improving Customer satisfaction by providing additional self-service options, it will be difficult to estimate the total cost of the project if it entails replacing your CRM system, ERP, and knowledge base. Until the high-level scope of the transformation effort is defined (even if it is in years), the Cone of Uncertainty will remain unbounded.
The key to reducing the Cone of Uncertainty is to establish a roadmap for each strategic initiative in the digital transformation program. The roadmap is critical for establishing the dreams and then breaking those dreams into executable plans that can be delivered in a timely and predictable manner. Each roadmap may have items on it that will never get realized because enough value may have been delivered by the earlier items on the roadmap to not justify the expense.
One of the biggest obstacles in digital transformation is the business impact to existing customers. In most cases, it is not practical to shut down your business while you re-imagine what the future looks like. This is a perfect example of the phrase – “changing the engine out of the race car while it is zooming around the track”. In an ideal world, Customers would never know you upgraded your service to them until they noticed things were better than they were. In reality – the cost of change for your customers will drive the success of your digital transformation effort. If your digital transformation effort costs your customers too much in time, resources, or money to participate in – they will likely look for a replacement for your product or service.
In the example where an organization provides their services via APIs and now has multiple products and portals available because of acquisitions, ensuring backward compatibility or providing upgrade utilities needs to be part of the overall digital transformation strategy at the risk of customers leaving for a competitor. In the case of Type 1 or 2 applications (see above) – adding new features or integrations may be easier than trying to retro fit the future state architecture into the old system. As the new platform matures and customers are migrated over it, the older systems MUST be evaluated to create a sunset mechanism for the older customers. A successful digital transformation CAN NOT leave the old systems in place long term. There must be a plan to move forward, otherwise all you have is additional operational costs.
This is another example of planning for the long term but delivering in smaller chunks of value. Look for ways to add the new capabilities and then shut off the old as quickly as possible. Many of the SaaS providers follow this model to minimize their long-term support costs. Ensure that your transformation efforts include ways to reduce the friction of customer acceptance and enablement early on including automated upgrade utilities, data migrations, or other options.
Another key strategy in driving a successful digital transformation program is to continually measure the value being delivered to ensure that the goals are being met or exceeded. Simply meeting a set of delivery milestones each month doesn’t necessarily mean that your digital transformation effort is a success. It is much better to deliver functionality that is useful and accepted by the users than to bury them in new features that they will never use or are buggy. While the goal is to “Dream in Years” we still want to deliver value often. If we continue to prioritize the most important things to work on first, it is highly likely that we will not have to deliver everything in our backlog for the transformation project to be considered successful.
One way of evaluating the backlog to ensure that the most valuable things are being worked on at any given point in time is to focus on the cost of the delay – Scaled Agile for the Enterprise calls this Weighted Shortest Job First (WSJF)3. WSJF measures the cost of the delay of a new capability by:
Cost of Delay = User-Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement
Figure 2 WSJF Cost of Delay
It is critical to continually evaluate the items in your roadmap to determine whether they will deliver the value expected based on the investment required. The goal is to focus on the work that will provide the greatest value with the smallest investment.
Another strategy is to utilize A/B testing to validate the assumptions that were made when the business transformation was strategized. Refining the assumptions based on customer feedback is critical to ensuring that the transformation effort is solving the right problems.
Digital transformation is an essential part of any business that wants to ensure long term growth. Digital transformation is not just a destination that provides value when it is complete – it is a journey that should provide value every step of the way. By focusing on the journey instead of the destination, you can greatly reduce the chance of catastrophic failures that could cost millions of dollars with no benefit. RCG has helped our clients on their Digital Transformation journey across every aspect of their IT ecosystem.
1. Medium (2020, Jun 18) "Class of 2020: from one data scientist to another" Retrieved from https://medium.com/@dpatil/class-of-2020-from-one-data-scientist-to-another-f3de5f2d70d
2. Medium (2020, Mar 16) "Learn About the Cone of Uncertainty Framework" Retrieved from https://medium.com/pm101/cone-of-uncertainty-framework-78927c1840f
3. SAFe "Weighted Shortest Job First" Retrieved from https://scaledagileframework.com/wsjf/