A documented process is not the same thing as a controlled process. The real process is what people repeatedly do when the work arrives.

There is a simple question I have learned to ask when a manager tells me a process is documented:

“If I asked three people to explain how they do the work, would I hear the same answer?”

That question can make the room a little uncomfortable.

The procedure may be sitting in SharePoint. It may have an owner, a version number, and a reassuring “approved” stamp. But if one employee follows it, another relies on memory, and a third uses a workaround learned from the person who trained them, the organization does not have one process.

It has three.

The real process is not what the document says. It is what people repeatedly do.

Imagine an Application Packaging & Deployment team preparing software for thousands of employee devices.

The intake form says the requester must provide licensing requirements, security dependencies, target user groups, and testing scenarios. One packager validates every field before beginning. Another trusts that Service Management already checked it. A third starts building immediately and follows up only when testing fails.

All three are capable. All three believe they are being practical.

Then an urgent application arrives with an undocumented certificate dependency. The package builds successfully. Basic testing passes. The deployment begins—and users cannot authenticate.

Now the visible failure sits at deployment, but the defect entered several handoffs earlier. Deskside teams begin troubleshooting healthy devices. The Service Desk absorbs a spike in calls. Packaging rebuilds the application. Security joins the incident. Business users lose productive time.

Management may describe this as human error. That is convenient, but incomplete.

The system allowed the same intake to mean different things to different people.

A technically perfect package can still fail operationally when the handoffs around it depend on assumptions.

This is why process discipline is not bureaucracy. Done badly, bureaucracy produces long documents nobody uses. Done well, process discipline makes predictable work repeatable while preserving judgment for genuine exceptions.

The challenge is that managers often audit the documentation instead of the work.

I would start by observing what actually happens. Ask people to walk through the task without showing them the procedure first. Listen for different triggers, skipped checks, invisible approvals, personal spreadsheets, and phrases such as, “Normally we do this, but…”

Those differences are not automatically evidence of poor performance. They are evidence about the operating model.

Some variation exists because the procedure is unclear. Some because it is difficult to find. Some because the tools do not support it. And some because experienced employees have quietly improved a process that management never updated.

The goal is not blind compliance. The goal is to understand the gap between the intended process and operating reality—then decide which one needs to change.

When three people describe three versions of the same recurring work, the manager has found a system problem worth understanding.

Discussion question: Which recurring process in your operation would produce three different answers if you asked three employees how it really works?

If this feels familiar—or you want to explore where hidden process variation may be affecting delivery—reach out. I’m always happy to have the conversation.