by Patric Roth
Senior Manager
July, 2019
These practical tips could help a bank shorten implementation timelines and ensure it can always choose the most up-to-date software, speeding up and ultimately increasing its return on investment, writes Patric Roth
Time is money and in business, there is often pressure on both. We see this repeatedly in implementation projects, where banks have made the decision to bring in a new platform and want it up and running as fast as possible, so they can start reaping the benefits.
Implementation projects are complex by nature; for complex read lengthy. Often the duration of a project can increase with little justification or reason. However, there are several ways to fast-track them when time is at a premium.
Two keys to speeding up projects are 1) making sure that the in-house teams are fully engaged and 2) that the right people – be they the implementation partners or the in-house project managers – are empowered to make decisions.
Engagement from in-house staff who really know the legacy system will help with knowledge sharing and shorten the analysis phase. When they’re on board and keen to see what the new technology will bring, they’re more willing to provide the right information at the right time. They’re the ones who know where data is stored, what it’s made of and any shortfalls in its current format, for example. The status of all these crucial elements will have an impact on the project further down the line. Being informed up–front allows project managers, who understand the target solution’s requirements, to plan accordingly.
At the same time, it’s important to give project leaders the power to make decisions. There are inevitable compromises to be made and decision-makers have to understand what’s at stake and act on behalf of the whole organisation, making decisions that will be respected, accepted and enforced.
Engagement and empowerment flow from senior management. If they pass down the right messages, both should follow.
A bank that can implement new technology or digital solutions as close as possible to the standard configuration will save time. Inevitably adaptations will need to be made, but keeping them to a minimum reduces the complexity of a project.
On the same note, if the out-of-the box software offers 20 features and the bank only needs 15, it will be necessary to configure the permission frameworks to ensure that the redundant five are kept unavailable to the end users. This saves on documentation and processing, speeding up completion through scope protection and effective stakeholder management.
It’s also important to understand that banking technology and its competitive landscape are evolving fast. There’s no need to decide on all the features and apps at the start of an implementation, but rather to take a phased and iterative approach.
By waiting, not only can those involved in the implementation focus on getting the core right, but the bank can also see what solutions and apps emerge in the meantime and select the best one according to where its competitors are and what its customers need. This avoids discovering upon go–live that 30 per cent of the functionality has been superseded by new technology, or that a competitor has an unassailable market lead.
Banks often look at implementation projects as opportunities to embrace change on several areas of the business. With substantial change already in the pipeline, the inclination is to do everything at once. Banks should resist this sweeping change approach if the project is a pure migration project, in opposition to a business transformation project.
Implementations and migrations are complex enough when moving the same business from one system to another. Creating, testing and implementing new scope demands new processes, new documentation, new relationships and new contracts, among other things. All that takes time and usually throws up unexpected delays. Keep it simple.
That’s not to say that further change can’t be planned for. It makes sense to phase change so that the business–critical objectives are met first with nice-to-have objectives scheduled down the line. This ensures the bank sees a return on investment faster than trying to do everything at once.
A project will likely never hit aggressive timelines without the right tools and service agreements already in place. This includes having as short of a feedback loop as possible during the testing phase – waiting 72 or even 48 hours before new code or processes can be tested is too long. It also makes sense to take advantage of night-time testing, when the bank’s systems are less busy, and to automate as many testing and integration processes as possible to increase time efficiency. Therefore a 12 hours feedback loop would be best suited to achieving these goals.
By following these tips, implementation projects could be carried out faster. It’s an agile way of working that not only delivers IT efficiently but allows the bank to see a return on its investment sooner.
