We're currently in the process of building a new website to replace our very dated Drupal 6 site. In January 2015, we put out a Request for Proposals and received 43 proposals in reply, far more than we expected. In the process of giving each equal care and consideration, we learned a lot about what we could have done better, what worked for us and what left us scratching our heads. In gratitude to those who gave us their time and effort, we wanted to share our takeaways from the process.
What we could have done better
Upfront soul-searching. In hindsight, we could have spent more effort defining our priorities. Approaching an RFP with wide open arms tends to result in an armful of RFPs. Had we trusted our instinctive preferences, say for a local partner and building the site in Drupal 8, we'd have saved ourselves, and dozens of firms around the world, an awful lot of effort.
Better communication. We should have set up an FAQ page from the get-go and announced it on the RFP, alerting folks that it would be updated continuously as new questions came in. We also should have scheduled a conference call for live vendor questions.
More detail beats less. Aiming for that fine line between giving too much information in the RFP and too little, we undershot. As a result, we spent a lot more time replying to questions than we anticipated. Overshooting seems a better option.
But a narrow focus beats a broad one. Along with greater RFP detail, we could have been more concrete about what we really wanted. Had we just stated outright that we only wanted to see Drupal 8 proposals, or been more explicit that we would accept full, design-only, and tech-only proposals, we might have saved Meyer — and potential vendors — time.
Team size matters. After looking at 43 proposals, we knew we didn't want a generalist freelancer or two doing the Drupal — a scenario we could have handled in-house. In the end, we discovered we needed the experience, best practices and processes more common in teams of specialists.
Of course, vendors might have more input here and we'd love to hear it and share it. Comment below or gkruger [at] mmt.org (email me) if there were things you wish we'd done better. Please don't mention the need to phone us directly though. It is impractical to accept calls from 43 firms (and often there were calls from more than one person at a firm). It was also frustrating when callers made hard-sell sales pitches, something our receptionist had to wade through, or attempted to trick us into revealing information we did not intend to share.
What we wished we'd seen
We looked at each website redesign proposal as a preview of a vendor's site-building abilities, professionalism and working relationships. If a proposal showed poor attention to detail or subpar communication skills, and if it disregarded instructions or contradicted the RFP, we took it as an indicator of how a vendor operates. Mediocre, cookie-cutter proposals, which might have had a shot in the absence of competition from other vendors, didn't stand a chance with us.
We get it: some vendors believe responding to RFPs is a waste of time. A San Francisco firm we'd heard great things about from other foundations told us upfront they no longer bothered with RFPs, instead prefering direct invitations to take on assignments. We appreciated their candor. But for those firms that choose to respond to RFPs, consider these tips to put your best foot forward. Many will seem obvious but we saw proposals with multiple examples of them:
Read the RFP and respond to what it asks for. Failing here will mostly get you rejected and certainly wastes time, including yours.
Respect the stated preferences. If the RFP says "no calls," then don't call. If it says "PDFs only," then send your documents as PDFs. Sometimes the requirements are a test to see who is paying attention. You'd be surprised how often people don't pay attention, and inattention is a poor trait to build a partnership on.
Proofread and spell and fact check. Among the RFPs we considered, we discovered accidentally included information about other clients and we were invited to drop by the office of a vendor located the other side of the country, etc. Feel free to use an RFP template, but take care that mistakes are fixed before you press send. You are selling attention to detail. Skip this step at your peril.
Line up your ducks before submitting the proposal. Sales, tech and management staff MUST be in sync on what you can deliver. If, for example, sales makes a promise tech can't support, your pitch will end up in the reject pile.
Be organized. Name your documents with both your firm's and the proposed client's names, e.g.: Amazing Web Firm Meyer proposal.pdf. Trust us, juggling 43 proposals named Meyer proposal makes for a massive headache. While we're on the subject, why not send just one document, not a proposal plus six separate resumes plus an appendix plus a document of examples... just one document. See massive headache, times nine.
Put your name on it. This one seems obvious but make sure to put your firm's name on the front page of your proposal. While you're labeling stuff, use page numbers and maybe include your name and the client's in the footer. It helps a lot.
Be succinct. If you're responding to an RFP that asks for a website that is less cluttered, less wordy and less overwhelming, think twice about sending an 80-pageAbout Us addendum. It is unlikely to be read — and may harm your proposal more than help it. Keep it short.
Your own site matters. It's your storefront and reflects the work you do. It is difficult to believe a vendor when they tell us how important great branding and an excellent website are if they are not doing these things for themselves. Out-dated tech, unresponsive design and the bad visuals will count against you.
Highlight how your examples fit the project. Tell us what you did. Among our favorite proposals were ones that pointed out which pieces of a previous project a vendor tackled, and how those pieces fit our needs. If you propose working with a partner you've worked with before, show us that work. If this is the first time partnering then pick examples of both firms' work that reflect what might dovetail with the client's project.
Highlight your expertise. Pick examples that showcase your technical capabilities and experience. Show sites that look like what you're proposing, that demonstrate current best practices and that use the same software (I used Wappalyzer to tell me how websites were built). If you have any prior clients in our industry then highlight them.
Stalk us. Okay, that may be overstated but it is nice when a proposed partner takes the time to get to know the client. Take a close look at our existing website and scan our social media. Notice what industry your client belongs to and tailor your pitch. Bottom line, you'll avoid silly mistakes, like calling a foundation a company or telling a nonprofit how your work will increase sales.
Remember who you're talking to. You are setting the tone for a business partnership. Being talked down to feels icky. Assume you are dealing with an intelligent, capable and highly motivated team. Look to the tone and content of the RFP to see how much explaining you need to do. For example, in our case we had a Drupal guy on the team (me) so we expected to field high level tech questions, from one pro to another.
Provide clickable URLs. You want the client to see your work, right? Making someone Google your examples to take a closer look is not what you want. Why? Well, if your work doesn't show up in the first few results, it may just draw my attention to your poor SEO skills.
Show us your team. If we ask for resumes of the team then give us the entire team we'll be working with. Not your policy? Then give us some reassurances about the level of developers you'll put on the job. Don't just give the resumes of managers who won't be integral to the project. And if you provide links to staff member's LinkedIn profiles, make sure they are up-to-date.
Make your best case. Say we state a preference for something specific, a like a type of software or a certain number of logo revisions. If you have a better idea, make clear the benefit we'll enjoy by doing it your way instead of ours. Alternatives without justifications left us feeling like we weren't heard.
Face up to technical challenges. If there are stumbling blocks we want to know that you are aware of them, that you want to be sure we know about them and that you are up to the challenge. For example, we requested Drupal 8 well ahead of its release date (read our reasons) so we were hoping for proposals that highlighted both the challenges and your confidence and competence to overcome them.
Be realistic about budget. Don't leave anything out. It can feel like subterfuge when surprises pop up. And if you win the RFP sweepstakes, be mindful of what you promised, and at what cost. Your client surely will.
Don't nag. We're not your only prospective client; you're not our only prospective vendor. Nagging makes people exhausted. Nagging before the RFP even closes leaves a bad impression. An email that politely says, 'don't call us, we'll call you' means just that.
Ways to improve a proposal for a Drupal or other tech website
If you're bidding based on a specific CMS or other software then show us your chops and those of your staff.
Link to your staff members' Drupal.org profile. Or link to a similar professional profile that shows your team's community standing, skills and contributions. And make sure the profile is filled in. Empty profiles do a vendor no favors. Also, consider that the client might read your proposal offline so offering a preview can be very user-friendly.
Open source communities are gift communities. Nonprofits have a lot in common with free and open source software (FOSS.) Showing nonprofits that you also give back is a good thing.
Don't explain to us what we already know. If we asked for a Drupal site then we already know why Drupal is a strong choice, so you don't need to tell us how awesome it is.
Watch your building blocks. This one should go without saying: Whatever you do, don't build your company website using Weebly, Webs, SquareSpace or any similar service aimed at non-coders, unless you are suggesting we use it too.
Equity and diversity
One final thing to discuss is diversity.
Tech is a field with a notorious lack of diversity. It is predominantly white, male and young and the data suggests that we're driving diversity away at every level, from high school through college to mid-career. Most firms don't question this or how they might be part of the problem. They wrongly throw their arms up and say the problem is too big and not their fault, enabling them to ignore the issue.
Equity and diversity are vitally important to Meyer. We stressed it in our RFP, and it's front and center on our website. In the majority of the proposals, there was no acknowledgement that equity and diversity matters and stock photographs showing predominately white, predominately male faces. Obtuse? Arrogant? Either way, we didn't feel listened to.
Diversity matters not only because it's right, fair and just, and because more and more of your clients will be looking for it from tech firms. It also matters because it makes firms like yours more productive, profitable and competitive. Sound like a crazy claim? Well, then you really need to watch Erynn Petersen's Keynote from the most recent DrupalCon on the financially measurable value of well-managed diversity in the workplace. She backed it all up with data and studies for which she included citations and references. Watch it and take note.
Wrap-up
The RFP process can feel an awful lot like online dating. You're comparing choices, trying them on for size and making decisions based on your best understanding of an possible partner.
Everyone can't make the final cut. But a number of firms that we did not select nonetheless grew in our esteem. We were impressed and grateful to have gotten to know them better. We regularly make recommendations to others in the nonprofit sector and we now have several new firms that we can point to. Though they didn't get this gig, they still may gain and there's a lot to be said for that. This backs up all of the above, which is to say do RFPs well, or don't do them at all.
— Grant