All Posts in Technology

|In: Industry Commentary|Last Updated:

Travel is supposed to broaden the mind. Regrettably, after more than 21 years of writing this column, my mental ruts seem to resist travel’s broadening impacts: Everything I see turns into guidance for running businesses, IT organizations, and all points in between.

And so, following a couple of weeks touring in Rome and exploring bits and pieces of Sicily …

> The Romans built the Colosseum in eight years, with no project management or CAD software to help them. It’s about 2,000 years old and still standing. That should worry us.

> The Colosseum’s construction depended on two innovations: concrete, and interchangeable parts built to standard specifications. If any Roman architects, artists, or engineers suffered from change resistance, those who embraced the innovations apparently drowned them out.

> The Colosseum’s standard program was executions in the morning, followed by slaughtering exotic animals, followed in turn by gladiators trying to hack each other to bits.

I think this means we have to give the Romans credit for inventing standing meetings with standard agendas.

It also suggests they were early victims of the consequences of bad metrics. Because every day started out with executions, the Roman courts had to convict enough suspects of capital crimes to fill out the program, whether or not a sufficient number of capital crimes had been committed. I presume the parallels are obvious.

In any event, combining the morning executions and gladiators who got the old thumbs down, a million corpses exited the Colosseum’s fabled arches during the years it was in session, although the pace slowed a bit when Rome became Christian and did away with the gladiators.

I guess that was progress. Speaking of which, for the Roman Empire, conquest was what you did if you could. Now, it’s frowned upon. That’s progress, too, I guess.

> While walking through the Pantheon our guide pointed out a row of headless statues. They weren’t, he assured us, early examples of Dr. Guillotine’s work products.

It was due to Roman parsimony. Coming from a practical society, Roman artists figured out the average statue would greatly outlive the person it had been carved to honor. And so, they designed their statues to have replaceable heads.

In IT we call this “modular design.”

> We didn’t spend all of our time in the Colosseum (and Pantheon and Forum). We also toured the Vatican, where, in the Basilica, we saw evidence of St. Peter’s tribulations. As it happens, visitors rub St. Peter’s feet for luck. No, not St. Peter himself but a bronze statue thereof. Bad luck for St. Peter. After centuries of this his feet are being rubbed right off, toes first.

I’m pretty sure we in IT have parallels to muster. If not, elsewhere in technology land I’ve read we’re running out of helium, one birthday balloon at a time.

Sicily has been more relaxing, at least from the perspective of spotting IT parallels. I’m hopeful this might mean I haven’t completely lost my ability to disconnect from the world of information technology. But there is Mount Etna, an awesome and awe-inspiring site.

> On the not-a-parallel-at-all front, shortly before its recent eruption, data integrated from a variety of sensors reported a 10 centimeter increase in the mountain’s elevation (about 3 inches if the metric system isn’t your bag; also about 3 inches if it is your bag only you don’t need me to handle the conversion for you).

Where was I? Oh, that’s right, 10 centimeters, and I hope you aren’t so blasé that you aren’t awed by our ability as a species to measure such things with such precision — a precision that allowed geologists to warn everyone potentially in harm’s way so they could get out of harm’s way.

> On the back-to-parallels front, Mount Etna doesn’t have just one crater, although the main caldera is enormous.

It has hundreds of craters. That’s because, when pressure increases and the old eruption paths are plugged, the magma doesn’t metaphorically say to itself, oh, gee, I guess I’d better calm down and head back to the earth’s mantle.

Nope. The pressure is there, the result of physical forces that can’t be eliminated and physical laws that can’t be repealed.

The result: The magma has to go somewhere, and where it goes is the path of least resistance, culminating in it pushing through the side of the mountain, resulting in a new eruption and new crater from which it spews out.

The business/IT parallel is, I trust, clear: Good luck trying to stamp out shadow IT, which is also the result of pressures that won’t go away just because you want them to.

It’s time for me to head back to the beach. The IT parallel? None.

Ahhhhhhh.

Comments

|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