• White Papers |
• Bloggers |
• Video |
• Webcasts |
• Events |
• Solution Centers |
• Newsletters |
• Magazine |
• RSS

How to Set IT Policies the Right Way

Your rules for running IT should derive from the people who have to live with them.

By N. Dean Meyer

November 01, 2007 — CIO — Danny was military, and he makes sure you know it. His colleagues grumble that he acts like he's the commander. Danny likes discipline and controls, especially when he's the one with his hand on those controls.

As assistant to the CIO, Danny was put in charge of policy. He was dubbed the "policy czar." Danny set about violating my Golden Rule of Organizational Design: Never separate accountability from authority. In doing so, he set himself up as a policy decision maker rather than, as he should have been, a policy facilitator.

Who Decides IT Policies?

Policies are constraints on the way we work— a "how to" procedure or "you must" requirement. The dictionary defines policy as a definite course or method of action selected from among alternatives and in light of given conditions to guide and determine present and future decisions.

A policy, once established, narrows one's choices about what to do, how to do it or which alternative to choose. Danny, as you can see from the following exchange, enjoyed his authority to prescribe choices for the rest of his organization.

During a leadership-team meeting that I attended as a consultant, I asked Danny which policies he felt he was responsible for. His answer was, "All." (I was disconcerted that he neglected to add "sir" to the end of his terse reply. I thought that was policy.)

"All?" I asked incredulously.

"All," he replied assertively.

"Even those that apply to a single line of business, like the policy on what gets connected to the network?" I queried.

"Absolutely," Danny answered. He seemed annoyed that I'd had the insolence to ask.

Undaunted, I pressed on. "How do you go about setting policies?" I inquired.

Danny described a process that was essentially this:

1. Danny decides which policy to work on next, setting priorities from among a list of potential policies that he generates, as well as considering requests by others within the department.



2. Danny drafts the policy, perhaps drawing on his peers as subject-matter experts.



3. After a private briefing by Danny, the CIO approves the policy (in some cases with the input of a steering committee representing the business units).



4. Danny enforces compliance.

The Problem With Top-Down Policy-Setting

I looked around the room at Danny's peers, and then asked one final question. "Danny, you said you are responsible for all policies, even those that affect only a single line of business. Who here is accountable for the safe, reliable, efficient operation of the network?"

 

Email

Print

Comments

Share [+]

Digg This

SlashDot

LinkedIn