The Darker Side of Digital Transformation - Invisible Factors
After completing several successful complex multi-year business and digital transformation initiatives, you acquire a long list of stories and learnings best to be discussed over a long haul of drinks at a favorite bar. The stories abound. You name them, I’ve got them … Stakeholder sabotage, vague and undefined measurements or outcomes, unreasonable timeframes, client lawsuits, moving targets, the list goes on… While it seems like I’m initially presenting a more negative, cynical portrayal of transformation – at the end of the day, anticipating and planning for situations that are not written on your checklist/playbook will make you sleep a little better at night when a transformation initiative starts to tact from left to right. Oh by the way, did I mention that your chance of succeeding will probably increase?
One thing that holds true with all transformative initiatives will be some kind of material change in the way an IT organization operates to support the initiative. There is always some number of old-guard personnel that don’t see the point of the transformation and the new guard transformation team charged with implementing the initiative. Corporate politics and posturing are almost always at play here. The organizational and reporting structure supporting the transformation initiative is key. Accountability and consequence are also key. I'll cover my thoughts on this in another article I plan to publish soon.
Any transformation initiative will have invisible and dark factors hiding around the corner that must be identified, solutioned and, agreed upon. Depending on how large the transformation is, these invisible factors become more disruptive when they occur. For those of you planning to embark on your first (or next) digital transformation journey, I offer some pearls of wisdom:
Digital Transformation with a focus on Cloud Computing – In most instances, a digital transformation initiative will include some focus on cloud computing options. Much has been written about the merits: having a tighter financial variable cost model that aligns with business consumption of services – a pay as you drink Opex that reduces the number of capital expenditures in play; shortening the break-even cost/benefit horizon assuming there is proper separation between common (cloud) and differentiated (in-house) technical functionality; easier to deploy updates; quicker onboarding of users; better virtual services for a remote workforce; centralized provisioning; less dependence on capacity forecasts; and, contemporary tools to manage application development environments. Equally, there are risks to mitigate such as: having a complete dependency on a vendor’s platform (ok for non-differentiated functionality or in other words, technology that isn’t a part of the firms “secret sauce”); limited customization options; process changes needed by your organization to cater to the cloud platform you choose; potentially limited access to data stored on the vendor platform; and, no physical ownership of a software asset once you stop paying your subscription fee.
In my experience, hidden factors that impact a successful cloud computing-focused transformation revolve around resiliency risk, and data. Vendor, network, cyber, and regulatory resiliency risks need to be assessed with appropriate failovers that are acceptable to the business. Consider revamping your business continuity plans. Stay with known industry leaders for your operational functions to mitigate vendor risk. Involve your end-users on the selection process as they will have to live with limited customizations. Adoption of cloud computing solutions tends to be more straightforward for smaller companies especially for start-ups where their main revenue generator isn’t some kind of proprietary software platform. The use of cloud services for big data activity is gaining adoption. More companies are paving the way of solving key issues such as potential data loss, latency, domiciling of private data across geographic jurisdictions, data portability, and of course – security. Depending on how important your corporate datasets are to your business's competitive edge, this is where you want to tread more slowly in cloud adoption. The last thing you want to have happened is to impact the flow of your business operations by not having a well-thought-out network resilient infrastructure to ensure quick and timely access. Track the developments of the larger firms as they have the budget to solve these types of risks.
Digital Transformation with a focus on operating efficiency supported by large legacy systems – When operating efficiency is the theme, fixed run-rate, and people costs are a big component of the equation. Being able to explain your organizational costs in detail creates executive confidence that the transformation team has a clear view and baseline to start with. A negative hidden factor is when the transformation team leadership cannot readily and at the tip of their fingers, walk through operating costs, issues and opportunities. If baseline metrics are not available, expect a hired consultancy to develop one for you. They will also have a seat at the table to opine on approach. The classic ones that come to mind are around people throughput, productivity, and employee idle time as well as allocated corporate overhead.
Digital Transformation is truly impactful when the strategy goes beyond just benefitting only IT; it must also include the transformative benefits for the business units it serves. Quantifiable financial, service, resource measures with critical dependencies must be agreed upon by the business and IT stakeholders. If the measurements aren’t agreed upon then the program is exposed to “failure” politics when something goes wrong - lack of accountability and finger-pointing abound will take precedence. This is a major negative transformation success factor for obvious reasons. Executive leadership will quickly lose confidence in the program. So set expectations upfront and make sure reporting cadences ensure effective flow of progress.
Don’t leave on the table, internal chargebacks and overhead. How many times have we seen internal charges that are unexplainable or more precisely, allocated charges on items that were not used by the charged units because the algorithm spreads an organizational cost across businesses evenly. Question every shared charge. Having said that, this is a potentially losing battle when it comes to infrastructure. Not so much on the people side. When you have a highly centralized organization, the politics weigh in favor of the central group and the transformation initiative charter/mandate has to have the ability to attack the financial setup of that centralized organization. This issue alone deserves its own in-depth article. Look out for it in the future.
Operating efficiency almost always includes the objective of doing the same work with less people which means workforce reduction; workforce reduction in your IT organization or the business units you serve. Likely both. If the final outcome does not result in a workforce reduction, then your program did nothing more than to provide more time at the coffee kiosk for your underutilized employees. As bad as it sounds, this is the sad truth and some executives will be right on top of it.
Allowing for Siloed representations of success are dangerous and often used maneuvers used by legacy managers to substantiate their headcount; I’ve seen one too many times in poorly run shared services organizations where one stakeholder group claims victory at the expense of another group being negatively impacted. Program managers can get easily fooled as the net argument may show that a silo may perform its tasks efficiently but the net outcome to a client or an internal customer doesn’t improve.
Digital Transformation without a Business Sponsor - It doesn’t help for instance, to push the effort and investment for a new omni-channel development platform to improve customer reach and experience if the sponsoring business units don’t define concrete and quantifiable baselines to improve revenue against newly acquired customers, cross-sell of new products or customer satisfaction. An investment in Digital Transformation always creates a cost bubble where ongoing BAU operating costs overlap transformation investments. Also, if there are vague deliverables in any interdependent work activity between groups, the cost/benefit model has to be embraced tightly from the beginning of the initiative with accountable actors.
Digital Transformation with a focus on application modernization - if there isn’t clear forethought around how legacy processes and BAU activity benefit from the transformation and all you are doing is an upgrade to a new version of software to improve functionality without any measurable financial benefit in operating efficiency, you are leaving prime meat on the table. Responsiveness to business requests must be improved. Cost-effectiveness for operational processes should meet or exceed the J-curve cost-save forecast. Temporary workaround solutions are needed to ensure the business (and signed off by the business executive) can service its customers while the modernization transition is underway. Cycle time reduction in your SDLC is an opportunity but should not be a main focus or critical dependency, especially if you are modernizing a vendor system. Improving governance of demand requirements are key to get agreement on transformational outcomes and deliverables agreed with your sponsoring executive, but these should be taken as parallel efforts.
Ensure the business case has the financial and time runway needed to handle to transition bubble when both systems and operations teams are running in parallel for reliable cutover to the new system. Add financial and time contingencies for unforeseen delays due to conversion issues.
Digital Transformation with a focus on implementing new disruptive technologies - (disruptive to your own IT organization) – If your transformation strategy is to actually acquire the source code and overall intellectual property of a new technology platform (vs just licensing a software application for use) then the incumbent IT organization (aka: in-house development team) will have the highest exposure to disruption from a skills and capabilities perspective; especially if the new technology isn’t a core component of the IT organizations existing technology stack. Usually, the acquired technical platform will need to be implemented with an external team that has the skills for a reliable implementation. Chances are that the incoming team will also have proprietary methods and processes that your own IT team will not be familiar with and may be in contradiction with incumbent standards. If this is the case, then your IT organization stands a great chance for a major gutting of your workforce and its existing processes. The trick is to avoid being the blocker and to invest the time to surgically build an IT strategic roadmap that embraces the change. Also if possible, look to engineer a rebadge situation where you may be able to monetize your workforce to a vendor that has a skill gap for a win-win scenario. Finding your future ex-employees is the right thing to do although not always feasible.
One vehicle used to acquire disruptive technology is strategic M&A. With this method, you get the tech, people, process, product, brand, and possibly revenue. IT organizations must avoid unwitting activity that causes value destruction. Two big reasons for this approach usually lie in the lack of time needed by the incumbent IT team to develop capability organically or to disrupt the acquirer’s competition to keep them from gaining access to a particular technology.
Obviously, the lesser disruptive vehicle would be to just acquire the license from an established platform. Again, organic workforce ramp-up to support new tech is also costly and may not have the luxury of time on its side.
Depending on the vehicle used for your digital transformation, these factors will weigh heavily into successful execution. If it's M&A, expect your corporate development team to weigh in heavily on diligence and post-merger integration activities. You will also have a series of different issues to deal with related to the investment thesis objectives and the potential duplicity of personnel.
Digital Disruption Via AI
Needless to say, most IT leaders today are still discovering how to deploy and manage an AI platform due to its recent commercialization from the scientific community over the past several years. When I worked with a European company to help build out an AI division just a few years ago many firms either thought of AI as a tack-on program or struggled to build a business case to substantiate the investment. As we now know, AI’s benefits are taking hold.
AI’s impact won’t just be the potential job reduction catalyst in business operations. It will also impact the IT side. AI development significantly differs in skill set from that of classical IT development. I’m not suggesting that an IT organization will be obsolete as legacy technologists will be needed to run old systems for quite some time. But here’s the dilemma:
Most technologists will not make the leap to programming in an AI environment. The technology stacks and programming methods are vastly different. Re-tooling will require a huge training investment. Monetarily, it will be better to hire young, trained programmers. The good news is that not all of IT will be dependent on AI.
Most innovations are coming from startups, academia, and the scientific community which makes it problematic for companies to gain access to these jewels of value; largely due to procurement policy and concerns with start-up stability risk issues.
AI initiatives get stopped dead in its tracks when an organization doesn’t have a large enough dataset to support machine learning objectives.
AI is a long-haul investment especially if it's in-house built.
Most legacy data warehouses are not curated for direct consumption by machine-learning algorithms. As much work here is needed for data curation; perhaps more so than the coding itself by a data scientist.
Traditional IT organizations have too much protocol and process chatter that get in the way of justifying a pilot or investment in new disruptive technology. The business needs to be brought into the discussion and in fact, should be the owner of the business case. In one engagement, I worked with the Corporate CFO of CBS to examine how AI could solve very high-cost activities involving re-shoots, use of music, and other use cases, none of which were identified by their IT partners. However, his IT organization was not structured in a way to perform this non-traditional assessment.
RPA and AI are non-complementary technologies at the onset. Unless it is properly thought out, you may develop solutions that don't feed from one to the other.
Digital Disruption: Migrating off Legacy Systems (application modernization)
Much has been written about this topic. To me, the biggest concern surrounding this issue relates to data conversion and surfacing the many hidden workarounds and business procedure gaps of information the legacy systems developers hid and would be eventually discovered during the data mapping, balancing, and ancillary transfer phases of your conversion. I recently completed a "conversion" turnaround situation where a poor contract, as well as even poorer program management between a customer and service provider, completely underestimated key components of the implementation: missing data and information, processes, business decisions to name a few. All of this could have been avoided had adequate planning and analysis been done upfront with rigorous governance to hold both client and service provider teams accountable. More on that in an upcoming article.
I’m interested in what you think. I’ve probably raised some debatable points of view. Let me know in your comments below.
Albert Eng is a recognized, IT and Business Transformation expert in the financial services industry. His experience in strategy, strategy implementation, and, as an operator gives him "been-there, done-that" wisdom to solve a wide spectrum of complex enterprise situations.
