Build Versus Buy Considerations for Data Analytics Projects

It is the age-old question: buy versus build? How do you know which is the best approach for your institution?

For years, bankers have known their data is a significant untapped asset, but lacked the resources or guidance to solve their data challenges. The COVID-19 pandemic made it increasingly apparent that outdated methods of distributing reports and information do not work well in a remote work environment.

As a former banker who has made the recent transition to a software-as a-service company, my answer today differs greatly from the one I would have provided five years ago. I’ve grown in my understanding of the benefits, challenges, roadblocks and costs associated with building a data analytics solution.

How will you solve the data conundrum? Some bank leaders are looking to their IT department while other executives are seeking fintech for a solution. If data analytics is on your strategic roadmap, here are some insights that could aid in your decision-making. A good place to start this decision journey is with a business case analysis that considers:

• What does the bank want to achieve or solve?
• Who are the users of the information?
• Who is currently creating reports, charts and graphs in the institution today? Is this a siloed activity?
• What is the timeline for the project?
• How much will this initiative cost?
• How unique are the bank’s needs and issues to solve?

Assessing how much time is spent creating meaningful reports and whether that is the best use of a specific employee’s time is critical to the evaluation. In many cases, highly compensated individuals spend hours creating reports and dashboards, leaving them with little time for analyzing the information and acting on the conclusions from the reports. In institutions where this reporting is done in silos across multiple departments and business units, a single source of truth is often a primary motivator for expanding data capabilities.

Prebuilt tools typically offer banks a faster deployment time, yielding a quicker readiness for use in the bank’s data strategy, along with a lower upfront cost compared to hiring developers. Vendors often employ specialized technical resources, minimizing ongoing system administration and eliminating internal turnover risk that can plague “in house” development. Many of these providers use secure cloud technology that is faster and cheaper, and takes responsibility for integration issues.

Purchased software is updated regularly with ongoing maintenance, functionality and new features to remain competitive, using feedback and experiences gained from working with institutions of varying size and complexity. Engaging a vendor can also free up the internal team’s resources so they can focus on the data use strategy and analyzing data following implementation. Purchased solutions typically promotes accessibility throughout the institution, allowing for broad usage.

But selecting the criteria is a critical and potentially time-consuming endeavor. Vendors may also offer limited customization options and pose potential for integration issues. Additionally, time-based subscriptions and licenses may experience cost growth over time; pricing based on users could make adoption across the institution more costly, lessening the overall effectiveness.

Building a data analytics tool offers the ability to customize and prioritize development efforts based on a bank’s specific needs; controllable data security, depending on what tools the bank uses for the build and warehousing; and a more readily modifiable budget.

But software development is not your bank’s core business. Building a solution could incur significant upfront and ongoing cost to develop; purchased tools appear to have a large price tag, but building a tool incurs often-overlooked costs like the cost of internal subject matter experts to guide development efforts, ongoing maintenance costs and the unknowns associated with software development. These projects may require business intelligence and software development expertise, which can carry turnover risk if institutional knowledge leaves the bank.

Projects of this magnitude require continuous engagement from management subject matter experts. Bankers needed to provide the vision and banking content for the product — diverting management’s focus from other responsibilities. This can have a negative impact on company productivity.

Additionally, “in-house” created tools tend to continue to operate in data silos whereby the tool is accessible only to data team. Ongoing development and releases may be difficult for an internal team to manage, given their limited time and resources along with changing business priorities and staff turnover.

The question remains: Do you have the bandwidth and talent at your bank to take on a build project? These projects typically take longer than expected, experience budget overruns and often do not result in the desired business result. Your bank will need to make the choice that is best for your institution.