Software selection teams put together RFPs with hundreds and even thousands of detailed questions, giving the appearance that they are paid by the word rather than the result. I have observed selection teams reaching consensus on a recommendation before all of the responses to their own question are tabulated. They complete the planned exercise to justify their recommendation. So why go to all this trouble? With the industry studies that can be purchased and the information that can be obtained from vendor websites, are any questions other than contract terms even necessary?

Advocates for short RFPs are concerned about efficiency and recognize that many of the questions people want to ask are no longer relevant, given the state of technology, or would not make or break the deal. They argue that by reducing your list, you are beginning to make the tough choices and focus on the real priorities.

Advocates for detailed questioning and thorough examination may have been surprised by previous software not delivering as expected. They see longer lists as demonstration of the thoroughness of the evaluation.

Rather than debate the number of questions, let’s talk about the criteria for adding questions to the list.

• Perspective: Each functional area involved in selection has a different perspective and interest in the solution. While the premium audit team may not be as large as your processing, customer service or claims teams, their requirements need to be met by the new solution. Product management might ask about configuration in order to gauge how fast new products can be defined and implemented with the new solution. The IT representative will want to understand how to manage the configuration files and propagate them to different environments. By including questions from each department’s perspective, you can achieve a more holistic review of the solution.
• Ownership: Developing questions and seeing your concerns incorporated into the selection process creates ownership and buy-in for the result. Adding questions from multiple areas increases the list, but also can increase the buy-in for the solution that is recommended. This pays big dividends when you start the real work of implementation.
• Differentiation: Asking if you can issue a policy is not going to differentiate many policy administration system providers. You either need to be more specific or ask process-related questions to understand how something is actually accomplished. For example probing integration issues with your existing application portfolio and technology stack may uncover significant barriers or an experience level that reduces implementation risk. Asking how the vendor’s product configuration tools are superior to competitors often yields a lot more information than a yes-or-no question.

It makes sense for different insurance carriers to pick different systems. However, the only way you can make an informed decision is to adequately define your unique requirements and make sure the team has a shared understanding of the importance of each requirement. There are many best practices that could be adopted to accelerate and optimize the selection process, but if there’s one that’s indispensable it is that the selection team should agree on the approach to take.