Known failures in buying Capital Markets software packages

The pace of change in capital markets area has never been higher. Profit margins are under pressure and institutions are seeking ways of lowering their costs. The 2 main drivers behind the increased demand for change is regulation and digitalization.

By Lars Christiansen, Partner | 20 September 2016

The current state of affairs

The massive amount of post financial crisis regulation, forced upon the market participants by the lawmakers has increased capital requirements, reduced the available product range, and established an unprecedented demand for data transparency across all client types and asset classes.

The prevalence of price engines and the internet based trading venues (ECNs) has initialized the digitalization of the trading room, and the pressure for cost reductions are pushing for a continuation down the value chain. The digitalization of the Operations department will require an extraordinary effort to finalize the forever on-going STP project. In addition, data should be made available to the clients for their choice of IT platform. Some banks have embraced this development and opened their technology stack for their clients, offering the clients BPO (Business Process Outsourcing). Taking over the lifecycle management of clients’ trades will provide a double advantage for the providing bank, an improvement in the utilization of the existing technology stack, and the possibility to regain some of the profitability lost in the transparency created by price engines and ECNs.

The change

For many capital market participants, the challenge of regulatory compliance and digitalization seems like a lost case. Their existing technology stack is best described with the German expression “historisch gewachsen”, which means it has evolved over time and delivered the required business functionality on an ad-hoc basis, leaving them with a patch-work of systems with multiple integrations and data spread across numerous data models. To change this, an obvious exercise would be to look for a consolidated technology stack capable of handling as much as possible of the value chain – from front office to regulatory reporting. Before making any decisions, the Executive Management should insure their organization has the capabilities of delivering not an implementation project, but a transformation project where all the advantages of the technology stack are incorporated in the new operating model.

SEE ALSO: The upside down of financial institutions 

Failure no. 1

The Business Case cut to short

For many Executives the consequences of transforming their existing operating model into a new model is overwhelming. Creating a target operating model that supports the need for creating digitalized client solutions and secures the compliance of the organization is swiftly done in Microsoft PowerPoint – especially by consultants. The implementation of the new model will however be a large transformation program.

For most experienced executives in capital markets, these large transformation programs are painstaking resulting in loss of income, reduced capabilities to react to market possibilities, less client focus and constantly being confronted with jargon speaking IT people. As if that was not enough, there is the task of making decisions on IT issues knowing that this will have width ranging consequences – which are not yet fully scoped or understood.

A positive side effect of the regulatory requirements is that once there is transparency on client data, a wealth of opportunities will arise from analysing this data.

The path of limiting the uncertainty starts with building a proper business case where the whole organization contributes. The business case should contain different scenarios including a continuation of the existing operating model and the expected outcome when challenged by, for instance, the innovations coming from the FinTech movement. A positive side effect of the regulatory requirements is that once there is transparency on client data, a wealth of opportunities will arise from analysing this data and offer the clients services and products based on their previous conduct. This offers the single most efficient weapon for the banks to strike back at the Fintech movement, where the majority only has very limited historical client data.

Lesson learnt

The building of the business case will create an organization wide awareness of challenges implied in performing a transformation project. The investment in a solid business case will provide the foundation for planning the risk mitigating actions.

 

Failure no. 2

Having vendor presentations or conducting a RFI/ RFP (Request for Information/ Request for Proposal) process

The procurement of capital market software is often considered an external exercise where different vendors are invited to demonstrate their software. The vendors will of course focus on all the well-functioning parts of their solution, and portraying themselves as positive as possible to make them eligible for a sale. The focus of the vendor will often be on the functionality of the front office as the holder of the budget often is from here – following the logic “I make the money, and I decide how to spent it”.

The audience will consist of the different departments along the value chain, and they might see functionality relevant for their work, depending on the vendor’s ability to demonstrate the system on the fly. Finally, IT will have some questions, but that is only relevant to them.

The above statement is of course exaggerated, but previously many procurement decisions were based on a process reassembling the above description. The following implementation/transformation projects would often be characterized by exceeded budgets, reduced scope, missed systems decommissioning and continued maintenance of a large fragmented IT landscape. All leading to a higher change-the-bank and run-the-bank costs and ending up with a flawed business case.

SEE ALSO: Process Overview – a useful tool or just a waste of time?

Lessons learnt

The RFI/RFP should be an internal exercise in its starting point. It is the natural extension of the business case where the scenario selected is taken through a thorough analysis and bounced against potential vendors. The institution needs to understand what the starting point is (as-is), and where it is going (to-be).

The purpose of the internal exercise is to create a clear picture of the solution the institution is looking for, and to be able to communicate this picture to potential vendors.

This exercise should cover the whole value chain and demands for thorough analysis of existing processes, a listing of present and future functional requirements, and a target operating model. The purpose of the internal exercise is to create a clear picture of the solution the institution is looking for, and to be able to communicate this picture to potential vendors.

The vendors should be presented with the desired target picture and requested to make their bid for the business. An initial round of vendor presentations should lead to the following deliverables:

• Overall budget estimation for change-the-bank and run-the-bank.
• A target operating model based on the vendor’s solution.
• A target IT landscape based on the vendor’s solution.
• Decommissioning plan for the existing systems.
• Gap analysis on vendor’s best practice and client’s target operating model.
• Typical resource requirements from the vendor and client.
• Typical timescale for such a program.

 

Failure no. 3

Executive Management involvement and decisions unsupported by evidence

Once the decision has been made to start a RFI/ RFP process for capital markets software, it is crucial that the Executive Management understands that the RFI/ RFP is an investment in risk mitigation in regards to the upcoming implementation/transformation project. As any other investment, it should not be left unattended, but constantly be under surveillance, evaluated and measured against a benchmark.

The RFI/ RFP will force the individual departments to refine their requirements and determine the dependencies across the whole organization. If the RFI/RFP is accelerated, cut short or poorly planned, it will limit the possibility of finding discrepancies between own requirements and vendor solutions. The success of the upcoming implementation project will to a high degree depend on the organization’s ability to map its target operating model against what the vendors are offering to support the future value chains. The RFI/ RFP process should be planned as a project in itself with activities leading to a number of deliverables.

Lessons learnt

The successful RFI/RFP process must be well structured with clearly defined activities and expected deliverables. The vendors should be informed about the deliverables, but also what gateways they will have to pass before reaching the final negotiation table. The formalized RFI/ RFP will secure an environment where management will meet the project team on a weekly basis, be briefed, and take informed decisions. A side effect will be to observe the performance of the vendors when they are to meet the deliverables based on the organization’s requirements. This will be the first indication of the vendor’s ability to deliver in the implementation/transformation project.

 

Failure no. 4

The use of consultants

Buying software that can transform an organization is a cumbersome task. The organization will be challenged by the task of defining the target operating model, specifying their requirements, and determine the impact on their existing processes.

Very often, consultants will focus on what they excel at and not so much on what capabilities the client has or wants.

In this situation, is there an excessive demand for skilled resources compared to normal “production”, and the ability to critically evaluate the existing set-up. Using consultants seems obvious. Therefore, consultants are often an important part of large implementation/transformation projects. Very often, consultants will focus on what they excel at and not so much on what capabilities the client has or wants.

This will result in a very large programme organization where consultants are setting up Programme Management Office to check how much progress other consultants are making, and following up on the consultant Project Manager, who is responsible for getting the estimates from the two internal developers, who are still responsible for the daily production. Other consultants will be chasing internal employees for information to fill in a model that they cannot explain, because their Manager thinks it is important. At some stage, the client may turn around and ask why there is no progress in the project, and the consultancy Partner in charge will honestly reply: “We have monitored the whole project carefully and can determine – your organization has not delivered”.

Lessons learnt

Consultants are offering services just like software vendors are offering applications. The procurement of their services should be treated equally. Be sure to understand your requirements for consultancy services – do not buy what you think you need.

The vendor and their consultancy partners are big companies, and just because some of their consultants have relevant experience you cannot be sure to have them on the project, unless you include it in your contract.

When your requirements are clear, then specify the deliverables you expect from the consultants. Help the consultancy by being as precise in describing what skills you are requesting and what deliverables you are expecting. If the vendor during the RFI/RFP, showcase a project that is “just like ours”, be sure to have names and CVs of the consultants involved. The vendor and their consultancy partners are big companies, and just because some of their consultants have relevant experience you cannot be sure to have them on the project, unless you include it in your contract.

Do not use consultants as a proxy for executive management. There is no replacement for management. The overall responsibility and control of business driven projects cannot and should not be outsourced. The interesting point about leaving executive management responsibility to consultants is that most consultants have very little line management experience as they have worked on an assignment basis for most of their careers.