The Art of the RFP
Yes, there’s also a good deal of
science behind the Request for
Proposal process, but the bottom
line is: When it comes to buying
technology, one artful document
can safeguard the process.
It’s Request for Proposal (RFP) season, so CA-based e-mail management and security vendor Mirapoint recently sponsored the Campus Technology-produced Webinar, “The Art of an RFP: An E-Mail and Messaging Security Case Study.” The Webinar was so successful—and the information presented
in it so universally valuable—that we’ve decided to publish highlighted segments of that presentation
here, for the benefit of our readers. Our thanks to Mirapoint for their work on this presentation, and to
Matt Villano, CT’s senior contributing editor, for his work as moderator of an outstanding panel discussion.
By this time of year, springtime rituals are blossoming like begonias,
and that’s true for higher education, too. Students move inexorably
toward the end of another year; professors get ready for summer session;
and in campus technology departments, CIOs and other decision-makers
furiously set their plans to purchase hardware and software for the fall semester. At most
schools, the annual purchasing routine revolves around official documents called RFPs.
These documents, which can be up to 200 pages long, serve as academic calls to arms;
ways for colleges and universities to notify vendors that they’re looking for new technology
solutions, and want solutions fast. Even for schools that have done it for years, the
process of writing an RFP is a daunting one—a rigmarole that requires time and
resources to complete. When handled correctly, however, the RFP process approximates
an art, and can yield huge benefits for everyone involved.
“We’ve used this process to buy just about every technology we have today,” says Roy
Teahen, director of Internet Applications and Systems at Baker College (MI). “When we
want to procure something new, an RFP is pretty much the only way to go.”
What Is an RFP, and Why Do You Need One?
No discussion of the RFP process can
begin without a brief explanation of
what, exactly, an RFP is. According to
Allen Eskelin, author of Technology
Acquisition: Buying the Future of Your
Business (Addison-Wesley, 2001), the
RFP is a tool that colleges and universities
can use to research and evaluate
vendors thoroughly. The document outlines
the specific functionality and technology
the buyer seeks, as well as the
potential for strategic partnerships and
the cost requirements for prospective
vendors. At the same time, the document
requests that vendor responses are
submitted in a predefined format.
"RFPs allow us to ‘cover our bases’
with the latest technologies—and help
us make sure we are including newer,
smaller vendors in the mix."
- Ellen Yu Borkowski, University of Maryland
Eskelin writes that because an RFP
requires so much input from each
responding vendor, the document both
directly and indirectly tells buyers a good
deal about the vendors who respond. If,
for instance, a vendor is meticulous and
thorough in responding to questions in an
RFP, it’s safe to assume that the vendor
will go to great lengths to win the
school’s business. If, on the other hand, a
vendor is not thorough at all, it can be a
sign to the buyer that the company has
other priorities, and d'esn’t value this
particular contract all that much.
“A sloppy RFP, chock-full of standard
literature, is a clear indicator
that the vendor didn’t feel your
business was worth a considerable
effort on its part,” writes
Eskelin. “An RFP tells you a lot
about the prospective vendors.”
Yet, there are a number of
other benefits to using an RFP for technology
purchases. For starters, because
all vendors receive the same document
with the same list of requirements, an
RFP offers a consistent platform for
researching prospective vendors. Next,
the document helps to solidify a commitment
and the expectations attached
to it, capturing in writing what a school
anticipates it will receive from a vendor,
and what a vendor promises to deliver.
In the event that a vendor misrepresents
its solution and a dispute arises, the RFP
serves as a legally binding document
that can be called upon in a court of law.
RFPs also help familiarize institutions
with their own requirements and
the technologies in the marketplace.
The process of creating an RFP forces a
school to define its needs in more detail.
As they prepare the document, schools
investigate the market, vendors, and technologies,
becoming keenly aware of
everything currently available. By documenting
these requirements, the RFP
formalizes the procedure, capturing the
decision-making process in writing.
Teahen says the RFP forces schools to
be objective in evaluating vendors, and
likens the process of hiring a vendor to
the art of hiring a new employee.
“In the case of acquiring technology
and building an RFP, you have to ask the
vendor the same kinds of questions you
would ask about having a human
resource join your team,” he explains.
“How is this vendor going to benefit the
organization? What types of attributes
d'es this technology have to have in
order to provide the service that you are
looking to employ?”
Was the vendor not thorough completing the RFP process? It’s a good bet this company has other priorities, and d'esn’t value your contract as much as it should.
The Master Plan
As Teahen explains it, the most important
part of the RFP process is researching the
document itself. At Baker, this usually
begins with a series of interviews. First,
Teahen and colleagues Google the latest
research on the technology they need.
Then they talk with users about the functionality
they seek. Next, the group turns
its attention to the market itself: If they’re
buying e-mail solutions, for instance,
they’ll get a sense of which vendor boasts
the biggest market share, and who is fading
fast. Finally, the team conducts a thorough
survey of the vendors themselves,
and what each has to offer.
The process is similar at larger public
institutions. Ellen Yu Borkowski, director
of Academic Support for the Office
of Information Technology (OIT) at the
University of Maryland, says that her
organization puts together a unique
committee of representatives to research
each RFP, and notes that the school
works on up to 10 OIT-related RFPs at
a time. Committees are different for
each RFP, but usually each is comprised
of IT administrators, professors, staff
members, and even students. As part of
their research, some committees put out a Request for Information, or RFI, to get
vendor feedback on product specifications
and the market at large.
“The RFIs enable us to get more
detail from vendors about what their
services do and what their products
are,” Borkowski says. “They also let
vendors know that we’re in the market
for a particular product, and that an RFP
will come next.”
As part of the research process, many
schools also ask themselves the critical
question of whether they want to put out
a project for competitive bid, or whether
they want to eschew the bidding process
altogether and go with just one vendor.
This latter approach is known as “solesourcing,”
and is much more
common among small, private
colleges that lack the time and
resources to go through a
lengthy bidding process. Many
institutions will sole-source
one-off technology purchases
that require minimal cash outlay
and will not need to be
repurchased in the future. Or
they will sole-source jobs for which one
vendor offers technology that’s unique.
Teahen says Baker is one such school.
Borkowski notes that at many large
public institutions, technology officials
are required by state law to spark competitive
bidding to guarantee that the
procurement process is open and fair. In
many cases, Teahen says this forces
some schools to go through the motions
of researching an RFP, even though they
have a good idea of which vendor they
plan to use. According to Borkowski,
however, the process enables schools to
“cover their bases” and see what technologies
are available. She adds that
this kind of due diligence also serves as
a great way for schools to make sure
they are including newer, smaller vendors
in the mix.
Has it been a while since your school methodically evaluated its own technology needs? The process of creating an RFP can force you to better define those requirements.
“Whether we sole-source or go
through the request-for-proposal process
is largely dictated by the functionality
we define as a need,” she says. “Most of
the time, it’s good to put a project up for
bid just to make sure we’re getting the
biggest bang for our buck.”
Putting the RFP Together: 6 Critical Sections
Once a school has researched an RFP,
it’s time to sit down and compose the
document. Borkowski and Teahen agree
that every RFP should contain a minimum
of six critical sections. These sections,
in no particular order, are:
- The synopsis or mission statement,
which summarizes the technology
problem and the solution required.
- A list of technical requirements that
outlines mandatory functionalities
of a vendor’s solution.
- The timeline for project completion,
including deadlines for completed
RFPs and incremental milestones.
- A sketch of budgetary expectations,
to give vendors a ballpark idea of
what a school would like to spend.
- Specific information pertaining to
warranties, payment schedules, and
other “nitty-gritty” details.
- Legalese stipulating that the RFP is a
full-fledged legal document enabling
institutions to hold vendors liable for
the solutions they promise therein.
No one of these details is more important
than the others; Borkowski says that
while some of these details may seem
“boring,” each is equally critical to the
process as a whole. “It is important to be
clear about each requirement and not
make any of them too ambiguous, while
still being careful to not include too many
things in each,” she says. “You want to be
clear so a vendor can respond in a way
that you can evaluate.”
Other RFP Must-Haves
In addition to the six key sections, many
schools add other, “softer” must-haves
of their own. At Baker, one of these
extras consists of nothing but specific
questions about how the vendor will
handle certain needs and issues pertaining
to the technology itself. Teahen estimates
that the school’s average RFP
consists of two or three dozen questions,
noting that in some cases, questions
make up the bulk of the RFP. He adds
that in some instances—particularly if a
vendor has sent over a product for realworld
testing—Baker’s purchasing committee
follows up with a second batch of
queries after they’ve tried out the product.
Make sure your RFP includes: mission statement, list of technical requirements, timeline/deadlines; budgetary expectations, nitty-gritty details about warranties/payment schedules, and essential legal stipulations.
These questions range in scope from
the broad to the specific, querying vendors
about everything from how they’ll
handle upgrades to how they’ll oversee
product registration. Teahen adds that
the questions frequently cover issues
pertaining to implementation, troubleshooting,
and compatibility with alternate
environments such as open source.
Queries cover: What type of service levels
will you guarantee? How many users
can partake simultaneously? What is the
system capacity? How will it interact
with existing network security measures?
Teahen says he asks all of these
questions, and more.
“At the end of the day, asking a lot of
questions gives you the best understanding
of each vendor’s solution,” he says.
“The RFP is your chance to interview
each individual vendor, and you want to
be sure to take full advantage of that.”
Once a school’s IT department has
researched and written an RFP, officials
post the document on the school’s Web
site or send it out to interested vendors.
Then the waiting game begins. While
the development and writing phases can
be completed in as little as two weeks,
vendors generally take a minimum of
another two weeks to review the proposals
and respond. Responses generally
come back en masse within days of the
deadline. From that point, the burden is
on the institution itself to review the
completed proposals and select a suitor
or suitors from the bunch.
Many large public institutions evaluate
completed RFPs in the same fashion
that professors evaluate student exams: by scoring on a curve. In this approach,
the evaluation committee determines
which areas in the document are “mandatories,”
and which are more secondary
needs. Some schools, the University of
Maryland among them, won’t even
grade completed proposals that fail to
respond to all of the mandatory questions.
Others will grade everything, but
weight significantly those proposals
that place emphasis on the areas deemed
most important—usually price, functionality,
and support, among others.
“While everything on an RFP is important,
vendors should be evaluated first and
foremost by the mandatory items on the
list,” says Borkowski, who notes that at
her school, one committee evaluates
completed proposals for content, and
another evaluates them for financial feasibility.
“If a vendor d'esn’t answer these
key questions, the proposal falls flat.”
What’s your evaluation strategy? Institutions often assess completed RFPs on a curve, determining which respond to mandatory and/or secondary needs. Some won’t even grade proposals that fail to answer all mandatory questions; others weight proposals that emphasize price, functionality, and support.
While large public school systems generally
grade completed proposals on a
pre-established scoring system to ensure
objectivity, the practice is much different
among private schools. In recent years, an
increasing number of these independent
institutions have taken to evaluating completed
proposals on a holistic basis. This
is how Teahen and his colleagues at Baker
review completed RFP documents—not
by how each vendor scores on a specific
set of questions but, instead, by how the
companies reply overall. According to
Teahen, the process provides a much
more accurate assessment.
If, for instance, a vendor neglects to
answer certain questions, the Baker team
may automatically move that response to
the bottom of the pile. Conversely, if a
vendor g'es above and beyond the field of
respondents, that vendor will receive
additional plaudits. While each
RFP still has a set of unofficial
“mandatories” that every vendor
must address, the holistic
approach takes into consideration
a broader spectrum of proposed
solutions. Teahen says
this enables those vendors offering topnotch
features but midlevel price points to
compete against the lowest bidders.
“There’s more to an implementation
than one or two things,” Teahen says.
“Sure, some areas are more important
than others, but when we evaluate proposals,
we try to take everything into
account and make sure that we’re going
with the best all-around solution for us.”
Borkowski and Teahen agree that vendor
references are critical to evaluation,
and note that, in completed RFPs,
schools should ask vendors to include
customer references. Teahen advises
schools to seek other customer references
on their own, since vendors rarely
put prospective customers in touch with
existing customers who have anything
but positive things to say. (Some schools
ask for a listing of a product’s installed
base so that they can randomly choose
their own references.) The thinking here
is that only references without a vested
interest will provide truly objective
opinions; sometimes the best way to see
how a vendor will deliver is to ask some
of its least-suspecting customers for a
On average, how much time should you spend on your RFP? Answer: Two weeks on planning, two weeks on writing, two weeks waiting for vendors to respond, and two weeks evaluating those responses.
More good advice: Take the RFP
process seriously. Teahen says that time
spent honing his school’s RFP processes
has proven to lower the total cost of ownership
(TCO) of technology purchased by
up to 30 percent—a huge savings no matter
how you slice it. By investing considerable
time and resources into preparing
the RFP on the front end, both Teahen and
Borkowski say their schools have selected
technologies that save time and
resources on the back end—true “winwin”
situations for everyone involved.
“The whole purpose of doing [an
RFP] is that you don’t spend a serious
amount of money and end up with something
that’s a nightmare to manage,”
Borkowski reveals. “It’s definitely an
investment to put all the effort into the
process from the beginning, but when all
is said and done, it should be worth it.”
Teahen agrees. When asked to identify
other potential pitfalls, the Baker College
RFP guru says there are a number of
additional missteps to avoid throughout
the RFP process, each of which represents
a critical step that schools too often
think they can take for granted because
they’ve done everything else right:
- Be sure to get input from constituents;
research the market to get a good sense of
which vendors have the most to offer.
- Be clear and concise so vendors
know exactly what types of information
schools expect them to provide.
- Outline technical requirements; the
more specific the RFP is, the more targeted
vendor responses will be.
- Inquire: How, specifically, will vendors
meet needs? The more questions an RFP
contains, the more specific the response.
In Teahen’s opinion, it’s easy for
schools to write a bad RFP, and those
that fail to look at the big picture and
identify what they’re trying to achieve
will falter no matter how much time
they put in. All told, Teahen says his
own school spends an average of two
weeks on the planning phase, two weeks
on the writing phase, two weeks waiting
for vendors to respond, and two weeks
evaluating those responses. He deems
the process quick but critical, a “must”
for the successful long-term development
of the school’s IT infrastructure.
“The truth is that RFPs have made our
network what it is today,” he says. “If
you want a solid approach for purchasing
the best technology at the best price,
this is the only way to do it.”