The May 2009 issue of Flawless Compliance is available, with Center Stage article, The Ultimate Insiders, SEC Cracks Down on Employee Insider Trading. Plus, what wired homeless people can teach you about efficiency, 3 Key tips for preventing an inside job, compliance violation inertia, and two stupid criminals make it easy to get caught.
The April 2009 issue of Flawless Compliance is available, with Center Stage article, Underestimating the Evil Genius, Staying Safe in Cyberspace. Plus, how to avoid a compliance pandemic, straight talk for the micro-manager, another banker parties with our money, and risky policy for Florida hikers.
The March 2009 issue of Flawless Compliance is available, with Center Stage article, Corrections Needs Correcting, Failed Controls Result in Oakland Tragedy. Plus, failed controls cause an Oakland tragedy, speeding up your process by adding chaos, Bush's shoe assailant goes to prison, and how to call the police when you're old.
The February 2009 issue of Flawless Compliance is available, with Center Stage article, Recovery.gov, Transparency in the New Administration. Plus, the fading relevance of print newspapers, leveraging PCI to build your compliance program, inflated returns bring down a Texas billionaire, and a download that might take a little while.
The January 2009 issue of Flawless Compliance is available, with Center Stage article, Transparency 2.0, Welcome to the New Age of Compliance. Plus, compliance lessons learned from a heroic pilot, how your image effects the outcome of an audit, India takes its place in the global scandal line-up, and a fishy control that should have been tossed..
US
Airways flight 1549 teaches us that improbable events actually do occur
sometimes. When the NTSB goes to investigate, the airplane’s black
boxes will prove vital in the determination of cause. We can leverage
this concept to fortify our chances of surviving a serious
investigation. In this article I introduce design considerations for
what I call the Black Box Data Store, the important data you need to
prove your innocence in an investigation. By
now, I’m sure you’ve heard about the Hudson River landing of US Airways
flight 1549. What a remarkable story of an unbelievably low probability
risk event actually occurring, and a heroic contingent effort that
mitigated a potential disaster. The popular theory on causation is that
a flock of birds flew into both engines, causing them both to fail. But
how do we know for sure that’s what happened?
Design Principle #1: Assume Your Company Will Be Investigated
Don’t assume that since an investigation is unlikely, you don’t have to
put effort into preparing for it. The incident that just happened with
US Airways had a probability of less than a million to one. You must
approach this with the attitude that you will be investigated, and
design the system appropriately. Design Principle #2: Collect More Data than You Need
I’ve been on several data warehouse analysis sessions, where the user
is mandated to provide an exhaustive list of data points that they want
brought from the source system to the data warehouse. This may be
appropriate for some strategic purposes, but for a compliance data
system it’s the wrong approach. More often than not, during an
investigation, you will discover the usefulness of data points that
never served a purpose prior to the investigation. You definitely want
this data available. Trying to pull in data after the fact is always
painful and in some cases impossible. Design Principle #3: Plan for Design Iterations and Mock Investigations
As with most designs, you will not get it right the first time. To
think you will is arrogant, and will cost your company dearly. As with
the Hudson River landing, you only get one shot to get it right, so you
need to practice several times. Assemble a team of coders, designers,
experts on the regulation or standard, and auditors. Build the system
you think is appropriate, and have a mock investigation. Do a thorough
post-mortem and go back to the drawing board. Plan on at least three
iterations, and more is better.
NOTE: This originally appeared on this date at Quest Software's
ToadWorld, on the expert blog "John Weathington's Quest for
Compliance". The link to the actual ToadWorld article is at the bottom.
When the dust settles, I’d be really surprised if this wasn’t the case.
I’m not trying to pitch a conspiracy theory here. My point is that we
won’t know the definitive answer until the NTSB (National
Transportation Safety Board) completes its investigation. And
fortunately, they’re well prepared. Every airplane is fitted with two
“black boxes” at the tail of the plane that records vital information
for the investigators: the cockpit voice recorder and the flight data
recorder.
Now the Hudson River case may seem obvious, and maybe they have enough
ancillary evidence to make a decisive conclusion on the bird theory,
however maybe not. In fact, in a lot of cases the NTSB investigates,
these black boxes are all they really have.
These boxes serve a specific purpose; they support NTSB investigations.
The NTSB at some point realized that it would be a smart idea to
collect a lot of data on every flight of every plane. The large
majority of this data is never used. However, in the unlikely event of
a water landing (can you tell I’ve had my share of plane trips), or any
other unusual (and usually unfortunate) happening, they have the data
that they need to determine what happened.
Your company is in the same position when it comes to compliance. The
intelligent architect of a compliance program will design a component
of the data system that collects data in anticipation of an
investigation. If you follow my work, you know that what I’m suggesting
is a contingent control for the risk event of an investigation.
In most cases your controls are dealing with an unfavorable risk to an
objective. In this case however, the objective itself is the efficient
compliance program, and the risk is that you’ll be audited and
subsequently investigated. The effects of the investigation are
probably detrimental to the company (i.e. penalties and fines), so to
deal with the effect before the risk event occurs, is what I call a
contingent control. Assuming your company is doing the right things,
lack of data to prove this can kill you in an investigation. So the
approach is to be prepared with lots of good data. And in honor of the
aviation system just described, the component of the compliance data
system that supports this control is what I call the Black Box Data
Store.
The Black Box Data Store is simple in concept, but powerful in
function. It can connect to any component of your compliance data
system, including your source systems, compliance operational data
store, compliance enterprise data warehouse, or even your compliance
data marts. Think of it as being downstream from your core compliance
data system. When designing your Black Box Data Store, keep the
following design principles in mind:
Investigations are a good thing when the NTSB is trying to get to the
bottom of an airplane crash, but not so good when your company is the
one being investigated. You can help your company be prepared for an
investigation with a Black Box Data Store. Assume your company will be
investigated, collect more data than you need, and conduct as many
design iterations and mock investigations it takes to get it right. You
probably won’t get to the point where your company is being
investigated; however, you’ll be happy you have a Black Box Data Store
if you ever do.
REPRINT: From the August 2008 issue of Flawless Compliance(tm). I felt it appropriate, based on the news Steve Jobs is making today. Hope you enjoy (again)!
 |
Steve Jobs doesn't feel well, as he has a "common bug." Picture Source |
Is the health of a company tied to the health of its leaders?
I believe so.
The New York Times ran an article in late July on Steve Jobs exploring this issue. You have to admit, he didn’t look all that well when they unveiled the new 3g iPhone. Interestingly enough, at a conference call after Apple released earnings, somebody asked about his health. The response from a company executive was, “it’s a private matter.”
Of course the obfuscation surrounding the “none of your business “ response never puts a lot of faith in the mind of the questioner, or anybody else listening. This consequently caused some speculation on the correlation between Jobs’ health and the sudden drop in Apple’s share price following the conference call. Unable to dispute the evidence that Jobs didn’t look too well, Apple further clarified that it was a “common bug.”
I think, as usual, they’re playing spin games.
Apple has a bad track record of disclosure around this issue. About four years ago Jobs had a rare form of pancreatic cancer, and it took nine months for Apple to disclose this to the public. Now they’re saying, “Oh yeah, the cancer thing. No, don’t worry about that, he just has a little cold or something.” How do we know that for sure? And if something serious does happen to Jobs, how will that affect the shareholders?
This brings up both an ethical and compliance issue. The compliance issue is somewhat objective, so we’ll start there. Does Apple have a duty to disclose Jobs’ health condition? According to TheCorporateCounsel.net,
“Under the SEC's rules, companies typically don't have an affirmative duty to disclose unless a Form 8-K is triggered or a periodic report (eg. 10-Q or 10-K) is due (I say "typically" because there are other 'disclose or abstain' circumstances to consider).
On the other hand, the company may have a duty to update if they have an outstanding statement that the CEO's health is sound. Given that an Apple spokesperson said Jobs' gaunt appearance at a recent event was due to a "common bug," there is an argument that the company had a duty to update (or was misleading to begin with).
Okay, but ethically what should be the call here? In my opinion, it fails the “smell test.” It just smells like something is sour in this situation. I have a real problem with the lack of transparency, with answers like “it’s a private matter.”
Under normal circumstances, I would say the health of a company executive ( or anybody for that matter ) is nobody’s business. However, the litmus test I apply is this. If he were to magically disappear tomorrow, never to return, would Apple be able to maintain its current valuation?
Well, aside from what all the spin doctors at Apple say, I just don’t think so. Steve Jobs is the genius behind Apple. His ideas, brought to life, is what originally made Apple, and what has recently saved Apple’s bacon ( alright, now I’m starting to get hungry ). My feeling is this. If the removal of Jobs ( in any way shape or form ) causes the company to lose any amount of value, then the shareholders have a right to know about any indicators that could cause this event to happen.
But that’s a pretty dramatic assertion, right? It’s pretty invasive to be required to disclose the condition of your health, so we wouldn’t want to put these demands on Jobs in such capricious manner. What’s the appropriate way to approach this?
This is what I would advise the board to do.
The most prudent first step is to establish causation. You have to know within a high degree of certainty that if Jobs leaves, Apple will not be able to operate as well. You can do this with what’s called a Design of Experiments. This is a statistical study that can affirm the causation between inputs ( Steve Jobs ) and outputs ( company performance ).
Once causation is established, the ethical responsibility is clear, and you should fully disclose any health issues. At the same time, I would strongly advise an immediate effort to control this risk. Having one person responsible for the health of a company the size of Apple is irresponsible. The preventive control would be to do anything possible to keep Jobs alive, and the contingent control would be to organize an effective executive team that can operate even in Jobs’ absence.I would do both. The operative word here is effective. Apple has already made statements to the effect that there’s a succession plan in place, but I wonder how effective that will actually be in the event of Jobs’ untimely exit from the company. To establish effectiveness, you can leverage the control plan that was created during the Design of Experiments project.
I really don’t think Apple will go down this road, unless they give me a call. Nonetheless, let’s hope Apple’s board does the right thing. In the meantime, if you’re an Apple shareholder, I’d be careful the next time Jobs gets a “bug.”
NOTE: This originally appeared on this date at Quest Software's
ToadWorld, on the expert blog "John Weathington's Quest for
Compliance". The link to the actual ToadWorld article is at the bottom. You
may have noticed that I recently took a short break from my “Quest for
Compliance” blogging duties, to handle some unexpected priorities, but
now I’m back and it feels great to plug in again. In my case, it’s
pretty easy to jump right back into the swing of things, but sometimes
coming back from a break can be quite disruptive. This applies to many
situations, including your company’s compliance programs. Fortunately
with your support, an unexpected break shouldn’t break your company’s
stride. In this article, we’ll explore what you can do aid the cause.
Why Your Company Might “Take a Break” from Compliance
Although unpleasant to deal with, breaks from normal operation are not
uncommon for a compliance program. That’s because your company’s
compliance policies are created and maintained by your compliance
organization, however the activities that keep your company in
compliance are largely executed outside of the scope of your compliance
program. For instance, if your company sells goods and services to the
government, your company should have a program devoted to your
government contract maintenance and compliance. However, to stand in
good stead when dealing with government auditors, the activities of
your sales staff need to be under control.
This puts your company in a position where the rules are coming from
one organization, and the duties are executed by another. In a perfect
world the alignment of both organizations would be in sync however in
the real world the two organizations will have different primary
strategic objectives. Your government compliance program’s primary
objective is to maintain compliance with your government contract. Your
sales organization’s primary objective is to make sales.
What does all this have to do with a break?
Well, assuming your sales department and your compliance department
have a good relationship and are in sync with each other, following the
proper compliance procedures isn’t a problem. However, let’s say
there’s a crisis in the sales organization, and they need to forget
everything else and focus purely on what it takes to make a sale. As
much as your compliance program doesn’t like it, compliance procedure
will go out the window. Your sales force will in effect “take a break”
from your compliance policy for a while. There’s no way for your
compliance program to formally enforce compliance policy, since the
compliance organization doesn’t have formal control over the sales
organization.
Okay, Crisis Over but Why Aren’t Things Back to Normal?
So what happens when the sales crisis is over? The sales organization
returns to normal operation, following all the appropriate compliance
procedures, right? Wrong!
What has happened is that too much time has gone by, and the
organization has done a collective loss of information regarding
compliance procedure. Why only compliance procedures, and not the rest
of the procedures? It goes back to the primary objective of the
organization. The sales organization is not motivated by staying in
compliance, they’re motivated by making sales.
So how do we get the sales organization back on track? Sure, the
compliance organization can reinstitute training, but that’s time
consuming and the longer your organization is out of compliance, the
greater the risk your company is taking. Wouldn’t it be ideal if your
sales organization could snap right back into compliance mode? That’s
where you come in.
To pull this off, your data around compliance needs to be extremely
organized, and accessible to the sales organization. When I mention
your data around compliance, I’m referring to policy, like I described
in Policy Data Management in 3 Stages. The trick however, is to prevent
compliance information loss, even though the procedures are not being
followed through the “break.”
Let’s take the last holiday break as an example, which for some of us
lasted two weeks or longer. Without any judgment, some of us made a
complete break from any work activity, and some of us sort of monitored
what was going on by checking emails or possibly taking some calls. For
the people that took an absolute break from work for a week or two,
this “back to work” week was either very tough, very unproductive, or
both. For the ones that kept in touch with what’s going on, it wasn’t
so bad.
Continuity is the Key
The difference is continuity. Those that maintain continuity through a
break (which sounds contradictory, but that’s only a frame of
perception) have a much easier time jumping right back into normal
operating procedure. Your goal is to design a data system that empowers
your sales force (or any other organization that is required to follow
compliance policy) to maintain continuity through a break.
This is an extension of your mature policy management system. I say
mature, because you must be at the point where your policy management
system is integrated with your process data system, like the one I
described in Automated Process Auditing. Also, it needs to be matured
to the point where it’s a preventative control system, and not a
corrective or adaptive control system (see Prevention over Intervention
for an in depth explanation of the difference). This in effect gives
you a policy early warning system.
What you’ve done by creating this type of architecture, is given the
sales force the ability to review policy at the time of activity (i.e.
process of the sale), even though the policy is not being followed.
This will keep the policy and procedures fresh in their minds while
they navigate through their crisis. To go a step further, you might
consider creating a sort of acknowledgment feature in your transaction
processing system, that electronically validates that the policy has
been reviewed, and it’s purposely not being followed.
Wait, Something Doesn’t Sound Right!
It might sound a little odd that you’re capturing evidence of
purposefully violating policy, however in reality it’s the most
responsible thing you can do, given the circumstances. I’m not
advocating the willful disregard for policy; I’m assuming your company
is in a position where it cannot follow policy, and I’m showing you how
to lessen the impact from a compliance continuity standpoint. Your
sales force is not following policy anyway, and not acknowledging it is
not a defense in an audit or investigation.
Having the policy information display as a constant reminder while
transactions are being processed will serve the same effect as the
person on break that is checking emails. This process will prevent the
inevitable decay of policy information retention that will
geometrically progress as time goes on.
Breaks in policy are an unfortunate but sometimes necessary reality in
the normal course of business. It’s not a popular statement, but it’s a
reality that your organization need to be mature enough to face; even
if it’s from a risk management standpoint (meaning we don’t expect it
to happen, but if it does …). If your company is fortunate enough to
come around to that conclusion, they will need your help to architect a
system that minimizes the impact. Start drawing plans for the
construction of a policy early warning and acknowledgment system to
serve the need you now know is there.
Just published in the Coalition for Government Procurement's monthly newsletter called, "Off the Shelf."
It’s no doubt that a Government sales program is one of the most intelligent decisions a company can make to run a balanced and profitable business. With the upside however, comes the responsibility of running a tight compliance program. As a compliance consultant, one of the biggest mistakes I see companies make is taking unreasonable risks with their government contract. And one of the key reasons why they take these risks is because they do not make a strong enough case -- for themselves and their management -- for the proper investment in their compliance program. In this article, we’ll discuss exactly what you need to consider when building your case for government compliance...
Hi All,
I just wrote an article for CEO Refresher entitled, "Want to Cut Costs and Still Be Compliant?" You can access it by clicking here.
In the article, I talk about the importance of creating a compliance project charter, and I offer a freeMS Excel template download which is featured on my homepage now. If you would also like to download the template, feel free to download it here.
Of course, let me know if you have questions about the article or the template, feel free to call or email.
Take care, and have a great new year!
-John
