RFI and RFP Resources
Carriers Still Want/Need RFPs: From Technology Providers
Mark Twain, great novelist and raconteur, was for a time an inhabitant of that once great insurance city, Hartford Conn. From 1874 to 1891, Twain lived on Farmington Avenue, a grand, tree-lined boulevard. The Mark Twain House sits next to the Harriet Beecher Stowe House and indeed the two were neighbors for about 15 years. For those of you who have never visited, both are much grander than anything to which Huck Finn or Uncle Tom would have aspired. Unfortunately these days one has to ignore the surrounding urban blight in order to appreciate these fine old homes.
In a former life, but not quite as long ago as Mark and Harriet, I too frequented Farmington Avenue and fancied myself a writer. In my case however, the writing was far more prosaic. I started writing requests for proposals (RFP) when I worked in Hartford. Over the past 30 years I have written countless RFPs. The most recent one I was involved with was published just weeks ago.
There is a tendency for CEOs to become disconnected from and unaware of the work their colleagues do and the needs and wants of their clients. With this in mind once or twice a year I roll up my sleeves and work on a client engagement as a way of staying current and hopefully relevant.
Most recently I acted as a business analyst (working for one of my own project managers) and gathered the requirements for a policy administration system RFP. It was great fun and particularly useful. It also gave me the opportunity to revisit the issue of why our clients go to the bother and expense of creating such a document and whether there is a quicker and more appropriate way of moving a software selection process forwards.
Indeed the trusty RFP has come under fire in recent years as being unnecessary, clumsy, and overblown. Some of the more recent entrants into the software selection services space have declared that scripted demos and proofs of concept can replace the value gained from an RFP more quickly and at less cost.
Further, they declare that vendors, especially busy successful vendors, are unwilling to take the time to respond to a detailed set of questions and will at best provide less than complete answers. So, did my PM colleague and I just waste our client`s time and money? Is the RFP a bloated relic? Is the RFP dead?
An RFP is designed to do several things:
Tell a potential vendor about the client company.
Tell a potential vendor about the project to be undertaken, including its basic scope and objectives.
Solicit information about the vendor as a company.
Solicit information about the vendor`s software in terms of its business functionality and technical features.
Solicit information about the vendor`s approach to implementations and the services it provides in support of the actual project.
Solicit basic information about terms and conditions along with initial cost and time estimates.
This is useful information the carrier needs to evaluate and differentiate between possible vendors and their competing solutions. It is also important to get this information in writing, and in a format that is consistent across the vendors and is dictated by the carrier. But is there, and should there be, a quicker and easier way of getting this information and is all this information necessary?
Scripted Demos and POCs:
Scripted Demos and POCs are an important adjunct to an RFP not a replacement. By definition, each chooses relatively small functional areas to focus on. Making the vendor perform is a critical aspect of software selection. However, using these processes to discover the scope and completeness of a system is like trying to understand the shape and size of a room by standing in the dark and randomly pointing and flicking a flashlight on and off.
Further, making assumptions about what a system can do based on the fact that it can do another task is dangerous. In the important business of selecting a core insurance system there is no substitute for methodical and complete review.
The Vendors Won`t Respond:
My company began to experience pushback from vendors in recent years. The complaint was that they were not required by other carriers to answer “thousands” of detailed functional and technical questions so why did we expect such unrealistic efforts? The reality of today`s marketplace is that it is dominated by a few very good vendors who are very busy.
These vendors can pick and choose to some extent the carriers and projects they wish to pursue. A successful software search must take account of this fact, but that doesn`t mean the RFP must be “dumbed down.” it simply means, for example, asking the vendors to respond to groups of questions rather than individual questions. This way the RFP retains all the details but the vendor gets the relief they need.
Are Details Needed in the RFP?
This brings us to the core question, which is why labor for several weeks to write down all these detailed questions in the first place? There are several answers.
First, the selection project is the first step of a core system legacy replacement. Sooner or later requirements will be defined in excruciating detail so starting with a decent overall statement of requirements is not lost work, even if some services organizations consider them unnecessary early on.
Second, performing a series of systematic requirements gathering sessions with a client has great benefits in addition to the actual production of an RFP. These sessions are valuable team-building exercises where people from different functional areas of a company get to work together and understand each other`s worlds. Team members also realize how much they do without necessarily knowing why they do it. And finally the team comes to a common realization of the breadth, complexity and inter-relatedness of insurance core systems processing.
Third, the requirements gathering phase creates a common mental landscape that benefits the team going forward. As they undertake new steps such as scripted demo development and vendor visit planning the team knows “where they are” and what they are focusing on and why. This is hard to do if you have only “flashlight” moments to direct you.
At a more general level this debate about the RFP has a larger context. Companies of course are always looking to do things quicker and at lower costs. I get that. And there are always services providers who want to exploit that tendency. I get that too. But here is my beef. It`s not the job of the vendor selection services provider to select the new vendor. Rather it is the job of the carrier team, facilitated, guided, and enabled by the services vendor, to select the new vendor software.
So, the most important outcome is the carrier team knows what they are doing, why they are doing it, and how they reached the conclusion they reached. This should take as long as necessary. The team members need time to learn and absorb new processes and new ways of thinking. The point is not how quickly the selection process can be done; it is how well it can be done and what new capabilities the carrier company grows during the process.
Like so many other things in the information technology world there is no silver bullet for software selection. Given its strategic importance to the carrier company it seems crazy to me that “doing it quickly” would ever trump “doing it right”. Software selections and attendant core system legacy replacements are once in a generation undertakings at most companies. They cost millions of dollars, take years of effort and are at significant risk of sub-optimization or even failure. Why would any rational organization choose to rush the critical early stages of this process?
Farmington Avenue is a long time ago. The information technology industry has made breathtaking strides since then. The ways of building and deploying software have improved. We have also witnessed examples of cutting corners where corners should not be cut. Thirty years later the RFPs my company writes are substantially similar to those I wrote in Hartford.
Modernity can be a good thing, but it has its dangers. Most “silver bullets” are illusions. Some things just work and can be improved on only at the margins. The RFP is one of these. The RFP is not dead; long live the RFP.
(George Grieve is a popular writer and speaker on the subject of insurance technology solutions and is the author of the book Shop Talk. He is CEO of the consulting firm CastleBay Consulting. The views and opinions in this column are those of the author and do not necessarily reflect the views of the Insurance Technology Association and its members.)