Digital Transformations aren’t Real…
I bet the title confused or enraged A LOT of people but let me clarify….There is no such thing as a stand-alone technology/digital transformation and if a transformation is treated as such, the organization is heading toward guaranteed failure. Sadly, this is how transformations are treated across many organizations, which tells us why 70% of technology transformations fail to achieve their goals (McKinsey). Successful technology transformations are business transformations that have a heavy emphasis on implementing state-of-the-art technology to drive business value. This might sound both odd and obvious, but it is one of my biggest learnings over the last decade of my career driving and advising large-scale transformations.
Let me explain- technology transformations likely come to life due to one or a combination of business cases including cost reduction, efficiency improvement, compliance requirements, error reduction, customer experience, etc. But regardless of the business case on paper, the transformation is meant to give the organization a competitive advantage; it should make the organization better than it is today to be relevant and win in the market. But rarely do technology transformations have measurables that reflect business outcomes or take into account key business process changes. My goal with this article is to help readers have a framework in mind to set up business technology transformations of any size for a higher likelihood of success.
Note that each of the elements below is to give you an idea of what best practices should be kept top of mind for a technology transformation. This is not an exhaustive list by any means nor am I suggesting that each of these requires a separate, dedicated workstream.
Business Processes- All impacted business processes and peripheral business processes that may not be directly impacted but are downstream and upstream from the technology changes should be analyzed and considered for improvement. Business process changes must not be left as an afterthought but be part of the transformation initiative.
Technology Development- Depending on the technology being off-the-shelf, customized on a platform or built from scratch, an Agile, Design Thinking inspired approach should be undertaken to appropriately involve end users and key stakeholders in the selection, configuration, or development of the technology.
The art of possible should not be ignored; end-users and stakeholders will provide their preferences, but they may not be familiar with all the latest technological advances and possibilities. These should be brought to their attention.
Technical debt should also be an important factor to consider during pre-development analysis and development to constraints on future transformations.
Operationalization- Operationalizing a technology transformation involves a good amount, broken down by the sub-elements below.
Data Migration- When transitioning to a new technology solution, data migration is critical. Suppose the current form of the data is not linkable or easily transferable to the new solution. In that case, it can add significant time and effort to the transformation before much value is realized. Assessment of data migration needs should be completed as early as possible and, if possible, efforts to align the data for easy migration should begin along with the development efforts.
Documentation- Quick reference guides and training manuals are critical and obvious documents that are created/updated but business process SOPs should be updated or created, especially for peripheral business processes that might be upstream or downstream from the technology solution.
Implementation- As obvious as it is, transformation teams often miss critical implementation constraints. This includes technology blackout dates, key commitments to customers, other transformations, fiscal year-end/beginning, etc. These constraints should be a part of the roll-out plan for the implementation of the new technology. Critical to note that external companies developing and implementing the technology will need guidance from the organization as they won't have visibility to these items.
Operational Infrastructure- Depending on the scale of the technology transformation, there could be operational elements that are needed to manage the technology post-go-live that don't exist or are not adequate today. These could include upskilling of helpdesk staff, reporting of metrics that were not available before, new organizational roles, etc. An operational assessment must be conducted to ensure the technology can be sustainably managed post-initial implementation.
Training- Training is often focused on the new technology platform but the training strategy and plan for the transformation should include the business process changes and operational infrastructure changes as well.
Hypercare- Implementation of a new technology should be accompanied by a robust Hypercare plan, which should be communicated to the end users and stakeholders.
Change Management- Often overlooked but ever important, Change Management is a critical piece to any transformation. There are two aspects to change management shared below (note that the ADKAR change management framework has five elements, which are all critical. This article just divides Change Management into two distinct parts for purposes of simplicity):
Stakeholder Engagement- Keeping stakeholders well-communicated and engaged throughout the transformation is critical. This should go beyond just written communication; the team should meet stakeholders where they are in team meetings, town halls, and leadership forums. Creativity is key here to keep the stakeholders informed and get them excited.
Mindset Shift- At the end of the day, the key purpose of Change Management efforts is to drive a mindset shift to allow a transformation to maximize its value realization. It is imperative to listen to the stakeholders, help them realize the value of the transformation they will see, and help them sustainably adopt the changes. Mindset shift comes in different ways and at different rates for various individuals, but some tools and activities will act as accelerators of this shift as described below:
A two-way feedback loop is a must for any transformation to be successful; if the impacted stakeholders don’t see their voices being heard and acted upon, they will have little to no interest in adopting the changes, especially if they don’t fully agree with the changes that are being made. It is important to not be ad-hoc about this as well, be intentional and set up a structure that allows ongoing two-way information flow. Furthermore, there must be adequate appetite and structure to allow the program team to react and respond to the received feedback.
Leadership alignment workshops, especially ones held in person, are a great accelerator for cocreating the value proposition of a transformation with leaders from the stakeholder groups and give them a chance to own the solution design from the beginning. These can be tricky because, if not facilitated correctly, they can easily become a non-productive waste of time for everyone. Using design thinking tools to help facilitate these workshops (e.g. headlines of the future, individual ideation and theming, clustering, structured round robin, prioritization PICK charts, etc.) goes a long way in bringing the necessary structure to have a productive output.
Smooth UAT and Training for the end user groups is a shared responsibility that the developers and the program team must take on together. This may seem straightforward but if there is chaos during this crucial period and not enough time is allocated upfront, we face the issue of losing the trust of the stakeholders before even going live with the process and technology changes.
These are just some thoughts around transformation management and holistic transformation design. This is not a playbook but food for thought as you go through a transformation, especially if it is set up as a “Technology Transformation”.