Loading ...
A lot of my readers end up on LeapComp looking for information about various vendors. I presume this is because they are considering getting a sales performance management solution at some point. In the next few posts I will discuss the vendor selection process, and I will address the following topics:
- Creating a good Request for Proposal (RFP)
- Creating a shortlist of vendors to be considered
- Getting the most out of sales performance management vendor’s demos / Proof-Of-Concepts / Interviews
- Conducing reference calls
- Negotiation
- Getting help
Let’s look at the first topic; creating a good RFP.
Creating a Request for Proposal (RFP)
A Request for Proposal (RFP) is a document inviting companies, in this case SPM software vendors, to submit a proposal. The RFP includes many sections including the project definition, the project requirements (functional and technical), vendor questions, an explanation of the selection process, scoring process, etc. The quality and completeness of the proposals will only be as good as the information provided in the RFP, so it’s important to get this document right!
Before even starting to write an RFP, make sure you understand your business needs, business and technical requirements. I wrote a scenario about the importance of getting the requirements right, which is relevant again.
Organizations often have an RFP template which they use for every RFP they send out. These templates will include common information such as a letter of invitation, instructions to bidders, a common glossary, and other forms. If you do not have such common template, you should look at various examples, and pick which sections you want. Many places on the web have “sample RFPs”. Here is an RFP gold mine, containing all Canadian’s government issued RFPs. They are not specific to SPM, but they can provide some good ideas.
Requirements and vendor’s questions
Formulating good requirements, and good questions for the vendors, is key to ensure the “winning solution” is the best fit for your organization. After all, you don’t want this winner to not meet one of your “must-have” requirements which was left out of the RFP. Secondly, what could be the best system for one company is not necessarily the best for yours.
Asking questions such as “The product must be able to calculate commissions accurately”, or “The product must be robust”, is bad. Why? Because this is the type of questions every vendor will answer “yes”. Not only is it important to ask questions specific to your needs, it is important to ask questions which will distinguish vendors from each other.
Specific must-have yes-or-no questions could be “The solution must be able to support multiple calendars”, “the solution shall be hosted in a data center with a SAS 70 accreditation” or “the solution shall be able to integrate with SAP without significant configuration”, are examples of questions which may be important to you, and which not all vendors may be able to check “yes” so easily. In general, most yes-no questions will be answered by “yes”. That’s why RFP for packaged solutions often add other answer options such as Supported,Modifications, 3rd Party, Customization, In the future and not supported. I would also recommend leaving space for vendor’s to add comments on that spreadsheet.
When scoring the RFPs, relying on these answers will give very similar scores. That’s why essay-type questions are often preferable, and can be a good complement to those questions.
Questions such as “Describe how your organization supports customers and resolves issues” will give a better picture of what the vendor has to offer compared to asking the question “can resolve issues in a timely manner”. Essay questions will also make the scoring more time consuming and potentially more subjective.
When formulating questions, first think about major categories such as compensation, technical, organization, etc. Keeping your specific needs, requirements and current challenges in mind, write questions related to each of those categories.
So you get the idea, the proposals will often be pretty large documents. That’s why my next post will focus on short-listing SPM vendors.
Julien,
Nice post. I like the description of what an RFP is and what are some common pitfalls in the process. Can you go into more detail as to which organization produces the document, business or IT? I see it being a document where both sides need to provide input to make it “whole”. Is that typically what happens? If not, what can companies do to create that ideal situation?
Stone Jin
Hi Stone,
I’ve seen it both ways, but typically it seems to work best when the business owns the RFP and drive the information gathering from IT. It often comes down to who owns and benefits the most from the resulting project, and for a comp system that’s almost always the business / comp department. The RFP is often a good time to start involving various people in the process; database people, security people, contracting people, stakeholders, etc.
While both sides need to provide input, it is important to make it clear which side is responsible to deliver the final RFP.
Getting buy-in from various people during the RFP write-up will get the ball rolling to get their help during other critical pieces of the vendor selection process (RFP evaluation, vendor demos, reference calls, etc).
Hi Julien,
Thanks for the ICM selection and implementation story. I agree with most of the conclusions you draw, but I would like to offer a slightly revised view regarding “finalized requirements.”
Like with any enterprise software implementation, nailing down the requirements will always be one of the most difficult aspects of an ICM implementation, and given the dynamic nature of incentive compensation plans, my experience has taught me that “finalizing the plans” prior to a vendor or tool selection isn’t realistic for many organizations. Rather, we at Merced believe that organizations have to work collaboratively with vendors during the selection process to understand how flexible the solution is and whether it’s a good fit for the organizational structure, scalability requirements, and desired plan complexity. Likewise, ICM vendors should be involved early in the definition of requirements because in the end, everyone benefits if an RFP truly represents the system’s ability to deliver benefits to the customer.
To read my complete posting about vendor-client collaboration on requirements during the selection process, please visit Merced’s Performance Matters blog (http://blog.mercedsystems.com/).
Dean Thomas
V.P. Client Services
Merced Systems
Hi Dean,
Thanks for your feedback. I’ll build a bit more on your ‘revised view’ when I get to my “Getting Help” post.
Two quick points I’d like to make here:
About the requirements, at the RFP stage I only expect them to be at a high level. How often have I been involved on an implementation where the client wanted to skip the requirement gathering phase because they “had those requirements” already. Maybe even worse, how often have ween seen implementation where the client believed the compensation plans WERE all the requirements that were required. I think that we agree, but I just want to clarify that I’m not suggesting requirements should be “final” in these early stages.
Secondly, you mention that ICM vendors should be involved early in the definition of requirements. This is usually tricky because companies writing RFPs don’t want to give an advantage to any vendor who will be bidding on it. Whether intentional or not, vendors probably will get an advantage by adding features or criteria in which they feel confident they can get an edge. Even if you don’t agree, asking a vendor to help out with the requirements for an RFP will give a perception that they are getting an advantage. The obvious solution - asking all shortlisted vendors to contribute - on the other hand is a pretty tedious task.
I’ll have a post dedicated to this topic in a few days.
Julien
Julien you are right in referencing the need for high level requirements for RFP. I would not call them detailed requirements for execution. These are more of a baseline functionality to be expected out of the vendor solution across compensation (base and Variable). reporting, dispute resolution, modeling etc so that the vendors can provide context for rating their products in the demos. In addition to having high level requiremets/functionality, I also advice clients to have a weighted rating of their requirements and also additional selection factors such as scalablity, flexibility, time to market, required hardware/software expectation, budget etc. for overall weightred evaluations.
These (crtieria minus weighting)is provided to the vendors to submit an initial RFP. Some clients prefer to get the vendors to rate themselves across those criteria. Other clients prefer demos to rate the vendors themselves. The next step is shortlisting of vendors to a couple for final decisioning.
Once vendoris selected, then it is productive to expand on the high level requirements for a detailed due diligence to provide scope for implementation.
Hi Ritu,
I couldn’t agree more with you regarding the requirements. As I pointed out, the functionality-related requirements will yield results which are probably very close for each vendor considered. What you list are great examples of where vendors will be able to stand out from each other.
However, I have always seen a mix of RFP / demo to evaluate vendors, for any large software package purchase. Why? Mostly because if you let vendors rate themselves, there is no way to know if they are telling/stretching the truth. Many solutions offer the same core features, but these features do not perform equally well and are not equally sophisticated. With a demo-only approach, there wouldn’t be enough time to cover everything, and they don’t provide a way to gather very technical information, or less tangible requirements like those you have listed.
Of course, as you said, once the vendor is selected, not only is it productive, but it is MANDATORY to revisit the requirements for the implementation. The requirements we have gathered to choose a solution are completely different than the requirements needed to scope out / being the implementation. For example, the implementation requirements will need to take every compensation plan in consideration. Fortunately, at this point, it is likely that the vendor or an implementation partner will be there to help out with this task.