Best Practices for New Product Roll-Outs
Building out or improving remote delivery channels, such as online banking, mobile banking and electronic bill pay, with new products and systems represents one of the greatest opportunities a bank can face – and one of the greatest challenges, as well.
Relying too heavily on vendor expertise has meant a missed opportunity for many institutions. While vendors have a lot of insight into best practices, they typically do not offer or bring that experience to their clients unless specifically asked. Leveraging internal resources and expertise, as opposed to simply implementing new software, will help banks bridge the gaps in a vendor’s statement of work (SOW) and successfully launch these important strategic products.
When examining the vendor’s proposed SOW, it is readily apparent that this document, although negotiable, focuses on the technical side of the conversion by defining the following elements:
Scope, which sets the boundaries of the conversion by defining the specific responsibilities of the vendor and the client/bank. Once a scope is set, changing it can be an expensive proposition. Make sure the scope is broad enough to accommodate the bank’s needs.
Conversion Timeline, which defines the time it will take to complete the project, delineated by milestones/checkpoints. The vendor and the bank determine a timeline that makes sense for both parties.
Product Set-Up, which includes branding (color scheme, logos and fonts) and configuration forms. These latter items contain institution-specific variables such as routing number, core processor, bill pay provider and account types. The importance of setting up these forms properly cannot be overstated. They can wreck an implementation if filled out incorrectly. At a minimum, the testing cycle is prolonged and you find yourself with unwanted change orders.
Data Conversion. The industry standard is two mock conversions and a final “Go Live” conversion. Banks should focus on cleaning up the data that will be converted, helping to minimize data conversion exceptions. A “clean” conversion is the first step to a successful implementation.
Testing Window. The vendor generally completes initial unit testing and a round of usability testing before handing it over to the bank. Vendors, with rare exception, offer little insight into what and how extensively the bank should test the new system.
Training. A “train the trainer” format is the most common. The focus here is on what training will take place and when it will be completed (i.e., how close to the implementation date).
Implementation/Conversion Responsibilities, which represents the vendor’s plan to implement the software in the production environment at the bank. These steps will be included in the larger Conversion Playbook, forming its foundation.
Banks that rely solely on the vendor’s SOW are overlooking factors that are critical to a successful roll-out of a new product or service. Here are suggestions for additional steps to help ensure the success of a new remote delivery component:
Devise and adhere to an Internal Project Plan, which contains all the steps the bank will take to launch the new product. It should include components of the vendor’s plan where it makes sense, such as the milestones. It is important to remember that 80% of the tasks in the Internal Project Plan are not related to the technology team and any notion that these are technology projects should immediately be dispelled.
Broadcast the internal Marketing and Communication Plan. Promoting the new product to employees is critical to its success. Telling employees what is coming, when and why is important to the bank. Involve some customers in a pilot release of the product, seeking feedback prior to launch.
Trumpet customer updates. Tell customers what is coming, what to expect and what they can do to prepare, like updating their contact information. Inform them of the enhancements and why the change is positive. The earlier this is started, the better.
Spotlight business process changes. There may be processes that the new system requires that are either entirely new, or different from those encountered in the old system. These support processes have to be created, tested and trained as a part of the implementation process. These processes will be unique to the institution. Lean on the vendors for assistance here. They certainly have insight that can help.
Create/execute test scripts. Develop a detailed plan that outlines when and how to fully test the new system. Again, lean on the vendors for insight. It is doubtful that the vendor will share test scripts but they will have insight into the “gotchas” that must be thoroughly tested. The bank will likely have to create internal test scripts and internal testing plans.
Training – both internal and external – is critical. Preparing both employees and customers on items that are specific to them will make the days, weeks and months following implementation that much smoother. Train customers on any login changes, password reset processes and major functional areas. Customer training generally takes the form of mailers, online tutorials and frequently asked questions (FAQs). Train employees with a focus on support and the ability to answer FAQs.
Develop a bullet-proof Conversion Playbook. This document should outline not only the vendor’s plans, but the bank’s plan as well. The playbook generally begins a few days before conversion and ends up to a week after conversion. Issue identification and resolution procedures should be included as a part of the plan.
Mr. Daley is a senior consultant with Cornerstone Advisors, Inc., a Scottsdale, Ariz.-based consulting firm specializing in bank management, strategy and technology advisory services. He can be reached at [email protected].