Guest Contributor: Berl Kaufman, Principal, Afferent Consulting Services
In some cases you are mandated to do RFPs for your product selections. Don’t do RFPs as a reflex action. The RFP is mostly a waste of time. Vendors always lie on RFPs to get high scores and qualify for your short list.
The RFP is only good to flesh out business requirements, but you have a good methodology in place for that, right? If you have decided to go the “buy” versus “build” route, you almost certainly have a few vendor products in mind. If there’s more than a few, your scope is probably too broad. If you don’t have a short list, ask your colleagues and associates in other firms or a trusted consultant. Whatever you are doing has been done before by someone, so there’s a best practices lurking somewhere. A far better approach is to do a proof of concept. If there are any unknowns (and let’s face it, there are always unknowns) about the products you are considering, the POC is a must.
If two vendors are very close in feature set, then do a POC in the form of a bake-off; this will give you a feel for the implementation teams and how well they work with your in-house team. Indeed, do a POC before you commit, even if you have already decided on one vendor. There’s a cost of course, but you at least you can avoid many wasted months (or years!) and lots of agony. The key is really nailing your requirements, keeping the scope narrow and managing the POC correctly. The purpose of the POC is to eradicate unknowns. The POC, if designed properly, will not be a throwaway, will help you focus on the real requirements, and probably expose a few more unknowns (expand the POC).
Here’s a high level guide to an effective POC:
- Use the version of the product you are actually purchasing;
- POC deliverables should be broad but not deep. Excise a tiny subset of each business requirement;
- Use your own business requirements, not the vendor’s feature list;
- Use your own data in the POC, not the vendor’s.
- Use the actual implementation team who would do the real product work;
- Base the POC on a solid list of business requirements. The “what”, not the “how”. The “how” is the product, and you haven’t picked it yet. Don’t use vague terms like “demonstrate support for”. Language should be specific and measurable.
- Any unknowns, including non-functional requirements (like performance characteristics) should be included, time permitting;
- Timebox your POC. Make sure all products start and stop at the same time;
- Ask the vendors which areas take the most time to implement in their experience. If they can’t answer you, drop the vendor. Consider including those items in the POC;
- Required changes to in-house systems should be included in the POC (remember – tiny fraction only, just to expose unknowns). You’ll find out how well the product integrates in your environment, gets the in-house team involved in the project, and will help you in post-POC project estimating;
- Try to include the entire life cycle of data in the POC;
- Run the POC like any project, with a project manager, deliverables, resources, etc.
In my next blog post I’ll walk through the details on how to craft a successful POC with a real-life example: selecting a multi-asset class trading platform for an asset manager.