Having managed the ‘beauty parade’ and selected a vendor, what are the considerations for investment managers procuring new software products and services?
How can the vendor best manage the handover from ‘wooing’ to delivering, asks Abbey Shasore, CEO, Factbook and Robert Corbally, founder, Hawser Consulting.
When an investment management firm has concluded its vendor selection procedure and contracts have been signed, it may seem like a time to celebrate. Yet the end of what is often an arduous process for both parties is only the beginning of a partnership, and the hard fought and considered decisions that have been made on both sides rapidly give way to the practicalities of onboarding. A problematic onboarding can result in significant cost overruns, critical deadlines being missed and already overburdened staff suffering from unnecessary frustration. How can firms and vendors – these two participants in a new relationship – avoid the pain stemming from differing expectations of the post-selection phase and where do the most harmful disconnects typically emerge?
Mission creep
Allied to the importance of clear objectives, mission creep is a constant problem in such a fast-moving industry. It can be driven by the ‘changing of the guard’ that follows the end of the selection process, when a new team charged with overseeing the implementation phase is installed. It may simply be driven by the client’s continued exploration into the service that they thought they wanted, ultimately reaching the point where they realise that the software system or service needs to be configured in a different way to meet revisions to the original objective. Regulatory impacts can also be a source of mission creep, where during the project the scope of any applicable regulation has been modified and additional burdens put in place. Most regulatory programmes are well signposted, but a change in scope could have an impact during a long onboarding process. Evolving business needs can also affect a project plan, where, for example, distribution changes or new products client-side can alter the desired extent or nature of an IT project. In the same way financial circumstances, of course, can have a major impact on any new deployment. Funding that was available to the client at the project’s commencement could have been cut and this may hamper its conclusion. Conversely, the business may have grown and there is a subsequent desire or requirement to expand the project beyond the original scope.
Achieving connectivity
Whilst interoperability requirements would be established early on in any selection process, connectivity-related ‘conditions’ may surface at a later stage. For example, a prospective client may approach a vendor requesting a fully outsourced investment reporting service, or a SaaS approach where the vendor does the hosting and the client’s team manages the monthly reporting cycle. At some point early in the implementation, it may transpire that the client has a condition that its data must come from a specific supplier. Connectivity with that particular supplier has suddenly become an imperative. Hard requirements that have been omitted from the original specification like this can cause significant disruption for the project delivery team. Connectivity is particularly important in the asset management industry because there is such a proliferation of vendors and solutions. If a firm needs a different client reporting system to do something better then there is usually plenty of choice, but without having access to the data that is required for the whole reporting endeavour, the project will soon be rendered meaningless. Equally, the data may be needed to feed a new reporting tool such as a web portal. Connectivity is key.
Resource changes
Despite the best planning, problems associated with changes in personnel or resource requirements can have serious consequences. Changes to delivery teams are a common issue. This might be where the vendor has introduced the client to the pitch team to win the business, but the delivery team is a different one. Have you as the client lost some of the impressive experience you saw during the pitch, or was the pitch team a crew of associates that might not be available for the implementation? And from the client perspective, did they limit their team involved in the selection process in order to make a decision more swiftly, but now need to involve other indirect ‘beneficiaries’ of the software? The needs of these beneficiaries may be slightly different from the key stakeholders on the client-side and may even alter the objectives of the project. Equally, the resources needed on the client-side may have been underestimated by the vendor. It may simply be that the vendor assumed that the client had more resources than it has in reality, or that the team presented on the client-side were also committed to multiple other projects about which the vendor was unaware. There is scope for a significant disconnect here between client and vendor.
Commonality of understanding
The implications of the client and vendor not being ‘on the same page’ in a number of areas can be wasted time and significant additional costs. Not to speak of frustrations. For example, did the vendor overlook certain costs, or simply not raise them, leading to a misunderstanding and tension when the implementation begins? Similarly, is the prevailing client-side culture one of a master/servant toward its vendors, whereas the vendor is more familiar with a relationship based on partnering? Or if there is a culture of overruns within the client firm, then that will be hard to counter. Any divergence from a cultural viewpoint may foster tensions or resistance.
Conclusion
Many of the issues raised in this article can be solved through the vendor asking the right questions in the right way at the right time – and managing expectations as they move from selection to delivery. Vendors must ensure that there is commonality of understanding in the widest sense – not just a match between what is being sold and what is being bought.
From the client’s perspective, establishing clear objectives and full transparency is critical. That said, the ‘client is always right’ and it will be their prerogative to set objectives and determine the level of transparency that they perceive as being necessary. The more clarity and engagement that the client is able to provide, the more fulfilling the outcome will be, particularly given that circumstances always develop.
Business transformation projects will naturally evolve but if there is any change in the requirements then it must be communicated as early as possible and in such a way that both parties can have consistency of relationship (even if the protagonists are sometimes different). Having the confidence in your vendor to share as much information as you can, as soon as you are able to, will reap healthy dividends for both your project and your business.
This article originally appeared in fundsTech.com