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.

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.

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

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

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).

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