All Posts in Process Management and Improvement

|In: Architecture|Last Updated:

While waiting in some line or other I noticed the young lady in front of me was reading a book about Watergate. She told me she was reading it for her history class. Her history is my current events. Ouch!

“Current” means different things to different people, which brings us to last week’s topic, the value of keeping your technology current.

Take IMS as an example. For those of you who also think Watergate is a historical subject (no, not “an” historical subject) IMS is an IBM product — a hierarchical DBMS, an technology that became obsolete with the advent of codacyl DBMSs, which in their turn became obsolete when relational DBMSs became available.

What’s good about IMS is that IBM still supports it. What’s better is that if you’re a DBA who knows IMS there are probably more jobs to be had than there is competition for them.

Here’s what’s bad: It’s hopelessly obsolete. Worse is that the only IT professionals willing to take those open jobs are either well on their way to geeze-land (like me) or don’t have enough on the ball to go after positions that will let them work on hot technologies like NoSQL, let alone mainstream SQL-oriented positions.

Worst news of all: If you’re the CIO or CTO of an organization that relies on IMS, you will never be able to make a financial case for converting to something modern.

Because there is no financial case for it. By now, your company’s investment in IMS is somewhere between formidable and incalculable. The cost of recreating the same functionality in a modern DBMS would be enormous.

After which the company would run exactly as it did before the conversion, only with that much less money available for other purposes.

The dots you’ll have to connect to associate the conversion with more revenue or less operating cost … the definition of “financial case” in most companies … are numerous enough that few business executives would sit still through your explanation, let alone buy it.

The problem is that most companies big enough and old enough to rely on IMS consider “business case” and “financial case” to be synonyms.

Most companies big and old enough to rely on IMS focus on financial engineering, not competitive advantage. If the CEO and board’s goal isn’t to sell more products and services to more customers, they won’t understand the business case for jettisoning obsolete technology.

Many IT professionals don’t either, because “obsolete” is an imprecise term at best.

In business terms, obsolescence is risk. That there will come a time when you’ll find yourself luring codgers out of retirement, or else have to settle for third-rate employees who can’t find any other employment … that’s a risk. A big risk.

There are others. Plenty of businesses still haven’t migrated from Windows XP, because it does everything the business needs, so what’s the problem? Again it’s risk:

  • Their anti-malware vendor will, at some point, drop support for XP. They’ll still need malware protection when that happens, and self-paced conversions are better than fire drills.
  • Computers wear out. Will Windows XP run on new hardware? At some point, no, and mixed environments are more expensive than homogeneous ones.
  • Printers wear out too. Will new ones have XP drivers? Many don’t right now.

But perhaps the biggest risk is the Stockholm Syndrome — the tendency of hostages to end up sympathizing with their captors. In the context of IT, it takes the form of accepting as normal the limitations obsolete technology imposes on business processes and practices.

You’re now a retailer, relying on batch mainframe COBOL systems. They are, everyone agrees, superior because they’re awesomely reliable and eat transactions just as fast as you can pump them in.

Nobody notices that while transactions are masticated and ingested in real time, they aren’t digested until 1 am, when the batch processes that post them are launched.

Because of the Stockholm Syndrome, it seems perfectly normal your company can’t ship orders until the next day. The delay is minor. Customers won’t care.

And when it turns out you have less in stock than you have orders, well that’s why IT developed a subsystem to inform soon-to-be-former customers their orders are now backorders, but don’t worry — backorders take precedence over new orders for the same item, whenever the shipment happens to show up.

Even if someone does realize batch COBOL’s limitations will kill the company, it doesn’t matter. There’s no money to fund a conversion to a more modern system. The board spent it all buying back stock to improve earnings per share. That’s much more important than winning and retaining customers.

Isn’t it?

Comments

|In: Leadership|Last Updated:

I’m getting close to giving up on metrics altogether.

It isn’t that metrics aren’t important. It’s that in so many cases they seem to do so much more harm than good.

Consider, for example, the lowly customer service call center—the place a company’s customers … its real paying customers … dial when something isn’t as they’d like it.

Lowly? Yes, lowly, because like it or not, few companies have much respect for their customer service call centers.

Want proof? Ask yourself this: What is a company’s best source of information about what characteristics of its products and services aren’t satisfying customers as they should?

The answer would be obvious even had I not just telegraphed the punch: The customer service call center.

Second question: How many companies analyze the calls to their customer service call centers to find out what customers are calling to complain about?

Answer: I have no idea, other than knowing that whenever I call one and ask if the person I’m speaking to has any feedback channel for passing along suggestions from customers. The unvarying answer is no.

Third question: What do companies measure about their call centers? Queue time. Abandon rates. Average call time. A few … and these count as advanced compared to most of what you’ll find out there … measure the first-contact problem resolution percentage and time to problem resolution.

Ever hear of a call center that’s measured on the number of product improvement suggestions it generates? How about one that’s measured on how many customer-eliminating business practices it identifies?

Me neither.

Look, companies pay good money to get their Net Promoter Score—a strategic metric that, instead of trying to measure the elusive “customer satisfaction,” measures how likely it is that a customer will recommend them to friends, colleagues, and other associates.

They’re paying to get the likelihood without gaining any insight into why that likelihood is as good or as bad as it is, when they could, instead, gain insight into why that likelihood isn’t better for a cost of … let’s see, divide by pi and multiply by the square root of a potato … for whatever it costs to ask call center employees what customers have told them.

To summarize:

MetricsTable
Peter Drucker famously said, if you can’t measure you can’t manage. Call it Drucker’s Metrics Dictum — DMD if you’re acronymically minded. At the risk of being criticized for criticizing the patron saint of management consulting (and please understand, I have immense respect for Dr. Drucker’s overall opus), the above table shows just how wrong DMD is. NPS is measurable. That’s its point. But it isn’t actionable.

And if a piece of information isn’t actionable, it doesn’t help you manage one bit.

Let’s start over, with a better understanding of what metrics are for. To get there, start with this: There are two kinds of metrics. One measures progress toward or achievement of goals, he other measures the current state and trend of controls, a control being a factor that contributes to making progress toward or achieving a goal.

Second: Goals and controls are fractal, which is to say, when you zoom in, every control becomes a goal with its own controls, and so on ad infinitum, ad nauseum, and ad only enough layers that you’ve reached the point of the obvious.

If, that is, you can map out a complete set of controls for a particular goal, and you can define useful and tallyable metrics for every control, then you really can measure things in a way that helps you manage them.

And: Metrics serve two purposes. One is to help management understand how it’s doing. The second is to drive employee behavior in the right direction, which explains Lewis’s Law of Metrics: You get what you measure—that’s the risk you take.

Set a goal and employees will help you achieve it. Establish a metric and employees will make that their goal — they’ll move the metric in the right direction, whether or not the steps they take to move it are actually good for the business.

Why would they do anything else?

Metrics tell managers how they’re doing and they tell employees what management wants. If metrics were completely out of the question, do you think you could find other ways to achieve these two goals?

Comments