Bigger isn’t always better, and innovative technologies aren’t always best. But, when choosing vendors and suppliers, the best choices aren’t always evident until the equipment is installed or the contract has been let. That’s when nasty surprises may occur and you realize that what you expected isn’t quite what you received, or—worse—what you asked for wasn’t exactly what you wanted.
To minimize the odds of that happening to you, use these five steps:
Develop a Process Framework
A structured process helps you compare apples to apples. It’s not unusual to submit a request for proposal (RFP) to six different vendors and get back six entirely different proposals, notes Tim Flynn, senior consultant, data center engineering, Forsythe Technology, a technology integrator. Differences may be as minor as cage sizes, but they often matter and can make it difficult to compare proposals.
“Power is where most operations’ expenses will be,” Flynn says. “Yet, most customers don’t make it a focal point when selecting vendors. Instead, power is discussed after they’ve narrowed their selections.” He advises considering power along with service level agreements (SLAs) early in the vetting process.
“Understand the contractual verbiage,” Flynn insists. If necessary, sign a non-disclosure agreement, or have providers sign one, to see the contract up front, before negotiations progress.
When preparing a request for proposal, first articulate the businesses’ goals so you know what you expect the solution to accomplish. For example, rather than basing the RFP on the systems you have, consider the ideal result. Can you achieve that result by evolving the current system, or is something completely different needed?
Don’t limit the goal according to the technology you believe is available. Instead, focus on the desired outcome. Solution providers may have technology options that are unknown to you or to your usual suppliers.
This focus on results enables you and your potential providers to match the technologies to your goals rather than shoe-horning goals to fit pre-conceived notions or technological solutions. With this understanding, you can formulate your vision into a request that suppliers can address.
When specifying technological solutions, consultant Laura Brown, president and founder of System Innovations & LBPI, Inc., advises organizations to go beyond merely outlining features and functions, service levels and scalability.
“You also must alert vendors to your expectations for integration with other systems,” Brown says. Specify, for example, whether systems must integrate natively and seamlessly with your existing systems, or whether proprietary systems acceptable.
“A data capture tool might store incoming documents in specific formats, but can your document management system read and process those formats?” Brown asks. “These are aspects of the unstructured data that every data management center needs to consider.” Therefore, when defining requirements, specify the formats with which the solution must interface.
Develop the RFP/RFI
Once you have identified your expectations, put your requirements into a written request for proposal (RFP) or request for information (RFI) that goes to each vendor being considered. The RFP/RFI should include a project overview with your business goals, as well sections discussing your existing technological environment, technological criteria, expected service levels and other relevant details.
Include your organization’s architectural standards in the RFP—not just in your internal, pre-RFP documents. As Brown says, “It’s valuable to provide vendors with graphical models (such as business process or data flow diagrams) that capture the integration requirements, as well as models that depict the data and process requirements the solution must cover. Vendors need to know the complete requirements.”
The RFP/RFI also should detail how and when responses are due, and any criteria for establishing proof of concept, if needed. The process should be structured and predictable for all parties, and should include the expected announcement date.
RFPs also should contain internal controls linked to the audit process to ensure you comply with audit requirements, Brown says. “Some audit controls are about timing of events to create equal access to information for bidders. For example, the time period an RFP is open for bids should be clearly indicated.” Also, there should be a time period during which you accept and answer questions about the RFP. Questions and answers should be compiled and made available to all bidders.
All deadlines, such as those for questions, for proposal receipt and postmark dates, must be stated clearly. Allowing some companies to deviate from those deadlines provides a basis for bidders to challenge the results of the bidding process.
The internal controls that apply to RFPs include:
– Ensuring a formal bid process on major purchases
– Identifying and limiting authorized signers for the bids and RFPs
– Documenting the accepted procurement process
– Establishing a formal order requisition process (so not just anyone can place orders)
– Developing an open purchase order system to track items not yet received.
Organizations should link their RFPs to these controls to ensure they comply with relevant audit requirements. If those controls are not already in place, “It’s important to build them into the process itself,” Brown emphasizes.
Be aware that RPF requirements vary by industry and between government and private organizations. “Public organizations (government) have another layer of compliance regarding fair access and equal treatment, as well as proper management of public funds.”
Private sector regulations are less strict than those for government, but Brown advises adhering at least to the “spirit of the regulations that apply to public concerns. You don’t want employees making significant purchases without due diligence and controls.” For example, “Organizations shouldn’t buy a particular system because ‘Uncle Bob’ makes it. You want to ensure that ‘Uncle Bob’ gets the same rigorous review as any other bidder.”
Evaluate the Findings
Once the RFP has closed, open and review the bids and issue a formal report of the findings. Some bids may be off the mark and can be set aside or immediately rejected. Others, however, merit a closer assessment.
“The extent of formality and rigor of review depends on company standards and the size of the contract. Obviously, contracts with larger dollar amounts require more rigorous review than smaller contracts,” Brown points out.
“At Telstra (a large Australian telecommunications and media company), we like to see that vendors operate with a similar open culture,” says Tom Homer, director of global enterprise and services, EMEA. “We like to work with partners who work collaboratively, trust others to deliver, make the complex simple and who show courage when it comes to decision-making.”
“The vendor vetting process is absolutely vital,” Homer says. “It must be strong and fit for purpose, without delaying projects significantly.” Therefore, Telstra expects to see other successful implementations, specific SLAs, certifications for technical, regulatory, security and compliance issues, and flexibility.
In evaluating the strengths, weaknesses, opportunities and threats of each vendor, “assign value versus risk scores,” Brown says. Numerical scores will help determine the relative value or risk of innovative technology, new or small companies, management experience and other factors that can determine success or failure.
For example, a company that’s young or that has disruptive technology may seem risky…unless its managers are well-seasoned. Then, it actually may be a better choice than competitors touting tried-and-true—but staid—technologies.
One of the greatest issues between clients and vendors involves customer care. Before signing a contract, “Understand how they will care for you and how quickly,” Flynn stresses.
“When problems arise, will you be talking to a trouble-shooter with specific knowledge of your environment? Are support personnel full-time employees of the vendor, or are they managed by a third party?” Regulated, security-conscious industries also may need to determine whether personnel accessing their data centers are citizens or are foreign workers.
Also beware of deals that seem too good to be true. For example, Brown says, “Beware of small vendors offering unusually low bids for service. They may lack good estimating skills and may be unable to deliver once they land your business.”
Additionally, Homer cautions against companies with exaggerated claims that lack solid supporting evidence, and companies that use high pressure tactics.
Telstra gets early looks at new companies and innovative technologies through its own venture capital group and software group. Therefore, Telstra is familiar with all the details of the technology, the company and the management team before considering those resources for its own operations.
Generally, when selecting new vendors or new technologies, it’s wise to start small. Understand how they will fit into your operations, so “start with a test bed or small, non-critical computing environment,” Flynn says. That’s as true for cloud computing providers as it is for innovative switches or servers. “Start small and learn from the experience,” then gradually scale up for more critical applications.
Forsythe prescreens its vendors, evaluating both day-one and long-term strategies. “A high-density environment eliminates a lot of vendors,” Flynn says. Data centers requiring low or medium density computing environments also should be careful not to overbuild. Installing a high-density cabinet for a low-density environment, for example, increases costs without immediate benefits. Therefore, he says, “Understanding the design density is important.”
Such considerations remain important as data centers move into the cloud space, too, says Mic Giess, a managing consultant for data centers strategy at Forsythe Technology. Even in the cloud, “The application, information and data center levels should be consistent with one another.”
Deal makers say that a big part of winning in business involves simply showing up. In IT, potential providers must be willing to “show up when it comes time for the short list evaluations, and to send their “A” team to make presentations, meet with the potential client or its representative and tour the facilities,” Flynn says.
As Steve Harris, VP of data center development for Forsythe Data Centers, recounts, “We’ve flown in to meet with providers who didn’t show up. That makes it difficult to tour facilities or to want to do business with them.” Consequently, some clients have eliminated very qualified vendors because they didn’t seem to care.
“Customer satisfaction starts in the pre-sales process. It sets the tone for how you’ll be treated on an ongoing basis,” Harris says.
Once potential providers are vetted, look closely at their proposals. Pay particular attention to service level agreements and their history of customer support as well as their solutions and management experience.
As Giess points out, “Know the SLA before signing the contract, and know the ramifications and remedies if the SLA isn’t met.” Some remedies, he says, may refund tens of thousands of dollars when the SLAs aren’t met for failures that cost millions of dollars. Therefore, “Don’t overlook the true impact of the SLA.”
Consider the future, too. Flynn says the average colocation contract is for a period of three years. “But, customers don’t want to relocate every three years.” Therefore, look beyond immediate needs and the provider’s capabilities to ensure that the provider can continue to support you as your needs grow, even after initial contract period.
As a data center manager, also determine whether the solution being considered is developed according to industry-standard specifications, is proprietary or even antiquated, Brown adds.
When assessing the technological solution, interoperability is a key consideration. For example, you need to know whether systems can communicate natively or whether adaptors are needed. If adaptors are employed, are they transparent to users or will they require a further investment of time and money to install them and ensure they work?
Write Formal Evaluations
For the top contenders, Brown recommends compiling written reports. Each report should include the price; discrepancies between the RFP and what the provider is offering; strengths, weaknesses, opportunities and threats associated with this company and this approach; the company’s delivery history; geographic coverage; reputation; and any other relevant factors. “The report should also include a recommendation for the actual selection, rationale for that selection, the recommended action plan and next steps,” Brown says.
The action plan, for example, may be to accept the bid as is, or it may outline needed adjustments to equipment or processes. Alternatively, Brown elaborates, “An action plan might include a negotiated project plan using resources from the vendor, the purchasing organization and other resource providers, such as off-shore development centers.”
A comprehensive final report also should include results from similar projects (supplied by the solutions provider). Those case studies should detail actual implementations and how well the solution met the requirements of those specific cases.
The RFP process is a joint endeavor that doesn’t stop once the RFP is released, Harris stresses. Instead, there should be frequent communication to ensure responders have the information they need to present accurate, detailed proposals. Data centers, he says, owe it to potential vendors to be “…truthful and honest, and be a part of the process,” answering questions and ensuring that each potential vendor has the same, accurate information.
Choosing the right provider and the right technology begins long before the actual vetting process. By taking time up front to ensure that you know what you want and to convey that information to potential providers as unambiguously as possible, both the vendor selection process and the ultimate results can be improved.
Gail Dutton is a regular contributor to Penton publications and can be reached at firstname.lastname@example.org