Of IT’s 18 critical success factors, none sounds more like stifling, choking bureaucracy than governance. Just typing it makes me feel pompous.

Here’s the key to understanding governance: Governing is what you do when management isn’t feasible.

When something is managed, whether it’s a resource, a process, or a restaurant, there’s someone in charge whose responsibilities are matched with corresponding authority.

Someone can make decisions, that is, and whoever they report to has “one throat to choke” if it all goes bad and the higher-level boss is the sort to choke throats instead of fixing problems.

But not every responsibility can be assigned to a single manager who has corresponding authority, for the simple and basic reason that there is no such thing as a perfect organizational chart.

Try it. No matter how you organize a company, you’ll find there are responsibilities that cross boundaries. Change the boundaries so one of those responsibilities now belongs to a single manager and you’ll find you’ve made some other responsibilities cross boundaries instead.

What in IT needs governance

Information technology doesn’t respect organizational boundaries at all, and even if it could, it shouldn’t. A company’s information technology is one of its most important integrating forces. Maybe the most important, because information technology requires consistency to work. (Simple example: it’s how Purchasing and Accounts Payable end up agreeing about who should get paid how much.)

The IT organization itself can, should be, and generally is managed. There’s a person responsible for it — the CIO or equivalent. And within IT, Operations is pretty much a matter of management as well — there’s little about it that requires discussion and compromise among competing stakeholders.

But IT Applications? That’s a messy business. When it comes to setting priorities for application installation, integration and configuration; also for development, maintenance and enhancement, the CIO generally doesn’t and almost always shouldn’t set priorities.

The reason isn’t hard to fathom.

IT’s job, after all, is to support just about every type of change the company’s leaders might envision. Many of these changes won’t respect the company’s organizational boundaries — see Purchasing and Accounts Payable, above. And even those that do won’t entirely respect them, because every hour of effort expended on behalf of one department is an hour that isn’t available to support another one.

So unless the CEO wants to set IT’s priorities personally (a terrible idea for reasons that are, I trust, obvious), the only alternative is governance.

That’s the why of it.

Governance CSFs

IT Governance is a big, messy topic. Balancing top-down strategic priorities with bottom-up high-payoff opportunities? Messy. Balancing what’s most important with what’s most urgent? Messy. And balancing the business benefit of different projects with the political clout of their sponsors? Even messier.

But if companies get just two aspects of IT governance right, they’ve generally reached the exalted state of good enough. These two “critical success factors” (CSFs) are: (1) Never chartering an IT project; and (2) knowing the only two permissible answers to any project proposal.

There are no IT projects

Regular readers of Keep the Joint Running will be tired of reading this, but it bears repeating nonetheless. There are no IT projects, or at least there shouldn’t be. It’s always about business change and improvement.

So “Implement SAP” is a terrible idea, while “Integrate the business (using SAP or some other ERP system as an enabling platform)” is worth evaluating.

Governance should always be about the business change, not the enabling technology.

Permissible answers

Here’s something that’s easy to recommend but hard to do: Stop giving Approved or Rejected as the outcomes of the governance process.

And don’t even think about We’ll think about it, because can’t you just make up your minds? No more information will arrive to inform the decision and all the logic is already there in the proposal and subsequent discussion. Maybe means the company has leaders who can’t lead.

There’s nothing wrong with Rejected as an answer. If a proposal doesn’t make the grade, that is and should be the end of the matter.

It’s Approved that’s the problem, because Approved is just pretending.

Unless a project has been assigned a launch date on a master schedule, complete with a project manager and key staff members with known availability assigned to it, it might be “approved” but it will never actually happen.

So the only two permissible outcomes of the Business Change Governance process are no and when. Anything else is just pretending.

Not pretending makes a pretty good CSF all by itself, don’t you think?