The process of implementing a new system constitutes a major investment in time and resources. If done right, the investment can pay significant dividends and position an organization for long-term success. However, the “shiny” new system capabilities are often distracting and institutions can overlook the critical factors that must be considered to meet the strategic needs of the business. The most common mistake organizations make is moving too quickly to select a platform based upon functionality seen up-front without carefully defining and prioritizing the business needs and downstream/upstream impacts. This mistake can be further exacerbated by handing off the project to an external technology vendor or internal IT for execution with limited direct business involvement—business needs and objectives are subsequently lost in translation resulting in a less-than-optimal solution for both technology and business partners. We have seen many instances where the requirements were explicitly met, but the business need was still missed. This article provides key considerations and best practices that should be addressed when selecting and implementing new banking systems.

Getting Started: Defining the Needs and Objectives

We have found that all organizations should start by formally documenting and prioritizing the business needs and objectives, obtaining agreement from all stakeholders. While this may seem like a foundational step, given the attention to detail and care required to get a large project right, a formal document containing the “single version of the truth” should not be overlooked. Having various constituents unknowingly following different priorities is a common occurrence that can often become a recipe for failure. 

“ Formal documentation of business needs ultimately leads to creation of an inventory of business needs–prioritized based upon their impact to the desired business outcomes.”    

The first step in this process is gaining an understanding of the overall business need, which is different from the business requirements. Business need can be defined as what the business must have (i.e., capabilities) to achieve strategic objectives. Formal documentation of business needs ultimately leads to creation of an inventory of business needs–prioritized based upon their impact to the desired business outcomes. The inventory should also contain all of the required business changes that must accompany the technology deployment in order to achieve the stated business need (e.g. X capability is implemented, and Y process changes). Understanding the change associated with new capabilities helps organizations understand the downstream impact and enables more effective design and decision-making up front.

Detailed business requirements to define what is “required of the system” can now be created. These requirements will need to be evaluated at various points in the process against the business needs inventory to validate that no major gaps exist between the overall business needs and objectives of implementing the system. This forms an important hierarchy of documentation that should be developed and maintained from the early stages of the selection process which can be universally applied to all development methodologies.

Keeping Business Needs in Sight and Minimizing Execution Risk

To minimize execution risk, gap analyses of business requirements should be conducted throughout development and prior to finalization against the business needs inventory to validate that all desired needs will be met if the requirements are satisfied. To conduct effective gap analyses, consider the following elements:

  • SME (subject matter expert) availability to review detailed requirements against need; ensure complete coverage by using someone from the business rather than technology or an external vendor
  • Inclusion of internal, external, or cross-functional constraints that may exist in meeting the business need (e.g. does the system satisfy the need, but, constraints mitigate the effectiveness?)
  • Accountability of all reviewers to “own” the effectiveness of the gap analyses

Upon confirmation that requirements are met, the process is still not finished. As the internal and external IT teams move into the technical design, build, and test phases, it remains critical that all stakeholders remain engaged to confirm that the final detailed business requirements and business needs are satisfied. The business should not move on from the project, leaving execution solely with technology, but instead remain engaged with the same resources who were involved up front. We have found that establishing a dedicated “interpreter” role with specific business expertise to sit between the business and IT in addition to a traditional Business Analyst can help ensure these gaps do not form. Proper “toll-gating” via sound project management discipline is encouraged to further ensure accountability and minimize execution risk.

In our experience, this emphasis on ensuring that business needs and objectives are met throughout any technology project is a key best practice that is far-too-frequently overlooked.