Once you’ve made the sale, management consulting is pretty simple. It works like this:

1. Interview a lot of people. If, like me, your name is Bob, hope the employees haven’t watched Office Space.

2. Ignore everything that works well. If two people complain about the same issue, it’s a problem.

3. If the company is centralized recommend decentralization. And vice versa.

4. Define metrics to track how the problems you identified improve. Don’t establish metrics to track what’s currently working well.

You’ll get results. Two phenomena guarantee it.

The first is that you get what you measure. Once a company establishes a measurement system, employees will move the measures, regardless of the actual impact on the organization.

The second is the Hawthorne Effect — the placebo effect of management change. Just paying attention improves things, regardless of the specifics.

Your job: Take the credit. Your metrics will “prove” improvement. And, in your future promotional efforts, you can use the popular phrase “measurable improvements” in your case studies.

Sure, you might have wrecked what used to work well, but that’s okay. With no metrics to track all the formerly positive attributes, nobody will ever know, or care.

Except, of course, the affected employees, but since everyone knows employees always resist change, you can ignore them.

No, this isn’t true confessions time, and no, my consulting company IT Catalysts doesn’t operate this way. Not that we haven’t recommended centralization or decentralization to support organizational change. We have … when doing so removed barriers to achieving important business goals and didn’t do more harm than good.

Here’s how to decide:

Some companies do a single thing. They sell a single product or service, or a well-focused family of products and services, to a defined industry segment in a single geographic region. Companies like this organize functionally. They are purely centralized.

Most companies are more diversified than this. Some diversify geographically — they open offices in (for example) Chicago, Altoona, and Ypsilanti.

Other companies might not think about customers in geographic terms. Instead they specialize their sales efforts on specific industries.

Or, they might sell both luxury and utility consumer products, to the affluent and middle market, respectively.

Whatever the diversification, it must result in some level of decentralized decision-making and operations. The question of centralization is not whether, but what and how much.

Here’s a handy guideline to help you decide, based on the six parameters of process optimization (overhead cost, unit cost, cycle time, throughput, quality and excellence; see “Six Stupid process controls,” KJR 4/30/2007) for more on this subject).

It’s pretty simple: For low unit costs, high throughput, and quality (adherence to specifications), centralize. For low overhead, short cycle times and excellence (flexibility and richness or customization of function), decentralize.

The question of whether to centralize or decentralize hits CIOs where they live, and the bigger the company, the harder the choice, not least because the executives who run large enterprises are only rarely in consensus on these points.

The CFO will likely prefer centralization, and be willing to invest in infrastructure (higher overhead) in order to gain economies of scale (lower unit costs). The Chief Marketing Officer will prefer it because centralized marketing helps prevent uncontrolled messages to the marketplace that could weaken the brand.

Meanwhile, every business unit head says the same thing: Go ahead and centralize as long as I get what I want, the way I want it, when I want it. Which is ManagementSpeak for “Go ahead and centralize, but the first time I don’t like anything at all I’m going to build my own.”

A CIO’s instincts are usually on the side of centralization — to build infrastructure, gain economies of scale, enforce a consistent and coherent architecture, and in general maintain control of the company’s information technology.

Luckily, being humans, CIOs have brains as well as instincts, which means they can (and should) choose a more nuanced course of action. Nuance in this case means looking at every IT delivery process. For each, decide whether centralization or decentralization makes more overall sense. Then add balance by recognizing special cases that don’t fit.

For example: Overall, centralized applications support might fit the business best — perhaps the company uses a standard ERP suite across all business units. Nonetheless, business intelligence will still be supported best using local analysts reporting directly to the business units.

No problem.

The question of centralization and decentralization is a false dichotomy. As is usually the case with false dichotomies, when the question is whether IT should centralize or decentralize, the proper answer is no.