Eighteen months after a good launch, nobody has announced that anything is wrong. There is no incident, no escalation, no post-mortem. But if you went looking, here is what you would find.

A spreadsheet has appeared beside the system. Somebody built it to handle a case the system does not handle well, and now four people use it.

Exceptions have moved back into chat. They went through the system for the first six months. Now the unusual ones get handled by messaging the person who knows, which is faster, which is why it happens.

Two people are keeping shadow versions of the same data, because they each need a view the system does not give them and neither of them asked.

And there is a change request that has been sitting for a quarter. Not rejected. Just sitting.

Every one of those is a reasonable local decision, made by somebody competent who was trying to get their work done that afternoon. Not one of them is a complaint, which is exactly why none of them reaches you.

That is the trap, and it is the reason this goes unnoticed for so long. The people closest to the problem have already solved it. They are not frustrated. They have adapted, and adaptation builds confidence, so there is nothing to report.

Failure is loud. Being worked around is not.

A system with no owner does not fail. It gets worked around.

The distinction matters because it changes what you should be watching for. Failure has a date, an incident report, and somebody whose job it is to explain it. Failure gets fixed, because it is impossible to ignore.

Being worked around is none of those things. It is quiet, it is gradual, and it is distributed across twenty people who each made one sensible choice, none of whom did anything wrong, and none of whom has the vantage point to see the pattern.

There is no moment when the organization decides to stop using the system. There is only a slow accumulation of small, defensible exits.

Which means the normal management instruments do not catch it. Nothing shows up red. The system is still up. Adoption numbers look fine, because people are still logging in. They are just doing the hard parts somewhere else.

You will not get a report about this. You will notice the spreadsheet.

The sequence is predictable, and there is one cheap moment

Stage one. Launch. It works, everyone is pleased, and there is usually a lunch.

Stage two. The first real exception. Something comes up the system does not handle cleanly, and somebody handles it outside the system. Once. Reasonably, with good judgment, under time pressure. Stage two is not a problem. Stage two is going to happen no matter how well you designed it, because no process survives contact with the actual world unchanged.

Stage three. The workaround normalizes. The second time that case comes up, the same person handles it the same way, because that is how it was handled last time. Within a month or two it is simply how that case is done. Nobody decided this. Nobody would defend it if you asked. It just settled.

Stage four. The system now describes a process nobody actually runs, and the reporting quietly stops matching reality. You usually discover that a quarter later, in a meeting, when two people pull the same number and get different answers.

Stage three is the one you can still reverse cheaply. At stage three it is a conversation and a small change. At stage four it is a rebuild.

Stage three is also the one nobody escalates, because at stage three nothing is wrong yet. It is just how things are done now. Intervening costs ten minutes: somebody with authority looks at the workaround and rules. Either the exception is legitimate, and it gets built into the process properly, or it is not, and you stop doing it. The entire cost of stage four is avoiding that ten minutes because nobody was sure it was theirs.

Process ownership, defined

Accountability for a process working across functions, held by a named person, after the project ends.

Across functions is what makes it hard and what makes it necessary. Anybody can own a process that lives inside their own team. The processes that degrade are the ones crossing three departments, because inside each department everything looks fine.

By a named person. Not a role, not a committee, not a department. A person whose name you could say out loud right now.

After the project ends is the part that gets skipped, because project governance is genuinely good at assigning accountability during a project and has no mechanism at all for assigning it afterward. The steering committee dissolves. The RACI describes something that no longer exists.

Here is the test, and it takes ten seconds. If the vendor onboarding cycle slips from four days to eleven over two quarters, whose problem is that? If the answer is a name, you have a process owner. If the answer is that it would depend on why, or that several people would look into it, then the process does not have an owner. It has observers.

And the owner needs enough authority to refuse. Not authority over the functions involved. Authority to say a proposed exception is not going into the process, and to have that stick. If the answer is eventually yes every time because the person asking outranks the person deciding, you do not have an owner. You have a queue with a face on it.

What an owner actually holds

  • The measure. Whether the outcome is still being met today, not whether the system is up.
  • The process, including which variations are allowed.
  • The change queue. What gets built next, and when, with a real answer.
  • The exceptions. Which are legitimate, which are drift, and the authority to refuse one. An owner who cannot say no is not an owner, they are an inbox.
  • The knowledge. Written down, not carried.

Roughly two hours a month once it is running. Twenty minutes on the measure, an hour clearing the change queue, half an hour ruling on anything new. The first three months are heavier, because you are catching up on decisions that accumulated during the build.

That number is worth saying out loud when you ask somebody, because the reason people resist this is that an unbounded responsibility sounds like a second job. A bounded one sounds like a Wednesday.

Name the owner before go-live

Answer this before launch and it takes an afternoon. Nobody has strong feelings yet, and you are allocating a responsibility that does not exist.

Answer it after launch and you are negotiating. People have built habits. Somebody is already doing part of the job informally and does not want it formalized. Somebody else assumed it was theirs. The budget that would have paid for it closed at launch.

Same question. Completely different conversation.

The Systems Implementation Readiness Assessment walks the operating decisions behind your next implementation. Ownership and decision rights is one of the four dimensions. Ten minutes: ruddconsulting.io/readiness