An RFP for a relocation has one job beyond selecting a vendor: it has to define the work precisely enough that the bids are comparable and the price holds. Those two outcomes come from the same thing, which is specificity.
Where scope is vague, providers bid their own interpretations. The proposals arrive at different prices for different work, the evaluation becomes guesswork, and the lowest bid frequently wins because it assumed the least. Every assumption that turns out to be wrong becomes a change order later, priced without competitive pressure.
What Should the RFP Tell Bidders About the Environment?
Everything needed to price it: the asset inventory, both facilities, and the route. Providers cannot price what they cannot see. The most common cause of unreliable bids is an RFP that describes the project in general terms and expects an accurate number.
Include the asset inventory: device counts by type, with rack unit totals and approximate weights. Rack counts and whether racks themselves are moving. Storage capacity and media types. Anything unusual — mainframe, high-density GPU, tape libraries, equipment beyond ordinary handling — called out explicitly, because these change the resourcing and the price substantially.
Describe both facilities honestly. Loading dock availability and dimensions, freight elevator capacity and its measurements, distance from dock to floor, floor loading limits, raised floor or slab, aisle widths, and any access restriction — stairs, tight turns, doors that equipment will not fit through. Building rules including permitted work hours, union requirements, insurance and badging requirements, and how long site access approval takes.
Distance and route between sites, including anything that constrains vehicles.
Where a fact is unknown, say it is unknown rather than guessing. A stated unknown gets priced as a contingency; a wrong fact gets priced as certainty and becomes a change order.
Which Scope Boundaries Cause the Most Disputes?
State plainly which activities are in scope and which are not. These boundaries cause the most disputes:
Who performs deracking and who performs racking. Whether cabling at the destination is included and to what standard. Whether the provider handles packaging and materials or whether they are supplied. Who powers systems down and brings them up, and who tests and validates them afterward; that system work is normally your IT team's. Who disposes of packaging, and who handles equipment not making the trip. Whether decommissioning of the source site is included.
Most of the others are legitimately either party's work. What causes trouble is leaving it unstated, which produces bids that differ in scope rather than in price.
Which Constraints Drive the Price?
Five constraints drive most of the price: schedule, downtime, waves, compliance, and insurance.
Schedule. The required completion date, any fixed constraints such as a lease expiration, and the permitted working windows. Weekend and overnight work costs more, and a provider who did not know it was required has underbid.
Downtime. The outage tolerance per system or per group. This determines the whole approach and therefore most of the price.
Waves. Whether the move happens as a single event or across multiple phases, and roughly how many.
Compliance. Any regulatory regime that applies, and any requirement for chain of custody documentation, cleared or screened personnel, escorts, or particular destruction standards such as NIST SP 800-88. These are cost drivers, and discovering them after award is expensive.
Insurance. Required coverage types and limits, and whether the client must be named on the policy.
Ask for Comparable Responses
Structure the response format so proposals can be evaluated side by side. Unstructured responses take longer to evaluate and hide the differences you most need to see.
Require pricing broken out by phase and by activity rather than a single number. A lump sum cannot be compared or negotiated, and it conceals which assumptions differ.
Require the assumption list explicitly. This is the most informative section of any proposal, because it reveals exactly where a low bid got its number.
Require the proposed team with roles, counts, certifications, and clearance status where relevant, and require named key personnel. Require the project plan, the change order process and rate card, references from comparable work, and confirmation of insurance and certifications.
Ask how they handle a specific problem — a system that will not power on at the destination, or a schedule slipping mid-wave. The answers separate providers who have done this from providers who have written about it.
How Should You Evaluate Bids Beyond Price?
Weight the criteria before the responses arrive, and write the weighting down, as federal buyers must under FAR 15.304. Doing it afterward invites the evaluation to be reverse-engineered from a preferred outcome.
Relevant experience with environments of similar size and regulatory posture. The realism of the plan — a schedule with no contingency is a schedule that will not hold. The quality of the assumptions, since a provider who has thought carefully will list assumptions a superficial bidder never considered. Team credentials and whether the proposed people are actually available. References that were checked rather than collected.
Treat an unusually low bid as a question rather than a bargain. Something in it is scoped differently, and finding out which thing during evaluation is far cheaper than finding out during execution.
Leave Time for Site Visits
Providers bidding a facility they have not seen are bidding a facility they are guessing about.
Build a site visit into the RFP timeline for both locations, and let bidders ask questions afterward. Distribute every question and answer to all bidders so they are pricing the same information.
The visit consistently surfaces constraints the RFP missed, because experienced providers know what to look for and will ask about things nobody thought to document. Those questions are useful to the project regardless of who ultimately wins.