I have good news, great news, bad news, and good news.

The American Cocoa Research Institute (ACRI) recently reported research on (what else?) the health benefits of cocoa and chocolate.

The good news: The ACRI exists. Something this important deserves a research institute. The great news is that cocoa and chocolate are chock-full of flavonoids. Flavonoids are naturally occurring anti-oxidents, which means they help clean up nasty stuff inside you. According to the ACRI’s research, the flavonoids in cocoa and chocolate are more potent than those in red wine, and in fact are more potent than Vitamin C.

While the current marketplace for flavonoid detectors is only $10 million annually, the Froschbosch Group predicts that by 2005, it will grow to over $2 billion. This prediction is neither more nor less reliable than any of the other triple-digit-growth-rate market predictions you read about every week in this and other IT industry publications.

Have you ever taken a close look at these puppies? They’re all identical. They’re exponential growth curves — not one is S-shaped, none have plateaus, interruptions, or inflection points in their smooth takeoffs to glory. They all start with sales statistically indistinguishable from zero, and end a zillion times bigger. Add together a complete set and the 2005 total is 37 times the current US gross national product.

That’s a lot of economic growth … which, if it meant anything, would be great news.

Sadly, it doesn’t. That’s the bad news. These market forecasts are almost perfectly unreliable.

The statistics themselves are fine. I’m confident that the samples are big enough, stratified enough, stationary enough, and unbiased enough, and the computations are handled with precision. But they’re based on surveys.

So. The Froschbosch Group calls a CIO and asks, “Are you currently using XML to define workflow metadata?” The CIO answers that he is not with confidence.

“Are you actively investigating its potential?” The CIO doesn’t want to look like an incompetent bowb, so “Yes,” he responds, with no real understanding of what workflow metadata is.

“Will it be in production by 2002?” The CIO just said his organization is actively investigating this mystery cure, and two years is a long time. “Yes.” Heck, for all he knows, he will.

But probably, he won’t. He hasn’t even started the internal selling needed to get funding approved. In the unlikely event that he sells it and the business buys it, about three of every four IT projects fails, which means XML-based workflow metadata never will go into production in his company.

Okay, let’s give our survey respondent a break. Maybe the question is about the future of object/relational databases, and the CIO understands the subject. Every RDBM vendor has announced object/relational extensions, and his policy is to stay current on releases. Will he have object/relational database technology in production by 2003? “Yes,” he answers, and the survey company announces exponential growth for the object/relational marketplace.

The bad news is that most of these market forecasts don’t mean very much. What’s the good news?

The good news is that none of them matter to you. Amazing market growth doesn’t mean a technology is important to you, any more than a more modest market growth rate means it’s not.

All that matters is whether your business can benefit from a technology. No growth curve can tell you that. Market growth matters only to venture capitalists and Wall Street analysts, not CIOs and CTOs.

Dear Bob,

As a new manager, I am interested in any publications or references that are available with sample policies — for example, sample backup policies, helpdesk policies, data retention policies, etc. I’ve searched many libraries and found few actual “templates” from which I can glean knowledge, and, if it was an excellent template, copy shamelessly from. I’m hoping you could point me in the right direction to do more research.

– Managing in Manhattan

Dear Managing,

I’m definitely the wrong guy to ask. One of my missions in life is preventing the creation of policies whenever possible.

I know there are times when they’re necessary, but in my experience it’s just one step from a policy manual to a bureaucracy, and it’s a short step at that. Any time you have a policy, you make employees responsible for memorizing someone else’s thought process instead of using their own. Be careful what you ask for.

Once you form the habit of creating policies, it won’t be too many months before you find yourself moving all of your policies from a 2-inch 3-ring binder to a 3-incher because the 2-incher won’t close anymore. You’ll have turned yourself from a leader into a policy-meister — an awful thing to do.

Another downside to policy creation is that you turn your employees into jail-house lawyers. Your policies will turn into excuses for not getting the job done. They’ll turn into reasons to turn down reasonable requests from customers. And your most innovative employees will waste potentially productive time searching for loopholes, which they’ll then take great glee in publicly exploiting.

Worst of all, your policy book will become a source of disgruntlement, because employees will use the thickness of your policy manual as a direct measure of your lack of faith in their judgment. That’s the only attention most will pay to it, too: The more policies you publish, the less impact any one policy has. The advantage to having a very thin policy manual is that it’s clear to everyone the issues they address really are important.

Anyway, if you copy someone else’s policy, you’re copying someone else’s solution instead of creating one that fits your situation. The reason to create your own policies is that it forces you to think through the issue thoroughly enough to understand the ramifications. Once you’ve thought matters through, you’ll usually conclude you need nothing more than a guideline, or nothing at all — you’re trying to fix a one-time event, which, since it’s already occurred, doesn’t need more fixing.

So always write your own policies. The problem with pre-written templates is that they make the whole process too easy.

The exceptions are compliance issues … insider trading or data retention are examples … or when it’s important to declare a company position on a subject (sexual harassment comes to mind). Under these circumstances you need not just a policy, but one that will hold up in court. Don’t mess around with these — go to either HR or Legal, go directly to HR or Legal, don’t pass Go, and don’t collect $200 either. For that matter, always run any policy you do decide to draft past HR and legal — you never know when your policy crosses some invisible line that can land your employer in court.

Avoid policies whenever you can, and consider: “policy” and “police” have a common etymology.

– Bob