Standardize the definitions. Be careful with the methods.

What a shared process actually buys

It is worth being precise about the benefit, because programs that cannot name it end up defending themselves on general principle and lose. There are five real ones.

• Comparability. Two companies reporting retention on the same definition can be read side by side. Two reporting it their own way produce a portfolio number that is the sum of two different questions.
• Cost. One contract, one implementation, one set of training material, rather than the same negotiation eight times.
• Transferable people. An operator moving between companies arrives knowing how the work is done, which is most of what makes a portfolio operating team possible.
• Speed on the next acquisition. The first hundred days are cheaper when there is an answer to how this is done here.
• Diagnosis. A shared process makes an outlier legible. Without one, a company that is struggling and a company that is merely different look identical from the fund.

The first and the last are the strongest, and they share a feature worth noticing: both are satisfied by agreeing definitions and outputs, and neither requires anyone to change how the work is performed. That is the cheapest standardization available, and it is routinely skipped because it has no vendor attached and demonstrates badly in a meeting.

Where local variation is doing real work

The failure case is not a company refusing to comply. It is a company complying, the process fitting badly, and the cost showing up two quarters later somewhere nobody connected to the program. These are the differences that are usually load-bearing.

• Regulation. A company selling into healthcare, financial services, or the public sector carries approval steps that look like overhead from outside and are not optional from inside.
• Channel. Direct sales, partner-led and self-serve are different businesses wearing the same revenue line, and a process built for one suits the others badly, structurally rather than cosmetically.
• Contract size. A process designed around contracts worth tens of thousands does not survive contracts worth millions, and imposing the reverse wastes most of a year.
• Market convention. Payment terms, procurement rules, and the shape of the buying committee differ by geography in ways a head office cannot overrule.
• Stage. A company still finding its market changes its process faster than any standard can be revised, and freezing it is a cost paid immediately.

Notice that none of these is about preference or culture. Each traces to a fact outside the company — a regulator, a customer, a contract, a market. That is not a coincidence; it is the test.

The question that separates them

Ask why the difference exists, and keep asking until the answer lands on something outside the company’s own history. Answers arrive in three kinds, and they are easy to tell apart once you are listening for the distinction.

The first kind names an external fact: our customers are hospitals and they require this sign-off; our contracts are annual because that is how this market buys; our qualification step exists because a regulator asks who approved it. That variation is load-bearing and standardizing it will cost more than it saves.

The second kind names the company’s own past: this is how the person who set it up preferred it; the previous tool could not do it the other way; we inherited it with an acquisition. That variation is an accident, and it is the entire territory a standardization program should be operating in. It is also, notably, where most of the variation in a portfolio actually comes from.

The third kind names no reason at all: nobody knows, and it is the most common. Treat it as an accident provisionally, then test it rather than assume: propose the standard and read the objections. An objection that names a customer, a contract or a regulator has surfaced a fact that the first conversation missed. An objection that describes how it would feel has confirmed the classification.

Standardize the interface before the implementation

Most of the damage comes from applying standardization at the wrong layer rather than from applying it at all. Four levels, in the order they should be attempted:

• Definitions. What a qualified opportunity is, what counts as churn, how headcount is stated, when revenue is recognized. Costs a company nothing locally and is the only level close to unconditionally correct.
• Outputs. The same small set of numbers, on the same calendar, in the same shape. Still no claim about how the work is done — only about what arrives and when.
• Systems. One tool for a job, where the migration cost is genuinely less than the reporting cost it removes. Test that arithmetic rather than assuming it.
• Method. How the work is actually performed. Standardize this last, narrowly, and only where evidence from one company is worth another company’s disruption.

Programs invert this more often than not. Everyone moves onto one platform in quarter one; in quarter three somebody discovers that two companies put different things in the same field, so the consolidated reporting the migration was for still does not work. The definitions were the point and the platform was the visible part.

How it goes in

Pilot with the company most likely to succeed rather than the one that needs it most. The purpose of the first implementation is evidence, and evidence from a company that was already well run persuades the rest of the portfolio more than a partial turnaround at the difficult one. The difficult one goes third, with a working version and somebody who has done it before.

Then publish what happened, including the parts that did not work. Adoption by demonstration is slower than a mandate for the first company and faster by the fourth, because each one is deciding rather than complying. The mandate stays available and should be spent rarely: a fund that mandates a growth process has taken responsibility for the outcome of it.

Give the standard an owner at the center and a revision path, or it becomes a document describing a process nobody follows — the worst outcome available, since it carries the compliance cost and none of the comparability. The exception process is part of the standard rather than a failure of it: a named approver, a stated reason, and a review date, so exceptions stay visible and finite.

Measure three things. Adoption, which is easy. The metric the standard was supposed to move, which requires having named it beforehand. And the cost of compliance, in hours, at the company rather than at the fund — the number nobody collects and the one that decides whether the program survives a change of operating partner.

If nobody can name the number the standard was meant to move, it was a preference. That is not always fatal — consistency has some value on its own — but it should be argued for as a preference rather than presented as an operating improvement, because the companies can tell the difference and their willingness next time depends on it.