How to: Develop an Effective Web Development RFP
It's a sign of the times I guess, that more than ever, folks are exercising their 'due diligence' in their business deals, making sure that nothing is overlooked in the quest for value and efficiency.
We are doing that ourselves, and it's one of the positive outcomes of this economic environment. We're all going to work harder and be more efficient, or we might not survive. It's the Law of the Jungle, come to the business world. Adapt or perish...
So I was neither surprised nor disappointed when a prospective client we've been talking to for a couple of years informed us that they were required by their corporate governance to create a Request for Proposals for the project we have been discussing, and solicit several competitive bids. As I said, it's a sign of the times.
I said, "Let me give you a little guidance, and make certain you're covering all the bases". Following is the outline of the conversation we had, and while it's not comprehensive enough to cover every type of web project, hopefully it is at least a good place to start.
- Define the goals: Ground your RFP (and your project) with a clear description of what the business objectives of the project are, and always try to keep these in mind as you go through the development process. It's easy to get distracted by stuff that is secondary to that if you're not mindful.
- Identify the Target Audience: Define the audience(s) that you are primarily intending to serve with the new site. Establishing the order of priority of those audiences is also a worthy exercise. Examples for this client included: Prospective Customers, Existing Customers, Prospective Employees, Business Partners, General Public, and finally News and Press.
- Explore Use Cases and Define Calls to Action: Having defined what you're trying to accomplish and who you're trying to reach, discuss the actions you wish the audiences to take.This will in turn lead you to some exploration of what content they would need to find and what calls to action are appropriate in order to induce the desired behavior. This can be quite simple, eg: 'Contact us for a free price quote', 'Send us your name and address and we'll send you our free guide', 'Apply online for a position', etc. These are those all-important 'calls to action' that are so often overlooked.
- Explore the Information Architecture: Having outlined your objectives, audience, use cases and calls to action, what are the high-level content categories you envision? You can either provide a simplified draft of the high-level architecture desired, or ask the developer to propose one that they feel will execute on your objectives based upon their own experience.
- Define the Brand Guidelines: Is there any guidance for the developer to help them stay within the boundaries of your branding? Or do you simply want them to pick up elements of brand and style from your existing materials and make it harmonious? Is there another agency that you work with that can provide guidance, or source materials and specifications for color, typeface, or usage of your logo?
- Explore the Technical Details: If you have any requirements for content management, even if they are generalized in the fashion of "The site must offer content management tools to allow non-technical staff to maintain frequently edited content on the site", then put them in there. Do you desire integration with any internal business systems or processes? You also want disclosure of the server platform and underlying component technologies proposed, and any licensing fees or third party software of applications that will be utilized, including any potential cost as part of the project, either in development or ongoing licensing fees post-launch.
- Discuss the Content: Say who's providing it, and whether or not you need help shaping or editing it.
- Discuss Photography, Illustrations and Graphics, including stock: Indicate if you're providing it, or if you want the developer to provider or shoot it, or if stock is planned-for, and any fees associated with any of that, initial and ongoing.
- Discuss Maintenance: Where will the site be hosted, who owns/pays for the hosting, who is going to maintain it, what is the fee basis? Is a retainer required or desirable?
- Discuss Continuity: What happens to the site in the case the business relationship ends? Can you continue to operate, extend and maintain the site in the event you part company with the developer, or if they turn into a pumpkin? Will you have the source files for the project post-launch, and more importantly, the right to use them?
- Ask for References: I suggest a two-pronged approach to this. Ask for the three most recent projects completed (including date started, date launched, and client contact) and optionally three others from their body of work that they feel best represent elements of the scope of work they have proposed to you. Then call the references, without fail, and ask them the most pointed questions you can. Did the project come in on time? Budget? If not, why? Do they feel they got a good value? How has the service and support been post-launch? Are they responsive, do they answer their phone and return calls or emails promptly? Overall are they happy?
- Disclose Budget and Desired Timeframe: You don't do yourself or the companies you contact any favors about being coy about your budget, or by not establishing one at the outset. Even if you reserve some of the overall budget you get for unforeseen scope creep or expenses, tell the companies you contact what you have to spend. If any decline to respond on that basis you did each other a favor. If you announce your budget you will be certain that all respondents are qualified within that budget, and vice-versa.
- Outline Projected Schedule: Indicate when you'd like the project to kickoff, and when you'd like to have it completed. For a primarily marketing-focused project like this client's, 90 days is a good end-to-end rule of thumb, but if you want/need it faster, you'll probably get it, especially these days. Make certain however that you're clear-eyed about how much work it will be on your end to keep up with the developer before you do put the pedal to the metal though. In our 11 years' experience, 80% or so of the project delays we experience are attributable to delays in receiving content on schedule or timely feedback from the clients as agreed. It is still a lot of work on the client side to produce an entirely new site.
- Outline the RFP Process: Outline the steps you are going to take during the RFP process, the basis upon which you will make your decision, the timeframe for review, the dates you will conduct follow-up interviews/presentations (at your invitation after receiving their response), and the process for responding to questions or requests for information-gathering meetings before their response. You should also indicate the date they can expect a decision, and on behalf of everyone you talk to, please stick to it. It's no fun on the vendor side hustling to hit submission deadlines only to have the hiring decision delayed indefinitely, and that happens all too often.
Statements and opinions expressed in this blog and any comments made are the private opinions of the respective poster, and, as such, iMarc LLC is neither responsible nor liable for such content.
Visitors
Read something more recent.