Flawless Compliance (tm) - January 2008, Issue # 1

A free newsletter on today's compliance issues, ideas, and solutions. Back issues are archived for free downloading at http://www.excellentmanagementsystems.com.

Published by Excellent Management Systems, Inc, One Embarcadero Center, Suite 500, San Francisco, CA 94111; toll free 800 / 379-8064; local 415 / 738-2342; fax 415 / 738-8630; newsletter@excellentmanagementsystems.com.

Your name and this list will never be shared with anyone else. If you wish to unsubscribe, instructions are at the end of the newsletter.

Copyright 2008 John Weathington. All Rights Reserved.

In This Issue:

• Don't Shoot the Tiger: 4 Lessons Learned from the SF Zoo Incident
• Wiki Wiki Wow: A Great Technique for Collaboration
• John Weathington's Blog
• Please Remember
• The Fine Print
  

Don't Shoot the Tiger: 4 Lessons Learned from the SF Zoo Incident

Why does a tiger jump a fence? Because she can.

It wasn't a very merry Christmas for the Sousa family in 2007. In the city where cable cars drive half way to the stars, a 300 pound female Siberian Tiger drove herself all the way over an 18 foot retaining wall where some serious damage was done. A 17-year old boy was killed, and 2 of his brothers were severely injured.

Coming to San Francisco's defense, Miami Metro Zoo spokesman Ron Magill said it's unlikely that a zoo tiger could leap that high, even with a running start. So I guess Siberian Tigers that are in zoos somehow have different DNA?

My sincere condolences go out to the Sousa family, however the real tragedy in my mind is the shooting of the tiger. What's the point? There must have been another other way to handle this, so why kill the tiger? Was that supposed to send some message to all the other tigers watching?

Although it does a nice job of giving the Sousa family some sense of closure, shooting the tiger is not going to fix the problem. I don't even have to think about this one. The problem is with the zoo, not the tiger. There are some classic compliance mistakes that were made here, and lessons we can learn.

Lesson # 1 : When it comes to compliance, "unlikely" is not good enough.

In most compliance situations, zero tolerance is the target. In statistical terms, it is impossible to guarantee a process will have zero defects, however in practical terms it means there is an extremely low probability that a defect will occur. For instance, if the SF Zoo had a true six sigma operation with the big cats, then that tiger would need to attempt that jump over 300,000 times before he made it over the fence. In a life or death situation ( I think a tiger escape defect would likely lead to human death ), not even six sigma is good enough -- I might consider seven ( one defect in 50 million ).

Not only is "unlikely" a vague metric, but to me it doesn't even sound tolerable. In too many compliance situations, we assume if something doesn't seem likely, that's good enough. Which leads me into my second lesson.

Lesson# 2 : Never assume anything.

There an old saying about the word "assume" which I won't repeat here, but it implies that anybody who assumes is a fool. I couldn't agree more. As humans, we have to realize our strengths and weaknesses. Inherently, we are pattern recognition creatures, not data crunchers. Your brain does not have the capacity to accurately estimate metrics, especially when those metrics involve a lot of factors.

I recently read the book "Super Crunchers" by Ian Ayres, and I thought it was fantastic ( I love numbers ). In his book, Ian takes you through an exercise where he asks 10 questions that have numerical responses, for instance, "What age was Martin Luther King, Jr. when he was shot?" To answer each question, you do not provide a direct value, but a range of values in which the real answer is between, within a 90 percent confidence. For instance, my answer to the above question was "Between 30 and 50", meaning I feel there is a 90 percent chance that Dr. King was between 30 and 50 when he was shot. I happened to be right on that question ( see the end of the article for the answer ), however I didn't fare that well for the rest of the questions. In fact, I only got 3 right answers ( and I'm smart and good with numbers). At a 90 percent confidence, I should have nailed 9 out of 10. I tried this exercise with a few other people, and they did about the same or worse.

The point is, humans routinely overestimate or underestimate depending on their emotions at the moment and gauged consequences. Ask any project manager how their team members are doing with their work estimates, and they'll tell you the same. Instead, collect data objectively, and let the computers do the number crunching. In most cases you'll be surprised at the outcome.

I don't think it was a good idea for the zoo keepers to assume that the tiger couldn't leap the fence. If the goal was to protect people from harm, they should have collected their own data on how high tigers can jump, and characterized that data with non-assumptive metrics.

Lesson # 3 : Never blindly take a guideline or regulation as your specification for compliance.

The wall at the SF Zoo separating the tigers from the humans was constructed to a height of 18 feet. Why 18 feet? Why not 25 or 30 feet? My guess is that there's some guideline or recommendation in the zookeeper's handbook that says tiger walls should be built 18 feet high -- so that's what they did. The problem here, is that they were more focused on meeting the guideline, and less focused on saving human lives. So, they followed the rules, but somebody is dead.

You need to extract the intent from regulations, instead of following them blindly. The intent behind compliance guidelines and regulations in most cases, is to prevent an unfavorable incident. Your focus should not be on the regulation, it should be on the incident.

A friend of mine told me that her girlfriend was in a really bad car accident a while ago. She was making a left hand turn, when a truck plowed right into her, putting her in the hospital. When my friend asked her friend what happened, her response was, "Well, I had the green light." So great, you didn't break any laws, only bones.

Preventing incidents is the best way to survive audits.

Lesson # 4: If an incident does occur, don't overreact and retaliate out of emotion or sense of retribution. Calm down, analyze and validate root causes, and take appropriate action to address the real root cause.

Shooting the tiger was unnecessary and cruel. If that tiger can make the wall, so can the other tigers in the exhibit,. They are not going to be able to reason with the tiger union, and have them sign an agreement not to maul humans. This is an uncontrollable variable that needs to be observed and understood empirically, not manipulated like a science experiment. Raise the wall, and fire the zookeeper, but don't shoot the tiger.

It's tempting when things go haywire to instinctively blame the people involved. People and whole organizations get remedial training, or in some cases completely downsized, because of knee jerk reactions from upper management. In all actuality, the people are rarely the root cause. Taking time to analyze and validate root causes, in the long run, will save you time, money, and a lot of grief.

Bonus Lesson : Don't mess with angry females, especially ones that outweigh you!

So, how old was Dr. King when he died? He was 39 years old.

Wiki Wiki Wow: A Great Technique for Collaboration

I'm sure by now, you are familiar with the Wikipedia, the online encyclopedia that anybody can edit. Well, before it's fame as the online global repository of knowledge, a wiki was typically used by an agile practitioner as the tool of choice for collaboration. The word "wiki-wiki" is the Hawaiian word for "quick", and true to it's name it's quick and easy to learn.

Communication is a key factor in your compliance success. In fact, if you are installing a new compliance system ( data system, processes, policies and procedures ), the success of your project relies heavily on your ability to communicate quickly and accurately with each other.

Once installed, a wiki can do wonders for any team's collaboration efforts, as long as the rules are followed. My characterization of a wiki from a communications standpoint, is as follows. It's a cross between a website and email, taking the best parts of both and combining them into one great collaboration tool.

A website is great for sharing information with a team. Information is centralized, and if done properly, organized in a way that makes retrieving information quick and easy. The downside with a website, is that the content is controlled by the webmaster. All information must be forwarded to him or her, translated to web language ( i.e. HTML ) somehow, and then published out to the official website.

Email is great for content contribution and dissemination. Anybody that has a thought can compose an email, and send it out to everybody that matters. The downside to email however, is content organization. How many times have you waded through a huge email thread to figure out what's going on?

A wiki works like a website for getting information, however the content is in control of anybody and everybody. When you go to any wiki page, you can edit the content of the page directly, and you don't need to worry about fancy computer jargon -- just type. There is some markup to learn if you want to, but it's simple. For instance, you may need to put an exclamation point in front of some text if you want to make it a heading, or put a star in front of some text to make it a bullet point, but it's nothing like HTML. To create a new page, in most cases, all you need to do is type in "CamelCase" and the new page link is created for you. Very simple.

This becomes very powerful when you have a high performance team dedicated to your compliance efforts. For instance, let's say you are on a SOX 404 compliance effort for identity and access management. Your internal auditor, could start a page by defining the regulation around password management. After knowing what she's dealing with, the policy manager could update the page with a policy that complies with the regulation. Now your process expert designs a process that makes it easy to comply with the new password policy, and your technical people document the designs for how the system will support the process. This is done real time, in the comfort of everybody's office.

Wikis are great, but of course there are limitations. First of all, you probably won't get a lot of fancy graphics, flash videos, or other sophisticated web elements on your wiki. Wikis are designed to be simple and lightweight. If you need wiz-bang stuff on your website, or if you need it to function as a web application ( i.e. process and report data ), then you should probably use the traditional methods.

And then there's the rules. Wikis are predicated on the assumption that the people who are using it, are using it with useful intention. Most wikis are pretty easy to sabotage if you've got people with malicious intent, because anybody can update any page at any time. Although "honest" mistakes are usually recoverable, outright attacks are hard to defend against.

Getting up and running depends on the type of wiki engine you choose to install. My favorite is the JSPWiki developed by Janne Jalkanen ( http://www.jspwiki.org ), but only because of my background in Java. There are several other great wiki engines on the market ( most of them free ), including the TikiWiki and MediaWiki ( the engine behind Wikipedia ). The ultimate decision is largely based on your IT infrastructure and experience, so check with them for their recommendation. Whatever the choice, it shouldn't take more than a day to get setup. I can setup a JSPWiki in about 20 minutes.

All things considered, it's a great tool that I've used many times when running projects. No effective Communications Plan is complete without it!

John Weathington's Blog

I'm excited to tell you that I finally setup my blog ( I know, it's about time )! It's located at http://blog.johnweathington.com. Please visit or even subscribe if you want to hear me rant and rave on a more regular basis.

Please Remember

As always, please remember to "Buckle-Up". It could save your life.

The Fine Print

Copyright 2008 John Weathington. All Rights Reserved. Feel free to share, excerpt or reprint this newsletter with proper attribution.

Your name and this list will never be shared with anyone. Please send letters and questions to john@excellentmanagementsystems.com. Please reference "Flawless Compliance Newsletter" in the Subject. If you received this newsletter from another source, and wish to subscribe, please send a message to newsletter@excellentmanagementsystems.com, with the words "Subscribe to Flawless Compliance Newsletter" in the Subject.

To unsubscribe, please send a message to newsletter@excellentmanagementsystems.com, with the words "Unsubscribe to Flawless Compliance Newsletter" in the Subject. You may be contacted if we cannot validate the email address to unsubscribe.