A multi-site IT rollout is planned in five stages: survey the sites, fix a build standard, pilot it on a handful of locations, sequence the remaining sites against engineer availability and access windows, then close each site with evidence of completion. Sequencing and site access, not engineering skill, decide whether the schedule holds.
Rollouts fail slowly and in the same places every time: a build standard that was never frozen, sites that cannot be accessed when the engineer arrives, and a plan that assumed every location looks like the head office. This article covers the sequence, what a survey needs to produce, how to staff the work, and the points at which schedules usually slip.
Throne Solutions is a B2B on-site IT field engineering provider headquartered in Sheffield, UK, supporting businesses in 60+ countries.
Need engineers on site in the UK, Europe or further afield?
Throne Solutions provides on-site IT field engineers across 60+ countries. Tell us your sites and the kind of cover you need, and we will come back with options and a quote.
Why rollouts overrun
Because duration itself is the risk. Research by McKinsey with the University of Oxford found that “large IT projects run 45 percent over budget and 7 percent over time”, while “delivering 56 percent less value than predicted” (McKinsey). The same study puts a number on drift: “every additional year spent on the project increasing cost overruns by 15 percent”.
McKinsey also attributes roughly half of all cost overruns to failures of strategy, stakeholder management and mastery of the technology and content, with “poor performance on the second two dimensions” — team incentives and core project management — accounting “for an additional 40 percent of overspending”. In other words, the cause is almost never the engineering. It is the planning around the engineering.
That has a direct implication for a hardware rollout. The way to protect the budget is to compress the calendar, and the way to compress the calendar is to run sites in parallel. Parallel delivery needs engineers in more than one place at once, which is a staffing decision made at the planning stage rather than a problem to solve in week six.
The five stages, in order
Every rollout follows the same spine, whether it is forty branches or four hundred. The stages are not optional and they do not reorder.
- Survey. Establish what is actually at each site, not what the asset register claims. Power, space, cabling, network, access, local constraints.
- Fix the build standard. One documented configuration, signed off, frozen. Variants are named exceptions, not improvisation.
- Pilot. Three to five sites chosen for difficulty, not convenience. The pilot’s job is to break the build standard before the estate does.
- Sequence and deliver. Order the remaining sites by access window, geography, dependency and risk. Then run as many in parallel as your engineering capacity allows.
- Close out. Per-site evidence, asset records updated, exceptions logged, support handover complete. A site is not done because the engineer left.
What the survey has to produce
A survey is not a visit; it is a dataset. If it does not produce a per-site record you can sequence against, it was a tour. The minimum useful output covers power availability and socket types, rack or cabinet space and condition, existing cabling and patching, network uplinks and addressing, physical access route and lift or stair constraints, security induction and escort requirements, trading or operating hours, and whoever on site actually holds a key.
That last item sounds trivial and causes more aborted visits than anything technical. A site survey and installation exercise that captures access reality is what lets the schedule survive contact with the estate.
Why the pilot sites should be the awkward ones
A pilot run on three easy sites proves nothing except that easy sites are easy. Pick the oldest building, the site with the worst cabling and the one in the hardest territory to reach. Everything the pilot exposes is a defect found at a cost of three sites rather than three hundred.
Staffing: the three models
| Model | Works when | Breaks when |
|---|---|---|
| Travelling team One crew moves site to site |
Sites are clustered, the build is complex, consistency matters more than speed | Sites are spread across regions or countries — travel and hotel cost overtakes labour, and the calendar stretches |
| Local dispatch Engineers sourced near each site |
Sites are dispersed, the build is documented, many sites must run in parallel | The build standard is vague — dispersed delivery amplifies every ambiguity in the documentation |
| Hybrid Core team plus local hands |
Most rollouts of any real size: specialists on the hard parts, local engineers on the volume | Nobody owns the interface between the two groups, so exceptions fall between them |
For anything crossing borders, local dispatch or a hybrid is usually the only model that fits the calendar, which is what global field services exists to provide. The decision is driven by site dispersion, not by preference.
Where the schedule actually slips
Access windows
Retail sites cannot be touched in trading hours. Factories have shift patterns. Hospitals and schools have their own calendars. Sequence by access window first and geography second, or you will build a beautifully efficient route that nobody can let you into.
Logistics and staging
Kit delivered to site before the engineer is kit that gets moved, opened or lost. Kit delivered after is a wasted visit. Staging — configure and label centrally, ship to site timed to the visit — costs more per unit and saves more per site. Decide early, because it changes the procurement schedule.
The unfrozen build standard
A build that keeps improving mid-rollout produces an estate with three generations of configuration in it, and a support team that cannot predict what is behind any given door. Freeze it after the pilot. Genuine improvements go into a documented exception list and a later phase.
Treating close-out as paperwork
Serial numbers, asset tags, photographs and a signed worksheet per site are what make the estate supportable afterwards. Skip them and the first fault at site ninety-three becomes an investigation. TechTarget’s definition of the underlying task set is useful here: moves, adds and changes are “a set of tasks that IT teams regularly perform to keep computing equipment up to date” (TechTarget) — and the same source notes that such work often sits inside “a larger IT asset lifecycle management initiative”. A rollout is the moment that asset record is either created properly or corrupted for years.
No plan for the exceptions
Across any real estate, a share of sites will not fit the standard — wrong power, no space, cabling that has to be replaced first. Budget for them as a known category with their own path, rather than discovering them one at a time and stopping the line each time.
What to fix before day one
- A per-site record from survey, including access and escort reality.
- A frozen, documented build standard with a named owner.
- A pilot on your hardest sites, with findings written up.
- A sequence ordered by access window, then geography, then dependency.
- A staffing model matched to site dispersion, with parallel capacity agreed.
- A logistics decision: staged centrally, or shipped direct, and who signs for it.
- A close-out pack definition, agreed before the first site rather than after the fiftieth.
- A support handover: who answers the phone about a site once the rollout has moved on.
Planning cover for a new contract or region?
Send us the countries, sites and service level you need. It takes two minutes, and there is no obligation.
Key takeaways
- Rollouts run in five stages: survey, freeze the build, pilot, sequence and deliver, close out. The order does not change.
- Duration is the main financial risk. McKinsey found large IT projects run 45 percent over budget, with every extra year adding 15 percent to the overrun — so compress the calendar by running sites in parallel.
- Sequence by access window before geography. A route nobody can let you into is not a route.
- Match the staffing model to how dispersed the sites are: travelling team for clusters, local dispatch for spread, hybrid for most real estates.
- Close-out evidence per site is what makes the estate supportable afterwards. Define the pack before the first visit.
Frequently asked questions
How do you plan a multi-site IT rollout?
In five stages: survey every site to establish what is really there, fix and freeze a single build standard, pilot it on a few difficult sites, sequence the remaining sites by access window and geography, then close each site out with evidence. Sequencing and site access decide the schedule far more than engineering does.
How long does a multi-site rollout take?
It depends on site count, build complexity, access windows and how many engineers can work in parallel. Parallel capacity is the lever that matters: McKinsey found that every additional year on a large IT project increases cost overruns by 15 percent, so a shorter calendar is a cheaper project.
Do I need a site survey before a rollout?
For anything beyond a handful of identical sites, yes. The survey produces the per-site dataset the whole schedule is built on — power, space, cabling, network, access route, induction requirements and operating hours. Without it you are sequencing on assumptions.
Should the pilot use easy sites or hard ones?
Hard ones. A pilot exists to break the build standard before the estate does. Choose the oldest building, the worst cabling and the hardest location to reach, and you find the defects at a cost of three sites instead of three hundred.
Is it better to use a travelling team or local engineers?
It depends on dispersion. A travelling crew gives consistency and suits clustered sites and complex builds. Local dispatch gives parallel delivery and suits spread-out estates with a well-documented build. Most larger rollouts use a hybrid: specialists on the hard parts, local engineers on the volume.
Why do IT rollouts go over budget?
Rarely for technical reasons. McKinsey, with the University of Oxford, attributes about half of cost overruns to strategy, stakeholder management and mastery of the technology and content, and a further 40 percent of overspending to team incentives and core project management. In hardware rollouts this shows up as unfrozen build standards, access failures and missing logistics planning.
What should a rollout close-out pack contain?
Per site: serial numbers and asset tags captured, configuration recorded against the build standard, photographs of the finished installation, any exceptions logged, and a signed worksheet. This is also the moment the asset register is either made accurate or left wrong for years.
Who handles support once a site is live?
Agree this before day one. A rollout team moves on; the estate does not. Decide whether live sites transfer to a help desk, a break-fix contract or a maintenance agreement, and make the handover a condition of close-out rather than an afterthought.
Rollouts and migrations from Throne Solutions
Throne Solutions runs rollouts and migrations across multi-site estates, starting from site surveys and installations and delivering the per-site work as IMAC services. Cross-border dispatch runs through global field services, with Wi-Fi services where wireless is in scope and retail support for store estates. Once sites are live, response tiers are agreed under SLA-baseret IT-support, backed by hardware maintenance and, where kit is past OEM cover, third-party maintenance. Coverage by territory is set out on Vores tilstedeværelse.
Throne runs offices in the United Kingdom, the United States, Denmark, Canada, Saudi Arabia and Pakistan, so a rollout can be run against your working day rather than someone else’s.
Send the site list, the build you want deployed and the window you need it in, and you will get a sequencing plan and a quote against the real estate.
E-mail: info@thronesolutions.com
Tell us what you need covered ·
Data centre support ·
IT consulting and field engineering
