Don’t Let Scope Creep Hurt Your Bank Digital Transformation Strategy

As we’ve discussed in previous entries in this series (see Part I and Part II here), build versus buy hinges on a concept of technical debt, and where you want that debt to be burdened. To this point we have focused on what can be considered “hard debt”, that is debt that can be repaid in the normal course of skills growth. There is another type of debt to consider in the build vs buy decision, and that is the idea of “soft debt”.

Soft debt is the technical debt that comes from deep experience in the business domain. The more complex or heavily regulated the business model, the more this type of debt occurs. Soft debt cannot be repaid as easily or quickly as hard debt. Think of someone who has had a long tenure at your organization and then left. The knowledge they took with them of the business, the real, inner workings of it is the “soft debt”. You cannot repay it with a class in a specific skill or by simply “doing the job. It is built on experience and “time on target” and there is no way to accelerate it.

Soft debt also deeply influences the hard debt. Rigid requirements in the business domain can result in complex and difficult solutions, creating more hard debt. This is probably the place where in-house development starts to fall apart the most.

Perceived Requirements

“Perceived requirements” is the actual terminology for “what you think the solution needs to do”. This is generally the side effect of the “I can totally build that” response. It always results in two horrible conditions for everyone involved: scope creep and feature misses.

Scope creep is the phenomena by which features are added into a project that causes the overall scope of the project to expand infinitely. It’s the “Boyle’s Law” of features that says until they hit a firm barrier, features will continue to expand.

digital transformation

Feature misses happen when there is a perceived requirement for something and the delivered feature either doesn’t fulfill the requirement, or worse, is a wasted feature. Now you have spent technical capital building a feature, which also increases your technical debt, and it isn’t even required.

By integrating with a platform versus attempting to build the entirety of the solution from scratch, the scope creep and feature miss phenomena can be reduced. The Avoka platform absolutely includes numerous functions that were put forth by our customers. It also allows customers to build additional functions that are “out of scope” for the platform. Avoka offers the customer the platform feature set that ensures a more rigid adherence to the needs of the business. It also allows the customer to “bolt on” additional features, either through integration or custom development, so that missing features can be added in seamlessly.

Actual Requirements

Building a solution from scratch is an immense undertaking and there are many steps along the road. We love this excellent diagram by Justin Baker at the Realtime API Hub3

bank digital transformation strategy

One of the strongest arguments for using a platform in any scenario is that the platform builder has already performed the first 4 steps of this process. To build our platform, Avoka was required to understand the needs, the market, the features, the regulations, and create and build multiple possible options for the platform. Fundamentally in this way, Avoka has taken most of the work out of the equation for you in terms of identifying the core business need.

There are arguments for and against doing the work on your own and there is never one right answer. The key factor is the ability to collect, maintain, and adjust business and feature requirements as your solution takes shape.

A platform accelerates that ability by removing one set of features from the consideration process. Want to learn more about how the Avoka platform can help your bank’s digital transformation? Contact us today!

Chris Harrold
Chris Harrold

Chris is the Director of Developer Programs at Avoka.