Overview: Multi-site infrastructure rollouts blow past budget most often not because scope changes, but because a design gets finalized and replicated across every location before anyone builds a real pilot to test it. A pilot phase surfaces hidden dependencies (like power, connectivity, or access requirements) while the fix is still small, instead of after it’s been replicated at scale.
Why do multi-site rollouts go over budget without any scope changes?
We’ve seen this pattern often enough across large rollouts to treat it as a known failure mode, not a one-off mistake. A project gets scoped and priced accurately based on what the survey found. Months later, someone does the math and realizes it’s grown into a multiple of that original number, and nobody can point to a single decision that explains it. The definition of the work never changed. What changed was what the team actually knew about the sites once installation started.
The gap almost always traces back to the same place: a survey documents what equipment exists, what needs replacing, and what the space looks like. It doesn’t always confirm that a site can physically support what’s being installed, things like power, network capacity, structural access. These gaps aren’t caused by a careless survey. They happen because that particular dependency had never been a variable worth checking in that type of project before. It seemed like a given.
What actually causes the cost overrun?
In a typical case, the overrun traces back to one missed dependency that turns out to be widespread. Power is a common example: new equipment draws more of it than what it replaced, or needs it somewhere it wasn’t previously required. Once installs begin and the gap becomes visible, the fix isn’t a design change. It’s calling in an electrician, site after site, on a timeline nobody planned for. The same pattern shows up with other dependencies: network capacity, structural access, or compatibility with equipment being reused instead of replaced.
Was the survey done wrong?
No, and this is the part that tends to surprise people. A survey built for speed and broad coverage isn’t built to surface every possible dependency. The dependencies that end up mattering most are usually the ones nobody thought to check, precisely because they’d never been relevant before. A well-run survey, executed by an experienced team, can still miss something significant. That’s worth some thought because it means the fix isn’t “be more careful next time.” The fix is structural. Built into how the project is sequenced, not into how carefully any one step is performed.
What’s the actual structural mistake?
Running the entire survey phase, across every site in the rollout, before a single install happens anywhere. When that happens, there’s no opportunity to learn from the first few sites and adjust before designing the rest. Whatever gap exists in the survey process exists identically across every site surveyed under that process, because nothing has yet happened to reveal it. By the time installs begin and the gap surfaces, it isn’t a problem at one site. It’s a problem already baked into the design for a large share of the rollout, discovered all at once, with no time built in to have caught it earlier.
How does a pilot phase fix this?
A pilot phase means installing a small number of sites completely, from start to finish, before finalizing the design for every remaining location. That changes where a hidden dependency gets discovered: at site three instead of site one hundred and thirty. It becomes a footnote in the design instead of a rollout-wide change order.
This is why a proof-of-concept phase should be a standard part of any large-scale, multi-site rollout, not an optional extra step, but the mechanism that catches the dependency nobody thought to survey for.
What does a proof-of-concept phase need to include to be effective?
A pilot only works if it’s treated as a discovery exercise, not a formality. Four elements matter most:
-
-
- A real, complete install at a subset of sites. Not just a survey. Perform an actual build, so hidden dependencies have a chance to surface.
- A “what did we miss” review, not just a technical check. The goal isn’t confirming the plan works. It’s finding what the plan didn’t account for.
- A lightweight risk register, built before a single site is touched. For each phase of the rollout, ask what could go wrong, specifically. Most gaps surface just from someone deliberately asking the question.
- Explicit stakeholder alignment on running the pilot. If a client or sponsor wants to skip it to save time, that’s a legitimate call, but it should be made with the risk visible, not assumed away by default.
-
What questions should a risk register include before designing a multi-site rollout at scale?
A risk register doesn’t need to be complex to be useful. Before finalizing a design meant to be replicated across dozens or hundreds of sites, it helps to work through questions in each of these categories. Ideally you have this conversation with someone who’s allowed to say “I don’t know yet, let’s check”:
Power and electrical
-
-
- Does the new equipment draw more power than what it’s replacing, and does every site have capacity for that?
- Is power available in the specific location the equipment needs to go, or only elsewhere in the building?
- Are there sites where power will need to be added, and who owns that cost if so?
-
Connectivity and network
-
-
- Does every site have the network infrastructure (cabling, switch ports, wireless coverage) the new equipment assumes?
- Are there sites relying on non-standard or legacy network setups that won’t behave the same way?
- What happens at sites with poor or unreliable connectivity? Is there a fallback plan?
-
Existing equipment and compatibility
-
-
- Is any existing equipment being reused, and has that been confirmed to work with the new system, not just assumed?
- Are there sites where credentials or admin access to existing systems aren’t readily available?
- Is there a plan for equipment that turns out to be end-of-life or unsupported?
-
Physical space and access
-
-
- Does every site have the physical space, mounting points, or pathways the design assumes?
- Are there sites with structural differences (ceiling height, building materials, layout) that change the install approach?
- Who needs to grant access to install, and is that consistent across every site or does it vary by location?
-
People and process
-
-
- Who at each site needs to be prepared ahead of the install, and how will they know what to do?
- Is there a single point of contact per site, with authority to make decisions on the spot?
- What’s the plan when a site isn’t ready on the scheduled day?
-
Ownership and cost
-
-
- If something is missing on-site (like power), whose budget covers it?
- Has the client or stakeholder explicitly agreed on how gaps like this get resolved, or is that still assumed?
- Is there a documented change-order process, so gaps get captured and priced consistently instead of case by case?
-
None of these questions guarantee nothing gets missed. But asking them deliberately, before a design gets locked in and replicated at scale, is the difference between finding a gap once and finding it a hundred times.
Is a pilot phase worth the added time and cost?
Clients and internal stakeholders often want the survey phase done quickly, and proposing a pilot can look like it’s adding time and cost up front to a rollout everyone is eager to get moving on. That resistance is real and reasonable. Nobody wants to slow down a project that’s already been approved and budgeted.
But the trade is lopsided. A pilot phase costs a small, known amount of time early. Skipping it risks a much larger, unpredictable cost later. That cost comes in change orders, in re-engineering, in explaining to leadership why a project that was supposed to cost one number now costs several times that. The choice isn’t between “fast” and “careful.” It’s between paying a small, known cost now or an unknown, larger one later.
What’s the core takeaway?
A survey only tells you what it was built to ask. The only reliable way to find out what it didn’t ask is to build the thing once, at small scale, before committing to that same design everywhere else. At any meaningful scale, something will get missed on a multi-site rollout. The only real choice is whether it gets found at site three or site three hundred and that choice gets made long before the first site is ever surveyed.