How to Set IT Policies the Right Way

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.

RELATED LINKS

Rules for Mobile Devices

Who Should Set ID Management Policies

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?”

Without hesitation, Danny pointed to Rob, the head of the network operations group.

And now we see the crux of the problem: How can Rob be held accountable for the quality of service of his network, while Danny is deciding policies that dictate how Rob does business?

This is a violation of that Golden Rule. Rob, with accountability but without concomitant authority, wasn’t empowered to run his business his way; yet he was still held accountable for results. A cynic might say that he was set up to become a victim and a scapegoat.

On the other hand, even if Danny accepted Rob’s input on the policy, Danny’s power to write the policy (and his de facto power to get it approved) gave him authority over Rob’s business. With authority but no accountability, Danny could easily become a tyrant. His peers feared exactly this.

Compounding this problem, the managers didn’t have the authority to establish the policies they needed to run their businesses. Danny became a bottleneck; he could work on only a few policies at a time, and he chose his priorities. Whatever he didn’t think was important enough sat at the bottom of the list.

For example, Allie is responsible for intranet services. Her clients have asked for an enterprise instant messaging service, but she has delayed deployment for two years, awaiting a policy regarding its use. Her proposed policy is still in the hopper awaiting Danny’s consideration.

The need for policies was not in question. This IT department had grown in size and complexity, and it needed to mature. It needed to improve its consistency, safety, reliability, efficiency, resource controls and business focus. Policies were necessary to facilitate all these goals. But the way Danny implemented them demoralized the staff and threatened the performance of the entire IT organization.

Ways Policy-Setting Can Be Distributed

The IT organization’s problem centers on who has the power to decide policy. If Rob is to be held accountable for the quality of service of his network, then Rob—and only Rob— should be empowered to determine policies on its operation and its use.

In general, according to the Golden Rule, policies should be determined by the individual or team that is accountable for whatever business is constrained by these policies.

For example, some policies apply to the entire enterprise. Think about security policies for passwords, and the rules for using the corporate intranet. Policies that affect the entire enterprise should be decided by a consensus of the leaders of the enterprise. As difficult as that may be to achieve, it’s the only way to ensure that the policy reflects everybody’s input and is by far the best means of gaining enterprisewide compliance.

Other policies apply to the IT department. A policy for getting IT to work on your projects might state that if you wish to do business with IT, your project must either be funded through an established portfolio-management process or you must show up with cash in hand. Such policies affecting one department should be decided by the head of the department, ideally with the consensus of his or her leadership team.

A third group of policies applies to a specific line of business within a department. For example, the network operations group may establish a policy that says that if you don’t meet certain safety requirements, you cannot connect to the backbone network inside the corporate firewall. One could even use the word policy to describe the operating procedures within a group, such as how problems are handled in a call center and which design tools and methods are used to engineer applications.

Policies that affect a single group (such as network operations) should be decided by the leader of that group. Policies that affect a number of groups within a department, though not the whole department, should be decided by a consensus of the leaders of those affected groups.

The Role of a Policy Group

Is there any circumstance in which Danny’s approach might work? Consider those policies that are departmentwide and hence should be decided by the CIO and, ideally, her leadership team.

Even here, Danny had it upside down. He declared himself the “prime contractor” for policy development and considered the subject-matter experts his “subcontractors.” That is, Danny felt that he was accountable for the delivery of policies, and others were there to help him do so. Danny was selling other people’s expertise (in the form of the content of policies).

However, the purpose of a policy group is to help others translate their expertise into policies, not to do it for them (or to them). An effective policy group “sells” the following products and services to its peers:

Policy process facilitation. A policy group can help an organization’s leadership team accumulate, prioritize and come to consensus on departmentwide policies, and it can facilitate enterprisewide consensus on enterprise policies. In this role, the policy group is strictly a process facilitator, not an author, decision maker or “czar.”

Policy editing and advice. It can help subject-matter experts craft well-worded policies, providing expertise in how to define and phrase an effective policy. This expertise can help everyone write policies that are practical and effective without being bureaucratic, inflexible, disempowering or expensive to administer.

Policy library. It can maintain a repository of policies, communicate their availability, and help people access and interpret existing policies.

A policy group should not be responsible for the content of the policies or have any authority over that content. And it must never be involved in auditing compliance. This would be a conflict of interest. No one can both serve others (policy facilitation) and stand in judgment of others (audit) without undermining the teamwork between the policy group and its peers.

Why All This Work Is Necessary

Policies are inherently risky. They reduce people’s choices and can make an organization less flexible, more bureaucratic and less creative.

But in many cases, policies are necessary. A well-chosen and well-written policy does more good than harm by establishing a consistent, meticulous process or necessary constraints that help leaders run an efficient, customer-focused, safe and reliable business.

The key to an effective approach is to make all parties accountable for policies within their respective businesses and to provide them with the help of a policy facilitation function (not a “czar”) that serves its peers rather than attempting to control them.

You can read a version of this article on consultant N. Dean Meyer’s website with links to other Beneath the Buzz columns, relevant white papers, books and other resources. Contact him at dean@ndma.com.