When discussing the institution of strong business processes, we consultants have been known to use the term “hero” disparagingly.

It isn’t that we think poorly of the heroes themselves. Those who overcome significant obstacles to create important results deserve nothing but praise. What we’re denigrating is the need for heroics — of creating an environment that requires employees to overcome barriers that exist only because company management hasn’t been willing to invest in their removal. Or worse, that exist only because company management has placed them there.

Which brings us to some more lessons from hurricane Katrina and its aftermath (see “Katrina Lessons,” 9/12/2005).

In the midst of watching the president and Congress argue over which of their dueling analyses is better (but why, exactly, was creating two competing analyses a good use of taxpayer dollars?) comes a valuable reminder to all of us who recommend the institution of well-designed, continuously improving, Lean, Six-Sigma-compliant, Theory-of-Constraints-aware processes: Who you hire is more important than how you design the work.

The proof is simple and syllogistic. It’s often ignored, too — perhaps because processes, being designable, documentable, objectively measurable, and without egos, personalities and feelings, are easier to deal with than human beings. Here it is:

My major premise is that the wrong people can, and usually do mess up even the best processes.

My minor premise is that the right people can achieve excellent results, even when shackled with abominable processes.

My conclusion is that having the right people is more important than having the right processes.

Q. E. D.

Logical proof is nice. Evidence is more persuasive. Which brings us to the President’s report. As described in a Washington Post article by Stephen Barr ( “Acts of Heroism Shine Through Homeland Security’s Humiliation,” Friday, February 24, 2006; B02), acts of heroism achieved important results in spite of the general lack of preparation, processes and procedures that characterized the overall response to Katrina. For example:

Coast Guard Petty Officer Jessica Guidroz, who herself had lost everything she owned, led a squadron of eight boats and crews that evacuated about 2,000 people from the University of New Orleans.

Petty Officer Moises Rivera-Carrion, a Coast Guard rescue swimmer, was on duty for three solid days. He dodged downed power lines and contaminated floodwaters to rescue 269 survivors trapped on rooftops and balconies throughout the region.

Then there was Coast Guard Petty Officer Rodney L. Gordon. He was the first to fly into New Orleans, in the face of strong winds and wind-blown debris. Cannibalizing broken gear for parts, he personally rewired emergency generators to get the Naval Air Station control tower up and running. Had he failed to do so, hundreds of lifesaving missions would not have flown.

Three heroes among many. The important question is the extent to which heroics should have been required, not the heroism itself.

For Katrina I’ll leave the answer to the dueling investigating committees. For IT, and how managers should think about and plan such matters:

Professionals divide problems into two categories: Foreseen problems and foreseen unforeseen problems. Professionals plan for the unexpected.

Amateurs, in contrast, deal with foreseen problems and unforeseeable unforeseen problems. Figuring bad things only happen to other people, and on someone else’s watch, is the mark of an amateur.

Then there are those who conduct the post mortem. Too often, they see only foreseen problems and foreseeable unforeseen problems. They consider the latter — the ones planners should have anticipated but failed to — unforgivable. They’re especially so because it usually turns out they were foreseen — just not by the people responsible for planning, who chose to ignore those who recognized the risk in question.

But people aren’t perfect; there’s no clear line separating foreseeable and unforeseeable problems; some of those who warn of impending catastrophes are right by accident, not expertise; and forgiveness — the flip side of blame — has no point. What matters is following three inviolable rules of the professional planner: (1) Anticipate and plan for what you can; (2) expect the unexpected and provide for it; and (3) use post mortems to drive improvement, not to find fault.

In your contingency planning, remember this lesson from Katrina. It won’t help you pass a Sarbanes-Oxley or CobiT audit, but it will help you survive your next contretemps. It is:

Your last, best hope when the unexpected happens is to have hired and retained employees who have the ingenuity, maturity and courage to assess the situation in front of them and take whatever action is necessary.

Doing so isn’t an alternative to having the right processes and procedures. It’s merely more important.

Rule #6 of information technology marketing is that if you don’t have a new idea, coin a new word for an old idea.

Clearly, those promoting SaaS (Software as a Service) memorized Rule #6. Just as clearly, those who think it really is new have memory problems worse than Leonard Shelby, the protagonist in Memento.

Yes, yes, I know. SaaS is completely different from the ASP (Application Service Provider) business model that preceded it because SaaS applications are designed for web hosting where ASP applications weren’t. I know this, just as I know that ASPs were completely different from service bureaus that offered time-sharing access to systems back when COBOL was king because ASPs were engineered to deliver access through the Internet instead of private connections.

I also know the English spoken in the United Kingdom is completely different from what’s spoken here in the U.S.A., because they say “lift” and “lorry” where we say “elevator” and “truck.”

As an RIP (Recognized Industry Pundit — AAW? (Ain’t Acronyms Wonderful?)), I have a few questions about SaaS:

  • Have they really solved the system integration problem? Blah, blah, web services. Blah, blah, blah SOAP (Simple Object Access Protocol — AAW). Yes, Salesforce.com has AppExchange. You’re still integrating across a high-latency, low-bandwidth interface compared to what you can engineer inside your firewall. More, the issue of SOA governance is gaining increasing attention. How do you plan to handle SOA governance when an SaaS vendor’s software is part of the mix?
  • Whose release cycles are they? They are, of course, the SaaS vendor’s release cycles. That makes you vulnerable.If you issue a new release of in-house developed software or install an upgrade to a commercial application, you’ll regression test it to make sure it doesn’t break any existing functionality. Yes, I know the SaaS vendor’s APIs aren’t supposed to change, and the data formats are supposed to be completely stable. But let’s not forget everything we ever learned about testing and change control. These disciplines matter because software doesn’t always do what its authors intended it to do, not because it does.
  • Is the touted advantage of being custom-engineered for web-based delivery truly an un-mixed blessing? From the perspective of engineering purity, of course it is. But anyone who looks at the subject solely from an engineering perspective is suffering from LSD (Leonard Shelby Dysfunction — see above; also AAW). Pandesic didn’t happen all that long ago.Pandesic, you’ll recall if you don’t suffer from LSD, was the SAP and Intel joint ASP venture. These two giant, reputable companies were willing to leave their customers in the lurch (see “Trend Overload“). What makes you think an SaaS vendor will treat you any better?By the way: SAP just announced that it’s entering the SaaS fray. To my knowledge every RIP (AAW) who has mentioned it has done so to enhance the SaaS model’s credibility. Not one has connected the dots between how shabbily SAP treated its Pandesic customers and its current plans. So you’re hearing it here first. Repeat after me: Fool me once, shame on you. Fool me twice …

    Make no mistake: If you build an SaaS vendor into your technical architecture and it goes belly up, you’re in even worse shape. Pandesic was built on SAP, so at least its customers were able to use the same software internally. SaaS software is custom, so you’d be dealing with a full conversion to an entirely different package. That’s much harder, and more expensive.

  • Whose release cycles are they? Part II. Beyond the expense of regression testing and change control on their schedule, there’s the potentially much greater expense of business integration.Beyond any shadow of a doubt, every release contains features so cool they’re practically cryogenic. That’s nice. But businesses don’t “use software.” They integrate software into their business processes and practices to make themselves more effective. If the software changes, the business process or practice changes, or what’s the point?

    It very well might be that the new features are all entirely optional. It very well might be that whoever manages the process for your company will be nothing but delighted at the prospect of figuring out how to leverage the new capabilities every six months, and of training employees in the new-and-improved process twice each year.

    It very well might be, but it’s far from certain.

What is certain is that when you install software, configure it, and host it inside your firewall you have much more control over the release schedule. Software as a Service? Call it Software as Business Enabler (SABE).

AAW.