How to Write a Great RFP (The Trouble with RFPs)
You've come here looking for help on writing a great RFP; probably searching for an outline for a good solid foundation. Great. The problem is that you're probably not as equipped as you think you are to start writing one.
There's nothing wrong with wanting to get things done efficiently, but there are some really big pitfalls with the RFP approach that you should be aware of if you're not experienced with it. Let's explore what can go wrong with RFPs before I give you some suggestions on how to go about things a bit differently:
You're not an expert
Let's face it. You're an expert at knowing what you want, but when it comes to what you need you most likely don't have a clue. That's where a technology expert comes in (isn't that why you're looking to hire one)?
Here are the problems with RFPs that I've come across that stem from you thinking you know more than you do!
"I need a website"
Again, people are great at knowing what they want, but have trouble when it comes to knowing what they need. I call this the "I need a website" phenomena. Occasionally I'll come across an RFP that says something like: "We need a new website with a professional aesthetic." Very seldom should this be the end of a needs examination. Every good technology consultant knows they need to dig in under this need to unearth deeper needs. We need to back track a bit and ask some questions: "What is your business?", "Why does it have to be professional?", "Why do you even need a website?" These may sound like very basic, and even redundant questions, but I assure you they are much more.
You'd be surprised the amount of times we get responses like: "My business sells cupcakes.", "Because I thought businesses should be professional", and "Because everyone has a website these days." All three are answers that require further exploration. Broken down, they might translate into: "I'm in the business of delighting someone's taste buds", "It needs to have an aesthetic that reinforces sensory gratification", and "My audience primarily locates my bakery through Yelp, on the web."
Do you see how this in-depth examination changes everything? Now we have a much clearer picture of what this bakery needs from technology (and that it needs technology at all). We also know what kind of design it needs, and the mission behind that design. We can suggest how to capture traffic from Yelp and appropriate design resources.
None of this is possible with an RFP that tells a vendor: "I need a website." They are in it to make money, and they don't want you to pass them by, so they'll throw a quote at you on some arbitrary proposal that hasn't examined your needs more deeply.
When you try to talk technology, everybody gets messed up
Many times our clients come to us and say something like: "...and I want it to send me a text message." We ask them, OK, why is that? And they'll say "because I want to be notified [of a certain event occurring]." Fair enough right? Now, we could respond with "...OK that'll cost you $5,000", or we could do our job as technology experts and say "well... if you want to be notified, we can have it send you an email for free and your phone will push notify you." You've gotten the same thing you wanted for $5,000 less. These time and money-saving suggestions can only happen if you've opened up a feedback loop with an expert first.
With your RFP, invariably, you'll be tempted to load up your functional spec up with technical requirements and you won't even know you're doing it. You'll say stuff like: "it needs to send a text message", "it should be accessible on our company servers", and "it should be built on WordPress". Word-for-word, all things that could be very difficult and expensive to do compared with other easier and cheaper alternatives. It's hard to keep the technical language totally separate, especially if you don't do this for a living.
You really should leave these tech. decisions to an expert. Someone who can constantly orient you in the right direction, to change your functional requirements to what you really meant, sans any technology implications: "it needs to notify me", "it should be accessible to everyone on my team", and "it should be built on something cheap, ubiquitous, and easily maintainable."
With the RFP, you'll blast your flawed functional spec out to a bunch of vendors who will be tempted to quote you on exactly what you've told them in a mad dash to win your business. The time hasn't been taken to be able to do anything else: to help you think things through a bit more to explore other options. It's just a bad setup.
Bottom line: You'll give them flawed information, you'll get flawed proposals and quotes, and you'll make a flawed decision on what team to hire. They'll build you a flawed product based on a flawed understanding of what you want. All for mega bucks ($$$). Garbage in, garbage out, anyone?
Your expectations are out of whack
Some of the requirements I've seen clients list out for RFPs are just absurd and amount to having a vendor write up 10-20 page documents. You're really begging for them to load it up with fluff. How could they come up with that much to propose for your project, when all they know about it is on a single page you drafted up in 30 minutes? It's just not realistic.
Then there are those who go ahead and say what the project should cost. And I'm not talking about those who specify how much money they're able to budget to the project, I'm talking about those who explicitly say that the project costs should amount to, in total, $X.
Let's face it, yes, you know how much money you have, but you have no idea how much a brand new project should cost. You've never done it before. And even if you have done something like it before, you're working with different companies and even what you think should be the same can be completely different and require a different approach, which requires a different budget.
You aren't forced to accept any offer, so there's no need to dictate this. Being obnoxious is an aside, but what you really should know is that when you do this with an RFP, you damage your ability to get the best price and get the job done right. You've created this arbitrary budget that vendors will either gobble up without regard to saving you money, or stoop down to and not give you the service you need.
The same goes for timelines. It's okay to say that you have some deadline looming, and to see if vendors can work within it, but it's not okay to say it should take X months, end of story. They'll rush or take their sweet time. Neither a good way to go.
Sadly, vendors are not going to confront you about these things: they'll just go with the flow to win your wallet, whatever it takes. Vendors are not going to raise the issues I'm raising here. Many will just nod their heads, yes you to death, and do whatever. They won't ask the hard questions. This can lead to bad business down the road if you move forward with them: unexpected costs, unmanaged expectations. Nobody needs that.
With the RFP, vendors end up just focusing on putting a bid out there, crossing their fingers, and hopefully paying their bills. This isn't what they should be focused on. Yes they should do better, but it takes a true technology consultant to bite the bullet on this: to educate and take the path less traveled. With an RFP, you won't easily put yourself in touch with true consultants because you're not giving their approach a chance. You'll put yourself in touch with jaded vendors who wear a fake smile.
Vendors aren't looking out for your interests
Okay so that's where you go wrong, and we've been giving you a pretty hard time up until now. But let's talk more about these vendors. The ones who take RFPs and blast out proposals back to you blindfolded. What kinds of shenanigans will they pull to win your business?
Here are the problems with RFPs that I’ve come across that stem from vendors saying "screw it" and just trying to take your money!
The designer's shenanigans
If a creative-type is handling the creation of your proposal, they'll try and awe you with making it super-pretty. Unfortunately this usually means things are a bit lacking when it comes to substance. They look at winning your business as an art project. Your project, no matter what anyone thinks, is most likely not an art project. It more than likely has something to do with using technology strategically to make you more money. This takes a different approach than the designer's approach, which in our humble opinions is more often than not: bullshit.
The copywriter's shenanigans
If your RFP lands in the hands of a copywriter-type, they'll look at winning your business as an exercise in writing statistically proven and compelling copy to manipulate your brain into clicking the "buy now" button. Calls-to-action, dissonance, identifying pain points, inspiring interest, provoking desire... all tools in the copywriter's tool belt. This is a little better, because at least they are saying what you want to hear, which in our opinion is a bit more substantive than drawing what you want to see. But it still isn't genuine in trying to win your business the right way: by demonstrating real expertise, critical and strategic thinking, and tangible results.
The sales guy's shenanigans
The sales guy is going to try to get a hold of you via email or phone and more or less flag your RFP in favor of trying to get you to like him. He's good at this too. If you end up talking to him, you probably will like him. This is better than the other two because at least it forces a dialog. Often times the sales guy will say and do whatever to win your business. Your project doesn't need "whatever".
Okay, so now you've got a good idea about how the RFP culture is full of it and not what your project really needs. You need to open a feedback loop with a technology expert who is genuinely interested in winning your business the right way. That's not easy to do, so that's why vendors don't do it (it's much easier for them to smile and take your money, right?) Find a technology consultant and start a productive dialog that can work through your ideas and project tasks to give you a better feeling of how they think, if you enjoy working with them, and if you agree with their reasoning and the solutions they come up with.
"But Ryan", you say, "how can I do this on limited time and resources? I don't have a lifetime to be shooting the breeze with technology consultants day-in and day-out!"
The right way to go about it
What you're looking for probably isn't really a proposal on how to achieve every little aspect of what you think your project entails (again, you need to leave it up to an expert to let you know what your project entails and how it should be solved with technology). You're likely just looking for some demonstration of expertise on part of the candidate. Any great development team should have a plethora of case studies, portfolio items, white papers, and testimonials available for your consumption on their company's website. You don't have to setup meetings with every company, but you do have to stop being lazy and do a little homework. Stop expecting for great things to be thrown at you. Stop expecting this "set-it-and-forget-it" RFP process to yield results. If you go this route, you'll get what's coming to you: junk.
Get on the same page with a company's values. Read their case studies and check out their testimonials. Have they demonstrated results with previous clients? Have their clients given positive, meaningful testimonials that backup these results? Do they have an extensive portfolio of relevant work? Do you simply like them? You'll be surprised how fast you'll be able to cull down a list of 50 or more candidates for the job.
If you're looking for a serious approach to ironing out the functional and technical specifications of your project, to get it done the right way, you'll definitely want to check out our Roadmapper service. Roadmapper will prepare you with a precise project blueprint that you can execute with any development firm of your choosing. Start off on the right foot: have the confidence you never had when creating your own RFP with Roadmapper.