Getting to know the ITS Policy Office: How to make policy

In the fourth post of a Getting to Know series about the ITS Policy Office at UNC-Chapel Hill, IT Policy Facilitator Kim Stahl, who is the entire ITS Policy Office, shares lists that explain how to create policy and the right and wrong ways of making policy.

If you missed the Q&A with Stahl, read the first post of the series. Also, learn the differences between policy, standard and procedure in the second post. In the third post, Stahl shares what she is working on and some interesting policy stats and factoids from the office.

Policies come into existence in three ways

1. Something bad happens, people want to prevent it from happening again, and policy seems like a way to take a stand or to make it clear what behavior is acceptable and what is not.
2. There’s a structure, a regulation, a framework or another external requirement that tells us to have a policy. Policies are evidence of organizational maturity and the presence of guidance toward right action. These external requirements tell us to prioritize certain values or actions.
3. People are behaving differently trying to do the same things. It creates challenges, inefficiency, frustration, obstacles. People are trying to do right, but it’s unclear what actions are right or what the organization’s expectations are.

How do we get policies right?

Finding the stakeholder groups (Every policy is different.)

Reducing draft iterations without losing collaboration

Being consistent and trustworthy (no surprises, gotchas or lack of transparency)

Remembering the goals (There must be a REASON behind every document.)

How do you know when a policy is right?

It doesn’t change much.

It is not that hard to change when it’s needed.

People ask for interpretation and they’re usually right before they ask.

Even if people don’t love it, they understand why it’s there and at least grudgingly agree it’s needed.

The things that are important to everyone affected are included.

It’s easier WITH the document than WITHOUT it.

How to get policies wrong

Standardize too much. (UNC-Chapel Hill is a leader, and what works for others may not work for us.)

Write everything into a policy. (There are a lot of other types of documents; they’re all useful!)

Articulate infinitesimal details with explicit and verbose language, far beyond what is required for common understanding, and above all, be redundant.

No exceptions. (If it’s so clear that no exceptions are needed, it’s probably also true that no policy is needed because it’s common sense.)

Make it unreadable. Formality doesn’t make a policy work better. If you read it out loud and it sounds as if you’re explaining the policy to another person, it’s probably well-written. If it sounds like a boilerplate contract, start over. If people can’t understand or interpret it, it’s a failure.

If they are unrealistic, the policies will fail. When a policy can’t be followed as it’s written and no means of granting exceptions exists, people will simply dismiss the policy.

What are the biggest mistakes to avoid?

Writing policies in a vacuum

Using a template or “best practice” guide as-is

Running drafts only by people in the same functional area

Using review and approval processes that deter collaboration