After Hours

10 things to consider when creating policies

Policies can help keep an organization running smoothly -- but only if they're clearly defined, carefully written, and have a legitimate purpose.

I hate inconsistent and inconsistently applied policies. They create conditions that are inherently unfair and can often lead to more problems on top of the ones they were designed to solve. Policies that are thrown together in immediate response to someone being annoyed aren't always the most well-considered texts, either, and they also tend to lead to problems down the line. However, policies are a necessary part of any organization. They define the parameters around which the organization operates and influence the behavior of people to a particular outcome.

In this article, I'll provide 10 items you should keep in mind as you work on new policies for your organization.

1: Ensure that there is a policy on policies

It sounds a little redundant, but it's important to work within a predefined and agreed upon framework even when it comes to policy formation. Creating a simple policy on policies that defines the organization's process for creating new policies is an important first step in maturing policies. This "meta policy" should include guidance as to what situations constitute the need for a new policy, the format that new policies should use, and the process that needs to be followed for a new policy to be approved. If you don't have a process and framework around policy formation, you risk having significant inconsistency in the outcomes and inconsistency in the creation, which can lead to poor or difficult enforcement.

2: Identify any overlap with existing policies

This one is simple. Before you create a new policy, check to see if the policy you're planning to create already exists or if portions of it exist in other policies. If so, consider revising existing policies rather than creating a brand new one.

3: Don't develop the policy in a vacuum

I've seen individuals sit behind their desks and create policies that they felt were necessary and that were developed wholly on their own. Most often, this has happened in organizations lacking any kind of policy governance structure. In most cases, the policies lacked key factors and were slanted in ways that were not positive for the organization. As you might expect, the policies did good things for the person developing them, though.

I'm of the opinion that policies need to be developed with input from those that will be affected by them. While the final policy may ultimately not reflect all opinions, it's important that all stakeholders be heard to minimize the potential for unintended consequences. Further, policies need to be complete and additional opinions can help close any gaps that may exist.

4: Step back and consider the need

Are you creating a policy because one is needed or because someone did something you didn't like? There is a big difference and, again, I have seen policies put into place out of spite and as retribution. Obviously, that kind of activity wouldn't happen in a reasonable organization. But it also won't happen in one that has a strict policy on policies, as the policy will generally go through multiple levels for approval and somewhere along the way, someone will step back and ask the question, "Why do we need this?"

Policies should be enacted when there is a clear need and a clear problem to solve.

5: Use the right words so there is no misunderstanding intent

Policies must be understood to be effective. Use of clear and unambiguous grammar aids in this effort. Use simple and specific terminology that can be easily understood by everyone. Use the words "must" or "will" rather than "should" in the body of the policy. The later implies that the action is optional, which makes the need for the policy questionable. If something is optional, use the word "should" -- but not when it's a requirement.

Always use an office, department, unit, or job title instead of an individual's name. Examples: "The CIO's office is responsible for..."; "Contact the assistant to the CFO to..."

Contact emails should always be general department addresses or a Web page that gives further contact information. Avoid using individual email addresses to prevent the policy from needing updates when personnel changes occur.

Do not underline subheadings or words that need to be stressed in a sentence. Rather, set subheadings in bold or italics if a word needs to be stressed. Underlined words can be mistaken for hyperlinks when the policy is posted online.

6: When possible, include an exceptions process

For every rule, there is an exception... at least in most cases. It's much easier to define in advance how an exceptions process is to operate before the policy goes into force. Before you say, "I will never allow exceptions," think again. At some point, a situation will arise that requires an exception. Since policies are implemented to control behavior and are supposed to level the playing field, it's critical that exceptions also be granted in a way that is fair and equitable. If you play loose with the exceptions process, the entire policy could be called into question.

7: Allow some shades of gray

So you've created an absolutely airtight policy and defined an exceptions process that no one can question. That's a good goal, but it's tough to get there for every policy. This is the point that might get the most criticism since policies are supposed to create equitable conditions. But I believe that some policies need to leave a little ambiguity for people to make decisions. That's not to say that the policy should just let people do whatever they want, but it seems that there are simply too many instances in which people are allowed to use "that's policy" or "zero tolerance" excuses to avoid doing the right thing. If your policy leaves a little bit a gray so that a person can make an on-the-fly decision, that's okay.

8: Define policy maintenance responsibility

Most policies require periodic review to ensure their continued applicability. Further, as questions are raised about the policy, someone needs to be able to provide clarifying information. Make sure that you always identify the office -- not the individual person -- that is responsible for the policy. You don't identify individuals since they come and go.

9: Keep senior executives out of the routine when possible

I mentioned the need to identify an exceptions process for policies when that's possible. In one organization I worked for, that automatically fell to the CEO. Frankly, that was a waste of his time. The exceptions process that is put into place should empower someone within the organization to handle exceptions. The identified person does not need to be a VP or the CEO, except when it's required due to regulation or law. Further, don't expect senior executives to develop every policy. That said, the senior team should hold responsibility for reviewing new policies before they go into production.

10: Establish a policy library with versioning

There are all kinds of tools out there these days, such as SharePoint, that enable you to store versions of documents. Every employee should be able to access all appropriate policies all the time. If employees can't get access to policies, how can they be expected to follow them? When it comes to versioning, as policies evolve, it's good to see their history to track what has changed over time.

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

2 comments
srl_l
srl_l

We've got some less successful policies lately. If they'd read this article, I think we would have been far better off. I'm going to link to this article in our intranet.

Editor's Picks