These practical tips could help a bank shorten implementation timelines and ensure itcan always choosethe 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 bankshave made the decision to bring in a new platform and want it up and running as fast as possible, so they can startreaping 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 themwhen time is at a premium.
Engagement and empowerment
Two keys to speeding up projectsare 1) making sure that the in-house teams are fully engaged and 2) that the right people – be theythe 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 onboard andkeen 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 tounderstand what’s at stake and act on behalf of the whole organisation, making decisionsthat will berespected,accepted and enforced.
Engagement and empowerment flow from senior management. If they pass down the right messages, both should follow.
Rational technical choices
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 aproject.
On the same note, if the out-of-the box software offers 20 features and the bank only needs 15, it will be necessary toconfigure the permission frameworks to ensure that the redundant five are kept unavailable to the end users. This saves on documentation and processing, speeding up completionthrough scope protection and effective stakeholder management.
It’s also important tounderstand 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 embracechange 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 approachif the project is a pure migration project, in opposition to a business transformation project.
Implementations and migrations are complex enough when moving the samebusiness 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 toautomate as many testing and integration processes as possible to increase time efficiency.Therefore a 12 hours feedback loop would bebest 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.
Patric Rothis senior manager at Orbium, based in Australia