It’s always more complicated than it looks.

Case in point: Houston

Your hypothetical challenge: Bring the city back on line. What does this entail?

Lots and lots of lots and lots, that’s what.

Understand, I know nothing at all about civil engineering, or emergency management, and not all that much about enterprise risk management. What I do know is that nobody else can keep the list of everything that has to come back on line in their head either, let alone the interdependencies that could lead to creating a proper Gantt chart.

Oh, by the way, a half hour of Googling failed to uncover anything resembling a disaster recovery plan for the city of Houston. An emergency management plan yes, a recovery plan no.

Which isn’t necessarily bad management. As with IT’s ancient habit of trying to create comprehensive software designs before beginning to write any code, so disaster recovery plans of metropolitan scale or larger for disasters of inordinate magnitude are probably pointless. If, that is, they do much more than list the organizations that need a recovery plan, specify what one should encompass, and insist they have them.

Even then there are limits. As everyone who’s involved in disaster recovery and business continuity knows, a plan that isn’t tested isn’t a plan.

And along came Harvey.

Case in point: New York City.

I worked with a client there several years ago, enough that a corporate apartment made more sense than staying in hotels. The result, though, was that for a couple of years I qualified as a resident, meaning I owed New York City taxes. These were (1) substantial, and (2) business expenses, not directly deductible from my Minnesota state tax bill.

This sawed me off. Until, that is, I saw a sign in the midtown Whole Foods that explained New York City creates enough garbage every day to fill the Empire State Building.

It occurred to me then that I had not the slightest idea how to go about removing that quantity of garbage every day, and that garbage removal is far from the most complicated challenge in running New York City.

As I had no idea how to run NYC I certainly had no idea how to run it at a lower cost, which meant I should put up and shut up. I benefited from services I didn’t even know were being provided. My New York City tax burden was how I paid for them.

Case in point: Any legacy retirement

Over and over again, companies make this mistake: They decide to retire the ancient mainframe batch COBOL system the whole company has been running on for forty years. And from this decision comes a logistical nightmare, because no matter how you go about it, you can’t shift the entire company from the old system to a replacement at the flip of a switch. It has to be phased and staged.

And no matter how you go about the planning it turns out many business areas will be running in a mixed environment for a year or more.

But unlike New York City or Houston, a lot of this complexity is a self-inflicted wound, the result of looking at exactly the wrong end of the horse.

The problem is the decision to retire the mainframe. Not that the company should stay on it. No the problem is that this focuses everyone’s attention on what they’re migrating from. In addition to the logistical migraines this thought process creates, it results in something even worse than the planning nightmare: When the project is done and the mainframe has been retired, the business runs pretty much the same as it ran before it invested the zillion or so direct dollars, plus sweat and opportunity costs, that were needed to make it all happen.

Much of which would have been avoided had everyone focused on the opposite question: What to migrate to.

Even better, they should be focused on how each business manager at every level wants to run his or her part of the business differently and better, leading to an applications portfolio plan that will mostly let them do so.

Taking this approach, things still aren’t simple. They are, however, simpler — a lot simpler, because (for example) moving Sales to a modern CRM system is, at a minimum, clear in what has to happen.

And moving Sales to a better sales process that’s possible because of the modern CRM system’s features has actual business benefit beyond a modest reduction in the IT operating budget.

Consider the Titanic.

Based on entire minutes spent Googling, it appears the ship’s lookout spotted the iceberg that sank the ship when it was about 2,000 feet away. This seems like plenty of time to steer around a hazard, and it would have been plenty of time — at 20 knots, almost a full minute — had the Titanic been, say, a fishing trawler.

It wasn’t. It was the biggest ocean liner of its day, and even with a rudder 78 feet 8 inches high and 15 feet 3 inches long, its turning radius at full speed was about 1,900 feet.

1,900 feet being a shorter distance than 2,000 feet, it appears there was enough room for the Titanic to miss the iceberg. But history and John Cameron tell us it didn’t miss.

What went wrong? It turns out the decision as to whether to steer around the hazard or to maintain course turns out to have been quite a bit more complicated than hindsight makes it appear. If this makes no sense to you: The ship might have missed the iceberg, which was after all in motion, by maintaining course; trying to steer around the iceberg might have resulted in impact closer to the stern, doing more damage; reducing engine power to reduce speed would have reduced the rudder’s effectiveness, to name three complications among many.

In the end it was a judgment call that took 37 seconds to make — enough time for the Titanic to have missed the iceberg. If you’re interested, read “The 30 seconds that sank the Titanic — fatal delay in order to change course doomed liner,” Jasper Copping, Daily Telegraph, 12/4/2011.)

Which has what to do with the worlds of IT, business, and their intersection?

Start with 20/20 hindsight. I’m assigning you the mission to allocate blame … sorry, to determine the root cause. You start with the most basic question: Was the problem that the ship’s turning radius was too big, or that it took too long to decide to change course?

The answer is, of course, yes.

And now (at last!) we’re ready for business, IT, decision-making, and all things Agile.

As we all know, IT has to adopt Agile. If you don’t use Agile techniques by now you’re two hops short of current thinking, current thinking having moved to DevOps, which is itself a hop short of what’s actually needed.

Among Agile’s many benefits compared to Waterfall alternatives are two sides of one coin that gets far too little attention.

Side 1 is Agile’s ability to reduce the damage done by the management fad du jour.

Something largely unappreciated about fads du jour is that in the eyes of the managers who sponsor them they aren’t fads at all. They’re responses to important business trends, marketplace shifts, new and better thinking … that sort of thing. But time passes, sponsors move on or lose influence, gratification is less than instantaneous, and the executive leadership team (ELT) moves on to whatever is next in queue.

But in the meantime, through various governance mechanisms rooted in Waterfall-based assumptions about how much time and investment is needed to make change happen, a very large fraction of the company’s total discretionary budget is directed to turn the fad du jour into operating business reality.

Which in turn makes it unavailable for other, more valuable but less strategic uses for timescales measured in years.

With Agile techniques, companies can slow down or stop business change efforts sooner and still get some value out of them because Agile delivers working stuff in timescales measured in weeks (sprints), and tangible business change in months (releases).

One of Agile’s most important characteristics is a governance mechanism that, depending which Agile variant you use, changes priorities dynamically in these same timescales.

Which in turn means fads du jour‘s resource commitments don’t have to be any longer than this.

Side 2 is the exact same thing, only instead of mitigating the damage done by fads du jour draining resources away from higher-value efforts, it accelerates the value provided by projects that with Agile deliver business change in months instead of years.

In Titanic Governance terms, it means decisions about how best to avoid various business icebergs can be made faster and changed faster.

While it’s stretching the metaphor just a bit, Agile itself is parallel to reducing the Titanic’s turning radius. Agile Governance, done right, decides to turn to avoid the iceberg faster.

Done wrong, the same old governance, unconsciously based on the same old Waterfall assumptions, can crash even the best Agile project practices right into the same old decision-delay icebergs.