So, I have been reflecting on this. Over my career, I have bought and/or implemented many investment management or financial services systems on behalf of my employers or customers; some have proven to be excellent choices for specific or narrow use-cases, while others have frankly been a disaster (and you know who you are). In the case of the ‘disasters’, it’s nearly always been a mismatch between client expectations set throughout the sales process, versus the functional reality of the system when it was being implemented. In my experience, the amount of effort put into constructing a ‘sharp and pointed’ RFP, together with a ‘Test and Verify’ approach, is an important predictor of the eventual outcome. Of course, there are always situations where a buying decision is made due to reciprocity or some other criteria unrelated to the functional performance of the proposed system, but those decisions almost never work out well for the people required to implement and operate that system!
By way of illustration, a few years ago I started an RFP search for an Investment Accounting platform with a specific emphasis on these core requirements, over and above the usual baseline functionality for such systems:
I sent an RFP around to a dozen firms in total – mostly well-known players, with the above specific passing criteria spelled out. Shortly afterwards I started to realize how difficult this specific ‘ask’ would be. By the end of the first round of response/reviews, five had pulled out mostly due to not being able to deliver on all or a combination of these three core requirements:
After the first round of eliminations, I was left with two firms on the short-list and one of those was STP. Unfortunately, the Covid pandemic hit, and this specific project was postponed for business reasons, but STP impressed me with their modern technology as well as their integrity and commitment, together with their clarity when a particular function was not immediately available, or was in development.
While a comprehensive RFI/RFP is always a great place to start, it needs to be written with very specific pre-qualification hurdles, which frankly will save all of the participants a great deal of time. After that, a comprehensive ‘Test and Verify’ step is vital. Having been on the receiving end of many, many RFPs of hundreds of pages, I can say that I had wished those requests were explicit in detailing the minimum acceptable requirements. RFPs that permit responses such as “Fully/Partially/Not Available” just prolong the agony for technology and service vendors that could otherwise be quickly eliminated. It seems to me that most good sales teams can manage to finagle a response of ‘Partially’ to just about anything…
Overall, the lesson I learned from this exercise – as well as many previous forays into the world of RFPs – was that while the attractive brochures and websites promise a lot, the reality is that there are still tremendous differences in the functionality and cost of ownership, even though each vendor seems to claim to provide everything that your business may need.
So thank you to everyone for your good wishes and I hope that explains what has attracted me to working with a company like Suisse Tech Partners. Please remember to make your RFPs ‘Sharp and Pointed’ with clear pass/fail criteria for your ‘must haves’, followed by a comprehensive ‘Test and Verify’ process. The question: “Can your System do this?” needs to be based on a precise and comprehensive RFP survey with clear hurdle criteria. At the very least, it would save a lot of trees…