Website RFPs (Requests for Proposals)
We just lost a bid for a website through the Southwest Florida economic development alliance. I’m not going to gloss this post over and pretend like I’m happy, like “hey you win some you lose some.”
This post isn’t about that project specifically, instead it’s about Website RFPs (or requests for proposals) also called Website RFQs (requests for quotes) and how ridiculous they are in our line of work and why – if you’re considering doing them as a company or organization, you should probably reconsider. EXTRA BONUS – at the end I will outline (if you have to do an RFP) some tips for making it more effective. Atilus has helped lots of larger organizations refine their RFPs after they sent them, in order to provide the best return on everyone’s time and efforts.
What is a Website RFP (Website Request for Proposal)?
A website request for proposal is simply a document an organization/company sends to a prospective vendor that says – here’s what we’re looking for. You then get it in the hands of vendors you think make sense, have them fill out the details, review the answers and select the final vendor. In theory this makes sense, in reality, in practice, in my experience (working through dozens of these over the past couple of years) it doesn’t work in our industry.
(I have to wonder if it works in any industry)
Why Website RFPs Suck
The sale and execution of a website, is equal parts Art | Social Engineering | Experience | Project Management – and that’s all before the project
contract agreement (thanks Kristen 😉 is signed. Atilus has a process, every dev company worth it’s weight has a process when it comes to sales and proposals, and messing with that process doesn’t make sense – we’re supposed to be the experts on this stuff. Organizations considering a web project and having to vet various vendors should rely on those vendors’ processes to guide them (more below). In fact I think this is one of the most important things you should evaluate in selecting a vendor – their normal sales process.
Many RFPs dictate the formatting of the final proposal. Take a look at the above Sales Process argument as to why this sucks and understand – it not only takes the company you’re soliciting extra time to format things the way you want, but it also doesn’t make sense. Often times the information being asked for – is included in the first line(s) of a vendors’ website. This in and of itself can be a qualifier – how well does the vendors’ own website speak to my needs and answer my questions?
This is one of our least favorite (and most ridiculous parts of a RFP). Let’s break down the process:
- Time to form the committee
- Time to Form the Website RFP
- Time to Figure Out Who is Going to Get the RFP
- Time to Explain the Website RFP (follow up phone calls that should be done by vendors)
- Time to Form the Proposal (as a vendor)
- Time for the Initial Selection (by the committee)
- Time to Pitch (as a Vendor) and Time to Hear the Pitch
- Time to Pitch Again (many include multiple pitch presentations)
- Time for Selection….
Typically an organization will form some kind of committee to select a web vendor THEN they’ll collectively create an RFP (with all of the communication/back and forth involved) THEN they’ll submit it, then we (Atilus as a potential vendor) typically need more information about the project to provide a truly accurate quote (so anywhere from 1 – 10 phone calls depending on decision makers’ availability THEN we’re typically asked to do a number of oral presentations (on this last one there were 2) and finally a final vendor is selected.
All of these extra hoops take time (as you can see), and costs everyone more money – either the vendor eats it or they inflate their prices to accommodate the hoops a lose-lose situation.
This (Web) Stuff is Complicated
Great web development is complicated. It involves marrying your business or organization’s needs with a web company’s capabilities. It’s our job during the sale and the “getting-to-know one another phase” to get exactly the information we need from you and then translate that into something more technical our entire team can execute to accomplish your goals. Speaking of Goals…
Who Are You & What Are You Trying to Do?
I’ve never seen this on an RFP, ever… period. Most RFPs don’t even have a paragraph about the underlying organization. What I do see is a list of technical requirements that (generally) don’t make sense. The most important thing is getting to know your business or organization, and at it’s most basic – what you’re trying to accomplish. You MAY think you want a website, a redesign, or hosting – but in reality, you really need a reliable partner that knows the web and that will help you attract more business.
But with a sterile RFP the above isn’t communicated. RFPs generally start 2 or 3 steps into the process and are addressing the technical details that great clients rely on us (Atilus) and the trust we build with them to make together. An analogy that I think might be helpful here – If you were soliciting a lawyer to help you draft a tight-contract, you wouldn’t dictate the software he used to draft the actual document or the keyboard he needed to type it on. Instead you’d tell the lawyer you’d like to protect yourself with a contract. Unfortunately in our industry we encounter this all of the time within RFPs and it has little if any bearing on the outcome of the project.
What do you want vs. what do you need?
This is closely related to the previous one although there’s an important distinction. You don’t know what you need. You know what you want. An RFP typically defines what you want (again 2 or 3 steps too far into the process). What you need is different. A recent RFP mentioned “wordpress” but because of the organizations larger goals – they needed something else. It’s our job again, to know the tech and marry it to goals – and this includes a stair step process – as not every organization can immediately afford the right solution so instead we work with clients to select the BEST solution for the moment (based on budget, goals, etc.).
Who do you send this to?
We’re the largest web development company from Tampa to Miami. Arguably one of the largest ad agencies as well. We specialize COMPLETELY online. We’re involved heavily in the community. However, we never received this latest RFP? Why? We weren’t on some arbitrary list. The problem with RFPs – is that at best you’re making the right choice – from what I’d argue is the wrong group of companies. The creation and selection of the group of vendors you’re going to send your RFP to should include initial research from the online space, and from local businesses. Look at who has the most successful websites in your area and canvas those organizations or companies to further refine/grow your list.
On a final note we believe RFPs can be a good idea, but that they should be saved for large projects with large budgets – I’m talking hundreds of thousands to millions of dollars. There’s a risk-reward factor we’re looking at as a company when we look at an RFP. Most RFPs end up being too complex, the processes around them too time-consuming, and the underlying projects, too simple to warrant that kind of bureaucracy.
How to Craft a Great RFP
With all of the above being said – there are clearly cases where Website RFPs are needed (or even required). So we’ve developed this quick list to help you through the process.
Exclude Basic Requests for Information That Can be Found on a Vendors Website – For example, company history, team, etc. any information which isn’t normally a part of a company’s proposal should not be asked to be included. If they decide to be included by the vendor great, if not, it should be readily available on their site. And if it isn’t use that as a qualifier.
Apples-to-Apples – Provide a framework to allow each vendor to both execute their sales process, but also understand how you’d like to communicate. We think it’s vital to coordinate the RFP process around each individual vendors’ own sales process in order to get a better sense of the structure they’ve created as a company. Organizations submitting RFPs need to stop thinking that sales is a separate part of a company’s structure from their technical proficiency. In fact, I’d argue it’s the most important tool – as we have to learn as quickly as possible (without spending too much time and money as we haven’t yet been awarded the project) who you are and what you’re trying to accomplish, and merge that with our technical proficiency to structure and plan the project. There’s no larger step in any project or new client relationship than the initial sale. If you get it right the project is a success and goals are met, if you get it wrong tens or hundreds of thousands of dollars go wasted.
Parameters, Budgets, and Goals – Be absolutely clear on any parameters, budgets and goals – and define them. If some items (like hosting) are flexible, but you’d prefer to implement a certain way – include this. If other items (budget) are hard and fast and can’t be manipulated – say so. And finally goals are the single most important element we find missing on every project proposal request. Tell the firms your soliciting what your goal is and be clear. Try not to include any technical elements in this section. A great sentence or two for a goal might be: “We’re trying to unify the messaging, efforts and moneys of the 5 county southwest Florida region in order to retain, grow, and help small businesses prosper while attracting site selectors at larger companies from around the country to the region with an attractive easy-to-use website. Our total budget for the website and marketing is $50,000.” – With this handful of sentences we’ve been able to understand the mission of the organization, as well as the audiences. We can then perform research on these audiences, what’s important, and provide a site that meets these goals.
Time – Everyone’s queue is different. Right now at Atilus we’re setting sales meetings for 2 – 3 weeks in the future. Consider that better firms might take a longer time to get the sales materials ready and schedule meetings/calls for more information. Based on our experience we recommend at least a 3 week prep time from initial RFP to final proposal delivered. This will give both you and your vendors time to talk, brainstorm, and get everything down in a proposal.
Be Flexible – Because every company and vendor is different, it’s important to remain somewhat flexible when it comes to the items in your RFP. One of the best RFPs we ever saw, didn’t allow us to directly communicate with the company. We ignored this and requested phone calls and meetings in order to get a better sense of the project. We’d prefer to break the rules and provide a great experience and fantastic service/product, then stick to the guidelines hoping that alone would win us the project. The potential client (LCEC) was hesitant at first, but we were able to learn information that was vital to the success of the project and ended up beating out other top firms in the State of Florida. They’ve now been a long term client and we’re happy we made the decision to bend the rules a bit – and that LCEC was willing to communicate with us beyond what was included in their RFP.
If you have any other tips, suggestions, or questions about website RFPs feel free to leave a comment or contact us for more information!