«Return to Blog List Why We Don’t Respond to RFPs: There’s a Better Way
Recently I got into a discussion on LinkedIn about Requests for Proposals (RFPs) and what makes a “good” RFP for web design and development. My position, basically, is that there is no such thing as a good RFP for web design and development, at least not following current “best practices” RFP models.
Why? Because successful websites are the result of collaborative efforts between clients and web developers. RFPs usually preclude collaboration by treating the process as furnishing a defined set of deliverables in a scope of work, with the vendor bound to furnish the deliverables as defined. Alternative (and often better) approaches are routinely dismissed in the interests of “comparing apples and apples.”
RFPs are a problem for everyone involved.
The problem for people writing RFPs is that few people or organizations are capable of defining deliverables in a scope of work in a way that allows for better solutions than they themselves had imagined, because they are rightly concerned with controlling costs. But defined deliverables usually means defined solutions, sometimes ruling out less expensive or more efficient alternatives. Things change rapidly in web development, and what was a good solution 12 months ago can be a decidedly inferior solution today. Even web developers scramble to stay abreast of changes, with varying degrees of success.
Further, few people and organizations are capable of evaluating proposals to sort out meaningful information from BS or fluff. If the best web developer/designer is selected for the project, it’s almost by accident.
The problem for those of us responding to RFPs is that preparing a proposal can easily consume 30-60 hours, depending on the scope of the project. We put some thought into addressing the specific items in the RFP, rather than making a few quick modifications to a standing proposal, and it takes time. Frankly, it’s time that could be spent more productively.
There’s a better way for both website owners and website developers.
Again, all successful website design/development is the result of collaboration between client and designer/developer. Aside from their ability to do the job, the most important thing you’re looking for in a designer/developer is someone you can collaborate with. I believe the following outlines a better way to find a collaborator and establish a collaborative relationship, one in which both parties work for a successful website within the agreed budget and timeline.
Figure out what you want to accomplish with your website. What are your goals? What are the goals of the people who might visit your website? What kind of functionality is necessary to meet those goals?
Figure out who your “audience” is (substitute “market” or “community” if more appropriate) and why they are interested in what you have to offer. Think about what kinds of online interaction with them would further your and their goals.
Figure out your budget. Bigger isn’t necessarily better, but some solutions are precluded by a budget that is inadequate to support them.
Look at websites similar to what you want. Contact the site owners and ask about the designer/developer. Would they recommend working with him/her? Include some local designer/developers in your research; often they will be more invested in your success (if your audience is primarily local, consider restricting your research to local designer/developers). Soon you’ll develop a shortlist of web people you want to talk to.
Call or email each of the designer/developers on your shortlist. Invite them separately to your office or a local coffee shop (or schedule a phone meeting, if they are not local) to discuss your project.
During your meeting, share your goals for your website (and describe functions you believe you need to meet those goals), what you know about your audience, and what your budget is. If they’re not taking notes and asking questions during this part of the meeting, you might want to cut it short. A good collaborator will be engaged and interested in this part of the process, and may even offer suggestions or observations that hadn’t occurred to you.
IF they took notes and asked lots of questions, find out more about them. Ask how they would go about helping you meet your goals within the budget you’ve described. Discuss timeline and try to get a sense of how focused they will be on your website. Ask them to walk you through a couple of websites they’ve launched, describing how they arrived at various solutions or solved design or technical issues. Ask about their business: not just how long they’ve been in business, but who their clients are, how they handle payments, and what kind of ongoing support they provide. It wouldn’t hurt for you to take notes for this part.
If you feel you can collaborate with them, invite them to submit a written proposal. The short proposal (no more than two or three pages) should include a description of the project as they understand it, recommendations for a general approach (project phases, technical platform, etc.), an estimate for both time and cost, and contact information for at least three clients who you can call to talk about their experience in working with the designer/developer. Do NOT skip talking with their clients.
When you’re done evaluating proposals (and checking out client references), you should have a pretty clear idea of who you can work with best. Once you make your selection, schedule a project meeting in which you and the developer map out a project plan.
On an ongoing basis during the project, you make decisions together about the best options to help you meet your goals; the developer as trusted advisor, you as final decision-maker. You are now on the path to a great website.
Tags: Business, Design/Development, LinkedIn
