Excellence is fragile. Dumb mistakes, in contrast, are more durable than Kevlar. It’s a universal law. For evidence, look no further than Microsoft Outlook.

Try this: Go to July 4th. If Independence Day isn’t already listed as a holiday, enter it as an all day event. Then click Tools/Options, the Calendar Options button, then the Time Zone button. Make sure “Show an additional time zone,” is checked, and set up a different time zone from the one you’re in. Click the Swap Time Zones button followed by Okay until you’re back in Outlook, and guess what: Part of Independence Day occurs on either July 3rd or July 5th, depending on your time zone choice.

Way back when Microsoft first designed Outlook, someone decided it would be clever to treat all-day events and midnight-to-midnight appointments the same way. Every subsequent version has inherited this bonehead design decision, which makes calendar management quite annoying for travelers who schedule events and telephone calls in multiple time zones, and want to show up or dial when they’re supposed to.

But wait. It’s worse! When Palm designed the original Palm Pilot, it ignored time zones altogether. You schedule meetings in local time, change the clock when you change time zones, and that has to do.

For entirely mysterious reasons they designed it this entirely incompatible way, even though they also designed it to synchronize with Outlook. The result? Change time zones in Outlook, the clock on your PDA, synchronize, and your calendar starts to look … wrong. And every subsequent version of the Palm PDA has inherited this bonehead design decision.

You’d think neither Microsoft nor Palm ever figured out that people travel.

I’ve found two PDA-based products that claim to fix the problem. One instructs me to never change the time zone on my PC, only the system clock. And by the way, it’s only reliable if I only enter appointments in my PDA, never in Outlook. No thanks.

The other would be fine if it weren’t for those pesky all-day events, and if it worked. Synchronize a few times and both all-day events and regular appointments act like gerbils — they mysteriously multiply. Make that cockroaches, because sometimes you can’t get rid of them: No matter how many times you delete them they just reappear.

The point of this column isn’t to gripe about Outlook and Palm (well, okay, that’s one point, but there is another, larger one). It’s to encourage you to encourage your managers to encourage everyone who works for you to pay attention to the consequences of their design decisions, because bad design never goes away. Quite the opposite — bad design inevitably creates a cascade of ever-more-fragile workarounds that eventually turns even the finest system into a shambles.

For example: Imagine you start up an on-line clothing store. As part of your systems you implement a customer database. In it you define “customer” as an individual: First name, last name, address and so forth.

After a couple of years you discover that sometimes, more than one customer lives at the same address. You’re selling to households and you never suspected. What to do?

Deadlines are tight and other priorities compete for attention so you take the easy way out — you create a Households table and write a program that sweeps the database once a night, recognizes new households, and populates the Households table accordingly.

Two years later you start selling embroidered clothing to businesses that stock up “trinkets and trash.” Now you also have to handle whole corporations, with multiple contacts, as customers. The pressure hasn’t let up, so you handle this situation much as you handled the Households problem.

The result: Every software change from this point forward has to take these kludges into account, increasing your costs while slowing down your ability to adapt to changing circumstances.

The moral of this story is simple: When you find that some of your design assumptions have changed, in the long run it’s better to adjust the design to your new circumstances than to make the quick fix.

Microsoft’s (and Palm’s) challenge is finding a financial motivation to fix the time zone problem, because it’s hard to see how doing so will sell any more software. Yours is a bit different: While “pay it now or pay it later” is easy for an engineer to understand, pay-it-now dollars are much more tangible than pay-it-later dollars.

Understanding the principle is the easy part. Helping the business make the right decision is a lot harder.

I fell in love with a client’s CEO a couple of weeks ago.

Platonically, that is. He’s an immensely successful entrepreneur, and we were discussing the value of his instincts for the business. “I don’t believe in instinct,” he told me. “I believe in evidence.”

Which brings up the recurring subject of Sarbanes-Oxley, why so many implementations spiral into out-of-control fiascoes, and what you can do to avoid that fate if you’re on the hot seat for bringing your company into SOX compliance.

At the KJR Conference last March, Jeff Sakamoto, then-CFO of Cyanotech Corporation, and Danielle Stariha, Director of Internal Audit for Gander Mountain Company shared their thoughts on the subject. Since they both managed to bring their companies into compliance on time and within budget, their thinking was well worth hearing.

I’m not going to try to summarize everything they said. They provided too much valuable content to easily summarize in a column or two, and much of what they had to say is similar to what’s been published elsewhere on the subject. Here are a few points you might not have encountered before, that will help you through your own efforts to become and stay SOX compliant:

  • It’s basically a good idea — having clean books and effective controls. What SOX requires of publicly held companies are practices they should already have in place. If you start your SOX program with that philosophy you’ll make much more progress much more smoothly than if you start with the attitude that it’s something you’re doing for the Feds.
  • It isn’t a good implementation of a good idea. Regrettably, like so many good ideas voted into place by our elected representatives, the good ideas were turned into a furball of documentation requirements. With SOX, if it isn’t documented it isn’t happening. Live with it.
  • It’s a project. Scratch that — it’s a program, which is to say it has multiple threads of effort (initiatives) each of which consists of multiple projects, each of which must be managed well, just like any other project. It’s banal, it’s obvious, it isn’t worth saying … except that it must be, because one reason many SOX efforts go bad is a failure of basic project management.
  • Master the subject. Your audit partner or some other SOX consulting experts will do a lot of the heavy lifting for you. That makes it an outsource, and like any other outsource, if you don’t know what’s going on you deserve whatever happens next. Another name for Sarbanes-Oxley is the Full Employment for Auditors Act. That doesn’t mean you have to be the one providing them with full employment.
  • Your CEO’s attitude tells the story. If your CEO is like our client, preferring evidence to instinct, you have a chance. The starting point for SOX compliance is a CEO who uses the accounting system as a tool to help understand What’s Really Going On Out There.

We have Sarbanes-Oxley because too many CEOs consider their company’s shares of stock to be a product, and their financial reports to be a marketing tool for that product. Marketing is about persuasion — about spotlighting the most favorable facts, de-emphasizing the least favorable facts, and describing those that are open to interpretation from their most favorable angle.

The other reason for Sarbanes-Oxley is that many CEOs make it known throughout the enterprise that Bad News Isn’t Welcome Here. Never mind shareholders and the Wall Street Analysts shareholders listen to. Their desire to hear what they want to hear instead of what they need to hear is overpowering. They trust their gut, believe in their instincts, and if the facts say otherwise then you’d better adjust the facts to match their reality.

The question is what to do if you work for a CEO like that (and here I’m going beyond what Jeff and Danielle presented: Neither described their CEOs this way).

Being responsible for SOX compliance doesn’t empower you to fire the CEO, much as you might want to. Your choices … your choices if you want to be effective, at least … are limited to one: persuasion.

Start with the first tool of the effective persuader — empathy. Say, “I don’t like it either, but we have to do it the SOX way whether we like it or not, and SOX doesn’t have a lot of wiggle room. We might as well be as efficient about it as we can.” And if you don’t feel any empathy, that’s okay — you don’t have to.

Pretend.