Inhibitors to Transformation In An Organization

A butterfly emerging from its cocoon

I have been an IT manager / executive for over 40 years working primarily for a large telecom company. During that period, we attempted many major transformations as Information Technology itself was transforming.

·       When I started, we were using keypunch cards for Cobol software that ran on IBM mainframes.

·       There were unsuccessful attempts to migrate to PL1 and Fortran as well as some auto-generated code tools that generated code but required debugging in Assembler.

·       I lived through the migration to C and C++.

·       We migrated from mainframes to client server architectures.

·       We were using the internet (a DARPA / University) tool before Al Gore claimed to invent it.

·       We utilized early browsers (Mosaic and Netscape) before Microsoft ruled the world.

·       We utilized early versions of IBM desktop computers and wrote (sophisticated) programs in DOS and 4GL languages (like Ramis)

·       With the advent of the iPhone, we pioneered smartphone apps and capabilities.

·       We pioneered API’s and Web Services when there were no standards.

·       Micro Services were next.

·       Migration to Cloud architecture and VM ware came next.

·       Migration to AWS and Azure followed.

·       We were early adopters of SaaS with partners like Salesforce and ServiceNow

·       We were heavy utilizers of Data Warehouses and Data Lakes and Big Data

Many transformations started well and accomplished varying degrees of success, but there were also lots of transformations that failed or were not fully successful due to factors that are widely recognized across IT organizations.

Some of those factors include:

·       Lack of Patience. Most transformations are multi-year efforts and require significant funding. The ROI can be significant too. However, there is usually some low-hanging fruit with a transformation that allows some quick ROI returns, but there is an increased amount of funding and diminishing ROI returns (or at least the ROI is over a much longer period). Organizations lose patience and redirect funding resulting in the major operational benefits never being achieved.

·       Business Processes Need to be Re-engineered and cannot be flash cut. Complex transformations require major impacts to business operations. They usually are delivered in phases due to time and risk constraints. Business operations must support different business processes as the transformation is evolving. The workarounds can be labor extensive. A flash cut (coming in on a Monday morning with new systems, processes, and wholesale re-training for the organization) is too risky with little opportunity for a fallback.

·       Organizations rarely look at integrated solutions across business units or revenue streams. Different organizations / products require different solutions resulting in poor integration across the “seams” ----- sales and service delivery for example. Because of the different solutions / technologies frequently result in out of synch conditions with core data required for the different processes. This results in fallout between processes, manual corrections, customer delays, etc.

·       Technology evolves faster than transformations complete. Lots of examples. Just recently, companies were moving from their own servers / databases to cloud providers as SaaS was replacing many business functions while AI is also being incorporated.

·       Transformations require re-skilling of technical teams as well as business operations. Re-training / re-skilling requires a significant amount of time to roll out the training as well as for the newly trained to become proficient. The re-skilling / proficiency gap becomes the throttle for how fast an organization can evolve. Bringing in new, highly skilled resources can jump start an effort, but cannot be leveraged at scale because they lack the business domain knowledge for a particular business. The speed of evolving technology only exacerbates the problem.

·       Incumbent teams / managers feel threatened by the transformation and become slow adopters. People like stability and are hesitant to change. It is human nature --- the unknown is threatening. Many transformations fail because the incumbent teams adopt slowly and managers / organizations prefer to protect their own “fiefdoms.”

·       Iterative transformation can be expensive and nobody likes to go back and re-do something that was delivered early but can be done better now.  This is common as technology itself evolves as well as when the skills of the practitioners are evolving too. The early transformations can be more costly to maintain and result in inefficiencies in the remainder of the business operations.

·       Businesses have existing software / technology that must be a factor in new transformations. Businesses may have spent tens of millions of dollars on existing hardware and software that has not been fully depreciated. Jumping onto something new may have significant financial implications for organizations or businesses financial cash flow and earnings.

·       Transformation strategies / plans need to be constantly re-assessed and evolve. The first view of a strategy / execution plan rarely endures the test of time. They evolve and need to be tweaked. Business conditions change because of business cycles, economic cycles, political changes, technological changes, etc. Change results in increased risk, higher costs, longer implementations, and a variety of other impacts. Plans need to be evolutionary to be successful.

·       Some transformations were poor strategies from the start and organizations need to recognize when to pull the plug and pivot elsewhere. The deck hands on the Titanic were not accomplishing anything useful as they were re-arranging the deck chairs while the ship was slowly sinking. Sometimes transformations become “sacred cows” for a champion who is hesitant / resistant to recognize changing conditions and is willing to pivot elsewhere.

·       Some transformations were doomed from the start because the strategy / planning effort never fully recognized the full cost the effort up front. There are transformation costs with embedded hardware / software depreciation, licenses no longer needed, re-training / skill development, proficiency evolution, business process re-engineering, business process deployment and maturation, etc. A business needs to fully understand the full scope of a transformation and have solid strategies / plans about how to address all the facets of the transformation. Too often the transformation strategy looks like a “greenhouse” type of solution that only factors in a portion of the costs and then becomes surprised by all the other factors that evolve over time ---- often sinking the whole effort.

This is not an exhaustive list.

Transformation efforts are / can be major evolutionary events in businesses. They can leapfrog a business from one level of success to another. Sometimes they are required to keep a business relevant. Many years ago, I took a training course that was taught by Willam Edwards Demming (W. Edwards Deming - Wikipedia), who was in his 90’s when he taught the class. He was a pioneer in instituting quality process and statistics into Japanese and later American business processes. He told a story about recognizing innovation and adapting to change. A company was working on ways to improve the efficiency of the steam engine (for boats, trains, etc) while others were inventing and evolving the efficiency of the internal combustion engine.

Businesses do not need to fall into that sort of evolutionary trap. There are always winners and losers in technology transformations. Being an early adopter can have a significant impact on your business competitiveness and profitability. Finding that balance of evolving with technology while accounting for the risks and pitfalls / obstacles can be the difference between success and failure.

Best to know the inhibitors to transformation in an organization and avoid them by better strategy and planning.