Is it time to rethink the investment technology request for proposal (RFP)? What is it we are really trying to learn by issuing a 200–300 question RFP where we probably already know the responses for 75% of the questions? Are the competitors really that different, and if they are what is the best way to understand those differences and assess the business impact?
These extensive RFPs require numerous resources and several weeks to construct, and then vendors take 2–3 weeks to respond, often with canned answers. This is followed by scoring, demos, and decisions—and through all of this, have we learned that much more than we already knew? The fact is, some firms have already predetermined a front runner, or have a bias based on prior experience, or a story their buddy down the street told them.
I am not suggesting we abandon the RFP questionnaire, just that we use it to obtain information that is important and a differentiator. Technology platforms, SaaS vs install, corporate and financial condition, and cost are important to understand and can be show-stoppers if they don’t meet the requirements of a prospective client. These items should be examined closely and using a questionnaire can prove quite useful.
When looking for a technology solution, like an accounting or trading system, it is important to choose a solution that best meets the investment firm’s needs now and in the future. Firms may have specific investment product requirements, private debt or equity, hedge funds, real estate, insurance, etc.—all have unique demands that may not be robust or even available in some solutions. Therefore, why not focus the search and selection process on those requirements? Do we really need to ask scores of questions about transaction types, accrual formulas, and security types? I propose we shorten the RFP questionnaire and focus on a proof of concept (POC).
I want to know: How are unique product requirements handled? Is the technology state of the art? Is data easy to import and export? Is access user friendly? These and other questions can be answered with an inclusive POC based on real data and user experience. It will provide the ability to focus in on current and future requirements, see potential gaps and workarounds, and build trust and consensus around a solution.
Many of my Citisoft colleagues have written on search and selection processes and how to perform effective POCs, and I say the POC is where our focus should be.
Who’s with me?
