All Posts in Process Management and Improvement

|In: Industry Commentary|Last Updated:

Six Stupid, the preferred Customer Elimination Management (CEM) process design tool, is alive and well.

The circumstances: Our electric dryer’s heating coil burnt out.

The offender: In accordance with KJR policy you’ll have to infer which failing retailer that sells and services appliances is the culprit.

The plan: The service tech who diagnosed the problem ordered a replacement heating coil, to be delivered directly to my home, scheduling its installation a full week later to allow plenty of time for delivery.

What happened instead: The day before the scheduled repair I went on-line with the tracking number, and learned the part had been delivered to an address in North Carolina. My wife, the dryer, and I all reside in Minnesota.

Three days, ten phone calls (at least four dropped while I was on hold), and various queries, expostulations, and expressions of incredulity and annoyance, led to my being “informed” (in quotes for reasons that will be apparent) that:

  • The part was delivered to the store. The service tech would, I was told, pick it up. Which store? No answer no matter how many times and ways I asked. Had the information been U.S. troop deployments in Afghanistan, it would have been safe too.
  • The part was damaged in transit, but a replacement had been ordered and would be delivered the next day.
  • (Next day): No replacement order had been placed. But don’t worry, an emergency replacement order has now been placed, and should arrive in time for the rescheduled repair. Tracking number? None has been assigned yet. But it is an emergency order. May I speak directly to the dispatcher to confirm? No. Did the service tech speak directly to the dispatcher? No. But don’t worry. It’s an emergency order.
  • (Next day): No, there’s still no tracking number. But don’t worry. It’s an emergency order. What’s that mean? It’s an emergency order. Does that mean it will be overnighted? Don’t worry — it’s an emergency order.
  • It’s not our fault. “You can’t blame us. UPS damaged the original shipment. How were we supposed to know?”

One ray of sunshine: The company has already charged us in full for the repair.

It’s the six-stupid methodology because this little morality play sits at the confluence of at least six different pieces of stupidity:

1. Blamestorming: The customer service guy blamed UPS. Yes, UPS damaged the part. But who decided to not stock the repair part, and to ship directly to my address (presumably to save money by having no handling at a distribution center)?

Any time your company puts its reputation in the hands of another company, make sure your systems communicate so you know there’s a problem before your customer knows there’s a problem.

And don’t blame-shift. Your customers don’t care why you failed. Your customers care that you failed, and that you’re going to fix the problem.

2. Dropped phone calls? That’s so last century. Correction — I managed telecom in the 1990s for a couple of years. Dropped calls are so 1950s.

3. Failure to log: At least half of the folks I spoke with started our conversation by entering the original tracking number into the UPS site and explained to me that the part had already been delivered, as if my previous calls had never happened.

4. Keeping the customer in the dark. Don’t transfer calls. Conference them and perform a verbal hand-off. And don’t use the hold button when consulting someone else internally. Conference those, too.

Among the advantages: Irritated customers like me get to express our irritation at the person who’s in a position to do something useful … or who isn’t but should be. That gives them an incentive to do something useful without prompting next time.

5. Failure to anticipate process failure. Process designers take note: Your beautiful process will work most of the time. Your exception processes will often work too.

But not always. When they fail too, don’t hobble customer service reps with handcuffs, leg irons, and blindfolds. When the defined process has failed, Free Customer Service! The rules of hub-and-spoke practice management should take over.

6. Ignoring what IT knows. IT has mostly figured this stuff out, starting with a simple principle: If there’s an outage of any kind, the help desk should know before the first user calls to complain. If not, there’s something terribly wrong beyond the outage itself.

And a second principle: The job isn’t done when the call is over. The job is done when the user’s problem has been taken care of.

If that’s important enough for employees, shouldn’t it guide interactions with real paying customers — like the ones who will buy the appliances for their new abode from just about anyone else?

Comments

|In: Organizational Effectiveness|Last Updated:

Promote the importance of using standard templates and styles in Word, and your personal brand will closely resemble that of a last-century librarian.

In the last century, librarians had the thankless but important task of making sure a book, once put on a bookshelf, could be found again when needed. But their image, like yours, is that of persnickety individuals who magnify trivia because they don’t have any important problems to work on.

Which is why, should you decide to try for standardization anyway, you’ll do well to remember the first rule of persuasion: Sell the problem (or opportunity), not the solution.

Last week’s KJR was an attempt to sell the problem, namely, that even when a business organizes work as a practice rather than as a process, failing to standardize on some of the basics can cause quite a lot of friction in the gears of getting things done, by creating completely unnecessary work whose prevention is almost entirely free.

And by the way, there are also situations where trying to institute standards would cost a great deal while being a hopeless cause. My daughter the programmer tells me GitHub illustrates the point well. While GitHub does publish style guides, the nature of the beast means there’s no way to enforce them, nor should there be. The result, though, is that making sense of what’s out there takes more work than if everyone followed the same coding standards.

Leaving this “And by the way” by the way, let’s get back to last week’s entirely prosaic example of a team that, in addition to coding, has to write documentation together. What’s the best way to get everyone on board? Put it differently, what does everyone have to understand about using Microsoft Word so standardizing on styles makes sense, rather than just being an act of resentful obedience?

MS Word styles are usually explained entirely wrong. They’re usually presented as ways to keep formatting consistent throughout a document.

They do achieve that, but it’s a happy byproduct, not the main event. Here’s what everyone on your team needs to understand about a style in Word: It identifies a specific part of a document.

Which in turn means that in order to use styles correctly, writers need to think about how they’re structuring what they’re writing. If you’ve ever been on the receiving end of someone who thinks their job is done if the information they’re supposed to convey is in there somewhere or other, you’ll understand the value of taking a writer through this thought process.

Documentation writers aren’t (or shouldn’t be) budding James Joyces. Their readers are more likely to be waiting for the project to be finished than for Godot, so there isn’t much justification for stream-of-consciousness expression in the documentation they write.

Authors of documentation should recognize when what they’re writing right now is the document title, subtitle, a section heading, body copy, one bullet in a bulleted list, a sidebar, a table column heading, table text, or something else.

They should, that is, understand the structural nature of what they’re writing as a document part. As author, they’re responsible for identifying this. Someone else can decide what a heading, sidebar, or list bullet should look like.

What’s strange about all this is that programming teams seem particularly resistant to adhering to the principles of document architecture in their writing, and this in spite of their being better-equipped to understand these principles than just about anyone else in the company. There’s no important difference, after all, between styles in MS Word and what developers do when coding cascading style sheets — the programs (yes, they’re programs — give them proper respect) that explain to a web browser how to render every HTML tag that’s included in a downloading stream of text.

One more point: As is so often the case, the all-too-frequent response to programmers who violate the rules … whether of documentation architecture or, more importantly, of software architecture and coding standards … is enforcement.

As a last, desperate alternative to receiving bad code and junky documentation, enforcement is better than nothing.

But if your goal is a high-performance software development practice (and this applies, by extension, to any business practice), enforcement isn’t what will get you there. Enforcement takes too much managerial effort to overcome too much team friction.

High performance comes, not from oversight, but from education and culture — making it how we do things around here.

Otherwise it won’t be how we do things around here.

Comments