All Posts in Process Management and Improvement

|In: Process Management and Improvement|Last Updated:

Everyone has a story.

I was re-reading Eliyahu Goldratt’s Theory of Constraints. It’s the principles he first elucidated in his groundbreaking “business novel,” The Goal, rewritten as prescriptive methodology.

Goldratt’s Theory of Constraints (ToC) is, as process improvement methodologies go, quite brilliant and sadly underappreciated. And yet, early in the book appears this disturbing statement about the value of ToC success stories:

Who would be helped by such testimonials? The people that have already been persuaded by The Goal do not need them, they have their own real-life proof. Those who were not moved by the common sense logic in The Goal will certainly find it easy to demonstrate that their situations are different and that these ideas will not work in their environment.

I say disturbing because Goldratt appears to be asserting that fiction not only is more persuasive than fact, but that it should be.

It probably is — when I talk to clients about DevOps, for example, more cite The Phoenix Project than any company’s real-world experience.

By this logic, if, in a debate about military strategy and tactics, my opponent were to support a point with Grant’s victory at Vicksburg as described in his personal memoirs, my best counterargument should come from the battle of Helm’s Deep as described in The Lord of the Rings.

Fiction can be an excellent way to illustrate a point. But offered as evidence it’s a cheat. Fictions’ authors are puppeteers, able to make their characters say and do whatever is necessary to “prove” whatever point they’re trying to make.

Not that business case studies are much better. They aren’t, because those presenting them (1) start with the conclusion they’re trying to prove rather than starting with evidence and using it to guide their opinions; and then (2) sort through the available stories to find those that support the predetermined outcome, ignoring all the others that don’t.

Then there are the anecdotes we consultants tell. We all have them.

I recall (but couldn’t track down) a bit of braggadocio from a Lean consultant who described his experience on a construction site. After a brief period of observation he was able to use Lean principles to save the construction firm oodles of time and sacks of cash by repositioning the concrete mixers.

In my own consulting we once saved a client the time, expense, and aggravation of a multimillion dollar process reengineering project through the simple expedient of having IT educate a business department in the use of an already-installed feature of the software package they used.

Twenty minutes later the problem the reengineering project was supposed to fix was taken care of.

We all have these stories. They’re fun to tell. We hope they convince potential clients that we’re adept at finding “low hanging fruit” — quick and easy improvements that can justify and fund the hard stuff.

Quick and easy improvements that, astonishingly enough, never require significant investments in new or changed information technology. In fact I’ve yet to hear an apostle of any of the major process improvement methodologies explain the importance of cleaning up and modernizing the organization’s portfolio of business applications. I have often heard them explain how they’ll work their magic without requiring major investments in information technology.

There is, for example, this little ditty, found in Six Sigma Daily. It does a nice job of presenting some Lean Six Sigma principles Jeff Bezos relies on for making Amazon hum.

Don’t get me wrong. The principles and examples extolled in the article, while not the sole province of Lean Six Sigma, are good principles and examples.

It’s just that, reading the article, you’d be forgiven for concluding Amazon runs its warehouses with stacks of 3×5 index cards and not highly sophisticated information systems.

Why are these tales of easy, IT-free success so popular? That, at least, is easy to explain: it’s confirmation bias in action. That is, most people, most of the time, including you and including me, tend to accept without much scrutiny anything that tells us what we want to be true, while we nitpick to death anything that tells us anything else.

Fiction, case studies, and anecdotes of the “all you gotta do is …” variety tell business decision makers what they want to hear the most: making revenue grow, costs shrink, and risks disappear is going to be cheap and easy.

Against this “logic” there’s this simple but unattractive fact: When you’ve picked all the low-hanging fruit there’s a tree-full of peaches left that’s going to need a lot more effort to harvest.

Someday I’ll have to write a business novel about picking them.

Comments

|In: Office Politics|Last Updated:

This week’s profound advice: Be plausible.

I was “talking” to Quicken’s chat support. I’d been trying to add a new investment account — something I’d done several times without trouble over the twenty plus years I’ve used Quicken.

The quick and accurate diagnosis: I’ve been using Quicken Starter Edition. That feature now requires Premier. The last update I applied removed it from Standard.

If Quicken sold cars instead of software and I bought a Quicken Standard, three years later, during a scheduled oil change, its mechanics would remove the turbocharger because the Standard no longer comes with one.

Look, kids, when you sell a product, the buyer decides if its features justify the price. Having paid that price, removing some of the features fails the plausibility test.

Speaking of plausibility, I recently had to renew my Minnesota driver’s license. Minnesota was one of the last holdouts for the TSA-mandated REAL ID, so sadly, REAL ID compliant driver’s licenses won’t be available in Minnesota until October of this year.

But that’s okay, because in the meantime I can get an Enhanced driver’s license, which isn’t a REAL ID license but is REAL ID compliant. It gets better: An Enhanced license but not a REAL ID license lets me drive in Canada, Mexico, and Bermuda.

Terrific — I want one! Especially for Bermuda in January! Only … I’m sorry, Mr. Lewis, but here at the Hennepin County Government Center building in downtown Minneapolis, the Minnesota DMV isn’t equipped to provide these. To get an enhanced license you’ll have to go to the Minnesota DMV office conveniently located in the nearby suburb of Plymouth.

I’m sure there’s a logical reason for this. I’m sure some committee somewhere looked at the available budget, drew coverage map alternatives, debated, erased, and re-drew until the budget was exhausted and so were the committee members.

And yet, right there at the surface where people walk up to the service desk, this is utterly implausible. It simply makes no sense that the location serving the largest number of people who need driver’s licenses doesn’t provide the most complete set of services. No amount of explaining will make it appear remotely plausible, no matter how much actual thought and logic went into these decisions.

How about you?

Take a common approach to IT governance: For IT to implement a solution, the business areas that want it have to submit a request that includes the business justification. An IT steering committee of some kind evaluates the requests, sorts them into priority order, and decides who gets some or all of what they asked for and who doesn’t.

If you’re on the inside of designing this sort of governance it probably looks like it makes sense.

But imagine you’re on the other side of the metaphorical IT services order counter. You’re a member of a five-person workgroup, you’ve found inexpensive or open source software that will make the five of you, say, 20% more effective at what you do. You add up the time needed to learn the proposal process, fill out the required forms, and defend it at the next steering committee meeting.

It’s more time than you or IT would need to just do the job.

Only you can’t because IT locks down PCs so you can’t, and IT can’t because your project is too small for the steering committee to worry about.

The loud and clear message from IT: We won’t do it for you and we won’t let you do it yourself, either.

So you kludge together something in Excel instead.

It’s utterly implausible.

It’s also easy to fix, which makes the reality even more implausible.

The fix comes in three parts. Part #1: For existing applications, go Agile. Whether they’re epics, features, or enhancement-scale requests, they all go into the backlog as user stories. The product owner sorts them. Problem solved.

Part #2: For small new needs, the IT Steering Committee allocates pools of IT developer hours. Requesters “spend” out of their pool. See how easy this is?

Part #3: Information Security sets up an application screening group. When someone in the business identifies a potentially useful application, the screening group evaluates whether, where, and how it might pose a risk. The default is a green light, which is given unless InfoSec identifies and explains the risk, so the requesting organization knows what to look for when researching alternatives. Nuthin’ to it.

And that’s the point. Avoiding implausibility isn’t hard. As the poet said, “O wad some Power the giftie gie us, to see oursels as ithers see us!”

That’s all it takes.

Comments