Financial institution strategies for smooth technology change management

As technology advances, sometimes critical proprietary and third-party technology becomes obsolete and new technology is needed.

Unfortunately, the change isn’t identified as necessary in a timely manner, defined properly, or communicated well. This isn’t due to a lack of effort; these projects are hard. Technology changes often and technology projects are usually time-consuming and expensive. Even when the technology is implemented, the organization can face a lot of resistance from employees and customers if they are not properly involved throughout the change process.

To effectively manage technology change, financial services organizations need to set up strong policies and procedures that cover each stage of the process to mitigate the risk of failure. These policies and procedures should cover several steps, including deciding if new technology is needed, determining the resources required to make the change, establishing clear goals, building an implementation team, defining strategy, testing and implementation, managing resistance, and making improvements.

Recommended technology change policies and procedures

Annual budgeting process: Technology projects tend to be expensive. Is there a clear consistent financial planning process that the Technology owners participate in and can easily propose technology change expenses and revenue impacts be included into the budget? Does the budgeting process account for the increased risk and or costs of not change technology?

Off budget-planning expense justification: Unfortunately, not all technology changes happen at convenient times. Is there a clear method for proposing off-budget cycle technology expenses? Is the cost/benefit evaluation process formalized?

Capital project planning: Fortunately, certain technology changes, like client-facing software customization, testing and development can be capitalized expenses, and recognized on a balance sheet overtime once the technology is released to clients. A clear policy on when expenses can or cannot be capitalized can help expedite technology change.

Technology project charter: This provides a high-level overview of the project, its goals and benefits to the organization, estimated expenses, project roles and responsibilities and the estimated schedule from ideation to implementation.

Vendor management policy: This policy should include principles for performing due diligence procedures and determine what is the best path for the organization to meet its strategic goals, utilizing third parties.

Audit: The policy addresses principles necessary in testing laws, strategic goals and other critical components of an organization’s core control system.

Cybersecurity policy: This is a key issue that often necessitates technology changes. The policy should provide guidance on how to identify and mitigate the growing number of cyber threats/risks institutions are faced with, especially with the inherent risk of having and utilizing new and old technology. It should also help quantify the costs of not addressing risks

Artificial intelligence (AI) policy: Policies that can guide decisions related to emerging technologies, specifically how they should and should not be applied based on the organization’s goals and risk appetite, are vital to your overall approach.

Determining if new technology is needed

Many times, a small group or an individual may decide there is a need for new technology, but change can’t come solely on their beliefs. In some cases, a critical third-party app may become obsolete or lose support which necessitates the need for a new solution. In cases of voluntary change though, there needs to be a legitimate business case for adopting new technology.

To properly determine such a shift, financial services organizations need to have clearly agreed upon triggers to require technology change planning. When reviewing new solutions against current technology, several factors should be considered to determine if change is necessary including, but not limited to:

• Age or lifespan of the current solution
• Whether and how business requirements have changed
• Build vs. buy analysis
• Quality of vendor technology and company operations (financial stability, growth, support)
• Operational impact
• Talent requirements
• Implementation, integration, and maintenance costs, integration costs
• User learning curve

Other important factors that can help drive a business case to consider include:

• Documenting and communicating the risks of not migrating to a new technology in a timely manner
• Documenting and communicating the costs of customizations and the implications of updates and migrations
• In cases of voluntary technology change, KPIs should be reviewed to evaluate the effectiveness of the current solution and should be measured against the potential results the new technology can provide

Once criteria are established for determining change, companies should establish who decides if new technology is required to identify. The group requesting the change works with the decision makers to thoroughly review the criteria to determine if there is a viable business case.

Build an implementation team

Once the request for new technology is approved, an implementation team needs to be established. Leadership should not be the only group of people associated with tech change. It is crucial to add seniority and diversity across an implementation team to provide perspective across several types of user groups.

Representatives from all departments affected by the change should be on the team and should include people at various levels within the department for accurate feedback on how it will be used and to secure stakeholder buy-in.

Establish clear goals

Once the bid for new technology is approved and an implementation team is established, it is crucial for clear goals to be established. There needs to be a plan in place on how technology will be tested and selected, creating and timelining milestones during implementation, and reviewing performance to identify areas of improvement. To establish these goals, the implementation team needs to ask and answer several key questions including:

• What problem are we trying to solve?
• Who does it affect?
• Why is it worth solving? (data helps here)
• How the problem can be solved? Why is your proposed solution better than alternatives?
• What resources are required to build/buy/license as well as implement and support the solution?
• How can the plan be clearly and regularly communicated with all appropriate parties throughout the process?

Define your strategy

After goals are established, the next step is coming up with a testing and implementation strategy. When technology is adopted, review periods should be set up to discuss market trends, sunset notices and to prepare for technology change. Technology projects are often expensive, and the review of certain software should consider the organization’s budgetary planning schedules.

Once these tasks are finalized, the implementation team needs to timeline the stages of the tech change process, which should include:

• Creating criteria to source and test new technology

• Setting deadline dates for data migration (if applicable), testing, editing and launching
• Addressing any blockers or potential concerns and baking them into the project timeline

Testing and implementation

Before moving forward with a solution, testing is also needed on the path to validate the change. Criteria should be set during the strategy phase, and before full purchase, to determine what the best solution for the company and all its stakeholders will be. To properly validate if either a third-party or proprietary solution makes sense before buying and implementing, organizations should take the following steps to ensure it will work:

• Set up a sandbox environment to review functionality of the solution without compromising tech and processes already in place
• Create functionality milestones with deadlines for a full-picture test before buying

Once a solution is deemed viable, plans and timelines should be created to manage the implementation process so all stakeholders understand change is coming and have a pulse on how it will be rolled out.

Regular communication should be provided to all stakeholders during the implementation process so that they have a chance to be active participants, which can also help minimize resistance.

Managing resistance

End users might be hesitant to change, so it is important to include them in as many steps of the change management process as possible to help them understand why it is necessary and get them used to the change. To simplify the transition, implementation teams need to realize communication is key.

Make sure that proposed dates for change are communicated, likely with reminders, and include documentation explaining what the change is and why it is happening. If stakeholders believe their voices are being heard, they should be more receptive to changes and training/educating them on the new platform should also be easier. This may include the ability to vote on a particular software solution, suggesting or helping manage implementation, etc.

There are two main groups to focus on:

• For internal resistance (employees), ample training resources should be provided as well as incentives for being an early adopter of the new technology to help them get on board.
• For external resistance (customers), helping them understand the change through videos, interactive guides, demos, etc. can help them manage the change better and get up to speed quicker. It can also be helpful to engage a handful of early adopter customers to offer feedback on prototypes and serve as beta users. Those contributions transform customers from passive recipients to partial process owners and evangelizers.

Making improvements

Once new technology is implemented, the job is not done. Organizations must constantly monitor feedback and KPIs to make sure the change is achieving desired results. To do this, it is important to collect regular feedback from internal and external sources. This crucial step can help make tech change as effective as possible.

For sure, not everything can be learned from testing, so paying attention to how people use new technology and listening to their suggestions can provide invaluable feedback that is still timely to the early days of implementation. If new KPIs are needed to measure performance, they should be determined during the planning phase so they can be measured as soon as the new technology goes live.

Lifecycle tracking

As time goes on, needs might change, which could lead to required tweaks. This might result from the technology itself changing or differences in how staff members actually use the technology (shifting best practices and regulatory updates can force this change). Organizations may shift the level of support they grant this technology over its lifetime as well as other initiatives require attention.

Banks and credit unions are likely to find that a smart end-to-end policy manager solution, which helps automate workflows, log policies, and update and track internal and external communications, among other features, is a must during technology management change.

Do you have the right policy manager in place?

In looking for a policy manager to help your financial enterprise meet customer needs, regulatory requirements and more, consider offerings that include these features:

• Industry-specific regulatory resources such as regulatory alerts (CFPB changes, FDIC updates, NCUA rules, etc.), policy considerations, policy templates and regulation overviews
• Powerful communication tools that help you communicate policies and procedure effectively, including a centralized repository, full text search, acknowledgement tracking, quizzes and more
• Focused processes to help compliance professionals make timely updates and collect acknowledgements by utilizing managerial and user dashboards, report subscriptions and automated reminder emails
• Easy setup and administration to ensure your organization can quickly start managing policies and procedures effectively through bulk data importing, a human resources information system (HRIS), and configurable and reusable workflows.

Christopher Boersma, CRCM, CAMS, CISA, CC, is Product Manager, Compliance at BAI.

Read more on the BAI Policy Manager.