RFP Process for Selecting a Colocation Vendor

Here I’m going to offer a brief overview of the RFP (Request for Proposal) and related processes, as they apply to the sourcing of ‘co-location’ services.

The data centre industry – generalities

The UK data centre industry is by far the largest in Europe and is expanding rapidly. Some surveys predict a 4% CAGR between now and 2025 with an estimate that the market will be worth in excess of $8.4billion (Source: Arizton).    

  

This is therefore big business, even though it may be built on layers of both SME and large corporate clients.

You may wish to leverage the benefits available in that environment but it’s important to go about it the right way if you’re to maximise its potential to transform your business.

The RFP is typically the first (or sometimes second) formal stage in positioning yourself for co-location or one of its variations.

Data Centre Types

There are some generic concepts that are important to understand

Colocation  

In colocation (“colo”) data centres, a company rents space within a data centre owned by others and located off company premises. The colocation data centre hosts the infrastructure, building, cooling, bandwidth, security, etc., while the company provides and manages the components, including servers, storage, and firewalls.

Enterprise Data Centre  

These are built, owned, and operated by companies and are optimised for their end users. Most often they are housed on the corporate campus

Cloud Data Centres 

In this off-premises form of data centre, data and applications are hosted by a cloud services provider such as Amazon Web Services (AWS), Microsoft (Azure), or Google Cloud or other public cloud provider.

Terminology

At the outset, you’ll need to have some familiarity with certain very basic core concepts. In no priority order:

  • Bandwidth. This relates to how much data traffic you plan to send up and down to your IT equipment in the data centre through communication interfaces to the internet or elsewhere. Broadly speaking, the more traffic you anticipate, the more bandwidth you’ll require. The more your operations grow, in volume terms, then the greater your need for bandwidth will be in future;
  • Scalability. The amount of space and bandwidth you have available might need to expand rapidly if, for example, your business grew by 50% over a few weeks (e.g. in some 2020 COVID-19 situations). Scalability indicates how fast a vendor could respond to providing ‘more’ if they had to;
  • Redundancy/Fallback/Contingency/Disaster Recovery. These terms all apply in situations where the unexpected might happen – this time in negative circumstances. An illustration might be where the site suffered a major environmental disaster such as flooding and how quickly your operations could be back up and running. The more demanding your ‘hot standby’ requirements are, typically the higher the cost might be;
  • RFI (Request for Information). This isn’t always undertaken but it is a free-form document sometimes used to obtain specific or very general information from a vendor. It’s sometimes useful as a precursor to help the project team clarify their own thinking and requirements with a potential vendor’s help. As the formats here can vary hugely, I won’t discuss this further;
  • RFP. This document is the first stage of starting to assess data centre solutions available in the marketplace. It should only be undertaken when a client has a degree of confidence that they understand their own requirements. It is typically written by team effort, as it may contain both business and technical statements of requirement

Preparing to produce an RFP

The good news is that there are some excellent templates available that can get you started.

However, I always advise against thinking to begin with that the RFP can be produced on a form-filling basis. Pro-formas are useful as an aide-memoire but they cannot replace the, sometimes considerable, preparatory work necessary before the RFP is put together.

Mobilisation

Your initial steps should be:

  • Clarify your enterprise’s objectives. Senior leadership levels must know what their business drivers are – such as cost reduction, risk reduction, service improvements, increasing support for business growth and so on. These should be prioritised in line with standard business analysis practices.
  • Remember if your organisation isn’t clear what it is trying to achieve through co-location, then it’s unlikely you’ll be able to communicate in your RFP what vendors need to ensure their subsequent proposal is the best fit-for-purpose possible;
  • Put together a team to produce it.  Multiple sources of expertise will be required (IT, Financial, Business, Compliance etc);
  • Allocate a senior person to lead the production activity. Ideally, this should be a business rather than IT led activity, to avoid your business objectives becoming subsumed by ‘technical frontiers’ visions and IT-speak;
  • Make sure the required personnel in your enterprise are directed to allocate priority to the activity – don’t ask the leader to somehow try and persuade potentially unwilling others to find the time to participate;
  • Invest in education and external consultancy if required. For example, understanding your eventual rack and power requirements in a data centre and the cost implications arising, can be complex. It may be difficult to discuss this in an RFP (or subsequently interpret a proposal) if you don’t understand what it all means;
  • Be certain that you and/or your team know the marketplace. This takes research and again, perhaps external advice. You should know just who is offering services in this area and in general terms, what these services are. You can use an RFI to facilitate this general information collection if necessary;
  • Select vendors to participate in the RFP, you should ideally have 3 or 4 vendors to provide adequate competition. Key considers are: location, tier requirement and whether the vendor is an appropriate in terms size, existing relationship or culture. 

Production

  • You can start with a standard RFP template. Use this though as a guide – not a rigid format, as you may find many components won’t apply in your unique circumstances;
  • State your business objectives clearly up-front;
  • Provide a view of your existing technical topography. Do likewise for your systems and applications architectures (at a high level);
  • You can sketch out your provisional thoughts for potential solutions but try to avoid drifting into telling vendors what their solutions should be – however IT literate your company and team is. You should though clearly state any proposed solutions that would NOT be acceptable (e.g. moving systems offshore);
  • Specify any requirements you have for things such as:
    •  physical locations (e.g. maximum distance from your main base – which influences accessibility times);
    • your standby requirements – often expressed as maximum permissible down-times;
    • scalability – e.g. capable of doubling bandwidth within ‘x’ notice period;
    • support response times – how long are you prepared to wait if you call with an urgent problem;
    • security – how access to the data centre facility and to particular zones/rooms are managed;
    • where you’re unsure of your requirements, you can include questionnaires. Try to avoid closed and meaningless questions of the “do you have fast technical support?” type.  You’re likely to get “yes” as a response, which will tell you nothing. Instead, be specific and eliminate the scope for misleading responses by asking “exactly how long on average will I need to wait for an expert to return my support call once logged with you?”;
    • commercial considerations. In order to have an “apples for apples” comparison it’s important to state the pricing model you wish the vendors to respond with.  Options include:
        • Space (square footage) + Power (by circuit, by kW or by usage)
        • Power only (all-in per kW) – Common in the wholesale (250kW+) market
        • Footprint – Combined space/power pricing based on kW density 
    • Either include your own agreement terms for the vendor to comment against or request the vendor’s agreement terms for review and scoring;
  • In order to gain an understanding as to whether the vendor can actually meet the requirements of your organisation, you must produce a questionnaire which challenges each of the requirement aspects stated within the above section.  Ask as many closed questions as possible, this will help scoring to be less subjective.   
  • State your required response formats. If you receive multiple RFP responses all in widely differing formats, it may be difficult to compare them.  If available use an e-sourcing tool to release the RFP.

Define your evaluation criteria

    

Even if you have responses all largely in the same format, evaluating them can still be tricky. For example, how will you weigh lower cost in one against superior scalability in another?

There is no easy answer to this, as what’s important will be unique to you.

Your evaluation criteria should link back to your original business objectives but it’s advantageous to construct them before the proposals are received. If not, your clarity of focus may become diluted by the sheer volume of material in front of you. This requires careful management, as stakeholders may also be juggling the evaluation task with their day job and might neglect or miss response deadlines.  

You may use the first evaluation as an opportunity to shortlist down to just two vendors; it’s important that the scoring and/or the initial pricing analysis supports the decision, with subjectivity being eliminated as far as possible. 

Vendor Presentations

This is an opportunity for the project team to quiz the vendor about their RFP submission and gauge their capability compared to competitors.  I typically try to have the highest scoring vendor presenting last, so you can accumulate more ammunition from the previous presentations.

Site Visits

Often the vendor presentation and the site visit can be done together. It’s an opportunity for the project team to see for themselves how the vendor can meet their requirements, witness the security management in action and verify the general upkeep and maintenance.    

Reference Calls

Reference calls or visits to one of the vendor’s existing clients can be useful, however, keep the reality of life in mind. Most vendors will have one or two favoured ‘tame’ clients available for reference.

The service they receive may be excellent but it might not be a reflection of the true service received by the majority of their clients. 

It may be better to solicit opinions from the project team’s network or reach out to clients stated on the vendor’s website, as they are not often closely monitored.

Workshop

Regardless of how much work has been done by the project team to articulate the requirements, a workshop with the vendor is necessary for both parties to further deep dive the requirements, understand how the vendor will deliver and the likely timeframes for migration.  This will enable the vendor to quote more accurately.   

Legitimate as these workshops are, many vendors will understandably also use them as an opportunity for hard-selling while they’re there. There’s nothing wrong with that but be aware that it’s happening and keep focus on the facts.

Negotiation Rounds

To create competitive tension, it’s best to have at least two vendors at this stage.  

However, due to the multitude of service variances between vendors, an e-auction in my opinion is not a suitable vehicle for finalising the price or selecting a vendor.  

Direct negotiation should be the only way forward, this must focus on the key commercial and legal terms such as: 

  • preferred pricing model;
  • discounts;
  • length of term;
  • how you can capacity flex up or down;
  • data transfer;
  • connectivity;
  • redundancy;
  • resource rate cards;
  • bundled services;
  • termination rights;
  • termination assistance;
  • Any agreement terms which have been challenged by either party.

Select a Vendor

Taking everything above into consideration, select a preferred Vendor and execute an agreement preferably based on your own template.

 

Common mistakes

There are no published statistics but from professional experience, I know that significant numbers of RFPs and evaluations of responses cycles, end in disappointment for vendors and you as the client.

From the RFP production viewpoint, some errors of approach can predispose the cycle to failure or at best, an unsatisfactory outcome. They include:

  • RFPs that fail to include critical details of the client’s business, your organisation’s objectives or existing technical infrastructure;
  • allocating insufficient and unrealistic time for vendors to respond. This often leads to no response at all or one that has been rushed and which is therefore potentially badly flawed. Remember, responding to an RFP is a lengthy and expensive process for the potential vendors concerned and you’ll want them to get it right;
  • you must allocate sufficient time for the sourcing project team to produce a quality RFP. This isn’t something that can be squeezed into a few spare minutes each day of someone’s existing workload;  
  • not performing a thorough evaluation of the market before issuing the RFP. This may lead to excellent potential candidate vendors never even receiving the RFP;
  • sourcing decisions made ‘in principle’ before the RFP is even issued. This often arises due to highly effective sales activities by some vendors, meaning the RFP becomes a notional compliance exercise only, as the background reality is that it is a ‘done deal’ already. This is never a sound idea (see the preceding point) but also because only an objective evaluation of a full RFP provides the basis for a managed-risk decision;
  • the sourcing project team not fully consulting with all key stakeholders in your organisation. That can mean the RFP lacks full key stakeholder advance buy-in, resulting in turn in proposals being discredited without serious consideration by those same stakeholders;
  • RFPs which have become a de-facto statement of a technical solution. This is not uncommon when your IT personnel alone are charged with its production. This can inhibit innovative and cost-effective thinking from potential vendors.

Summary

The RFP process exists to facilitate the reception of proposals for co-location services that have the potential to positively transform your enterprise.

Given the potential criticality of its impact, it’s therefore imperative to take all of the above steps if you’re to get a number of suitable and cost-effective propositions.