Death by RFP! Why Writing a ‘Spec’ Isn’t the Best Way to Engage Salesforce

RFP's are no fun. And not much use either.

If you want to build systems so that you become a customer-centric company,  should you issue an RFP with detailed functional specifications?  The answer is a resounding no. This approach doesn't help you get the best solution, and it's unlikely to help your business get what it really needs at a 'fixed' price.

Why an RFP is all wrong!

RFP's tend to start with a blank sheet of paper and force all vendors down the same path. An RFP says "Give me system that looks like this!"

The best modern solutions to your problem should have the following characteristics

  1. significant out-of-the-box functionality. You don't want to start from scratch.
  2. a platform to customise what comes "out of the box"
  3. a surrounding ecosystem of vendors who have built extra functionality that can be easily plugged into the solution to save development effort.

If you issue a RFP, no matter how diligently and comprehensively you specify your requirement, you are likely building requirements with inadequate reference to the starting position of the eventual solution.

In fact, the more painstaking the documentation, the more time and money you are wasting.

Lets face it, Salesforce has to be at least in the starting line-up for a huge percentage of major system implementations. Do you want to issue an RFP that has no imagining of how Salesforce would best tackle the problem?

Here at ProQuest, we unashamedly take the out-of-the-box Salesforce functionality as our starting point for any new project, and we evolve and customise the solution according to the business needs of our customers. We do this with one eye on the long term roadmap, sound technical architecture and complex integrations,  and the other eye on tactical phased deliveries that provide wins to the business early and often. We do this using a process that constantly refines and 'grooms' the business requirements and their prioritisation, in the context of current and changing circumstances. The emphasis is on a collaborative agile governance model that allows the business to see the possibilities of Salesforce evolve and take shape as the solution.

An RFP doesn't allow for that a-hah! moment when you see how things get done by Salesforce.

If you drop the RFP approach, you will probably see a more meaningful response from all the vendors each playing to their strengths. In the case of Salesforce, you will see a response promoting

  1. A phased delivery that deploys high priority functionality early and builds enthusiasm within the executive team.
  2. Configuration of Salesforce standard functionality, rather than excessive coding of the solution is usually the most cost-effective and pragmatic approach.
  3. An end system that will in all likelihood look like a familiar Salesforce-type system.
  4. Regular opportunities to change and re-align business requirements based on, subsequent to each sprint, a look at how Salesforce technology actually works. This review may even result in some of the original requirements dropping out of scope and new requirements being added to ensure the best solution is delivered to the client.
  5. An opportunity to dramatically improve on what you thought you needed because Salesforce invites innovation you hadn't thought of.
  6. A collaborative engagement, without the potential acrimony of a heavy and expensive governance model associated with a fixed price engagement.

So, rather than invest dollars and emotion into an exhaustive RFP process, give your possible vendors some high level requirements, and invite them to discuss their approach and perhaps a customised presentation of how a key business process or two might be handled. Talk to previous customers who have successfully executed on their vision using an agile approach, and ask the vendor to present useful solid cost guidance around a multi-Phase, multi-sprint delivery. Have a look at their version of an appExchange. Does your prospective platform provider have one?

Getting a Price for implementation.

Rather than ask for a committed price for a defined scope, and the heavy contractual documents that will also be required, ask the Salesforce partner for their blended daily rate, their likely team make-up, estimated team size, and the estimated elapsed time to deliver a reasonable Phase 1 activity that brings joy and profit to your executive management way earlier than they ever imagined. And then keep on keeping on.

It's a change in thinking. But it's a more realistic, strategic, trusting and profitable way to proceed.

We at ProQuest are very proud of our project delivery record,  and in order to sustain it, we really try to make sure this partnership arrangement is set up from the earliest possible moment.  RFP's are unlikely to be the best starting point.

 The logo above links to the NoRFPS website here which in turn has a link to some interesting posts on this subject

Add a Comment

Your email address will not be published.