I knew better when I wrote it.

A couple of weeks ago I based KJR on a blistering, self-righteous critique of the various guilty parties responsible for the Katrina fiasco, deriving a number of lessons for IT along the way. While the guilty parties are just as guilty as before, it turns out the root cause of the flooding was much more complicated than my simplistic analysis (failure to invest despite a clear need to do so) suggested.

It’s almost always more complicated, which is why “self-righteous indignation” and “ignorance” are strongly correlated, if not synonymous. Simplistic analysis is for the simple, the intellectually lazy, and (to be fair) the excessively busy. None of the three are excuses for bad decision-making.

It turns out that while hurricanes have doubled in total destructive power over the past 30 years, and that global warming is probably a major cause, Trent Lott’s lost house exemplifies the bigger reason that hurricanes do more damage than they used to: Lots of Americans have chosen to build their homes along hurricane-prone shorelines.

It also turns out that Katrina’s storm surges were smaller than initially thought, well within the design parameters of New Orleans’ flood control system. Some newly renovated levees failed, apparently due to poor design (preliminary analysis suggests the use of flat plates instead of interlocking plates is a primary culprit).

Want to bet that at some point during the design process, the engineer who suggested interlocking plates was overruled due to cost considerations? And if not, that the contractor whose bid was based on interlocking plates lost out to the contractor whose design did not? The federal government does, after all, tend to award contracts to the low bidder (except, of course, when it awards no-compete contracts to Haliburton).

This new information reinforces the final point of the Katrina column — engineering does matter — but adds an entirely different perspective to it that provides another important, if prosaic reminder for IT: An absence of defects does not ensure the presence of quality. It’s a necessary condition, but not a sufficient one.

Depending, of course, on how you define “defect.” Too often, in IT, we equate bugs with defects, and as a result, testing with software quality assurance. It’s a basic point, but then, in IT as in most other disciplines, 80% of success comes from mastering the fundamentals. It’s still the case that in far too many IT shops, even testing receives too little time and attention.

In the case of New Orleans’ levees, it wouldn’t have mattered how good a job inspectors did after the installation was complete. Even if there were no construction flaws, the fundamental design was defective (assuming the preliminary analysis holds). The parallel for software development isn’t subtle: Software designs should be reviewed for conformance with software engineering standards prior to coding.

Not perfectly parallel is the need for stress testing, which would have been highly desirable for the levees were it not impossible, since there’s no practical way to set up Development and Test versions of New Orleans. There’s no equivalent reason to not stress test software.

But the larger lesson is the first one: Other than in Aesop’s Fables, it’s rare that challenging situations leave us with a few, simple, clear lessons. The world is a multivariate place, especially when those pesky human beings get involved.

Which leads to one final point, after which I’ll leave the hurricane post morti to the committees and experts. That’s the matter of what, for want of a better term, we can call “contingent responsibility.”

Contingent responsibility is what didn’t go wrong but just as easily might have. When you do something dopey, you sometimes get lucky and live to tell the tale … fortunately, or many more of us wouldn’t have survived our formative years. If you’re smart you recognize you got lucky, and avoid repeating your dopiness. If you aren’t, you figure it means your reasoning was sound.

People being what they are, I’m confident that when those who made the decisions to not invest enough in levee maintenance learned it was new construction that failed, they decided their allocation decisions were just fine after all. I’m equally confident that when those who discount global warming saw that the rise in coastal construction was the primary cost driver, they felt justified in continuing to fight emission reforms.

I’m confident, because I’ve seen too many business managers rely on luck as an alternative to investing in the mitigation of well-understood risks, disparaging those who warn of the consequences with this compelling logic:

“It hasn’t happened yet.”

We call it the “process bypass process.” Hold that thought.

In a healthy organization, IT’s business partners have a lot of ingenuity, much of which is focused on what IT can do to make their work more efficient, productive, and effective.

Far too much ingenuity, in fact, for IT to be able to take care of it all. The result is the ever-present “IT backlog” — the list of projects IT won’t be able to get to for the foreseeable future. IT has struggled to find solutions to the backlog for as long as I’ve been in this business. The problem is as pernicious as ever.

There’s no single solution — you have to nibble away at it. Here are some techniques you can apply to deal with it and, if not solve it altogether, at least make it manageable.

  • Apply the rule of ten. Any organization, at any level, can deal with between three and five initiatives of any size in a given year. Any more than that and the organization’s energy is divided too thinly for anything to get done. That being the case, whenever anyone suggests a great idea (as in, “You know what this organization needs to do? It should …”) ask this question: “Great idea. And we have a lot of great ideas in front of us for what this organization needs to do. Does this make the top ten list? Because if it isn’t one of the ten most important, we’ll never get to it.”
  • Insist on a business sponsor. No, not just someone willing to testify that “we need it.” We’re talking about someone who has the authority to commit to the business benefits to be had from whatever the request is for and live up to delivering them once the project is finished. That also means defining all projects in terms of business change, not software delivery, and including implementation of the business change within the project plan. No benefit, no business change, no project.
  • Use a magic quadrant. Yeah, I know, but use one anyway. The x-axis is total benefit — amount of improvement combined with organizational scope. The y-axis is total investment — the combination of cost, effort and risk. These don’t have to be precise — consensus scales of 1 to 10 will do just fine. By throwing each request into the magic quadrant you can do some initial screening: Reject everything (of course!) that combines high investment with low benefit. Accept everything that combines low investment with high benefit. So far, so good.Low investment and benefit? Either make it a local problem, to be solved with Excel or MS Access, or find a way to fold it into another, larger effort.

    The high investment/high-benefit proposals are the toughest. These are the ones you carefully screen and analyze. Choose only as many as you can successfully implement, and make sure they get a lot of oversight. They’re the most likely to get out of hand, and the most likely to be disappointing once completed.

  • Don’t say yes or no. Say no or when. If you can’t provide a project launch date, you might have said yes, but you didn’t mean it because you don’t know if, let alone when, you’re going to work on it. Don’t pretend. You haven’t said yes until you’ve put the project on the master schedule, with the launch date predicated on the availability of all staff required for the project to proceed.So now you have an governance process. Be careful what you ask for. Another name for well-defined governance is bureaucracy — the loss of flexibility and agility that’s the result of slow, consensus, committee-driven decision-making.

Which is why, as part of your IT governance process, you need a process bypass process — a governance process that bypasses your governance process. It’s a way to fast-track opportunities that just won’t wait. The keys to success for a process bypass process are (1) it’s only used for time-sensitive opportunities, not to placate the loudest voices; (2) it’s used to give the project the next available time-slot in the master schedule, not to interrupt work in progress; and (3) process bypasses still require approval — most likely by the CEO, CFO and CIO. And that includes approval to use the process bypass process in the first place.

Which is to say, nobody gets to bypass the process bypass process.