Many storage managers view requests for proposals (RFPs) as a magic wand that can be waved over a procurement to...
ensure that it's fair and will result in the best technology solution at the lowest possible cost. Yet a recent survey of IT managers and executives by Equation Research, Pleasantville, NY, revealed that only 39% of organizations used RFPs; of the total surveyed, 48% shopped storage to multiple vendors without a formal RFP process and a surprisingly high number (28%) acknowledged that most storage technology was purchased via sole source negotiation.
And those organizations that use an RFP for major storage acquisitions often stumble because they lack a solid RFP process. Compounding the problem, internal staff typically lacks the hands-on experience to perform due diligence for an RFP. So organizations end up buying storage technology based on a rationale not much different than what would have existed without the RFP.
Too often the well-intentioned goal of using an RFP is undermined by cagey vendors, overworked staffs and internal partisan politics. One way to get a better grip on the RFP process is to break it down into four chronological phases. Following these phases will put you, the storage buyer, at an advantage in acquiring new storage technology.
Once the word leaks out that a storage acquisition will be accomplished through an RFP, the various vendors will request meetings, each seeking inside information and extending offers of help. What organizations need to demonstrate to vendors, though, is a stem-to-stern RFP process that determines requirements and publishes them to all concerned parties, inside and outside the organization.
This phase involves serious data collection, inventory and documentation of current operations. Sometimes office politics intrude, preventing adequate information collection. Longstanding conflicts between data center staff and lines of business managers can erupt when discussing service levels, performance, system uptime, availability and access to information. Without this critical information, however, RFPs often become no more than a "tech spec sheet," which leads to a least common denominator solution that fails to address the business problem.
|Truly creative ideas|
Gary Brown, senior storage consultant at Dimension Data in Charlotte, NC, notes that RFPs are best when they aim to fix operational problems. "The challenge," Brown says, "is that no one wants to air dirty laundry by admitting to these problems, and so the requirements don't reflect the real need. Without clarity, vendors can not propose effective solutions. RFPs also need to address the internal process or people issues contributing to the pain."
At a minimum, organizations should follow these steps during the first phase of the formal RFP process:
Project lead. Appoint an internal staffer to be responsible for collecting data, interfacing with other departments, working with third parties and driving the process to completion.
RFI before RFP? Because RFPs require a good bit of knowledge and insight, some opt for a request for information (RFI) first. RFIs provide an informal forum for vendors to give their slant on the state of their technology and how it can affect your business. RFIs can help shape the boundaries of the potential solution.
The status quo. You should document all flaws and positive attributes in the current storage environment, quantify the exact financial status of the installed systems (depreciation, leasing, maintenance, etc.) and state future growth plans in all affected applications. You should also assess the current level of storage expertise in-house and state corporate direction with regard to host environments, database, backup providers and application rollouts.
Requirements. Meet with all internal stakeholders to draft a gap analysis that compares current service, functionality or support capabilities with line of business needs. Further, they should determine how the contemplated storage acquisition affects or enables any existing SLAs. If the buying organization has a platinum/gold/silver service model, there are likely specific attributes the solution must meet--uptime, functionality, etc. These all need to be identified and integrated into the emerging requirements document.
Industry status. Attend the next meeting of the local Association of Storage Networking Professionals (ASNP) chapter or a similar user group to get the latest vendor scuttlebutt and study recent findings from the major storage analyst firms. This is also an opportunity to update yourself on the latest developments with the key industry organizations such as the Storage Networking Industry Association (SNIA) and the Institute of Electrical and Electronics Engineers (IEEE). Lastly, reach out to trusted contacts in other companies to get their views on crucial storage issues.
Business case. Because major storage buys need to be based on more than a technology evaluation, you should create a business case for the forthcoming purchase. The business case should help upper management understand why additional storage gear is needed, as well as solidify their support.
During this phase, you should:
Pick a vendor point person. Designate someone from Purchasing to serve as the single contact point for the vendors once the RFP is on the street.
Consider vendor content. It is almost heresy to say so, but some vendor-provided RFP "samples" contain very detailed and thought-provoking material. As no vendor will provide verbiage prejudicial to their product, it needs a thorough vetting; still, if you solicit input from all parties you can obtain a real jump-start on the wording and stimulate some thinking.
Watch out for "knock-out" requirements. Because the purpose of an RFP is to facilitate choice, it seems counterintuitive that some organizations issue RFPs with requirements that only one vendor can meet--yet it happens regularly. Screen the document for those technical requirements which will result in only one responsive bidder.
Include many details. When it comes to RFP content, brevity is not the soul of wit. Specifications should be broken down into many categories: array/storage area network (SAN) hardware and software, backup and recovery hardware and software training, implementation,
connectivity, availability, replication, integration, interoperability, servicing, maintenance, operational attributes, storage resource management (SRM) and so on. Also, consider using shareware sites which offer RFP templates to download.
Be clear. Each requirement in every category should be precisely worded with no ambiguity. Some RFPs go further--consultant Brown includes an analysis section for his RFPs that shows how technical requirements are derived so that vendors understand the underlying assumptions.
Avoid unintended consequences. Some organizations fashion a solution as though it were the only one installed in the data center. Any technology deployment of substance affects existing systems. Each touch point between the potential solution and existing technology should be identified.
Set priorities. Identify the relative degree of importance for each RFP requirement. You don't have to inform the vendors about how you intend to score the RFP responses. Still, you should give the vendors some indication as to what the most important requirements are so they can allocate their responses according to your criteria.
Distribute widely. Make sure that the document is sent to a reseller or original manufacturer of all major storage technologies. Also, ensure that at least two integrators receive the RFP.
Master the matrix. Get all internal parties to agree on the proper "weightings" for each RFP requirement. This can be an elaborate process with a different percentage for each item or it could be more of a summary. Either way, this evaluation matrix should provide the sole prism through which vendor submittals are reviewed.
Toward that end, activities in this phase should include:
Hold a serious Q&A period. Some RFPs omit this crucial step or do not give it enough attention. Vendors should be encouraged to ask detailed and provocative questions. Furthermore, the organization that issued the RFP should answer each question fully and clearly. The questions and answers should be published to all RFP recipients, resulting in a vendor community with complete knowledge of the desired solution elements and attributes.
Establish well-defined proposal submittal guidelines. Most vendors will structure their responses differently, making it difficult for organizations to compare them. To avoid this, instruct vendors to submit proposals that conform to the following format:
Decision-maker sketch: a one page summary of the bid's key points (cost, differentiators, most compelling attributes and so forth). It's sometimes presented in the form of a cover letter.
Executive summary: a roll-up, in five or fewer pages, of the technical and business solution proposed, including graphics to depict important concepts and an ROI breakdown.
Response: the detailed answers to each RFP question/requirement. This should be provided using identical numbering and format as the RFP so that each requirement can be referenced easily and compared to other vendor responses.
Appendix: All vendors should provide a CD containing all the large documents, white papers, diagrams and other material referenced in the response.
|How not to do an RFP|
Despite all the work up to this point, the most trying phase is the last--a decision must be made. All but one of the vendors will be disappointed. In particular, if the incumbent vendor loses, there are sure to be complaints from inside the organization.
Although there's some creativity in the decision-making process, much of it can still be carried out systematically. Here are the steps you should take: Narrow the field. Based on the review of the proposals, limit the review to three or fewer vendors.
Structure the presentations.
Invite the vendors to present their solutions, but carefully script the topics they should address. Limit the areas they cover. Some find it useful to have vendors present the parts of their bids deemed weakest.
Scrutinize the ROI. Every ROI justification takes some liberty with the facts, or at least makes debatable assumptions. Have the vendors explain in detail the derivation of their cost justifications.
Consider proof of concept. Some data center staff demand to see the proposed solution in some form of production configuration. This usually takes a significant amount of time on both the vendor and the organization's part. This approach is advisable for solutions that contain recently released or less well-known components, but not for those with wide distribution or marketplace acceptance.
Select with conditions. When selecting a vendor, ensure that the contract lists the satisfactory completion of a series of specific tasks before the vendor is paid. In some cases, this will prevent the vendor from counting the revenue until the criteria are complete. This is your insurance policy, so it should be non-negotiable.
To successfully work an RFP process requires commitment and sometimes third-party assistance. There are consultants who specialize in helping companies through the RFP process.
How will you know if you're successful in this process? Consultant Brown says that in the best RFP initiatives he has seen, "vendor proposal prices are within a narrow bandwidth of less than 10%. When the requirements are well-defined, each vendor must meet them. It is only when requirements are vague that vendor interpretation leads to wide gaps in vendor pricing."
Successful procurements executed along these lines can become a point of synergy between the IT managers and their internal customers. The payback for this type of deliberative and comprehensive storage acquisition rests in the confidence that the solution will not only exceed expectations, but that it will do so at the lowest possible cost and in such a way that business needs are addressed.