The Complete Guide to Multi-Jurisdiction Permitting

Permitting across multiple jurisdictions is not a bigger version of permitting in one jurisdiction. The discipline is structurally different, and the operators who treat it as a scale problem rather than a new problem will lose the schedule by site fifteen. This guide is a complete reference for designing a multi-jurisdiction permitting program from first principles, drawn from the operating model Commun-ET runs for national, multi-market rollout programs.

If you are about to launch a national rollout, run a multi-state development pipeline, or stitch together a portfolio of acquired projects spread across cities, this is the playbook. It does not require any single platform to execute, but it does require a system that refuses to lose information at the seams. Our External PM Playbook for Multi-Site Rollouts covers the engagement model; this guide is the operating manual.

What changes at scale

A single-jurisdiction permit is a vertical problem. You learn one code, one set of reviewers, one fee schedule, one submittal format, and you execute against them. A multi-jurisdiction program is a horizontal problem. You are now running a fleet of permits, each with its own code, reviewers, fees, and format, and the variance between them is the work. The mistake almost every program makes is staffing the horizontal problem with the same vertical-thinking PM model that worked at one site.

Three things break at multi-jurisdiction scale: information transfer between sites, reviewer-relationship continuity, and standards drift. A program that does not solve all three will plateau at the point where its strongest individual PM hits capacity. That is usually somewhere between twelve and twenty active permits per PM, depending on jurisdiction mix.

“Single-permit thinking does not scale. Programs that win at twenty jurisdictions are built around a system of record, not a roster of heroes.”

The architecture: a system of record, not a roster

Every multi-jurisdiction program lives or dies by its system of record. That is the single source of truth where every permit, every comment, every approval, every condition, and every reviewer contact lives in a structured, queryable form. It does not have to be PermitPilot. It can be a properly disciplined instance of a generic PM tool, a spreadsheet system that never breaks its conventions, or a custom-built tracker. What it cannot be is a collection of personal inboxes and individual SharePoint folders.

The system of record has three jobs. First, it has to capture every artifact the program produces (submittals, comments, responses, approvals, conditions) in a format that is searchable across sites. Second, it has to expose the program's status to leadership in a single view, not a status meeting. Third, it has to survive turnover. When a PM leaves, the next PM should be productive in days, not months, because every relevant fact about every active permit is in the system, not in the departing PM's head.

If you are choosing between building this yourself and bringing in a firm that already runs one, the tradeoff is well-defined. Building gives you exact fit to your process. Engaging a firm gets you a faster ramp and a much larger universe of jurisdictional records on day one. Commun-ET built PermitPilot™, our proprietary operated service layer, specifically because the system-of-record problem is unsolvable at portfolio scale without dedicated infrastructure that a delivery team maintains every day. The PermitPilot overview walks through what our team runs.

The standards: format, not content

The single highest-leverage discipline in multi-jurisdiction permitting is enforcing a standard submittal format across every site, every jurisdiction, every package. The content of the package will vary, because every jurisdiction wants different exhibits and different code citations. The format, the structure, the cover sheet, the drawing index, the response-to-comments template, the close-out checklist, never varies.

When the format is standard, reviewer comment volume drops because reviewers can navigate the package quickly. Internal review time drops because every PM looks at every package in the same structure. Cross-site analysis becomes possible because every artifact lives in a known place. On a recent national QSR rollout, packet standardization alone cut average reviewer-comment count per site by 40 percent in the first two months.

The contact matrix: who you know per jurisdiction

For every jurisdiction in your program, the contact matrix should name the building official, the chief plan examiner, the lead inspector for your trade, the public-works coordinator, the fire marshal contact, the environmental review lead, and any council or commission staff with jurisdiction over your use type. These are not relationships you build the week you file. They are relationships you maintain continuously, ideally through a named principal who attends pre-application meetings even on sites that are months from filing.

The contact matrix lives in the system of record, gets updated every time a reviewer changes, and travels with the file across PM turnover. It is the single artifact most program teams underestimate the value of, and the one most likely to be lost when an experienced PM leaves.

The cadence: weekly, monthly, quarterly

Weekly, the program runs a one-page executive brief: what shipped, what slipped, what is at risk next week. No exceptions, no slides, no meeting required. The brief is the forcing function that keeps the program from confusing activity with progress.

Monthly, the program runs a cross-site comment analysis: which conditions are recurring, which jurisdictions are generating the most rework, which design standards need to be updated to pre-empt the next round of comments. This is where the program's institutional learning compounds, and skipping it is why most multi-jurisdiction programs feel like they are reinventing the wheel on site twelve.

Quarterly, the program runs a jurisdiction-portfolio review: which markets are slowing down, which are speeding up, which reviewers have changed, where fee schedules have shifted, where new ordinances are coming online. The output is a refreshed risk register that drives next-quarter submittal sequencing.

Staffing the program

Multi-jurisdiction permitting at scale is run by three roles. A program director who owns the executive narrative, the cross-site standards, and the steering-committee relationship. A pool of jurisdiction-anchored PMs who each carry 10 to 20 active permits in a contiguous set of markets where they have built reviewer relationships. A program operations role that owns the system of record, the contact matrix, the comment-tracking analytics, and the cadence.

Programs that try to run with just PMs, no director and no ops, will plateau early. Programs that try to run with just a director and an ops layer, no anchored PMs, will lose reviewer continuity and pay for it in cycle time. The three-role architecture is the smallest viable team that scales past 50 simultaneous permits.

When to bring in external help

Most internal teams hit a clear inflection point somewhere between 30 and 60 simultaneous permits across more than 10 jurisdictions. Below that line, an experienced internal director can hold the program together with a strong PM bench. Above that line, the standards drift and the institutional memory problem become structural, and external PM engagement becomes the highest-leverage move on the table.

Commun-ET's External PM service is built specifically for this inflection. We install the system of record, write the standards, build the contact matrix, run the cadence, and hand the operating model back to the internal team after the first year. The goal of the engagement is not to be permanent. The goal is to make the program legible to everyone who touches it.