Stop Responding to RFPs: 2016

Request for Proposals (RFPs) have long been the bane of my existence. Not because I’m lazy or just don’t want to write, but because I’m philosophically opposed to the notion that we should give our 12 years of experience (over 100, cumulatively) away for free. And, participating in that game sets the precedent that everyone else in our industry should, too.

I take deeper issue with the concept of the RFP as well. I acknowledge that there are better RFPs, worse ones, and a world in between. But, the majority of what I see are terribly flawed and misguided documents being prepared by people unqualified to prepare them.

My deeper issue is that the RFPs I see so often tell me precisely the desired solution and at what cost. Which means that either the client is self-diagnosing or has hired a consultant of sorts, very rarely the person, or persons, qualified (great–if they are) to implement the work. This is bad. For everyone.

I want to clarify that the kind of RFP I’m talking about in this article is one in which the problem that needs to be solved is more complex than a basic website. Ecommerce sites in and of themselves embody a certain kind of complexity, but Shopify has made a previously extraordinarily complicated world, oh so much simpler.

So, the kind of website solution I’m talking about here, is beyond slapping a pretty theme on and going live. What I’m talking about is the kind of problem that requires an in-depth understanding of the client’s business and operations in order to solve. One that involves multiple integrations and multiple stakeholders.

You might also like: The Counter-Intuitive Approach to Getting Your First Client

What is an RFP?

Let’s take a step back, identify what an RFP is, and what it typically consists of in the digital industry.

The Request for Proposal is a document put forth by a company looking for a particular service or services. The company articulates their problem (and too often what they perceive as their solution) and ask vendors to submit a document in return that details how they are going to solve that problem and at what cost. The document is usually expected to contain a host of other information about who the vendor is and their credibility, case studies, references, and usually a detailed timeline for the project.

All of this is expected to be done for free, as some sort of investment in the hope of winning the project. When you go to the doctor, even if it’s for a referral or consultation, you still have to pay for the office visit. Why is it that creatives are so often expected to give their work and their experience away for free?

The problem

I understand that we, in the digital industry, are selling more than a commodified, cut and dry, relatively the same, service or product. That as a company seeking a vendor, there’s a lot on the line and more than just a few bucks. But doesn’t that, in and of itself, make a case for an alternative process that would better ensure the outcome is more along the lines of what’s hoped for?

I have actually used this response before, more than once:

“To respond to this RFP with a proposal for this project would mean that we have to essentially put in as little time as possible, to get enough of a sense of what this project entails. And throw a number at you that will cover our bases amidst the inevitable and significant unknowns that are a result of not having a thorough technical discovery and strategy in hand. And, I guarantee you that is what every other agency you are getting bids from, is doing.”

It’s harsh and there’s a risk of losing the project right off the bat, but by some sort of grace, I have reached the point in my career in which doing things of value that I’m philosophically in alignment with, has outweighed pushing dollars and other numbers through the door. That is not to say that taking this approach has weakened the financial or cultural health of my agency in any way shape or form, it hasn’t.

The problem is that so many of us are just accustomed to doing things the way we’ve seen them done before. This is human nature and I get that. But this is a challenge, a call to action, to us of the digital industry, paving a whole new industry one day at a time, to rise above what’s been done before and do something the right way, the better way, the fairer way that elevates us all.

You might also like: 6 Tips for Finding New Clients

The solution

The right way is a paid technical discovery. By paying for expertise up front, by paying to actually have several firms dig deep into your business and the potential ways to solve your problem, you are acknowledging what is true: that there is no one way in today’s technological landscape to solve any particular problem.

The more complicated the problem, the more variable, plausible solutions. By spending the time and money to do this up front, to study the ins and outs of your unique operations and to compare various options different teams come up with (by being paid to dig deep and be diligent), you are taking out an insurance policy on your investment. It is the obvious way, the smart way, the wise investor’s way of getting the best possible outcome.

We do not respond to RFPs that come without a thorough Technical Discovery. We’ve been evolving our technical discovery process over the past several years, and will continue to iterate on it each time we do it. We break the process down by phases according to the scope of work at hand.

The technical discovery process

In the first phase of a technical discovery, we want to establish a framework for the project. This includes clearly defining the overarching goals of the project. For example, one goal might be something along the lines of: “To determine the fewest number of integrated third party tools that address all of our core operations at the lowest cost.”

This means that our job is to take a thorough inventory of the client’s operations. To do so, we identify each of the project stakeholders—everyone that participates in the operations—and interview them to get an understanding of their daily tasks and the most important parts of their job. It’s important to note the distinction between “must-have” and “nice-to-have” features.

We prepare documentation outlining what we’ve learned and send that back to the client to confirm we’ve got it right. We then compile what we’ve learned in each interview into one final document that addresses the comprehensive goals of the project, along with each component that we’ll need a third party tool to address. It is best to have an unbiased third party (such as ourselves) perform this discovery process.

At this point, we are in a position to begin researching and consulting with third party providers. This includes, but is not limited to, providers that address inventory management, POS systems, 3PL, shipping, etc. We will setup demos of each piece of software we’re considering, in order to have the client get a first-hand feel of the tool and ensure that it will work for them.

This process narrows down the potential right fit solution. Ultimately, the client needs to choose what’s best for them, but we see our role as helping to make that possible by cutting through technical jargon, and identifying loopholes or gaps from an unbiased perspective.

Once the client makes a decision as to what software is best, we are then in a position to put together a clear scope of work and assess costs. A typical RFP either leaves out the expert until the solution has been determined, or asks the expert to put in all of this work and do a good job at it without getting paid, which leaves very little incentive for the thoroughness this process requires.

The benefits of the discovery process are threefold:

The client dramatically decreases the likelihood of selecting the wrong platform(s).
A plan for the project is fully articulated up-front, lowering the chances for oversights down the line. This usually also shortens the timeline for implementation and gives the development team a clear scope of work to quote, eliminating price inflation for unknowns.
The foundation of the relationship between both parties is built prior to engaging in a six figure contract. This is only good.

It’s like this

To take it back to the medical field one more time, most projects I see that are the result of a flawed RFP reflect this scenario: I have a toothache. I go the dentist, they tell me that I might have a cavity, need a root-canal, or need to have a tooth pulled. They tell me they need to do some further examination into the tooth, probably an x-ray, in order to determine what specifically is the cause of my pain. And, I have to pay for that further examination (in addition to the office visit).

But instead, I just tell the dentist that it is a cavity, even with my limited knowledge because I am not a dentist, but rather just a human that has a problem. I choose not to acknowledge this and have the tooth filled. A few months later, I’m back at the dentist and paying for root-canal because the wrong problem was fixed based on my unwillingness to pay for a thorough examination up front. And now, I’ve paid twice-as-much to fix my problem. This is precisely the issue I take with RFPs.

Call to action

What I am saying my friends, my colleagues, is please do us all a favor and play your part in maintaining and raising the integrity of our industry, by demanding that your time is valuable. Demand that you should be paid for both your experience and your investment, because it is in the best interest of the client that they allow you to be the expert you are.

How do you feel about RFPs and project bidding? Share your thoughts in the comments below!

You might also like: The Value of Saying No to Potential Clients

Sara Bacon