Why Multi-Site Development Outgrows the Spreadsheet

The Weekend Tracker That Runs the Program

Walk into almost any retail development team and you will find the program running on a spreadsheet. It tracks the pipeline of sites, the construction schedule, the budget, the open issues, and the opening dates, all in one workbook that someone built in an afternoon. Industry analyses are blunt about how common this is. The primary business system for managing projects is, more often than not, Microsoft Excel.

Spreadsheets are familiar, cheap, and fast. Anyone who knows Excel is productive in hours, a team can start on a credit card, and there is no implementation project and no procurement battle. For a handful of stores a year, that is a perfectly reasonable choice.

The trouble is not that spreadsheets are bad at tracking work. They are genuinely good at it, which is exactly why they get entrenched. The trouble is what happens when the portfolio grows faster than the tracker, and the same flexibility that made the spreadsheet easy to start makes it expensive to trust.

Which Version Is the Real One?

The first thing that breaks is version control. A spreadsheet has no inherent single source of truth, so copies multiply. There is the master on the network drive, the copy someone emailed to the landlord's project manager last Tuesday, the version a regional manager downloaded to a laptop to work on during a flight, and the one named Budget_FINAL_v3_updated that nobody is sure supersedes Budget_FINAL_v2.

The storage model makes it worse. A file on a shared network drive can be overwritten by the last person to hit save, with no record of what changed. A desktop copy forks the moment it leaves the drive and never merges back. Moving to a cloud sheet in Google Drive or SharePoint helps with simultaneous editing, but it does not solve the underlying problem. People still keep private working copies, tabs proliferate, and a link shared in an email points to whatever state the file was in at that moment.

The cost shows up in meetings. Industry reporting describes teams spending the first fifteen minutes of a status meeting just establishing which version of a report is correct. When the number on the screen depends on which file you opened, the program is no longer working from one set of facts.

Rollups That Break When the Org Changes

A single store's tracker is manageable. The hard part is the portfolio view, rolling fifty or two hundred projects into one picture leadership can act on. In a spreadsheet, that rollup is hand-built, usually with links and lookups that reference specific tabs, columns, and file names.

That scaffolding is fragile. Rename a column, reorganize the regions, or restructure how a team labels its phases, and the consolidation quietly breaks. Even the platforms built on top of spreadsheets warn about this in their own documentation, cautioning that changing column names after a rollup is connected can break the deployment. And because every region or project manager tends to build their own version of the tracker, there is no standard structure to roll up in the first place. You are not consolidating one model across the portfolio, you are reconciling dozens of slightly different ones.

The result is reporting executives stop trusting. One cross-industry survey found that roughly nine in ten workers doubt the accuracy of their critical project information, and that most spend hours every week just hunting for it. Numbers assembled by hand from disparate sheets invite exactly that distrust, and at the board level, distrust is expensive.

The System of Record in One Person's Head

Every mature spreadsheet program has a person behind it, the one who built the formulas, wired the links, and knows why the rollup tab works the way it does. That person is a single point of failure. When they are on vacation, updates stall. When they leave, the institutional knowledge of how the system actually works can walk out the door with them.

This is not hypothetical. The portfolio tools built on spreadsheets expose the same risk in their own admin models, where deactivating the wrong account can strand the records nobody else can reach. The more capable the spreadsheet becomes, the more it depends on the one person who understands its plumbing, and the harder it is to hand off.

A system of record should outlast any individual on the team. A hand-built workbook usually does not.

What a Multi-Site Program Actually Needs

The point is not that spreadsheets cannot track projects. It is that a multi-site development program needs a few things a blank grid does not give you, no matter how cleverly it is configured. These needs are tool-agnostic, and they are the right checklist to evaluate any system against.

• A shared model everyone reads from, with stores, sites, and projects as real objects rather than rows someone defined locally
• One current version of the truth, so a link always points to the live state and there are no private working copies to reconcile
• A structure standardized across regions and project managers, so the portfolio rolls up without manual reconciliation
• Cost tracked as a governed baseline with commitments and approved changes, not formulas anyone can overwrite
• Versioned documents and drawings, so the current set is unambiguous and prior issuances are preserved
• An audit trail that records who changed what and when, so the numbers survive scrutiny
• Scoped access for outside partners like general contractors and landlords, without emailing them a copy of the whole workbook

Knowing When You Have Outgrown It

None of this means the spreadsheet was a mistake. It was the right tool to start, and for a small or early-stage program it still is. The skill is recognizing the moment you have outgrown it, before a missed opening date or a blown budget makes the decision for you.

The signals are consistent. Project volume is rising faster than the team can keep the tracker current. A reorg or a renamed field breaks the rollup. Executives no longer trust the numbers, and meetings start with a debate about which version is right. Someone who holds critical knowledge about how the workbook works leaves, or nearly does, and the program feels the gap. This is the gap purpose-built software is meant to close. A platform like RolloutIQ™ ships the retail model as first-class objects, from brand down to location, site, and project, with the budget, schedule, drawings, and approvals already wired together and an audit trail underneath. The difference is not that it can do more than a spreadsheet. It is that the model and the workflow come built in, rather than invented and maintained by hand.

Multi-site development is ultimately a coordination problem across many people, many sites, and a long timeline. The container that coordination lives in has to be something the whole team can trust, update, and hand off. Past a certain scale, that is the one thing a spreadsheet cannot be.