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