The most important document of your Internet business may be your request for proposal (RFP).

Here's an insider's guide to writing that document.

Could that giant sucking sound be your company's resources being drained by Web site development? Many companies misjudge the cost of building their e-commerce sites, underestimating everything from labor fees to resources needed to integrate the new site with existing systems. When late in the process these unfortunate businesses realize they're trapped in a technological money pit, skewered by change orders and bleeding red ink all over the place, it's too late to make the project fit the budget.

Before you think about hiring a developer to build or redesign your commercial Web site, think again. With thousands of dollars at stake, you can't plan too much. Long before you hire a solution provider, you must define the problem: who you are, what you want, what you can pay for it, when you want it, and what it will do for your bottom line. Consulting with a development company like i-Commerce Solutions, and taking advantage of our FREE Strategy Session, can help you get a handle on these questions.

More and more companies are addressing these issues by writing requests for proposal (RFPs), site-planning documents to be sent to developers in order to solicit project bids, just like other business needs are sent out to bid. An RFP is like a business plan for your site: It defines site structure and ties that structure into the business's goals. Detailed RFPs identify business objectives and problems the site addresses, expectations of what the site will provide, the site's audience, the business's expectations, the resources (human and technological) the business can commit to building and maintaining the site and a development timeline and budget.

A well-organized RFP can mean the difference between tying together a bunch of haphazard Web pages and building an integrated site that is of maximum usability to your audience - and to your bottom line. As a proposal, it will help you find qualified developers who can meet your needs and help ensure that the development process stays on target and on budget with minimal conflicts, changes or ambiguity.

As vital as an RFP can be to your site's success, you can go overboard. Development cycles are so long and companies can change so fast that change orders are almost inevitable. If an RFP is so detailed that it does not allow flexibility towards the changing needs of your company, it can actually harm site development. In extreme cases, RFPs define the architecture of a site to such an extent that the site cannot scale to business needs.

Setting RFP scope

There is no standard structure for RFPs. Determining the scope and depth of an RFP depends largely on your company's structure, what you want from the development process and the desired site architecture. Some companies write less structured RFPs because they feel they have too little expertise to evaluate the technology necessary to actuate their site ideas or they can't spare the internal resources required for an involved drafting process and don't want to hire a consultant. Some businesses prefer to let developers' proposals help them refine their site vision.

Although loose RFPs keep the field of potential developers and ideas open, they shift creative responsibility from the client to the developer. This shift is not necessarily advantageous to the client company: Relying too heavily on unscrupulous, under qualified, or otherwise unfit developers can lead to the client disliking (or misunderstanding) project results, being unable to evaluate the work of the developer in terms of the company's business and site goals, or rejecting the price tag associated with its new technology.

Budgets, in particular, tend to suffer omission from RFPs. They represent a major rift in philosophy between the companies that issue and receive the documents. Companies may omit budgets from the RFP because think if they say how much money they want to spend on the project, that's the proposal amount they're going to get. We would rather see any proposed budget, even if it's unrealistic. When we have a budget, we can say "Here's what you can get for your proposed amount, and here's what it will take to get what you want."

Otherwise, the open-numbers tactic can backfire, encouraging companies to envision sites they ultimately can't afford.

Developers might also interpret a loose RFP as an indication that a company is unprepared to tackle the issues that will arise during development. As a rule of thumb, the more you nail down the specifics of a site and proposal requirements in your RFP, the more uniform the responding proposals will be and the better you will be able to evaluate them. In addition, detailed RFPs let you more easily meter the progress and quality of the chosen developer's work. Although very specific RFPs allow less opportunity for developers to be creative, many companies preparing to commit major money to site development are happy to exchange this element of uncertainty for the comfort of understanding exactly what they're buying.

Build your ultimate site in phases

Strict RFPs can also lend themselves to segmentation. This tactic can be useful if the project requires budget approval or when the desired site exceeds a chosen developer's capabilities. In the former situation, a project's large price tag can also be its toe tag: Funding is often more readily given for several small projects when it's rejected for a single large one. Developers may bid on segmented projects a la carte, taking only segments they can handle and deferring others to more appropriate developers, with whom they often form strategic alliances to meet specialized needs on certain sites.

Is it possible to have too much detail? There is danger in overly specific information: It can lead to problems if the company decides it wants something different from the RFP specified, or if the developer suggests a detour in the development route. Unless designed to be scalable, a fine-tuned RFP can be difficult to alter in midstream. Change orders can wreck budget targets as well.

Ultimately, all RFPs-whatever their specificity and structure-require forward thinking. The goal is to build into them ways to economically and efficiently introduce changes and to allow changes to be made without wrecking the integrity of the whole plan or site architecture that's already been built.

As an RFP writer, you should also limit the resources you dedicate to your RFP within the scope of your entire site development. The RFP is a critical tool to getting what you want, but it's unwise to spend half of your project's time and finances planning your site when the bulk of its costs lie in creating site architecture. No matter how tightly you plan, you can't solve all of the Web's issues with one site design, and you never know what's down the technology pipe.

Writing useful RFPs

An RFP should contain enough information to give potential developers a good feel for what you want. It's generally to your advantage to give bidders as much information as possible, and good RFPs also include ways for vendors to contact the client company with questions. This could be an email or snail mail address or, for large projects, a live Q&A forum open to all bidders.

If you don't know what you want or how to write an RFP, arrange meetings with developers or hire a consultant. Some Web developers, like i-Commerce Solutions for example, will be happy to help you for at least a couple hours, even if you don't promise them anything in return. The best thing a developer could want is to write the RFP. At least it gives them a true idea of what the client is looking for.

Getting help can promote good company-developer relations no matter what your estimated expertise level. In reality, some developers don't trust RFPs written by client companies, suspecting the companies lack the technical expertise to accurately describe their project.

"Sometimes, companies don't have the expertise on board to know what they need. They might choose somebody who is not very good to be the developer of their Web site. Anybody can put up a pretty Web site. That is why at i-Commerce Solutions we say, "e-commerce is more than a pretty web site." There aren't enough people out there who have the technical expertise to see beyond the pretty picture, and thus they could be hoodwinked.

Arm yourself against missteps by yourself and potential developers by analyzing your company's structure, selecting who will be involved in planning the site, identifying organizational or departmental goals that drive site development, listing measurable effects that the finished product should produce, gathering information on financial and employee resources you can dedicate to site development and maintenance (be generous in your estimates) and setting a realistic timeline for development. Getting your ducks in a row before you call in a consultant will benefit your bottom line.

Additional pre-RFP resources include magazines, conferences, business associates and any other sources of information on concepts related to your project, particularly as you examine your competitors' sites, and other sites that you find useful. Your own knowledge about Web sites will help you participate proactively in the RFP writing process and enable you to meaningfully double-check consultants' ideas.

Be realistic about your project timeline. You'll want to see your plans come to fruition quickly once the RFP is completed, but be wary of proposing deadlines that neither your company nor a developer can meet. Write proposal deadlines into the RFP, bearing in mind that many developers require weeks to respond with proposals and that the amount of time it will take to generate a proposal is directly related to the complexity and demands of your RFP. You don't want your RFP or the developer's proposal to hog-tie anyone, as exciting ideas are generated along the design process. More important than nailing down all the details you both can think of is finding a Web site development company who can show you good work that they have completed, and with whom you communicate well and enjoy working! It's a long process, which continues after your site is launched with a good company that stays on top of how your site is doing, and will work with you to continually improve the internet side of your business.

Adapted from an article in Puget Sound Computer User
January 2000