Operating processes examples: what the cases show

Process problems present as symptoms, and the symptom almost always suggests the wrong cause. That is the interesting part, and it is why the same fixes get applied repeatedly to problems they do not touch.

What follows is organized by what you actually observe. Each entry gives the diagnosis people reach for, the one that is usually correct, and something you can do about it within a week. None of these describe a real organization; they are the ordinary shapes, written so you can match on the symptom rather than on a story.

What to take away

• The obvious cause of a process symptom is usually the visible one, and visibility is not evidence. Check the boring explanation first.
• Almost every complaint about speed turns out to be about waiting rather than about working. Measure the gaps, not the steps.
• A fix that depends on someone remembering will decay. If the old path is still there and still cheaper, it wins.

The same question keeps arriving

Usually blamed on: people not reading the documentation.

Usually true: the answer exists somewhere the question does not. Somebody hits the problem at a particular moment, and the documentation is in a system they are not in, phrased around a topic rather than around the moment. Occasionally the document answers a different question that looks similar, which is worse, because people stop asking and start guessing.

This week: collect the exact wording of the last five times it was asked. Not your summary: the actual sentences. The wording tells you where the person was and what they were trying to do, and it usually points at a spot in the flow where the answer could sit. Then put it there, in one line, and see whether the question stops.

If it does not stop, the question is a decision in disguise, and people are checking rather than looking up. That is a delegation boundary problem, which belongs with team management rather than with documentation.

Everyone is busy and nothing finishes

Usually blamed on: not enough people.

Usually true: too many things started. Work in progress is invisible while work not started is visible, so the natural response to pressure is to start more, which lengthens every queue including the ones that were nearly done.

This week: count two numbers for one team. How many pieces of work are open right now, and how many were finished in the last week. If the first is several times the second, adding people will not help and may not even be affordable in coordination cost. Stop starting things, finish what is closest to done, and watch what happens to the finishing rate.

This one is usually met with an objection that everything is urgent. Sometimes true, and in that case the queue is being fed faster than it can drain, which is a decision about intake rather than about effort. The productivity systems view of the same problem covers the personal version.

The improvement worked for a month

Usually blamed on: people reverting out of habit or resistance.

Usually true: the improvement depended on somebody's attention, and attention moved. If the new way is even slightly more effort than the old way, and the old way still works, the old way returns as soon as the person who cared is busy.

This week: find out whether the previous path is still available. Not discouraged: available. If a form can still be sent by email when the point was to route it through a system, email wins, because it is one step shorter for the sender and the cost lands on somebody else.

The general rule is that a change survives when it is the easiest route, and needs continuous enforcement when it is not. Enforcement is a running cost most teams cannot pay, so prefer the version that removes the alternative over the version that forbids it. Designing the work so the wrong route is not available, rather than discouraged, is the idea behind poka-yoke.

Two competent people do it differently

Usually blamed on: a lack of standardization.

Usually true: some of the differences matter and most do not, and enforcing uniformity across all of them costs more than the variation. The important question is whether the difference is visible downstream. If whoever receives the output cannot tell which of the two did it, the variation is free.

This week: take one recent case from each person and follow the output to whoever uses it next. Ask them, without saying why, whether these two look different to them and whether it changes anything. The answer sorts the differences into the ones worth a standard and the ones worth leaving alone.

Where a difference does matter, resist writing a rule immediately. Find out which one is better first, because there is a decent chance the standard you would have written is the worse of the two, and the person doing it the other way has a reason nobody asked for.

The work is fine and always late

Usually blamed on: the people doing the step.

Usually true: most of the elapsed time is spent waiting rather than working, and the waiting is invisible to everyone except the person at the front of the queue. Speeding up the step improves a small share of the total and is the most expensive place to intervene.

This week: take five recent completed items and, for each, write down when it arrived and when it was finished. Then ask the person who did it roughly how long the actual work took. The gap between the two totals is the size of your real problem, and it is usually uncomfortable.

Once you have that gap, the useful question is what it was waiting for. Approval, an answer, a system, another team, or simply its turn. Each has a different fix, and only the last one is about capacity. Be careful about when you start the clock, since a queue that forms before the work is formally received will not appear in anything you currently record.

A step nobody can justify, and everyone defends

Usually blamed on: bureaucracy.

Usually true: the step catches something, and the person who knew what has left. Controls outlive their explanation more often than they outlive their purpose. The defenders are not being irrational; they have seen the step matter once and cannot articulate why.

This week: instead of debating it, look at the last several times the step produced a result. If it never fires, it is genuinely dead and can go. If it fires occasionally, find out what it caught and whether anything else would have caught it. Then write the reason down next to the step, which is the thing that should have happened originally.

Removing a control that turns out to be load-bearing is the most expensive mistake in this whole area, and the damage shows up on a delay, in a different part of the operation, where nobody connects it. Dropping one safeguard because nothing happened, and then the next, is the drift known as normalization of deviance. The quality management treatment of controls covers what is worth keeping.

A modest rise in volume broke everything

Usually blamed on: the volume.

Usually true: one step was absorbing variation using slack that has now gone, and everything downstream of it is starved while everything upstream piles up. Processes rarely degrade smoothly; they run fine and then stop running.

This week: find where the queue is. Not where the complaints are, which is usually downstream of the problem where people are idle and visible. The step with work stacked in front of it is the constraint, and effort spent anywhere else changes nothing.

Then check whether that step is slow or merely interrupted. A step that could run at twice the rate if the person doing it were not also handling questions is a scheduling problem, not a capacity one, and it is much cheaper to fix.

How to use these

Match on the symptom, then check the boring explanation before the interesting one. Most of the diagnoses above are dull, which is why they get skipped in favor of explanations about culture or motivation.

Then change one thing and write down what would make you put it back, which is the discipline the operating processes pillar returns to repeatedly. Situations involving people rather than flow are handled differently, and there are worked ones in management foundations examples.

Common questions

What if two of these are happening at once?

They usually are. Start with the queue, because a system with work piled in front of one step will produce several of the other symptoms as side effects, and fixing those first gets undone.

How much investigation is proportionate?

Almost all of the checks above take under an hour and use cases you already have. If a diagnosis needs a data collection project before you can begin, either the problem is large enough to deserve it or you have chosen a measurement that is more precise than the decision requires.

People will not tell me the real story. What then?

Look at artifacts rather than asking. The private spreadsheet, the folder of past examples, the message thread where the real coordination happens. None of those are opinions, and all of them show where the designed process is not sufficient.