One Bad Apple

Do Apple Shareholders Deserve to See Steve Jobs' Medical Records?

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.”

A Hard Look at Principles Based Accounting

The New Wave Looks More Like a Tsunami

January 2008 Whitepaper on Principles Based Accounting. Click Here to Download ( PDF )

There’s no doubt that principles-based accounting is quickly taking over as the predominant overriding methodology for accounting. I guess the key question for me, along with the more astute followers of this trend, is how to maintain transparency through all of this.
Let’s talk about this for a bit.

Back in January 2008, all the top executives from all the big accounting firms put their heads together, and drafted this whitepaper on principles-based accounting. Their collective endorsement has in no small way contributed to the wave of new regulation, advisement, and general migration away from the old rule-based thinking that currently permeates US GAAP rules. Now it’s generally accepted ( pun intended ) that IFRS is certain to be the accounting standard of the near-term future for the US – it’s just a matter of time.

In their seminal brief on the topic, the top number crunchers of the country discuss these key elements in support of their argument for principles-based accounting:

• faithful presentation of economic reality,
• responsiveness to needs for clarity and transparency,
• consistency with a clear conceptual framework,
• a basis in an "appropriately-defined scope that addresses a broad area of accounting,"
• clear and concise writing in plain language,
• and allowance for the use of "reasonable judgment."

How noble of them.

I’m concerned at the conundrum this puts us in, as doing an accurate and diligent job in all of these areas simultaneously, is no small feat – bordering on impossible ( even though I love the challenge of “impossible” ).

My interpretation of “faithful presentation of economic reality” translates to fair value accounting. Issuance of standards like FAS 157 ( the fair value measurement standard ) clearly communicate the direction being taken within the accounting industry, and it’s importance is being punctuated by the recent fallout of the major financial players in the market.

However, “responsiveness to needs for clarity and transparency” becomes a nightmare when fair value comes into play. Think about fair value accounting on a Level 3 asset. Here’s how a somewhat recent blog on the Wall Street Journal characterized a Level 3 valuation of assets:

“Level 3 is for assets where one or more of those inputs don’t have observable prices. This is the bucket that has been described as a guesstimate, because it is reliant on management estimates.”

Guesstimate? I don’t see anything clear or transparent about the word guesstimate.
And what about that last bullet? – “allowance for the use of ‘reasonable judgment’.” This is based on who’s reasoning? How do you get transparency out of anything subjective like this?

I understand that there are problems with rule-based accounting, but you cannot argue that transparency was a big plus. The rule is the rule – and either you follow the rule or you don’t. Whether or not the rule made sense, or has anything to do with economic reality, is another issue.

However, what’s wrong with just adjusting the rules? Why throw out rules altogether, in favor of reasonable judgments and guesstimates?

To me, they’re just creating a bigger mess. And everybody’s going along with it, like they’ve invented the light bulb. Principles-based accounting will undoubtedly make your accounting opaque, and empower unethical executives and their spin-doctors to squirm out of difficult realities that they don’t want to face.

In this new day and age of the unavoidable train wreck called principles based accounting, I would strongly advise that you get very, very serious about your data systems and procedures for explaining yourself to the world. You will need to document every decision, store every detail of every analysis with hard evidence, and have a flawless change management system in place.

Oh, and buy a Kevlar® helmet. This one is going to hurt pretty bad.

* Kevlar® is a registered trademark of DuPont.

Don't Depend on Project Dependencies

3 Key Tips for Breaking Dependencies, and Bringing a Project End Date In

How can you make a deadline on a project, when a deadline doesn’t seem possible? A key trick in getting your compliance projects in under schedule is understanding how to break dependencies.

Dependencies in a project happen, when two or more activities depend on each other. The most common kind of dependency is a “Finish to Start” dependency, meaning the first task needs to finish before the second task can start. For instance if you’re building a house, you cannot put up the walls until the foundation is dry.

The obvious problem with dependencies, is that they force a constraint on your project’s timeline. If you have two different activities that both take a day to complete, with enough resources you should be able to get both done in a day. However, if there is a start to finish dependency on the activities, then your group of activities is forced to take 2 days.

For that reason, whenever I setup a project that has been allocated a good number of equivalently skilled resources, I go out of my way to break dependencies. Here are 3 key tips that will help you pull it off:

Tip # 1 : Resist the Natural Urge to Sequence Things

Novice project managers tend to create dependencies, even when no dependency exists! That’s because it’s human nature to think in terms of sequences. Processing things in blocks, and further in sequence, is a natural process that we follow to solve a problem. Let’s take a random example of making coffee. Here’s what comes natural:

1. Grind the coffee beans
2. Put the filter in the coffee machine
3. Pour the coffee beans in the filter, and close
4. Fill the coffee pot with water, and pour the water into the reservoir
5. Replace the coffee pot on the warmer
6. Push the “ON” button

Seems like a 6 step process, but if you step back to think about it, there are a few things we can do in parallel. For instance, with enough people you could grind the coffee beans, put the filter in the coffee machine, and pour the water into the reservoir all at the same time. Most likely you will be able to fill the reservoir and replace the coffee pot before the beans are finished grinding, and pushing the “ON” button takes literally no time. So with some help, you could go through the whole process in the time it takes you to grind beans and press “ON”.

Tip # 2 : Eliminate Soft Dependencies with Risk Planning

A soft dependency is a dependency that in and of itself isn’t mandatory, but rather a “good idea.” Let’s go back to the construction example. It’s a real good idea to paint before you lay carpet, but there’s no physical reason why you cannot ( unlike the foundation example above ). So, what many project managers will do is treat this as a dependency for good practices sake.

What I’m suggesting is that you eliminate these soft dependencies. In most cases, following good practices like this are in-built risk management. By establishing a dependency like this, you’re controlling the risk that paint will get on the new carpet. The problem with this approach is that you’re masking risk management into the schedule, which is a bad idea. The reason this shows up so often, is because proper project risk management is usually overlooked.

The more advanced approach is to break the dependency, and call it out as a risk on your risk management plan. Since you’ve highlighted the risk, you can deal with it as a risk instead of hiding the details in the schedule. Building the dependency is only one way to control this risk. You could also buy paint-resistant carpet, hire more skilled painters, or invest in better painting tools.

Tip # 3 : Eliminate Hard Dependencies with Interfaces

We’ve already discussed what a hard dependency is, so what is an interface? An interface is a simulation or placeholder of sorts, that mocks up the dependency between the two activities. For instance, the walls could be constructed ahead of time, if we had some sort of mock foundation that we could use as a guideline. Also, the majority of the foundation could be poured as long as we had some mock up of where the walls would fit in. The walls could then be grafted in later with steel reinforcement.

Breaking hard dependencies takes a lot of imagination. You have to force yourself to think outside of the box. Fortunately, the human mind has an infinite power to problem solve. To get there however, you have to allow the question, and assume it’s possible to break the dependency. If you tell yourself, “there’s no way to break that dependency”, then you’re probably right. But I would probably come along and pull it off, just by thinking a different way.
In our coffee example, we’ve gone to great lengths to parallelize things, but there still seems to be dependencies. How can you press the “ON” button before the water and coffee is in the machine?

Well, don’t use the coffee pot to fill the reservoir. Use two other containers, one small, and one just the size to fill the reservoir less the size of the small container. Somebody quickly fills the small reservoir with ice cold water, dumps it in the coffee machine, and turns it on.

It will take a while for the cold water to heat up. While the beans are being ground, the larger water container is being filled with room temperature water, and dumped into the machine. The rest of the process goes as planned. Now the entire activity cycle time is dependent on the time it takes to grind the coffee and dump it into the filter.

Breaking dependencies is an art that’s worth exploring, if you want to take it to the next level as a compliance project manager. Some key tips include resisting the urge the naturally order things, breaking soft dependencies with risk planning, and breaking hard dependencies with interfaces. Take some time today to look over your current project plan. With these tips in mind, you should be able to remove some of them, and bring your project end date in.

Mid-Level Siemens Manager Takes the Wrap

Following Orders is No Defense

Richard Siekaczek waiting for his sentence in a Munich courtroom. Picture Source

Herr Reinhard Siekaczek ist in der Kartoffelsuppe this month as the ex-manager at Siemens was convicted of misuse of funds, and slapped with a $170,000 fine and a suspended two-year sentence. If it seems a little light to you, that’s because it is. Siekaczek was served a somewhat lenient sentence because he cooperated fully with the investigation, and it was clear that he was just following standard Siemens practice.

According to the International Herald Tribune:

“there was no evidence that Siekaczek personally benefited from the corruption at the company. Siekaczek testified during the trial that his superiors had told him to create a new payment system after paying bribes abroad became a criminal offense in Germany in the late 1990s.”

So, he was just following company policy. Unfortunately, company policy was in direct violation with the law so it’s still wrong.

The sad thing is, Mr. Siekaczek is only a mid-level manager. They are currently pursuing the upper echelon, but they cannot go straight there. They have to go to the executioner first, then work their way up to the Capos and ultimately the Don and Consigliore – former chief executive Klaus Kleinfeld, and former chairman Heinrich von Pierer.

It will be interesting to follow how far up the corrupted management chain this thing goes.

Phelps Takes the Gold

But His Gold Medal Ceremony Wasn't Exactly A Gold Medal Performance

Michael Phelps winning his first Gold Medal at the 2008 Beijing Olympics. Picture Source

How exciting are these The 2008 Beijing Olympics?

If you're anything like me, you sat spellbound at the opening ceremony. Can you imagine the skill and discipline of the Chinese people, to put together such a spectacular show? What makes it even more mind blowing, is that there were no markings on the ground whatsoever. Everything was carefully planned and executed with precision timing and unparalleled synchronicity.

Even more exciting for us Americans, is watching our finest athletes bulldog through some of these competitions. We're already starting to make our mark on the 2008 Olympics, and leading the charge is our own Michael Phelps. On a mission to shatter Olympic records for most gold medals won, he was off to a good start by clinching the Gold in his first race, the 400m.

But did you listen to the medal ceremony? What a blunder on our national anthem! At first it sounded like they were playing the bars out of order, then the tape got caught in tape recorder, because the whole thing abruptly ended!

So somebody please explain to me how the Chinese can get 2008 people to do tai-chi perfectly synchronized in a circle, but they can't get through a taped recording of our national anthem to play right!

Compliance lesson : getting the hard stuff right is certainly an accomplishment, but keep an eye on the easy stuff too. Don't smash it out of the park on a knuckle ball, just to strike out on an underhand pitch.

Updates, and More Free Stuff!

New Articles Published on John Weathington's Quest for Compliance

John Weathington was invited by Quest Software, to be an expert blogger on the topic of compliance. Here you'll find a discussion for DBA's, database developers, and IT management on compliance concerns, observations, issues, and solutions, based on the consulting work of John Weathington. Click here to visit the blog site at Quest Software. Below are links to the individual topics.

• How to Survive a Death March
  • A death march is a project that is doomed to fail. If you are in IT, and you are dragged onto a compliance project, chances are you will find yourself stuck here. In this article, I'll give you my tips for identifying a death march, and more importantly surviving one.