Avoiding the wreckage on the IT selection highway

The smouldering remains of expensive IT projects that litter the investment management highway bear testament to the many problems faced by asset managers in system selection. The software procurement process within the funds industry needs to evolve to meet current market needs, writes Steve Young, Citisoft managing partner.

Author
Date published
January 05, 2018 Categories

The smouldering remains of expensive IT projects that litter the investment management highway bear testament to the many problems faced by asset managers in system selection. The software procurement process within the funds industry has changed little over the years and needs to evolve to meet the current market needs.

Most asset managers follow a tried-and-tested approach, using a well-established and formal process. I think the selection procedure should be more encompassing and inclusive, using tools such as informal referencing, vendor site visits, speaking to the user network and understanding the current client’s situation. Issuing RFPs, watching demos, proof of concepts (POCs) and formally assessing vendor risk are not sufficient. Vendors are increasingly skilled at managing this process, and invest in training and technology to ensure that they maximise their capabilities in this area. Asset managers must never lose sight of the fact that they want to procure the most appropriate solution and not buy from the firm with the best sales process. Asset managers can learn much about vendors by taking them beyond their comfort zone and not following their rules of engagement.

“Asset managers can learn much about vendors by taking them beyond their comfort zone and not following their rules of engagement”

In many ways, the biggest risk in a selection is implementation. A lot of projects falter because they fail to be deployed on time, to budget, or to meet the needs of the business and yet still I don’t think there is enough focus on deployment. It is very common for buyers to begin a process with unachievable project plans and inappropriate budgets. It is not in the vendors’ (or in many cases any selection consultants’) interests to give concise and open feedback on these plans. Their motivation is to close the deal, not suggest delays and further investigations. Firms, naively in my view, try to mitigate this risk with contractual terms, but in reality, if these ever become discussed or triggered the project is on a slippery slope and will probably be terminally impacted.

“Firms, naively in my view, try to mitigate this risk with contractual terms, but in reality, if these ever become discussed or triggered the project is on a slippery slope and will probably be terminally impacted”

A large proportion of implementation failures are due to unrealistic goals and a lack of effective programme management from the beginning. Maintaining credible expectations and adjusting the project plan and budget accordingly are critical aspects. It is nigh on impossible to anticipate a complete programme from inception, so flexibility and effective management are required at all times. The programme must be supplemented with open and transparent communications, both internally and between supplier and client. These communications should all be discussed, assessed and planned as part of the selection process.

When it comes to systems selection, following the herd also has its risks – particularly if a large number of asset managers are buying the same big, complex application. For example, if a system has been selected seven or eight times in the last 12 months, asset managers need to consider who is going to handle their deployment. There is only a finite amount of qualified resource to install any software application, so if an asset manager’s implementation is number eight of the year, it needs to really scrutinise the level of experience in the proposed team. Vendors often begin to draw in external consultants or contractors when their in-house resource is overstretched; these individuals may be highly qualified but not necessarily in the intricacies of the system being deployed. It needs be more about partnerships and developing capacity ‘ahead of the curve’.

Systems also need to be open and easy to assimilate within the asset manager’s existing IT infrastructure, but I don’t think asset managers pressurise the vendors enough to ensure that this is the case. New applications are more often evaluated on the strength of what they can do in isolation, rather than how capable they are of integrating with prevailing data sets and pathways. With technical advances and increased focus on digitalisation, this ability to readily integrate is key and always underestimated.

Purchasing firms also need to invest time in visiting other users and asking questions, beyond the clients offered by the vendor. Many vendors actively cultivate their references to gain favourable rather than honest and open feedback. It is usually relatively simple to stage manage a reference call. Firms need a more rounded view and speak, if possible in person, to a group of end users across a number of firms – ideally independently of the vendor. No firm in my experience has a solution that has not had issues or challenges at some point. Any reference or vendor that will not present some of the challenges is almost certainly being economical with the truth.

“Asset managers need to challenge the status quo in their system procurement environment if they are to get the best from the vendor community and mitigate the risk of their project becoming the next IT wreck”

A final process that too few purchasers undertake is a site visit to the HQ and or development centre of the application. During this visit, asset managers should ensure a facility tour, identifying departments and speaking to individuals. This knowledge will be invaluable in assessing the capability and culture of the vendors.

Asset managers need to challenge the status quo in their system procurement environment if they are to get the best from the vendor community and mitigate the risk of their project becoming the next IT wreck.

Exit mobile version