Rapidly Adopting Emerging Technology? Not so Fast…

Corporate business stakeholders are frequently motivated to rapidly adopt #emergingtechnologies, typically driven by a combination of hype hypnosis, inflated expectations, and general fear of missing out. In some cases, the aspirations of improved efficiency, better performance, and enhanced customer experience are actually exceeded by the fear of falling behind competitors who have leapt to adopt those technologies even faster.

However, time and experience has shown that inadequately prepared organizational infrastructure, lack of awareness of the #datarequirements, and a general misunderstanding of how the technology needs to be integrated with business processes will impede the monetization of these innovations. Often, the urge to adopt the technology overcomes the process of identifying the business problems that can be addressed, how the technology can contribute to solving the problem, how individual roles evolve in light of the adopted technology, and what business processes need to be changed to make it successful. The result is that funds are expended, and effort is exerted in implementing a product that then sits idly, consuming resources until someone figures out how to best use it. Alternatively, the product gathers virtual dust while it takes years for the key personnel to realize that the investments made in adoption are never going to pay off.

Here is a (sanitized) example. In the mid 2010s, when #Hadoop was the hot technology du jour, one of our clients announced that they were abandoning their on-premises enterprise data warehouse and replacing it with Hadoop. When I asked what they meant by “replacing it with Hadoop,” they told me that they were extracting all the data from the data warehouse and moving that data into an HDFS (Hadoop Distributed File System) repository managed in a massive on-premises storage cluster (with an appropriately immense price tag). I probed a bit more, asking questions like:

• How much effort was it going to be to move all the data?
• How are the business users going to be supported when binging in new data sources?
• How were they planning to migrate all their existing reports?
• What type of analyses were they planning to do that could only be done using Hadoop?
• Did they have staff with the appropriate skill sets to do development in the Hadoop environment?

I was assured they had answers to all these questions. When I caught up with the client about 2 years later, though, he told me that the Hadoop transition was a complete bust. They grappled with the challenges of migrating the data, their hardware requirements were higher than before, they struggled to support the existing business information users, and the analyses they actually did manage to port to the new environment ran at the same speed or slower than on the original data warehouse. He told me they ditched the Hadoop system and went back to their original data warehouse configuration.

This operational failure was not a condemnation of the technology – at the time, Hadoop was the right solution for lots of big data analytics challenges. But the organizations that successfully adopted Hadoop did so by determining the best way to exploit Hadoop’s capabilities. Just buying the hard and installing the software was not a solution – it was a means without an end.

Needless to say, the same issues are going to spring up with this year’s model. The media hype about Generative AI, Large Language Models, and applications deployed on top of those technologies is reminiscent of the same hype cycles preceding prior shiny new objects promoted in the technology media. So what are the right ways to adopt emergent technology such as #GenerativeAI and #LargeLanguageModels? Here are some steps to take:

• Step 1: Baseline the Technology. Adopting a technology that you don’t understand will lead to situations in which your teams cannot determine whether it is doing what you want it to do.  Get a baseline understanding of the technology by researching what the technology does and how the technology works. You don’t need to become an expert, but having a fundamental awareness of the technology’s strengths and weaknesses will better prepare your organization for adoption. Also: become cognizant of the skill sets that are necessary to be able to integrate, operationalize, deploy, and maintain the technology.
• Step 2: Survey Opportunities. Survey the business landscape for business processes that can be improved or business problems that need to be solved that might be addressed by the technology. Don’t be limited to existing business issues, since the emergence of a new technology might enable situations that were untenable before. Use a scenario planning approach that considers how the business processes would change if the new technology were to be in place and did what it is promoted to do. As part of this exercise, consider the potential lift that could be delivered through adopting the technology. Once you have a list of opportunities, score them based on variables such as cost, time to value, and lift and identify the highest priorities.
• Step 3: Prototype Architecture. Technology adoption is not executed in a vacuum. Review technical platform and software dependencies and draft a technology stack that would be required for implementation. Examine what platform, software, storage, and other resources that are needed, and map out a plan for how the technology is to be integrated into the environment. And remember the sociotechnical constraints – look at how the business processes would change, and what additional training is needed for the people involved.
• Step 4: Execute a Proof of Concept. The proof of concept, or POC, is often misunderstood. In many cases a POC is used to show that a technology can be implemented, or to show some default examples of what the technology does. This approach, often driven by a technology vendor or service provider, ultimately is inadequate because it focuses attention on functional operation rather than alignment with business objectives. Instead, the goal of the POC is to demonstrate that your organization’s perceptions of the technology’s value are validated within a constrained yet relevant example. At the same time the POC can be used to identify any potential issues that would complicate a full-scale adoption.
• Step 5: Evaluate and Decide. There are three choices you might make after evaluating the results of the POC. A “Go” decision means you are moving forward with the adoption. A “No-go” decision means that the POC’s results did not warrant adoption of the technology, which means that you are now done. The third alternative is that more information is required to make that decision. Either continue the proof of concept to gather additional results, or devise and launch a second POC.
• Step 6: Program and Project Planning. If the decision is to move forward, take the time to do a program plan that maps out the different projects needed for development, implementation, testing, and ongoing management. That should result in a managed approach to adoption that is aligned with defined success criteria.

Taking these steps will help in adopting emergent technologies in a way that has a greater potential for success. At the same time, these tactics allow for an “off-ramp” from the adoption process should there be a point where the anticipated value no longer is justified by the resource and time investments.