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? Plus, 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
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
effort? The reality of today’s marketplace is that it is dominated
by a few 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 service
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 a RFP. These sessions are valuable
team-building exercises where people from different function-
al 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 fi-
nally, the team comes to a common realization of the breadth,
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, 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 the debate about the RFP has a
larger context. Companies are always looking to do things
quicker and at lower costs. I get that. And there are always
service 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
service provider to select the new vendor. Rather it is the job of
the carrier team, facilitated, guided, and enabled by the service
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, 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 for 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
Farmington Avenue was 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
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. ITA
(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.)