Overview
A core migration, whether you are staying with the same provider and moving to the cloud or from one provider to another, is one of the biggest endeavors a credit union or bank will undertake. These projects are often the result of years of evaluation and research. While we take a methodical approach to any project, our approach to this project demanded an extra level of diligence, management, and communication.
Execution
Phase Zero was engaged in this project roughly six months into the year-long project, in a classic “things are moving along but we are starting to feel the lack of overarching management of the initiative” scenario. This project had a non-negotiable go-live day, a holiday that the credit union was closed to members but the team historically used as a training day.
Late entry into the project and a hard go-live target drove us to apply our simplified project methodology very quickly. Within two weeks, we executed the following:
First, we cataloged all of the outstanding actions, issues, and risks for the project.
Next, we focused on enriching the items cataloged to ensure that they could be prioritized and assigned.
Once items were ready to be prioritized and assigned, we started the regular reviews with the project team and vendors to assign and schedule the prioritized items.
Once the project itself was underway, we had another fundamental challenge: limited internal resources for both the actual migration and testing.
The default EASE UAT cycle is four weeks. In those four weeks, we had to test every user, every device, and every third-party connection to the new cloud core. The work was completed through the heroics of a few team members, which was not optimal at all.
Our final challenge was managing the Go Live event. A core migration impacts every member of the credit union. This project was our first attempt to rely on real-time issue reporting through MS Teams. We had a group of leads assigned to the Teams channel to pick up issues, but the primary problem was the sheer volume of reports and the way Teams manages threads. Reports were quickly buried in the Teams channel as new issues came in, leading to much additional channel management time by the SME leads.
Overall, the project go-live was a success, and it launched on its scheduled day, but not without some pain along the way.
Lessons Learned
Extend your core migration UAT and track every facet of it. Four weeks may be the recommendation from Jack Henry; we could have used eight. Testing every person, every device (PCs, printers, signature pads, etc.), and every third party might be possible in four weeks if that is the only thing you are doing. When you have members to serve and a credit union to run, it is not nearly enough. The second part of this is tracking every test. We tried to distribute the load across CU management but were way too general with our instructions (test every person and device and get back to us), and on go-live day we realized just how many tiny things were missed along the way.
Have a multi-tiered approach to Go Live issue reporting and communication. Teams and Slack are great for real-time reporting, but the issue is the velocity that reports come in at when there are issues. Since go-live, we have moved to a form-based reporting system for issues. Reports come in through a form, get stored in a database on the back end, and Teams is used for communication from the project team outward to the CU. This has enabled us to very quickly combine duplicate issue reports and cleanly assign issues to internal resources and vendors for resolution.
If you are looking at implementing a similar system and would like to talk further about how we have managed these projects in the past, don’t hesitate to reach out to us.
We would be happy to chat.