Multi-Site Lab Portfolio Governance, Decision Rights and Funding Ladders

The moment a lab organization crosses from one site to two or three, the friction stops being about pipettes and freezers. It becomes about who decides what. A single lab has an implicit hierarchy — the PI or lab manager makes the call, everyone knows it. Spread that same organization across three cities, four cost centers, and two funding sources, and suddenly nobody knows who owns the shared LC-MS, who pays when the Site B freezer fails at 2am, or whether an incident at one site should freeze operations at the others.

Most multi-site problems get blamed on communication. They're actually governance problems. The information exists; what's missing is an agreed structure for who acts on it and who pays for the consequences. This article lays out a portfolio-level operating model — decision-rights matrices, funding ladders, and reusable resolution bundles — that lab managers can adopt without hiring a governance consultant or inventing a bureaucracy nobody follows.

Why cross-site governance breaks in predictable ways

Single-site labs run on relationships. You know who to ask because you've worked next to them for years. That works right up until the org scales, and then the same informal habits create three recurring failure modes.

Ownership ambiguity. A capital instrument bought partly by Site A's grant and partly by shared infrastructure funds sits physically at Site A. Site B books time on it. When it needs a $40k repair, everyone points at everyone else. Nobody wrote down who owns the asset versus who operates it versus who funds it — and those are three different roles that quietly collapsed into one assumption.

Funding gaps at the seams. Each site budgets for its own operations. Shared services — the cross-site LIMS instance, the courier contract moving samples between sites, the on-call engineer covering all locations — fall between the cracks. Nobody's annual budget line explicitly covers the thing that spans everyone.

Escalation confusion during incidents. A contamination event or a freezer alarm at one site raises an immediate question: does this stay local, or does it become a portfolio-wide issue? Without pre-agreed escalation triggers, the answer depends on whoever happens to be awake, and it's inconsistent every time.

All three failures share something — they only surface under pressure. During a repair, a budget cycle, or a 2am alarm. That's the worst possible time to be negotiating who's in charge. The fix is to make these decisions boring and pre-made, long before the pressure hits.

The decision-rights matrix: the backbone of the whole thing

The single most useful artifact in a multi-site setup is a decision-rights matrix. It's a table that answers, for every recurring decision type, four questions: who recommends, who decides, who must be consulted, and who just needs to be informed.

If you've used RACI before, this is a close cousin — but keep it tighter. RACI charts tend to sprawl until every cell has three names and the whole thing becomes decorative. For multi-site lab governance, force yourself to name exactly one decider per decision type. Consultation can involve many people; the decision cannot.

The value isn't the specific rows — yours will differ. The value is that arguments about authority get replaced by a lookup. When the $30k repair comes up, nobody debates who signs off. You check the row.

One pattern worth calling out: the most contentious decisions are almost always the ones with a dollar threshold near a boundary. A repair quoted at $9,800 that creeps to $11,200 after the technician opens the unit suddenly changes deciders mid-process. Build in a rule for that — something like: "if a repair crosses a tier boundary during execution, the higher tier's decider is notified within four hours but work already authorized continues." Otherwise you get repairs paused halfway while someone hunts for approval.

Funding ladders: making shared costs someone's explicit responsibility

A decision-rights matrix tells you who decides. A funding ladder tells you whose budget absorbs the cost — and the two are deliberately separated, because the person who decides is rarely the one who pays.

The core idea is that every cost category has a defined sequence of who pays first, what triggers escalation to the next rung, and what the cap is at each level. Think of it as a waterfall for money.

Example funding ladder for shared-instrument maintenance:

1. 1
   Rung 1 — Usage pool. Routine maintenance and consumables are funded from a chargeback pool built on booked hours. If Site B uses 40% of the LC-MS time, Site B contributes 40% of the routine pool. Cap: the pooled annual maintenance budget (roughly $30k across sites, though this varies).
2. 2
   Rung 2 — Owning site's capital reserve. Repairs exceeding routine maintenance draw on the owning site's equipment reserve, up to a set limit (e.g. $15k per incident).
3. 3
   Rung 3 — Portfolio contingency fund. Anything above the site reserve, or any repair that would exhaust the reserve for the year, escalates to a central contingency line funded by a small levy on all sites. Cap set annually.
4. 4
   Rung 4 — Executive decision. Beyond the contingency cap, it becomes a replace-or-retire capital decision handled by the portfolio committee.

Each rung has a named owner and a cap. The failure mode that shows up most often is a contingency fund that exists on paper but was never actually funded — every site assumed the other sites' contributions covered it. Write the levy into each site's annual budget as a real, non-negotiable line, or the ladder collapses at exactly the rung you need most.

A second funding ladder worth building covers cross-site logistics — couriers, cold-chain shipping, cross-border fees. These costs are notoriously hard to attribute and they're rising. If your organization ships samples between sites regularly, responsibility for surcharges and disbursement fees should be explicitly assigned rather than absorbed by whichever site happens to be the shipper that month.

Resolution bundles: pre-packaged answers to fights you already know are coming

The most practical thing you can build is a set of resolution bundles — small, reusable playbooks for the three or four conflicts you know will recur. Each bundle contains: the trigger, the decision-rights reference, the funding-ladder reference, the required evidence, and the target resolution time. When the conflict happens, you don't improvise. You pull the bundle.

Here are three worked bundles you can adapt directly.

Bundle 1 — Contested asset ownership

Trigger: A shared instrument needs a decision (repair, relocation, retirement) and more than one site claims a stake.

Process:

1. 1
   Pull the asset register entry, which must record three distinct roles

   owner (holds the asset on their books), operator (runs day-to-day scheduling and maintenance), funder(s) (contributed capital, with percentages).

2. 2
   If the register is complete, the decision-rights matrix names the decider automatically. Done.
3. 3
   If the register is incomplete — which is the real-world case more often than not — the portfolio ops lead makes an interim call within 48 hours and flags the asset for a proper ownership reconciliation.
4. 4
   Log the outcome and update the register so this exact fight never happens twice for this asset.

Contested ownership is almost never a genuine dispute about competing interests. It's usually an artifact of a missing register field. The bundle's real job is to catch and close those gaps.

Bundle 2 — Cross-site funding gap for a shared service

Trigger: A shared service (LIMS licensing, on-call engineer, courier contract) needs funding and no single site's budget covers it.

Process:

1. 1
   Classify the service

   is it usage-driven (attributable to sites by volume) or availability-driven (a fixed cost that exists regardless of who uses it)?

2. 2
   Usage-driven services get split by measured consumption. Availability-driven services get split by an agreed fixed key — often headcount or number of active projects per site.
3. 3
   Route to the funding-ladder rung that matches the amount.
4. 4
   Lock the split for the fiscal year so it doesn't get relitigated monthly.

Most cross-site funding fights come from trying to usage-attribute a cost that's actually availability-driven. The on-call engineer costs the same whether Site C calls twice or zero times, so charging by call volume just punishes the site with the worst luck.

Bundle 3 — Incident escalation across sites

Trigger: An operational incident (contamination, freezer failure, data integrity event, security breach) occurs at one site.

Process:

1. 1
   First responder assesses against pre-set escalation criteria (see checklist below).
2. 2
   If any criterion is met, escalate to portfolio ops lead immediately, regardless of local severity assessment. When in doubt, escalate — the cost of an unnecessary escalation is a phone call; the cost of a missed one can be an entire cohort of samples.
3. 3
   Portfolio ops lead decides whether other sites take precautionary action (pausing a shared protocol, checking their own reagent lots from the same batch).
4. 4
   Document with a timestamped incident record and run the after-action review within a week.

Escalation criteria checklist — escalate to portfolio level if any of these are true:

1. 1
   The root cause could exist at other sites (shared reagent lot, shared SOP, shared vendor)
2. 2
   The incident involves samples or data spanning more than one site
3. 3
   Regulatory or sponsor notification may be required
4. 4
   The estimated impact exceeds the on-site manager's decision authority in the matrix
5. 5
   The incident affects a shared resource other sites depend on
6. 6
   There's any uncertainty about whether it qualifies

That last bullet matters more than the rest combined. The most damaging cross-site incidents aren't the big obvious ones — they're the "probably fine, stayed local" calls that turn out to share a root cause with other sites. A contamination traced to a single reagent lot means every site that received that lot needs to check, and that only happens if someone escalated. This connects directly to how you structure your broader operational risk register — the escalation criteria should map back to the risks you've already catalogued.

How this system connects to the rest of your operations

Portfolio governance doesn't sit in isolation. It's the layer that decides how your other operational systems get invoked across sites.

Resilience planning, for instance, lives or dies on clear escalation authority. A well-built operational resilience framework tells you what to do when critical infrastructure fails — but in a multi-site context, someone still has to decide whether one site's outage triggers precautionary action elsewhere. The governance layer is what turns a site-level playbook into a coordinated portfolio response.

Vendor decisions get sharper at portfolio scale too. When three sites buy the same critical reagent independently, you lose negotiating leverage and multiply your risk exposure to a single supplier. Consolidating under a portfolio-level procurement and vendor governance approach requires the decision-rights matrix to name who owns cross-site supplier relationships — otherwise every site keeps buying its own way and the "portfolio contract" exists in name only.

The workflow end to end looks like this:

Each piece feeds the next. Break any link and you're back to improvising under pressure.

A real scenario

A translational research group ran three sites — one hospital-based, two university-based — sharing a central biobank and a cross-site LIMS. On paper they were one organization. In practice, every cross-site decision was a negotiation.

The breaking point was a freezer compressor failure at the hospital site. The freezer held samples from projects run by PIs at all three sites. The repair quote came in around $22k. The hospital site refused to pay for a unit "everyone used." The university sites argued it wasn't their equipment. While the argument played out, the failover freezer filled to capacity and they came uncomfortably close to losing sample integrity on roughly 1,200 aliquots.

They resolved that specific crisis by executive fiat, but the near-miss forced the issue. Over the following quarter they built exactly the three artifacts described here: an asset register with separated owner/operator/funder fields, a maintenance funding ladder with a properly funded contingency levy (around $18k annually, split by sample-storage volume), and the three resolution bundles.

The measurable change wasn't dramatic. It showed up in time to resolution. Cross-site funding disputes that used to eat two to three weeks of email threads started closing in a day or two, because the answer was already written down. The next freezer repair, about eight months later, was authorized and underway within a few hours. No standoff. Nobody paused work to track down an approver. The governance was boring, which is exactly what you want it to be.

When this level of structure makes sense — and when it doesn't

This isn't free. Building and maintaining these artifacts costs real time, and there's a scale below which it's overkill.

When it makes sense: You have three or more sites, or two sites plus shared capital assets or shared funding sources. You've already had at least one cross-site dispute that ate significant management time. You're anticipating growth — adding sites or collaborators — and want the structure in place before the complexity arrives rather than after.

When it's premature: You have a single site, or two co-located sites under one budget and one manager. The informal hierarchy still works and everyone genuinely knows who decides. A heavy governance matrix in that situation is bureaucracy for its own sake, and it'll sit unused.

Who should be cautious: Organizations mid-merger or mid-restructure. It's tempting to lock down governance during a transition, but a matrix built on an org structure that's about to change will be obsolete in months. Build a lightweight interim version and do the full build once the structure settles.

Keeping it alive

The most common way these systems fail isn't bad design — it's decay. A decision-rights matrix built once and never revisited becomes wrong within a year as roles change, sites are added, and funding sources shift. Register fields go stale. People stop trusting the artifact and drift back to improvising.

Two habits prevent this. First, tie a review of the matrix and funding ladders to your annual budget cycle — you're already making money decisions then, so it's the natural moment to confirm who decides and who pays. Second, make every resolution-bundle invocation update the underlying registers as a required closing step. That way the system self-corrects: every time a conflict surfaces a gap, resolving it plugs the gap.

“

Tie a review of the decision-rights matrix and funding ladders to your annual budget cycle to ensure they stay current.

Over a year or two, the artifacts converge on something that actually reflects how your organization works. None of this requires exotic tooling. A shared spreadsheet and disciplined maintenance will get most organizations a long way. What matters is that the decisions are made before the pressure, written where people can find them, and owned by someone whose job it is to keep them current.

Multi-site governance isn't about adding control — it's about removing the need to negotiate the same three fights every time they come up.