Change management from five desks: one small change, five accounts

One change, described five times. The change is invented and small: incoming requests that used to arrive by email at one team are rerouted through a form into a shared queue owned by another team.

A change plan is normally written from one position and read from four others. The differences below are not misunderstandings. Each account is accurate from where it stands.

What to take away

The designer's account

The current arrangement has no record. Requests arrive in one person's inbox, get handled or not, and nobody can say how many arrived or how long they took. Two have been lost this year that we know about, which means an unknown number have been lost that we do not.

The form fixes the record problem at the point of entry. The shared queue fixes the single-point-of-failure problem. Both are straightforwardly better and the objections are about familiarity.

What this account is about: the system's properties. It is correct about all of them.

What it does not contain: any estimate of how long a requester takes to fill in the form, or what happens to a request that does not fit the form's fields.

The supervisor's account

My team is at capacity, and this adds a queue they now own. Nobody has said whose hours pay for it.

The plan estimates a small amount of extra work per request. That may be true. Small amounts of extra work per request are how a team goes from busy to underwater without anyone seeing the moment it happens.

The other thing is the exceptions. About one request in six is not really a request, it is somebody asking whether they should make a request. Those get handled in two lines of email today. In a form-and-queue arrangement, they become tickets that get worked and closed, and they will consume more than the ones that matter.

What this account is about: capacity and the shape of the work. It is the account most often missing from a plan.

The operator's account

The form will be filled in wrong. Not out of malice. The people sending these requests do it three times a year and they do not know our vocabulary, so they will pick the wrong category and write the detail in the wrong box.

Today when that happens, I read the email and understand what they meant. In a queue, a miscategorized ticket goes to the wrong place first and comes back a day later. So the change adds a day to exactly the requests that were already the confusing ones.

I am not against the form. I want a free text box at the top that says what do you actually need, and I want permission to reroute without a handoff.

What this account is about: the failure path. It is specific, actionable, and it is the single highest-value sentence in this article, because it is the change to the plan that costs nothing and prevents the most damage.

The neighboring team's account

We are the ones who send about half of these requests. Nobody asked us.

We send them mid-task, in about thirty seconds, in a sentence. A form takes several minutes and requires decisions we usually work out in conversation.

The cost of the change lands on us and the benefit lands on them, which is fine, but say it out loud instead of calling it an improvement for everyone.

There is also a prediction here. Some of us will stop using the channel and go back to messaging people directly, and that will not show up in the new metrics because those only count what came through the form. The record will improve while the reality does not.

What this account is about: where the cost falls, and how the measurement will hide it.

The customer's account

I do not know any of this happened, which is the point. What I notice is that something I asked for took nine days this month and took four days last month, and nobody told me it would be different for a while.

The only thing I needed was to be told. Not consulted, not involved. Told, once, that there would be a slower period and roughly how long.

What this account is about: the difference between an inconvenience and a broken promise. They are the same delay with different notice.

What to do with the five accounts

Read them as a set and three changes to the plan become obvious, none of which were visible from the designer's position.

Add the free text field and the permission to reroute, because the operator identified the failure path and named the fix in one sentence.

Count the requests that never enter the form by asking the neighboring team once a month whether they went around it.

Otherwise the new measurement will report success exactly where the change is failing. That happens whenever a measure can only see the channel it was built for. The general form of that problem, including cases invisible to your data, is in operating processes metrics.

Tell the customers, once, with a duration. This is the cheapest item on the list and it is the one most often skipped, because the people who would send it are busy with the parts that are hard.

How to collect these accounts yourself

You do not need five interviews and a report. You need to ask four people one question each: what will be different for you on the first day, and what will you do when it does not work.

Two rules make it produce something. Ask people who will do the work rather than people who represent them, since a representative gives you a position and an operator gives you a failure path.

And ask before the plan is fixed, because after that the answers you get are objections rather than information, and they will be treated as such. The sequencing and the announcement side of this is treated in change management, and the twelve conditions worth checking before committing are in change management checklist.

The habit underneath is going and looking at the operated process rather than the described one, which changes what a plan is designed against, and that is set out in change management framework.

Human factors guidance published by the UK Health and Safety Executive treats organizational change as a risk to be managed rather than a communications exercise. The same source's material on managing human failure is a useful counter to the assumption that a miscategorized form is a training problem.

Common questions

Is the operator's objection not just resistance?

It contains a specific prediction: miscategorized requests will take a day longer. That is testable within two weeks of going live. Resistance does not usually come with a falsifiable claim attached, and when it does, the claim is worth more than the label.

Whose account should win when they conflict?

None of them, because they are not competing. The designer is describing the system, the supervisor capacity, the operator the failure path, the neighbor the cost distribution, and the customer the notice. A plan needs all five, and they only look like disagreements when compressed into a single yes or no.

We have made the change already and it is not going well. Is this still useful?

Yes, and it is faster after the fact, because people can describe what actually happened rather than predicting. Ask the same question in the past tense: what was different on the first day, and what did you do when it did not work.

What if the neighboring team simply will not use the new channel?

Then find out what the channel costs them, because that is usually the whole answer. A route that takes thirty seconds is competing with one that takes five minutes, and no amount of communication changes that arithmetic.