In preparation for the kickoff of a series of monthly RFP (request for proposal) templates, eWEEK Labs recently spoke with a group of IT managers to discuss best practices for the development of RFPs.
Technology Editor Peter Coffee, Executive Editor Deb Donston and Senior Writer Anne Chen spoke with members of eWEEKs Corporate Partner Advisory Board—senior IT professionals from a variety of industries and company sizes—who agreed that the quality of an RFP correlates directly with the quality of the response.
Randy Dugger, president, Dugger & Associates
Tom Miller, director of IT, FoxHollow Technologies
Nelson Ramos: CIO and Enterprise IT Strategist, Sutter Health
Robert Rosen, CIO, National Institute of Arthritis and Musculoskeletal and Skin Diseases, National Institutes of Health
Francine Siconolfi, senior project manager, Aetna
Kevin Wilson, product line manager, desktop and mobile, Duke Energy
eWEEK: When we look at RFPs, we always wonder whether the driver tends to come from inside the tech organization to business managers or from business organizations to IT. Is there a general perception that its starting in any one corner or another?
Dugger: Its a hard subject to tackle because RFPs are so personalized for every organization and in every instance.
Rosen: Well, it depends on the RFP. Basically, there are a couple kinds of RFPs that are done. One is a fully competitive RFP that is open to the world, and whoever wants to bid on it can bid on it. Then there are others that are more narrowly defined. Typically, there is a formalized structure used in the government.
Ive done way more RFPs than I ever wish I had to do. The hardest part is you cant tell the vendor how to do something. You really have to put it in terms of, "Heres the result I want," and you cant constrain the vendors in defining how they want to do it.
Thats difficult when youre trying to solve a particular problem. Youve got smart people here, and you know how it has to be done to fit in your environment. And, youre trying to write a RFP thats not telling them to how to do something a certain way.
eWEEK: Tom, I would imagine that in some of the areas where youre buying stuff, youre not only at the leading edge but beyond the leading edge. Are you therefore wide open as to how it has to be done? How do you manage that process?
Miller: A lot of our RFPs arent just driven by the technology but by the business, by clients regulations and by educating the vendors on the potential direction were interested in going in. The product may or may not even exist at that point—maybe its an aggregation of a number of products instead of a point solution.
We take a hybrid approach, in terms of describing business need and in describing the technology we want to acquire. For any RFP we put out, were very clear on what were looking for. We have our standard RFP sections: administration requirements, technical, business and legal requirements. We try to align the RFP with any project plans and preliminary scope of work that weve defined.
We also make sure as we are defining needs that we have very clear and defined selection criteria that we rank so all the vendors can easily understand in terms of "must-have," "need to have," "nice to have" and "deferred." We use that to grade those responses so we do an equal comparison of the responses were receiving. Its difficult when its something that doesnt exist in a commercial product at that point, so the more we can describe what the end process is on top of what the technical process looks like, the better our RFPs.
eWEEK: Francine, can you tell us something about the origin and process of RFPs within your organization?
Siconolfi: At Aetna, what Ive seen are formal project proposals and a business-needs assessment process done at the third quarter of every year. Folks determine what theyre going to spend time on the following year, so theres a discussion on what should go through an RFP process.
As far as whos driving the process, the ideas come from the business as well as the IT managers. We get these ideas based on experiences at conferences, observing what competitors are doing and more. The ideas come from many channels, and during the planning process the following year, the decision is made as to which one will go to a RFP process.
Some decisions will be made based on that fact that were leveraging house technology from a vendor we have a relationship with. Sometimes well decide were going to do an RFP on this one technology and open it up. From what I have seen, a BNA [business needs assessment] is submitted, and we have a very high-level discussion as to whether or not were going to submit a RFP.
Wilson: We usually watch the players we want to work with and even get some demo stuff to become familiar with them. If youve got a technology and you dont know if its right for you, you have to work with it for a while. And an RFP [means you are] committing to action. The thing now is not to pre-commit but to get a sense of whether the time is right. Even for some of the larger infrastructure stuff, I dont see as much a formal process there as much as an ongoing monitoring of these things.
eWEEK: Weve seen in some organizations where the RFP process was very much two parallel tracks, where one team will say, "This is whats being proposed," and the other team saying, "Is the company reliable, and are we comfortable doing business with them?" Do you have a two-track process of whats being offered and whos offering it? Or is it a more holistic process, with one group making an overall decision?
Rosen: When you set up your evaluation criteria, you decide whether its price or technology or best value, and you do it in priority so that the vendors know how youre going to do the evaluation. They can tailor their bid to meet the evaluation criteria.
Miller: Its pretty much one track for us. We try to keep the same people focused. A key part of many of our processes is vendor reliability. We want to make sure the vendor will be around for the mid- to long term. We usually want a partner that will be viable over a three-year period, and we want to make sure we have an exit strategy just in case.
eWEEK: How do you go about describing and documenting the environment in which the new project is going to be functioning without disclosing too much to people you might not wind up having a confidential supplier relationship with?
Miller: For us, unlike the government, we can limit the number of participants in our RFP process. So we always make sure that we do have non-disclosure agreements in place before we go into an RFP discussion. We provide a high-level overview, and then we will use the RFP process—sort of the Q&A part of it—to answer any questions the vendor brings up. This also helps us understand how deep the vendors are probing us to ask questions and try to understand our environment to come up with a really tailored proposal rather than giving us a standard response to our RFP.
Siconolfi: The last RFP I worked on, we had a huge spreadsheet that we used to track our technical requirements about our infrastructure and some of the things that the vendor had to integrate with. But we didnt reveal anything that was so critical that we couldnt work with that vendor.
eWEEK: Do you tend to avoid questions on RFPs that you cant give objective grades to?
Dugger: Yes. If you give them a fuzzy question, how do you grade that? The whole idea is to be clear and succinct so theres no question as to what youre asking the vendor for.
I would ask other questions that would give me a better picture, like: Give me the references or names of people who have implemented the solution that Im requesting.
The questions have to be structured where they understand what you want and you understand what you want and it can be graded. If its subjective, then you leave yourself open to someone coming back and saying youre not fair.
Ramos: We frequently ask for cost-benefit analysis from a vendor, and it sort of gives us an idea of the vendors sense of business relevance or business reality. We find that a nice complement to getting technical presentations from some of the vendors. Usually we ask if there are any benefit realizations at organizations similar to ours.
We also ask what kind of savings would we expect to achieve. We are finding that more and more vendors have done some kind of benefit realization, and, in reviewing it, it gives us a good sense of their business acumen. A lot of times their presumptions of what it takes to accomplish certain tasks is obviously skewed toward their sense of reality.
eWEEK: Have you ever spoken to technical teams other than sales teams? Are you more comfortable when response to your proposals includes face-to-face contact with technical people?
Miller: One of the things we do along with getting the sales person and their technical designee is ask to have a professional services person attend the discussion, even if we elect not to do professional services. We have them describe a typical implementation and an appropriate-size business reflective of our company—whether its in the same industry segment or the same size or [is similar] in complexity. And, by that, were able to understand each vendor and its ability to actually implement.
eWEEK: How long would you ever be prepared to wait for a competent proposal between the time you had the need identified and the time you were looking for some suggestions?
Rosen: On most of the RFPs that we do, of varying complexity, we give 30 days and vendors come back for an extension. So we usually plan to give 45 days. The other things weve had to do lately is put a page limit on how much the vendor can write.
Wilson: You really have to keep it short. We evaluate everything but the price element, and then go back and invite vendors to do the final piece with actual prices.
eWEEK: Is it difficult to get customer references from vendors?
Nelson: Depending on the complexity, we may ask the vendor for a proof of concept. Once we get to an advanced stage, vendors are open to providing references for us.
Siconolfi: The vendors are very careful with who they let us talk to.
Miller: A lot of times Ive gone back to vendors and told them their references dont meet the criteria. You need to define criteria for references. You shouldnt let the vendor drive the reference process.