Every property COO has run this project. You write the standard. Move-in inspections will be done this way. Work orders will be coded like this. Renewals will follow this sequence. You roll it out, you train on it, and for about a quarter it holds. Then a property manager in one building starts handling a recurring situation slightly differently because the standard did not quite fit, and it works, so she keeps doing it. Another building inherits a manager from a company with different habits. A third has an owner who wants something reported his way.

None of these is a rebellion. Each is a small, reasonable local adaptation. And eighteen months later, you have twenty buildings running twenty variations of a process you wrote once, you cannot compare their performance against each other, and nobody can tell you precisely when it stopped being one process.

The instinct at this point is to conclude that the team lacks discipline, or that the rollout was poor, and to run the project again, harder. That instinct is wrong, and running it again usually produces the same result. Operational drift across a distributed portfolio is not a failure of leadership or competence. It is the natural consequence of managing physical places you cannot constantly watch, staffed by capable people who will always adapt to what is in front of them. If you do not design for that, it will happen to you.

The half-truth that kills the project

The moment you push standardization, someone will tell you that each building is different, and the way you respond to that sentence determines whether the project survives.

If you dismiss it, you lose. Because it is partly true, and everyone in the room knows it. A 1970s garden-style complex with an aging boiler genuinely does not operate like a new mid-rise. A building with a single on-site manager cannot respond on the same clock as one with a full staff. An asset with a demanding institutional owner has reporting obligations another does not. Those differences are real, and a standard that pretends they are not will be quietly ignored by the people who have to live with them, which is the actual mechanism by which standards die. They are not usually rejected. They are just skipped, by good people, for defensible reasons, until nobody remembers there was a standard.

But if you accept the sentence completely, you also lose, because "each building is different" gets used to protect a lot of things that are not differences at all. They are habits. The way one manager codes a work order is not a property characteristic; it is a preference she developed at a previous employer. The reason one building runs its renewals ninety days out and another sixty is usually not a market difference. It is that two people made two choices once and nobody reconciled them.

So the useful work, and it is genuinely hard work, is separating the two. Which variations are demanded by the asset, the market, or the owner, and which are just accumulated personal history wearing the costume of a business requirement? Most standardization projects never do this, which is why they either fail as too rigid or dissolve as too permissive.

The failure mode nobody expects: too much standard

Here is the finding that surprises most operations leaders, and it inverts the usual story.

The typical failure point is not resistance to consistency. It is overcomplication. The pattern is well documented across multi-site industries: an organization tries to build one master procedure that anticipates every possible condition across every site type, and the document becomes so bloated and so poorly matched to any actual building that people begin skipping sections, because the tool no longer resembles the reality in front of them.

Think about what that means. The standard fails because it was too thorough. The COO, trying to be rigorous, wrote something that covered every case, and in doing so made it unusable for every case. The staff did not defy it. They just could not run it, so they built shadow processes, side spreadsheets, private trackers, the message thread where the work actually gets coordinated, and the official process became a thing that exists for auditors rather than for work.

If you want to know whether this is happening in your portfolio right now, do not ask whether people follow the standard. Ask how they actually handle an edge case, and listen for whether the answer involves a system you did not authorize. Rising exception volumes alongside high paper compliance is the classic signature: everyone is technically compliant, and the real work is happening somewhere else.

What actually holds

The pattern that survives contact with a real portfolio is not uniformity. It is a mandatory floor with a flexible ceiling.

You define a core that does not move, and you make it genuinely small. Not every step of every process, but the things that must be identical for the portfolio to function as a portfolio: how a unit and a lease are identified, how a cost is categorized, what a work order must capture before it can be closed, what a completed inspection must contain, and how the key numbers are defined.

That last one deserves more attention than it usually gets, because it is where standardization quietly dies without anyone noticing. Ask two of your property managers for economic occupancy and you may get two numbers computed on different foundations: one excludes units down for renovation, reasoning that they were never available to rent, while the other leaves them in, reasoning that an empty unit is an empty unit. Both positions are defensible. Neither manager is wrong. But the moment those two numbers land in the same portfolio report, you are comparing figures that do not mean the same thing, and every decision you make on that comparison is slightly untethered. The same happens with maintenance cost per unit, where one manager counts a capital replacement and another does not.

The floor, then, is not really about controlling how people work. It is about ensuring that what they produce is comparable, because comparability is the entire reason you wanted a standard in the first place.

Above that floor, you allow variation, but you do not allow it to be silent. This is the whole trick, and it is where most programs are weakest. The failure is not that exceptions exist; it is that a local manager can satisfy a genuine need by quietly changing something, and nobody upstream ever knows. So the deviation gets recorded, with a reason and an approver, and it shows up somewhere a regional leader can see it. Now the exception is a decision rather than a drift. You can look at your portfolio and see exactly where the standard was bent, by whom, and why, and you can tell the difference between a building that needed something different and a building that simply developed a habit.

That distinction is the entire value. Drift is invisible; governed exceptions are visible. Same variation, completely different operational position.

Why this gets harder in property specifically

Two things make this materially harder for a property portfolio than for, say, a chain of stores.

The first is that your operating units are physically distributed and mostly unwatched. A COO cannot walk twenty buildings, and the people running them are largely autonomous by necessity. Variation compounds fastest exactly where observation is thinnest, and in property, observation is thin almost everywhere.

The second is more structural, and it is the one that quietly defeats otherwise good standardization programs. If each building's information lives in a different place, or in systems that define things differently, then standardizing the process cannot deliver its main benefit, because you still cannot compare the outputs. When the data from each site cannot be meaningfully compared, benchmarking becomes impossible, and once you cannot benchmark, you cannot tell which building is actually underperforming, which means you cannot enforce the standard even if everyone agreed to it. The program collapses not because people rejected it but because it produced nothing you could act on.

Where to start on Monday

If you want to make progress on this without launching another failed program, three moves do most of the work.

Take your existing standard and cut it in half. Whatever is left after you remove everything that is not strictly necessary for buildings to be comparable, that is closer to your real floor. A short standard that people actually follow beats a comprehensive one they route around.

Then go and find the shadow processes. Ask three property managers how they really handle a difficult move-out, or a disputed charge, or a vendor who did not show. Do not ask whether they follow the process; ask what they actually do. The gap between those two answers is your true operating model, and it is more accurate than any documentation you have.

Then pick the handful of definitions that must be identical, the ones that make comparison possible, and enforce only those, hard, while letting the rest be governed exceptions with a name attached. You will get further with a small floor rigidly held and every deviation visible than with a large floor that quietly erodes.

Standardization does not fail because property people are undisciplined. It fails because it was designed for buildings that behave and staffed by people who cannot afford to wait for the standard to catch up with reality. Build for the reality and it holds.

Frequently Asked Questions

Q1. Why does operational standardization erode across a property portfolio?
Because distributed teams naturally develop local adaptations when a standard does not quite fit the situation in front of them, and those small variations compound over time. It is not a discipline problem. It is the predictable result of managing physical places that cannot be constantly observed, and it happens to well-run companies as reliably as to badly run ones.

Q2. Isn't it true that every building really is different?
Partly, and dismissing that is how standardization projects die. Asset age, staffing levels, owner requirements, and market conditions produce genuine differences. But "each building is different" is also used to protect variations that are just accumulated personal habits. The essential work is separating the differences the asset demands from the ones a person happened to introduce.

Q3. What is the most common reason a standardization program fails?
Overcomplication, not resistance. Organizations often write one master procedure trying to cover every possible condition, and the result is so bloated and poorly matched to any specific building that staff skip sections and build shadow processes instead. The standard fails because it was too thorough to be usable.

Q4. What are shadow processes and how do I detect them?
They are the unofficial ways work actually gets done: side spreadsheets, private trackers, message threads where coordination really happens. To find them, do not ask whether people follow the process. Ask how they handle a difficult edge case and listen for tools you never authorized. High formal compliance alongside rising exceptions is the classic signature.

Q5. What should actually be standardized?
A small mandatory floor: how units and leases are identified, how costs are categorized, what a work order or inspection must capture before it is complete, and how the key metrics are defined. That last point matters more than it seems. If one manager excludes renovation units from economic occupancy and another includes them, the two buildings are not comparable, and comparison is the point of standardizing at all.

Q6. How do I handle legitimate exceptions without losing control?
Make them governed rather than silent. A deviation from the standard should be recorded with a reason and a named approver, and it should be visible in reporting. The failure is not that exceptions exist; it is that a local manager can quietly change something and nobody upstream ever knows. Visible exceptions are decisions; invisible ones are drift.

Q7. Why does standardization fail even when everyone agrees to it?
Often because the information from each building cannot be meaningfully compared, so nobody can tell which sites are actually deviating or underperforming. Without comparable data, benchmarking is impossible, enforcement becomes guesswork, and the program produces nothing actionable. Process standardization depends on the consistency of what sits underneath it.

Q8. Where should a COO start?
Cut the existing standard down to only what is necessary for buildings to be comparable, find the shadow processes by asking managers what they actually do rather than what the process says, and then enforce a small set of shared definitions rigidly while allowing everything else as a recorded, approved exception.