Four paths for implementing a major fintech project
You're tasked with implementing major fintech in your firm, the kind that has the potential to transform your business, but you’re worried about adoption. Pull it off and you're a hero. Fail and you're a goat.
What do you do? We don’t hold ourselves out as experts on change management, but we can share what we’ve learned from how our clients have gone about implementing potentially game-changing fintech.
Basically, we’ve seen four approaches, which we’ll call:
- See If They Like It
- See if They Like It (a Service)
- Just Do It
- Launch a New Business Line
Here’s a description of each, with our take on pros and cons:
See If They Like It
Basic idea: release the product and see if users within your firm like it. Ideally, the merits will be obvious and adoption will take care of itself.
This is the path that minimizes conflict, since no one is forced to do anything. It can be useful as a real-world pilot, but it’s not a permanent solution. With very few exceptions, there will always be holdouts who don’t adopt new technology. Ultimately, successful implementation will still require the expenditure of management’s mindshare and “political capital.”
- Lower risk: No old systems are removed, so if the implementation goes wrong or the product doesn’t work right, you can always revert to the old way of doing things.
- Opportunity to learn: The rollout can be viewed as a type of pilot that can expose hidden strengths and weaknesses of the application.
- Low demands on management: No one is forced to change. Management is not required to expend political capital.
- Proliferation of systems: If the previous system is not retired, you have twice as many systems to maintain.
- Inconsistent client experience: Having multiple system choices will likely lead to your firm providing an inconsistent client experience.
- Delay: Ultimate rollout, and achievement of the objective of implementing the new tech, is delayed.
See If They Like It (a Service)
Basic idea: create an internal service bureau around the new software. That is, don’t offer the software, offer what the software can do. Users don’t need to adopt the technology. They just need to use the service.
The service bureau can be staffed by specialists and architected to extract maximum value from the new technology. A service bureau can both serve as a demonstration project and may also simply be the best way to deploy the technology. For example, with our system, a service bureau would take the form of a central rebalancing group that rebalances on behalf of the client-facing advisor.
This is a variant of the “See If They LIke It” approach. No one is forced to use the new service—it’s just offered as a convenience. And like the “See if They Like It” approach, it’s a temporary strategy that leads either to a decision to discontinue the service or mandate total adoption.
Creating a service bureau is not suitable for all technology. It’s not obvious that any system that supports real-time interaction with clients—CRM, proposal, planning, etc.—could usefully be implemented as a service.
- Lower risk
- Opportunity to learn
- Low demands on management
- Greater efficiency: Centralized teams can become experts at using new software more quickly than users in the field.
- Proliferation of systems: If use of the service bureau is optional, you still need to maintain the user-in-the-field tool set.
- Inconsistent client experience
- Delay: An optional service is not likely to lead to 100% adoption. Ultimate rollout, and achievement of the objective of implementing the new tech, is delayed.
Just Do It
Basic idea: Adoption, either of the software or a service bureau that uses the software, is mandatory. You rip out the old system and install the new one.
The hope is that, like pulling off a bandaid, the pain is minimized if you do it quickly. When decisions are spread out over time, they tend to get revisited and “re-litigated.” It can encourage “factions” and ultimately end up causing more strife than focused one-time transitions and requiring more, not less, management involvement.
This is the path for firms that know where they want to go and are willing to commit the political capital to make the changes happen. It has been successful everywhere we’ve seen it applied. Notably, it has required less total management engagement than alternate, incremental approaches. While this is an encouraging track record, we would not conclude that it’s necessarily the right approach for everyone. It’s possible that the organizations that tried this were precisely the ones—due to culture, personality or size—where it was most likely to work.
- Higher observed success rate: It has worked everywhere we’ve seen it applied.
- Lower overall effort: The decision is made, implemented—and then it’s done.
- Streamlined operations: There is no need for IT to maintain two systems.
- Greater downside: If the implementation goes badly, there’s no fallback.
- High short-term demands on management: There is likely to be some pushback on decisions of this sort. This will require greater immediate effort from management. As one executive very colorfully phrased it, “you may need to leave one or two dead bodies in the hallway. But then it’s easy.”
Launch a New Business Line
Basic idea: Start a new business line from the ground up to take maximum advantage of the new technology, e.g. a robo advisor.
“Retrofitting” new technology into existing operations is hard. The natural tendency of organizations is to try to use the new tech to do things the way they were done before, just a little faster. This is easier but less effective than adapting operations to take advantage of the new technology. Manufacturing robots are a classic example. Just installing them on an existing factory floor typically results in little gain. To really take maximum advantage of the power of robotic assembly, both the product and the assembly line should be designed from the ground up.
With the pitfalls of retrofitting in mind, some firms are launching entirely new “clean slate” business lines. Everything from the client experience to the delivery model are reengineered from the ground up. New “robo advisor” offerings are the most prominent example. In most cases, the name “robo advisors” is a misnomer. A better, if more prosaic, name would be “fully-fintech-enabled advisors.” Most of the new “robo” offerings we see from large players aren’t actually robo. Human advisors are still there, just deployed differently. In particular, they’re no longer doing things that machines can do better, like rebalancing. Instead, they’re focusing on financial planning and answering questions.
- Maximum use of the power of new fintech
- Less disruption of existing operations
- Opportunity to learn: The new business line can serve as a model for the future transformation of existing business lines.
- Proliferation of systems: The new business line will have an entirely new tech stack.
- Doesn’t improve existing operations
- New business line may fail: It’s a new business line. Unless there’s a plan to transfer AUM from existing business lines, it’s hard to build businesses from scratch.
Which approach is right for you?
We doubt there’s one best answer here. There are many good reasons to take things slowly — pushing change too fast can backfire. But proceeding too cautiously has its own dangers — eventually, it may be too late to catch up with competitors.
Looking at the experience of our clients, we see maximum success with decisive conversions (“Just Do It”) and new business initiatives (“Create a New Business Line”). But we are cautious in simply concluding these are the best options. No two of our clients are identical. By and large, those who have chosen to “Just Do It” are the ones whose organizations were already fairly hierarchical—or whose circumstances required decisive action. Here’s the rub: Ultimately, all firms will be required to take decisive action—and face head-on the complexity of change management.
We are not change management consultants, but we are very interested in how firms go about changing their organizations. Let us know your experiences. What’s worked for you? What hasn’t? If there’s sufficient interest, we’ll follow up in a subsequent post.
For more on this topic, check out What is Rebalancing Automation?