All Posts in Policies and Procedures

|In: Industry Commentary|Last Updated:

The value of information struck me while I was waiting for an elevator.

In the lobby of most buildings each elevator’s position is displayed above its door. Armed with that information you can intelligently decide whether to wait for it or climb the stairs instead.

But elevators give you no positional information on any other floor, forcing you to guess whether waiting or using the stairwell is the better vertical travel decision.

Fixing this is trivial engineering. As the Rutles once sang, all you need is cash.

Not so for the New York subway system, as explained in “Why New York Subway Lines Are Missing Countdown Clocks,” (James Somers, The Atlantic, November, 2015), a charming and fascinating article that explains the answer to the author’s question, “I honestly just wanted to know why the F train didn’t have clocks. I never expected it to be so complicated.” (And thanks to long-time correspondent Leo Heska for calling the article to my attention.)

Turns out, the answer isn’t what’s complicated. The New York subway system relies on early 20th century technology whose architects had a clear and well-chosen design goal: Subway trains must not collide.

To accomplish this goal they engineered an elegant combination of sensors, switches, and on-track displays, through which drivers know whether the next section of track is occupied by another train. If so they slow down. If they don’t, a mechanical relay tied to the train-detection sensor automatically applies the brakes.

The system, that is, was designed for Operations, and relies on a highly decentralized combination of human and automated decision-making. Nothing about it identifies individual trains and their positions, so there’s nothing in it to repurpose to tell passengers when the next train will arrive, let alone support any management analytics.

Solving this is a non-trivial problem.

If these were trucks, a GPS receiver, IoT chip, and Google Maps hack would make it pretty easy. But we’re talking about subway trains. They don’t have line of sight to any GPS satellites, and so, never mind.

Maybe there’s nothing to solve. Knowing each train’s position and velocity is, after all, a luxury, not a necessity. Well, okay, except for this small detail: The entire system is worn out, there’s no source of spare parts, and even the wiring’s insulation is about shot.

Oh, and the estimates for replacing this 1930’s vintage technology with something modern start at $20 billion.

Does any of this sound familiar — a legacy system that would be good enough except its architecture is obsolete, the platforms it runs on aren’t around anymore, and:

  • “Lift-and-shift” replacement provide no new features, and so no business-driven value to justify the expense?
  • Nobody can describe important new features that would justify anything more than a lift-and-shift replacement?
  • Investing in any kind of replacement system would drain needed capital away from other efforts that are also important for the organization’s ongoing survival and success?

Of course it does.

We’re dealing with a linked pair of seldom-discussed IT disciplines: Lifecycle management and migration management. Lifecycle management is about detecting incipient obsolescence and preventing it. Migration management is about becoming excellent at replacing obsolete or near-obsolete systems.

Together they make obsolescence avoidance an operational matter, from both a budgeting and an execution perspective.

Competence at migration management is what makes IT very good at moving from obsolete technology to something modern enough to last a while. Lifecycle management is what says it’s time to repeat the cycle.

Here’s how they might have helped New York’s Metropolitan Transit Authority:

By 1985 (to pick a year out of the air), the subway system relied on 50-year-old technology. Computerization was by then mainstream. The subway control system was clearly obsolete.

So imagine if the MTA had started migrating to a modern system in 1985 through a phased, route-by-route plan.

By now it would probably be time to start the next migration … but it would be from a far better base state, with no looming crises from a lack of spare parts and failing insulation driving a high-risk replacement project along.

Depreciation is the mechanism through which the general ledger depicts how a capital asset … the New York subway system’s control system being an example … loses value over time.

What’s strange is how many business executives consider it an accounting fiction. If they just believed their financial statements they’d bank the funds needed for capital asset replacement as standard operating procedure instead of lifecycle management starting with hat-in-hand supplication.

That’s right: The problem isn’t executives managing by the numbers.

It’s executives choosing to ignore them.

Comments

|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