Maintenance
Part of Operating processes: a clear guide with practical examples
Operating processes questions: what to know and why
Operating processes uncovered by interview: ask about the last case not the usual one, who to ask, what the answers mean, and what wastes the conversation.
Ask someone how a process works and you get the official version: tidy, sequential, and missing the parts they have stopped noticing. Nobody is hiding anything. Practiced work becomes invisible to the person doing it, and improvised work gets remembered as the standard method.
The way around this is not better rapport. It is asking about specific recent cases instead of about the general shape, and asking the right people in an order that lets each answer check the last.
What to take away
- Never ask how it usually works. Ask about the last three, by name and date, and let the pattern emerge from cases rather than from summary.
- The person receiving the output knows things the person producing it cannot know, and vice versa. Neither has the whole picture and both think they do.
- Write down the exact words people use for stages and states. Where two people use different words for the same thing, or the same word for different things, you have found a real defect.
Ask about the last one, not the usual one
This single substitution does most of the work.
"Walk me through the most recent one you handled" produces detail. The person is reconstructing an event rather than describing a category, so the awkward bits come along: the missing attachment, the message they had to send to chase something, the bit they did by hand because the system was slow that day. Those improvisations are usually adaptations to a system that does not fit the work, which is the framing used in the UK Health and Safety Executive's material on managing human failure.
Then do it twice more. Three real cases give you the variation, which is what you came for, and the third one usually contradicts something in the first, which is the most useful moment in the conversation. Three cases chosen because they were recent is a small and deliberately unrepresentative sample, and being clear about that is the point of thinking in terms of sampling.
If they reach for the general version, bring them back gently by asking for a specific detail: who sent it, what time it arrived, what the first thing they did was. Specifics restart the memory.
Who to ask, and what each can tell you
| Who | What they know | What they cannot see |
|---|---|---|
| The person doing the work | Exceptions, workarounds, what they check twice | Whether their output causes problems later |
| The person receiving the output | What arrives incomplete and how often | Why it arrives that way |
| The requester at the front | How long they waited before anything visible happened | Anything after they handed it over |
| Whoever covers during holidays | Which parts are undocumented, because they had to ask | The rest of it |
| The most recent joiner | Which parts are confusing or arbitrary | What used to be worse |
| Whoever owns the risk behind a control | Why a step exists | Whether the step still catches anything |
Two of these are usually skipped and are the most productive. The holiday cover has recently done the job without the tacit knowledge, so they can tell you exactly where the documentation runs out. The newest joiner has not yet normalized the oddities, and that window closes within a couple of months.
Questions that produce something usable
Grouped by what you are trying to find out. You will not need all of them.
To find the exceptions. Of the last ten, how many went exactly as intended? What happened to the others? What is the version that makes you sigh when you see it arrive? When did you last have to ask someone for permission to do something out of the ordinary?
To find the waiting. After you finish your part, what happens to it? When you are stuck, what are you usually stuck on? What is sitting on your desk right now, and what is each item waiting for?
To find the hidden tools. What do you have open while you do this that is not the official system? Is there anything you keep your own record of? What do you copy from where?
To find the mistrust. What do you check twice? What do you not believe when the system tells you? What do you do to protect yourself against something going wrong later?
To find the missing information. What do you have to ask other people for? What should have arrived with the work and did not? What do you have to guess?
To find the fragility. If you were away for two weeks unexpectedly, what would go wrong first? What can only you do? What would somebody covering for you get wrong?
Ask the last group of anyone senior in the work and take the answers seriously. They are the fastest inventory of single points of failure you can get, and they are usually accurate.
Reading the answers
Some answers mean something fairly reliable.
- "It depends" is an invitation, not an evasion. Ask what it depends on, and you have found the branch that is missing from every description of the process.
- "We usually just ..." marks a workaround that has become standard. The word "just" is doing a lot of hiding.
- "That never happens" followed a minute later by an example is normal. People classify rare events out of the process and then remember them.
- "You'd have to ask X" identifies a dependency. Count how often one name comes up across several conversations; that is your concentration risk, and it is a team management problem before it is a documentation one.
- A long pause before an answer about why a step exists usually means the reason is gone rather than the step being pointless. Find out what it catches before you touch it.
- Two people using the same word for different states is a defect you can fix this week, and it explains a surprising share of the rework at that handoff.
Questions that waste the interview
"How does the process work?" Produces the official version. Everything above exists to avoid this.
"What would improve it?" Sometimes useful, usually gets either the answer they have been proposing for two years or a request for more staff. Ask what would have made the last difficult case easier, which is answerable.
"Is the documentation accurate?" Nobody says no about a document they may have written. Ask when they last opened it, and watch whether they can find it.
"Why do you do it that way?" Sounds like a challenge whatever your tone. Ask what would happen if it were done the other way, which gets the same information without a defense attached.
Anything answerable with yes. You will get yes.
After the conversations
Three things to do while it is fresh.
Write down the words people used, exactly, particularly the names of stages and states. Your summary will smooth over the inconsistency that is worth finding.
Check one thing you were told against something that is not an opinion: a timestamp, a folder, a queue, a sample of recent items. Not because people are unreliable, but because the parts they are most confident about are the parts they have stopped examining.
Then take the picture back to the people who gave it to you, with the awkward bits included, before you take it anywhere else. Somebody who first sees their process described in a document circulated upward, with the workarounds listed, will correctly conclude that talking to you was a mistake. This is also the point at which anything you intend to change becomes a change management matter rather than an analytical one.
Scope the whole exercise before you start: where the boundary sits and which level you are working at, as set out in operating processes framework. And for what to do with what you find, the four fields that describe any process are in operating processes. Where the answers point at output being wrong rather than slow, the questions to ask are different and belong with quality management.
Common questions
How long should one of these conversations take?
Forty minutes with one person, covering three real cases, is usually enough and is about the limit of anyone's patience. Two shorter conversations a week apart beat one long one, because the first will have made them notice things.
Should I record it?
Notes are usually better. Recording changes what people say about workarounds and about colleagues, which is precisely the material you need. If you do record, ask, and accept a no without negotiating.
People keep telling me the problem is another team. What do I do with that?
Take it as a description of where the handoff hurts, not as a finding about the other team. Then ask the same questions there. The reliable result is that both sides are describing the same undefined word or missing field from opposite ends, and neither has heard the other's version.
