One of the most frustrating gigs I ever bid on was a project for a local university.

My consultancy got most of our clients through direct inquiries or referrals; for the most part, we completely avoided the RFP game. In my mind, it was on the same level as spec work.

An employee of mine let me know that his former employeer, a local university that we had strong ties with, was looking to upgrade the internal ticketing tool their IT department used. What made this project really appealing was that this employee used to be on the in-house development team that built version 1.0 of this tool.

In my mind, we had this project. The guy who wrote the original app worked for me. We were local. We knew quite a few of the higher-ups at the university. And, in our opinion, all the other local custom software shops were rigid government contractors who couldn’t compete with our team, who were pros at building web based software.

But we didn’t get the project.

I was bummed. On paper, we were the right choice. I’d gone to the Q&A meetings and met the other companies competing for the contract. They were non-technical salesmen! How could the university be so stupid?!

Well, at the end of the day, I broke the RFP rules. I treated this RFP like any old project request. I failed to realize that my proposal would be read by a procurement officer, and not the IT team backing the project. And I failed to realize that I was pitching my consultancy against fiercely competitive solution providers.

(Note: Outside of the US, RFPs – or a Request for Proposal – are often called “Tenders”.)

Don’t treat RFPs like normal project proposals

Anytime you’re writing a proposal, you’re responding to an RFP. If someone calls you about a project, they have a request for [a] proposal. But the RFPs I’m referencing in this article are written documents that are sent to a number of different companies (vendors), or posted to a directory of some sort.

Some companies, especially larger firms and government agencies, require that any outside vendor be recruited via a public RFP process. This is done to keep costs low and with an air of fairness. The idea being that the people in charge of a project can’t spend their budget on their brother-in-laws company or a golf buddy.

The mistake I made, and the mistake many consultants make when responding to an RFP, is that they treat it like any old proposal. They get creative. They get personal. They don’t play by the rules.

Because an RFP typically gets a bunch of responses, often these RFPs are structured and require that responses follow the specified structure. You might have the best, most badass proposal in the world — but the people vetting these proposals want to shorten the stack of proposals on their desk. They love throwing out otherwise solid proposals on technicalities.

The people who need the project don’t always write the RFP

At larger organizations, RFPs are written by a procurement team. Let’s say you’re running a university. It requires a lot of external stuff to keep the university in business: Projectors in each classroom. Toiletpaper. A well-manicured campus green. And, yes, ticketing software for the IT department.

This can lead to some seemingly strange wording within an RFP. What’s the cost per seat? Are updates free? How much downtime has your product experienced over the last few years? If you’re used to building custom software or custom websites, this wording makes no sense. The per-seat cost is… uh, the marginal overhead of a new record in the user’s table. Updates… free? What? Just hire us if you need more work. Downtime averages? This thing doesn’t even exist yet!

These were things that confused me, but it’s because I was inexperienced when it came to writing responses to RFPs. You see, the procurement officer is used to working with vendors, who supply parts and solutions. Projectors in each classroom? Sure — how many classrooms do you have? We’ll multiply that by a unit cost, and even throw in a volume discount.

But when they’re working with someone like you, who is likely not selling something off the shelf, but instead the result of your technical know-how multiplied by some amount of time, it’s hard to cast your proposal in the terms they’re looking for.

They’re going to usually want a fixed cost, and a fixed deliverable (the “solution”). To them, there’s probably not a ton of difference between getting a new website and buying a license of Microsoft Office. They’re also going to usually dictate milestones and even the scope of the project.

Propose a solution, not your time

If you want to win RFPs, start thinking of yourself as a solution provider and not a consultant or freelancer. RFPs are not for everyone, especially if you’re unsure about your ability to estimate large projects. Typically, it’s rare to find a time & materials project; you’re typically going to be asked to provide a fixed timeline, budget, and deliverable.

• Follow the structure and rules of the RFP. The easiest way to ensure that your proposal ends up in the wastebin is to not play by the rules.
• Pretend you’re a software vendor. Imagine what they’re asking for can be bought off the shelf — how can you position and describe that, even though it’s going to require you to do something from scratch?
• Propose a solution that’s custom-tailored to them and their specific needs. Ignore the fact that you’re capable of doing anything for just about any industry given they’re able to pay your rates. Your solution should be presented as the perfect fit for the “parts” they need.
• Don’t forget to include a maintenance package. They’re going to expect that anywhere from 10% to 20% of the cost of the solution as a maintenance package — and this probably isn’t a bad thing. They’re basically asking you to put them on a retainer.

RFPs aren’t for everyone. They can be time-intensive and yield few results. Also, I soon discovered through working on a few government contracts that RFPs, which officially mandated, are often written in such a way that only one provider (read: the buddy of whoever’s issuing the RFP) can fully satisfy the project.

It’s a lot more lucrative to source clients directly through some of the ecosystem-building techniques I’ve described in the past. However, challenging yourself with the occasional RFP or two can possibly get your foot in the door with resumé-boosting organizations. I ended up working with a major non-profit, a big client out of Asia, and a few Fortune 500s because we learned how to respond correctly to the RFPs that came across my desk.