Opening a new location
Fractional IT Lead for a New Location Launch
In short
A fractional IT lead for a location launch is not a part-time systems administrator. The role exists because a launch generates a specific kind of work that neither an existing IT team nor a general managed service provider covers: deciding what gets installed and in what order, holding the dependencies between IT and every other workstream, coordinating vendors nobody internally knows, and being reachable when the site is trading.
You need one when the launch has a fixed date, technical ownership sits elsewhere, and nobody on the ground is accountable for the sequence.
This applies to a second site, a franchise location, a relocation, or a first presence in a new country. The distance between the site and whoever owns the systems changes how much the role matters, not whether it is needed.
What the role actually does#
Sequencing. Deciding what has to happen before what, and which few items should jump the queue. On most launches only one or two items genuinely cannot wait, and the internet circuit is usually one of them.
Holding dependencies across workstreams. IT waits on the lease before circuits can be ordered, on interior design before detailed specification, on recruitment before device procurement is sized, on the payroll platform before journal integration can be tested. Others wait on IT: visual merchandising cannot start until customer-facing technology is in, stock cannot be received until logistics integration signs off, insurance cannot be placed until the controls pack exists. Somebody has to own that map.
Vendor coordination with unfamiliar suppliers. Carriers, cabling contractors, security installers, hardware suppliers. This is where local presence earns its cost, because remote vendor management at distance is slow and unreliable.
Being the on-the-ground decision point during local hours. Not doing everything. Being reachable, and empowered enough that routine matters do not wait a sleep cycle.
Translating between the parties. The existing IT team, any incumbent managed service provider, the local contractors, and the programme manager. These groups have different vocabularies and different assumptions about who owns what.
When you need one, and when you do not#
You need one if the launch has a hard date, technical ownership sits away from the site, you are opening a physical location, and nobody local is technically accountable.
You probably do not if the new presence is a handful of remote workers with no physical site, or your existing provider already has genuine delivery capability in that location rather than just clients there.
Hire permanently instead if the new operation will exceed roughly thirty people within a year, or it will hold its own systems ownership rather than extending the parent's.
Fractional lead, MSP, or permanent hire#
| Fractional lead | Managed service provider | Permanent hire | |
|---|---|---|---|
| Covers sequencing and dependencies | Yes | Rarely | Yes |
| Covers day-to-day support | Sometimes, often paired | Yes | Partially |
| Local vendor coordination | Yes | Varies | Yes |
| Cost during a nine month launch | Low to moderate | Moderate | High, plus recruitment lead time |
| Available on the timeline you need | Yes | Yes | No, hiring takes months you do not have |
The common pattern is a fractional lead through the build, converting to a managed service retainer at launch, with a permanent hire considered once headcount justifies it.
What to have them do first#
Get the delegated permissions defined as actions. A support responsibility matrix that names which services each party touches looks like agreement and is not one until it says which actions each party may perform. This is the single most common place a launch discovers, late, that its support arrangement cannot do what it promised. It also gates pricing, because nobody can commit to a service level for work they may not be permitted to carry out.
Build a dependency register with two owner columns. Most registers have one, which conflates the person chasing an answer with the person able to give it. Separate who routes from who decides, and add a field marking whether each item is a contractual requirement, a project dependency, a proposed practice or an open question, so nothing inferred gets read as an obligation. Multi-party launches fail at the routing layer more often than at the technical layer.
Run a reversed-dependency pass on the programme plan. Reversed dependencies never show as overdue and therefore never show as red. Two found on a recent launch: a cyber insurance controls pack scheduled after the insurance was to be bound, and website content testing scheduled to finish after the website launched. Neither was late. Both were impossible in the order given.
Write the boundary in one sentence. A new person should be able to read it and correctly infer who does what. If it takes a paragraph, the boundary is not agreed.
What it costs, and why the number arrives late#
The structure can usually be agreed before the figures. The stable components are a one-off setup fee billed across the build period, a fixed monthly retainer from launch, hourly on-site above an included baseline, and a per-seat charge above an included headcount.
The figures depend on things that are often still open: the delegated permission scope, the site layout, confirmed headcount, and the duration once the schedule is re-baselined. Naming what a number is waiting on is more credible than producing it early, and it avoids a renegotiation once reality arrives.
One thing worth expecting#
Most launch programmes begin later than the original schedule assumed, and the dates on the plan need re-baselining rather than defending. A lead who says so early is doing the job. A plan carrying dates everyone privately knows are wrong stops being used, and once the plan is not used the register becomes the only source of truth by accident rather than by design.
Common questions#
How many hours a week does the role take? Through a build, typically one to two days a week, concentrated around decision points and vendor coordination. It drops substantially after launch, when the work becomes support rather than sequencing.
Can our programme manager cover this? They can route it. They usually cannot make the technical calls, judge whether a vendor's answer is reasonable, or spot a reversed dependency inside a technical sequence.
Can the same person do the ongoing support? Often yes, and it is a natural conversion at launch. It is worth checking they actually have delivery capability and not just advisory capacity, because those are different businesses.
What should be in place before they start? Very little. A good first two weeks is spent finding out what is not agreed, which is more useful than starting with a complete brief that turns out to be wrong.
What is the biggest risk if we skip the role? Discovering a sequencing error close to the date, when the only remaining options are expensive. Circuits, cabling and landlord permissions are the three that cannot be compressed.