All Posts in Policies and Procedures

|In: Organizational Effectiveness|Last Updated:

My list of 18 IT critical success factors (CSFs) … the one we’ve been slogging through for the past few weeks and will continue to slog through for the next several weeks … is a terrible list.

It’s terrible because it violates the sacred law of seven plus or minus two.

It’s too long, that is. In principle I should either winnow it down or aggregate some of the factors into broader ones.

I didn’t aggregate because the aggregations would have also included other factors that didn’t make the top 18. I didn’t winnow it down more because I couldn’t — I’m pretty sure that if an IT organization doesn’t get all 18 right, it’s going to find itself in trouble, and it’s going to find itself there sooner rather than later.

My 18 CSFs aren’t exciting or “strategic.” They often range from irritating to downright boring. That makes them no less important. Take this week’s pair: change control and policy-driven information security and compliance.

They’re zzz-inducing, and that’s a good thing because boring is what you want. The alternative is the sort of excitement IT professionals would generally rather avoid.

Change control

ITIL calls this “change management.” I prefer “change control” because it’s less likely to be confused with “business change management,” an entirely different discipline.

Yes, they’re analogous, but analogy isn’t identity. Business change management covers what a company can do to minimize the social disruption that’s likely to occur from changes in how it conducts business. Change control is what IT can do to minimize the chance that a change in technology might disrupt IT operations.

It’s boring. It’s bureaucratic. It’s a set of flaming hoops developers have to jump through to put their new releases into production.

Change control is the discipline that helps IT operations score high in its key metric: the Invisibility Index.

If that isn’t the key metric for your IT operations group, stop reading right now and make it the key metric, because it is the key metric whether you measure it or not.

IT operations is one of those areas that only gets noticed when something goes wrong. Its highest aspiration is for that to never happen.

Every change is a threat to systems stability, which is why controlling those changes is so very important.

Policy-driven information security and other areas of compliance

This is actually a grammatical redundancy, but don’t worry about it. It’s like this: Information security is either driven by a business policy that establishes the company’s risk profile, or else your InfoSec function will have little choice but to do everything possible to prevent anyone from getting anything done.

The same is true of every other compliance topic you have to deal with. The only difference: With the exception of information security, most compliance areas start with formal policies as a matter of habit. With information security, in contrast, having a business policy to start with seems to be the exception.

If you’re in the healthcare industry, you have HIPAA. It’s a formal policy, mandated by the federal government. The policy guides what everyone has to do, inside and outside IT.

If you’re a retailer, the credit card companies have established PCI. It’s a policy designed to protect credit-card data from identity thieves. The policy guides what everyone has to do, inside and outside IT.

There’s no equivalent official, mandated approach to information security to guide what everyone has to do, inside IT and elsewhere besides. And so, companies have two choices. They can either write their own policy (a very good idea), or they can penalize InfoSec whenever there’s any form of intrusion.

That’s a very bad idea, because if InfoSec is going to be punished whenever there’s an intrusion, it will:

  • Establish thirty-seven concentric internal firewall perimeters.
  • Assign separate passwords for each application everyone uses, each of which will consist of a minimum of 33 randomly-generated characters.
  • Lock down every desktop and laptop computer so they can’t do anything at all beyond running a VDI client.
  • Disable every USB port on every PC and laptop so no one can move data from one PC to another.
  • Disable the email system’s ability to attach files to messages.

Got the picture? InfoSec will have no alternative. With no written policy that establishes the company’s preferred risk posture, all InfoSec will have is the unwritten one: “Any intrusion or data loss is unacceptable.”

And as any time two people exchange information there’s a risk, all communication, right down to hallway conversations, must be forbidden.

It’s our policy.

Comments

|In: Leadership|Last Updated:

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?

Comments