Why do customers rebuild the same business process with new technologies?
More than 80% of the customers we have spoken to about their completed projects say that they have received less than 75% of their initial vision at the end of the first project. Almost 25% say that they received 50% or less. Yet, more than 90% say that the project was worth the money they spent. Why?
The answer lies in something I call the "Business Transformation Paradox". The paradox is the explanation for why the initial intent of a project is rarely achieved in full yet does not erase the perceived value of the project. In summary, the paradox is simply that a customer cannot both buy a new technology and build a new business process without having to regress, in part, to implementing the old process. Hence, this paradox only exists when the customer is attempting to build a new "to be" model in the hopes of replacing an existing "as is" model with a technology they have not used before. At best, this regression is only slight, but in many cases, it can be a substantial part of the overall new solution the project is attempting to implement.
Customers purchase new technologies in the belief that it will provide them with a new and more advanced operating process. This creates a new "to be" dream model that excites the customer's organization. However, with this new product, comes a new set of building blocks which need to be understood in order to effectively build the "to be" operational workflow. Without understanding the new building blocks, there is little hope of designing and agreeing this new process effectively.
While the customer may attempt to complete product training to gain knowledge, this training is rarely taught in the context of the customer's existing process. At best, this lack of understanding makes it almost impossible for the customer to accept with clarity the design that is eventually presented to them. At its worst, the fear of changing to something that is not understood causes the customer to demand that the old process be retained.
The Business Transformation Paradox means that when deploying a new technology, it is not possible for a customer to achieve 100% of its "to be" vision unless it understands how that technology would have been used to deploy its current "as is" process.
Obviously, most projects achieve some of their initial vision, but our guess is that most enterprise projects achieve somewhere in the range of about 75% or less. The rest of the initial "to be" is lost to this paradox in combination with the other age-old project conundrum of balancing project budget and scope.
The "ideal" project methodology for business transformation projects attempts to avoid the paradox by conducting a full investigation of the new "to be" model in comparison with the "as is" model. The Analysis phase is intended to help the customer understand the consequences of using the new technology before the project swings into implementation mode. However, these kinds of projects have become rare even for large enterprises.
In other words, customers tend to cannibalize the "analysis budget" by using it as "execution budget". To be fair, I can see how this makes sense if placed in that position. Given the nature of budgets and their limited availability, we are more inclined to maximize execution because we want to get stuff done. But when we do, we must also accept that we are driving ourselves into the New Business Transformation Paradox.
Can we avoid the Business Transformation Paradox? Yes. The paradox is not present when using a known technology to build a new "to be" (a subsequent phase project) or by using a new technology to rebuild the "as is" (a technology swap). However, most projects are trying to achieve business transformation which necessitate the use of a new technology to create a new process.
So, can we resolve the paradox when it is present in a business transformation? While not wanting to turn his article into a guidebook, I can summarize three approaches that might help.
1. Proactive Consulting
The first, is to continue doing what we already teach. Encourage consultants to be more prescriptive when they provide customers with solutions. This means not allowing the customer to simply back away from the "to be" model without understanding what they are giving up by rebuilding the "as is" or understanding the long-term cost of using the new technology in old ways. This means that as we deliver a project, we must ensure that our knowledge of how the new technology might be able to work for the customer is brought to the fore and that we do not back down from our own recommendations without some kind of prescriptive escalation.
2. "As Is" Demonstration
The second approach is to alter the methodology to include a partial rebuild or demonstration of the existing process in the new technology as a way of giving the customer context. While a Proof of Concept ("PoC") shows how a technology might build the "to be" model, it only does so through a partial lens. This idea would shift the process so that the customer could learn the new product's capabilities within their current understanding of their "as is" model. After accumulating this knowledge, they would be in a much better position to start using the product's strengths to design and build the "to be".
This would only be a viable approach if the exchange of extra effort of building a non-production version of the "as is" was worth the project's increased chances of achieving more of the "to be". In both this and the first suggestion, it requires both the customer and service provider to be more open to changing the traditional way in which projects work.
3. Technology Swap
In some instances, focusing on a complete rebuild of the current "As Is" with the new technology (a technology swap) is a viable option. This already occurs in some projects and while many people might think it is a waste to not get anything new from the project, it does provide the most effective way of having the organization wrap its mind around what it could do with the tool in a phase two. The caveat to this approach, however, is that there must be an assurance that rebuilding the "as is" process in the new technology won't create an instability in the supportability or stability of the final solution. We typically find that many new technologies that have an improved architecture can find it difficult to account for old "as is" processes.
Until then, expect that projects that set out to achieve the full "to be" will actually achieve somewhere between fifty and seventy-five percent of it. By using traditional means, you may be able to mitigate the effects of this paradox on your project, but you will be unlikely to avoid it unless you are willing to increase budgets or change the way you look at the solution development process. It is helpful to understand that this paradox doesn't make a project unsuccessful. Nor should you scale back your project's "to be" vision. It just means that you should not define a project's success solely by its ability to achieve 100% of its "to be" vision and expect that during the process, it is ok if you need to regress a little.