“We all want this to be a success,” is a pretty common sentiment at the outset of a major RFP. When considering hardware for data center maintenance services, in many cases, the outcome can mean significant cost containment for the IT group and accolades all around for a job very well done. And let’s face it, it is not only a fiduciary duty to avoid over-paying a vendor (even the original equipment manufacturer) it can be flat-out galling to think that your company has been over-paying for YEARS. So, damn straight, you want this to be a success! This article will touch briefly on several topics that will make the success you are seeking far more likely.
All organized people would agree that the degree and type of effort at the beginning of a project can have a dramatic effect on the outcome – carpenters say “measure twice and cut once,” for example. The corollary being a jacked-up and hugely wasteful mess if you don’t apply the right tactics at the beginning. As a point of clarity, this article is not going to touch on the basic best practices of issuing, evaluating and awarding an RFP (because you IT procurement pros already know this), but instead will focus on particular aspects of hardware for data center maintenance service contracts: internal collaboration and quality of data.
Create a culture of collaboration with your internal IT client:
It is improbable that an over-emphasis on this point could occur – you have got to work closely with the IT branch to have a successful event with a positive, measurable outcome. The recommendation is to get the buy-in from as high in the IT organization as you can and have this executive make certain the staff takes this project seriously. The amount of time invested does not have to be particularly large, but frequency and involvement are paramount. It’s not just ONE meeting, but a series of meetings along the course of the RFP process. We have seen many events span more than eight months from inception to conclusion. If correctly approached, this duration gives ample opportunity to get all the necessary consensus and feedback along the way.
One reason this collaborative mindset is so important is this: in order to be effective and successful, you have to get a little disruptive. In this case, disruptive may be advocating for a different approach in selecting and managing vendors in the data center equipment services space, the “way things have always been done” may get challenged. Don’t shy away from that but do be careful. Make sure that your collaborative mindset ensures you all have a clear and mutual understanding of these types of things:
- How do you identify, evaluate and mitigate risk in your IT organization? (We are referring specifically to service interruption risk and/or system downtime)
- What risk (of service interruption) might your vendor put you in? How do you identify, quantify and mitigate this risk?
- What amount of risk is your group willing to accept, on what assets grouping(s) and for what reward?
- Apart from operational risk, what commercial risk might you encounter in various scenarios?
- If part of the risk you are considering is fear, uncertainty or doubt projected at you by a vendor or the OEM, how do you determine what is real from what is artificial (FUD)?
- Are there any vendor policies that seem to restrict you from a particular course of action? What solutions might be found for these policies?
- How will the group choose to score and rank the offering from the RFP contestants? What weighting might you put on savings, quality and certainty of a solution?
These types of conversations should be intended to flesh out a prioritized list of requirements, goals and “nice to haves.” So, sit with your IT partners and discuss the topics above, then prioritize. Both you and your IT stakeholders need to have an excellent understanding of how risk can be manifested in data center equipment support contracts, and what degree of risk is acceptable for what amount of reward. You also should jointly consider the types of risk you are willing to allow. This way you will be far better prepared to implement tactics guided by a strategy that is directly focused on achieving these prioritized objectives, and you won’t be distracted by a bunch of “nice to haves” that don’t add up to the main requirement. The very last situation you want is to contract for terrific savings that is loaded with risk that you didn’t see coming.
Work to get the most detailed data possible, up front:
The critical point here is that without detailed information about the assets, and specifically the customizable configuration of these assets, your vendor(s) will have to guess or make assumptions about essential details. Details that, if unknown by the vendor support team, will make it difficult if not impossible for them to meet an agreed SLA. How likely are they to quickly repair what they do not know is there? A secondary issue, which carries a commercial risk rather than an operations risk is a little more nuanced. This is risk that, without specific details, a vendor could basically assume the lowest configuration possible and charge accordingly. This looks great on the surface because the perception of savings can make you look heroic, but your vendor is likely to claim that certain aspects (multiple CPUs in a system, for example) are not covered under the contract. They may request change orders that may not only degrade your savings but create a situation in which your second-place vendor had the best value offering. Oy! What a mess.
At a minimum, you should have this information. And frankly, this is abbreviated and shown here as an illustration:
For all devices types:
- Make
- Model
- Serial number
- Location (country, city, state, facility)
- Preferred service level
For servers:
- Number of CPU cores and MHz
- Amount of physical memory
- Number of and capacity of storage devices: disk and tape
- The number of Host Bus Adapters (HBAs)
- The presence of any externally attached devices
For mass storage:
- Number of and capacity of storage devices: disk or tape
- The amount and capacity of cache memory
For configurable network devices:
- The number of activated ports
This may sound a bit daunting, but your IT staff should either already have this information or be able to collect most, if not all of it. It is imperative to get as much of this information as possible. Some OEMs allow the original configuration of a device to be searchable by serial number, but even this method does not allow for enhancements/upgrades that may have been applied after purchase.
Applying careful consideration and diligent follow-through to these topics will be tremendously helpful in your next hardware maintenance service RFP for data center equipment. Look for part two of this article for more practical advice.
Region:
