The Art of the RFP

• By Matt Villano
• 05/21/06

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.

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?”

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.

“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:

1. The synopsis or mission statement, which summarizes the technology problem and the solution required.
2. A list of technical requirements that outlines mandatory functionalities of a vendor’s solution.
3. The timeline for project completion, including deadlines for completed RFPs and incremental milestones.
4. A sketch of budgetary expectations, to give vendors a ballpark idea of what a school would like to spend.
5. Specific information pertaining to warranties, payment schedules, and other “nitty-gritty” details.
6. 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.

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.”

Evaluating Replies

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.”

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.”

Takeaways

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 status report.

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.”