Nearly two decades ago I presented an excruciatingly dull paper (“Quantitative Analysis of Electrical and Overt Behavior of the Electric Fish Brienomyrus niger,” if memory serves) at the Animal Behavior Society’s annual conference, held that year at Tulane University.

While there I met a researcher who claimed to have demonstrated rudimentary speech in parrots. Not “Polly want a cracker,” but real speech, with the parrot using rudimentary grammar and vocabulary.

I never heard anything more about the subject, so I guess nobody was able to repeat her results. It’s too bad. Given how much parroting some human beings do, finding parrots to be a bit more human would have been fun.

But parrot we do, as I found out while awash in e-mail following my proposal that we hold a National Boycott Stupidity Day (NBSD) and my suggestion that much of the concern over the use of foreign technical workers sounds suspiciously like bigotry. Quite a few readers parroted currently fashionable political rhetoric, equating neo-conservatism with intelligence, liberalism with stupidity, and my assertion of bigotry with “playing the race card.”

Parrots.

The response to NBSD was so overwhelming that I’m actually tempted to organize the event. We have an alternate name (Intellicom) and several volunteer projectionists (for our continuous showings of Forrest Gump, which we’re all going to not watch together).

We also have a program change. We will allow curling after all, since several readers persuaded me that this is a game of wit and strategy, not just sliding things on ice. My apologies to all you curlers. Instead, we’ll ban ice fishing, since I have to offend someone and sitting in a hut on the ice in winter, drinking beer, and waiting for a nibble seems a safe target.

Speaking of offending people, several of you took offense at my excluding Newt Gingrich from NBSD. Supposedly, he really does promote intelligence, despite his ethics violation, his insistence on buying a bunch of B1 bombers the Pentagon doesn’t want, and his pursuit of his own foreign policy. Oh, if only he hadn’t been named after an amphibian …

(I’d give equal time to offending Bill Clinton’s defenders, only there weren’t any. Sorry, Mr. President.)

NBSD was, of course, satire. Its point wasn’t that you should promote your opinion as “smart” and opposing views, for example liberalism, as “stupid.”

Now I personally think liberals see everyone except the wealthy as victims, while conservatives see no victims at all unless a criminal receives legal protection or Bill Clinton is involved. I think both fraudulently promote simplistic solutions to the complex issues we face as a nation. But that’s just my way of making unpleasant generalizations about groups I don’t like, an activity as American as wiener schnitzel and burritos.

If I actually held NBSD, those who disagree with me would be welcome. Those who parrot other people who disagree instead of troubling to formulate their own opinions wouldn’t make the cut, though, nor would people who equate disagreement with a lack of intelligence.

Take this thought about parrots into your office: I sometimes think there aren’t more than a dozen people in this industry who have actual ideas. A new thought ventures into the jungle, gets squawked back and forth, and eventually sounds like a trend. Actually, it’s just one person with chutzpah and a bunch of parrots. You hear the parrots and, mistaking them for authoritative sources, think something important is going on.

Take this thought, too: The glib, simplistic solutions for complex problems you so often hear parroted around rarely work, despite our collective preference for easily understood concepts. Both technology and public policy are complicated. While simplicity may reflect design elegance, below the surface a lot has to happen before anything works.

Take one last thought into your office and keep it there forever: That irritating employee with the cubicle you placed as far away from yours as possible because of how often he disagrees with you … is he really irritating, or are you wrong more often than you think?

Delegation is a difficult skill to master. Many managers confuse it with tossing work over the transom and forgetting about it until the deadline. That’s a weird mistake to make when you think about it, given the absence of transoms, not to mention doors, in the modern workplace.

One way to think about the role of IS in the enterprise is that the business has delegated management of technology to it. Most businesses have tossed the task over our virtual transom and wonder why in their eyes we often botch the job.

When someone uses your transom to delegate to you, your proper response is to insist on meeting to make sure you understand the purpose, scope, and time frame of the task.

That’s why, in our continuing development of an integrated IS plan, we spent so much effort learning about the company’s strategic, tactical, and infrastructure goals. That was our means of understanding the purpose, scope, and time frames associated with our responsibilities.

Now that we know about ’em, what are we going to do about ’em? We’re going to change our architecture to satisfy them, and our starting point is supplying applications that satisfy the company’s requirements for process automation. (No, not databases that satisfy information needs. They come later. It’s the applications, processing information in our databases, that provide business value.)

Your applications suite needs regular review and grooming. Especially, you need to go beyond assessing the current business value provided by each application. What you’re trying to do is determine how well your current mix of applications supports the future state of your business, and what changes you can make to support it better.

You can be as informal or structured as you want in making this determination. Here’s a framework you can use as a starting point.

Begin by identifying key business functions – major activities, like marketing and manufacturing – based on how you expect the company to be structured in the near future. (Don’t be too abstract. If you have multiple business units and each has its own manufacturing operation, count these as separate business functions.)

Next, inventory the application systems you support. That’s right, all of them, not just the ones you think are important. You’ll have to make some arbitrary decisions on what constitutes a “system” – is your enterprise resource planning solution one system, for example, or do you deal with its HR/payroll, manufacturing, and accounting modules separately? Rule of thumb: If you can’t replace it as a unit, it isn’t a system. If you can, it is.

Set up a matrix (you saw that one coming). The columns are your business functions; the rows are your application systems. Put two scores in each cell: (1) How important the application is to the function; and (2) How well the application fulfills its role. If you’ve implemented a GUI shell that shelters end-users from the underlying computing environment, set up two matrices – one that describes the end-user experience, the other that describes the underlying applications environment.

To use the matrix, look at how well your applications support each business function. How well each application fulfills its role has an obvious impact. The number of applications required is also significant—the more applications required (weighted by importance) the less satisfactory. Count each application’s market viability in your assessment of how well it supports a function – you can’t count on orphan products to survive compiler and operating system upgrades, so by definition they don’t support your future business.

The computations you use in your assessment depend on your appetite for mathematics – you can create a formula that takes all factors into account and behaves properly, but it won’t be a simple one.

Compare your computing environment to “perfection”: a single system that supports the entire enterprise and is perfectly adapted to your business requirements. That obviously isn’t achievable, but every step you can take that improves the fit between applications and requirements, reduces the number of applications with which end-users interact, reduces the number of applications you have to support, and minimizes the risk of conversions is a step worth taking.