Long-time readers of this column might imagine I don’t like business metrics. But if you imagine that, you’re wrong. It’s true that my columns on the subject are more cautionary than laudatory. But I love good business metrics, and treasure the rare occasions on which I encounter them.

Most business metrics I run across are either shallow or absent entirely. Mostly, managers adopt industry standard metrics. But it’s okay, because companies are adopting industry-standard business processes as well in their ongoing attempts to become generic.

Last week’s column was an attempt to point the way toward one important goal of a well-designed system of business metrics — the establishment of an organizational dashboard. The critical point, you’ll remember, is to start by defining a conceptual hierarchy of performance goals and sub-goals for the organization as a whole, pointed at the factors required for achieving organizational effectiveness. Metrics are crafted to assess how well you’re progressing toward your goals, not to roll-up from individual performance to workgroup, workgroup to department, and so on.

And especially, the metrics must not be divided according to the organizational chart so as to Hold People Accountable (HPA). When you build a dashboard of key organizational performance metrics, do the opposite: Construct them so as to make the organization’s leaders interdependent. Otherwise, leaders will make their numbers at each others’ expense, the organization will fragment into silos, and nobody will understand why the system collapsed, because all of the metrics looked good.

Still, the absence of HPA leads to its own problems, and without reasonably accurate ways to assess individual and group performance, HPA is an exercise in authoritarian futility: You declare the quality of performance with nothing to back it up; those reporting to you accept your authority to do so without accepting your assessment if it disagrees with their own.

The resolution to this apparent paradox, to the extent it’s resolvable, starts with the recognition that there are two separate, equally valid but entirely different views of the organization. One — the dashboard view — dissects the organization into the factors that drive performance. These cross all boundaries, which is why the organization’s leaders are interdependent when dealing with them.

The other view is functional, divvying up responsibility for who delivers what. It’s the orgchart view — the perspective that leads to HPA.

The organizational chart is a form of delegation. Done right it assigns responsibility and commensurate authority. Doing so without creating organizational silos is one of the most difficult tasks faced by business leaders. Dividing the work of the organization into defined responsibilities and delegating them to various managers so everyone knows who is supposed to do what is, after all, the only known alternative to organizational chaos. Once you do, your managers should establish clear internal organizational goals and metrics of their own, for the same reason you need to do so for the organization as a whole — to understand the health of their organizations.

You can’t entirely avoid the creation of organizational silos, because it is the purpose of the exercise. To illustrate the issue, imagine you have the simplest organizational chart in the IT world — Applications and Operations, and nothing else.

They’re natural enemies. The fastest and most efficient way to code, after all, is sloppily. But this drives up the cost of building and managing the IT infrastructure while increasing the likelihood of system crashes. Meanwhile, the easiest way to maintain stability and performance is to never upgrade or change anything.

Beyond holding managers collectively accountable for dashboard results, you have one more tool at your disposal: remembering the point of it all — in a word, the mission (which is distinct from, and usually independent of the dreaded Mission Statement).

The performance goals, dashboards, organizational chart and all the rest are tools, recognizing that with few exceptions the most effective way to fulfill any mission is to build a high-performance organization capable of its fulfillment.

But in the end it’s the mission — the goal — that’s the point. To avoid the creation of barriers between functional areas of your IT organization, keep the point in front of all managers, always. And establish, clearly, that making the numbers at the expense of the point isn’t making the numbers at all.

It’s inverting means and ends.

It appears my column about avoiding ambiguity calls for a correction and a clarification.

The correction: As Joris Linnsen, writing from the Netherlands, reminds us, “If you don’t know where you are going, any road will take you there,” appeared in Alice in Wonderland long before George Harrison wrote it into a song. I should have given the Cheshire Cat proper credit.

The clarification: Some readers thought I took an unfair shot at General Eisenhower when I said, “Yes, Eisenhower said plans are useless, but planning is indispensable.” And if you can figure out how to plan without creating a plan, go for it. I recommend a different formulation: Plan the work and work the plan.”

I had no such intention. While Eisenhower’s performance as president is debatable (which is to say, many have debated it), that he was a phenomenal general is beyond any reasonable dispute.

Eisenhower’s point was that events make plans obsolete. Bad military leaders stick to the plan anyway. The good ones use it as a platform for ongoing adaptation. My point was similar: Plan, then continually adapt your plans as circumstances change and new issues, opportunities and facts become available.

Which brings us, through logic so tortured I won’t bother presenting it, to Apple Computer and its debatable decision (which is to say, many have debated it, too) to base future systems on Intel chips. But unlike the subject of Eisenhower’s presidential performance, on which I have no opinion worth sharing, I have plenty to say about this subject.

Well, actually, I don’t. Mostly, the words, “Who cares?” came to mind when Steve Jobs announced the MacIntel, and the clamorous debate that followed hasn’t changed that reaction.

If you’re a CIO or are otherwise responsible for planning your company’s IT architecture, I suggest you adopt a similar stance. Apple isn’t, after all, planning to sell OS X on generic PC boxes. It’s merely replacing the PowerPC chip with Intel chips in its proprietary ones. So the MacIntel will sell for the same premium prices Macintoshes do. And the idea of running MacIntel computers instead of Windows machines brings with it these exciting scenarios:

  • Move all the Windows client software needed by your enterprise applications onto Citrix servers and deploy a Citrix client on your new Macintoshes.
  • Run Virtual PC for all your Windows client software, still deploying Citrix servers and clients for the odd applications that stubbornly refuse to run on it.
  • Replace every enterprise application that requires anything Windows, experiencing colossal conversion costs along with the loss of your job for showing equally colossal poor judgment.

In our consulting business, we advise clients to evaluate technical solutions in four dimensions: technology, features and functionality, market viability, and vendor desirability. To help you ignore the noise, here’s how the Mac stacks up:

Technology: Superior to every other desktop alternative. MacIntel’s architecture, construction, and security will beat both Windows and the entire bewildering array of Linux distributions because of OS X. MacIntel hardware will be comparable to Wintel; in any event they won’t differ enough to matter to anyone other than industry wonks, who think hardware comparisons make fascinating reading.

Features and functionality: OS X has everything a desktop OS needs at the moment. MacIntels will be fully administrable, and will integrate with directory services and access server file systems just fine. When evaluating MacIntel, though, you have to include the question of compatibility with your whole installed base of software. For most enterprises, MacIntel, as Macintosh before it, rates better than Linux but worse than Wintel. Your mileage, of course, may vary, and MacIntel may also rate very well for some corporate niches, such as marketing and media production. Where it does, Macintosh rated just as well, of course.

Market viability: Macintosh is a niche player — Linux appears to have surpassed it; the two together claim perhaps 6% of the total market. Market viability matters — for staffing, and for assessing the extent to which developers will support the platform in the future. MacIntel inherits Macintosh’s marketshare and does nothing to change it.

Vendor desirability: Apple provides little support for enterprise IT, and is legendary for its shabby treatment of distributors and early adopters. Add to that the Mac’s premium pricing and MacIntel is a clear loser when considered from this perspective.

The short version: The Macintosh has always offered terrific technology, and has never had anything else going for it. MacIntel offers the same terrific technology and lack of anything else, running on a new chip.

Big deal.