Core-System Conversion: Dos And Don'ts

Core-system conversions are complex, intense, and fraught with customer and user problems. Allow me to call upon my 40 years of bank operations and technology experience with nearly two dozen core-application conversions to discuss what works and what doesn't.

Although my comments are in the context of banks and credit unions, they apply to any company converting its critical systems.

First, apply the basics of project management, the foremost of which is that:

Management must be involved from the start.
Success starts at the top and is evident to the troops by the depth of senior management involvement and commitment.

[ Wondering how jobs will shape up in the new year? Read 5 IT Hiring Trends In 2014. ] 

Conversion projects aren't IT driven. They're driven by the needs of the customer and the lines of business. IT has only 15% to 20% of the conversion tasks. Mapping data from one set of applications to another requires know-how from the business units. The LOBs establish the vast majority of the processes affected by systems.

Prepare detailed project plans.
It's an old but true axiom: Plan the work, work the plan. It's a bit of an art to set the right level of detail for system conversion tasks. Details set at too high a level can lead to a lack of transparency, which can hide failures until it's too late.

For example, a task such as "test deposit system" is too high-level. Where's the detail? When are we to develop test cases and scripts? When are we to assign testers? And how are we to resolve problems?

Then there's the other extreme: using project plans as a detailed checklist. The right approach seems to be describing tasks that take about five to 10 days to complete, not 20 days and not one day. Of course, milestones are often designated as one-day events.

Complementary actions include laying out a detailed conversion-weekend playbook, wherein specific tasks are listed day-by-day, hour-by-hour; tasks behind schedule are measured and monitored; and risks are identified, managed, and mitigated.

Set up function-focused (customer service, back office, finance, marketing) project teams and weekly team meetings.
Don't create more than 15 such teams. In a recent system conversion, the client insisted on having 25-plus teams, resulting in unnecessary and unproductive management coordination time and expense.

Weekly team meetings must include minutes, noting attendees, decisions made, decisions to be made, obstacles, and problems that need management resolution. The staff will object to these weekly meetings as unnecessary or an impediment to their regular activities. Nevertheless, their benefit will become evident as the conversion date looms.

In a recent conversion, we needed to build an important interface between a third-party application and the core systems. However, problems arose and a team's minutes didn't alert senior management sufficiently far in advance to require vendors to provide automated solutions. So the bank had to develop a temporary workaround until post-conversion, when the problems could be solved.

Demand accountability at all levels, not just from the team leaders.
At weekly meetings, each team lead must provide a three-minute status report (another important reason to limit the number of teams). It's sad but true: "Public floggings" of people who don't perform are effective.

Staff training is the single most crucial factor in a conversion.
You can't overemphasize staff training, especially for customer-facing functions, right up to conversion weekend.

A hallmark of good management is its ability to identify key subject-matter experts and make them trainers.
These experts then prepare training materials and conduct intensive training sessions on the different applications across the bank.

Test thoroughly.
System testing always receives initial management enthusiasm, but during the conversion process it's frequently not managed or measured. 

Each team must set up test cases and scripts; determine who's to perform the testing and sign off on it; determine which test results are accepted; and lay out the steps to remediate a problem. Each team must measure its testing progress and report it weekly.

Monitor and coordinate vendors.
A couple of vendors always require constant oversight (harassment?) to ensure they complete critical tasks.

A few years ago, an East coast client of ours was within a few weeks of changing its Internet banking provider, which had to test the files on the new system. But the current provider was lackadaisical about the conversion, requiring our client to rouse the provider's CEO out of bed one morning to get his staff to furnish the necessary files.

Take time to recognize or celebrate major milestones.
The troops need recognition, and they need to see that they're making measurable progress. Additionally, recognize the people who are working doubly hard, increasing the visibility of the project. 

Anticipate much higher call-center volumes once the new system goes live.
Banks invariably underestimate how many people they need to respond to customer inquiries.

In a conversion last year, a bank in the Northeast had contracted with its new core system vendor to handle the overflow calls, particularly those related to e-banking. The bank and vendor were so swamped that abandonment rates exceeded 25% and wait times approached 25 minutes on the first day. So the vendor had to increase call center staff by 50% on the second day. 

One credit union client of ours changed its home banking and bill pay system, requiring members to phone in to the call center to re-establish their PINs. It was overheard: "No, ma'am, I'm actually the security guard, but they asked for volunteers to answer the phones, so I'm here to help."

It's also a good idea during conversions to turn off the "estimated wait time" message customers hear. "Your estimated wait time for the next available operator is 7 hours and 52 minutes." Not good.

Test and reconfigure your voice response unit.
The VRU is the first line of defense to answer customer questions. If properly configured, it can handle up to 90% of customer calls. Consequently, during conversion weekend and immediately following, the VRU must have sufficient capacity, provide quick answers, and be easily understood by customers.

Communicate, communicate, communicate.
You can't over-communicate with customers ahead of a core system conversion. It's estimated that only 30% of customers read, let alone understand, mass mailings. Ineffective communication causes customer frustration and leads to even more calls to the customer service center.

The small stuff matters. One bank that had done an online platform conversion sent two separate letters to customers to give them new site registration information. The first letter provided the new user login in the upper right of the first page in one font size. The second letter had the password information buried and in a different font. Customers got confused.

Give employees lots of information on the new system in order to service customers.
It was overheard while the teller line went out the front door of a branch: "We had nothing to do with choosing this new system. Had they asked me, I would have told them to do it differently."

This gets back to the need for repetitive training and a consistent message.

Don't change too many things at the same time as the core system.
Wherever possible, convert ancillary applications earlier or later than the core system. A bank in the Southeast converted its general ledger and trust systems a few months in advance of conversion weekend for its transaction-oriented core systems. A bank in the upper Midwest, having decided to change item-processing vendors, converted its check processing to the new vendor about two months before conversion weekend.

Both of these approaches reduced the already-intense pressure building toward conversion weekend, while spreading the risk of one of those systems failing.

Don't introduce major product enhancements and process improvements.
For example, adding mobile banking at the same time as a core-system conversion increases risk and creates confusion, especially if it doesn’t work as advertised. Same goes for major procedural changes. Introduce such changes early on and phase them in.

In a recent conversion, management wanted to piggyback an automated balancing process on top of its new core system. While this was a worthwhile objective, it was difficult to implement during the conversion and resulted in several days of labor-intensive adjustments. If management had heeded the business unit, it would have waited until after the conversion. But the IT team wanted to push it through.

Bennett Quillen, a former CIO for a leading mutual fund processing firm, advises financial institutions on project management and technology, specializing in system evaluation, development, conversions, and security and compliance management.

IT organizations must build credibility as they cut apps, because app sprawl is often due to unmet needs. Also in the App Consolidation issue of InformationWeek: To seize web and mobile opportunities, agile delivery is a given. (Free registration required.)