Well written administrative policies are clear, concise, and respectful to the people they govern. IM/IT policies are no exception.
The written policies of many organizations fall far short of that goal, however. They are overly long, ambiguous or confusing, and written as if angry parents were talking to bad children. It should come as no surprise in those cases that the organization spends an inordinate amount of time dealing with compliance problems.
Remember that the purpose of a written policy is:
1) to outline decisions made by the organization,
2) to set limits for employees and customers, and
3) to serve as the single, authoritative source for a particular decision.
Policies are not training aids or background explanations, nor are they meant to be as an exhaustive compendium of everything people need to know. The proper place for text that teaches, explains, illustrates, or reinforces what people need to know is the guidance documents, such as training manuals, employee handbooks, and other communications pieces.
Here are five things that well written IM/IT policies avoid:
1) Repeating the law
One reason policies are too long is that they contain unnecessary statements. Often a policy will contain a statement such as
“All information is subject to the Freedom of Information Act.”
If legislation exists in your jurisdiction subjecting you to Freedom of Information requirements, then it does so whether or not you include it in your policies. It's no truer or stronger when your policy repeats the statement. If you need to remind your employees of the existence of this rule, the proper place to do that is in the guidance documents.
2) Repeating a fact
The same principle applies to decisions that are made elsewhere, for example, in external standards you adopt. A statement such as
“Twitter has a 280 character limit.”
or
“File names may not contain /, *, or #"
is not a decision your organization made (unless you work at Twitter, Inc. or Microsoft). As with the law, these kinds of statements are no truer or stronger when your policy repeats them. If you need to explain a fact to justify or reinforce a policy decision, again the proper place is in the guidance documents.
3) Using the word “should”
Another reason policies are too long is because they contain information which is essentially advice, rather than a decision.
“Should” is a word policy writers reach for to convey some kind of moral imperative instead of a requirement. Moral imperatives are not appropriate content in a policy instrument. The word “should” is often found in statements like the following:
“Employees should change their passwords every 90 days.”
That statement is meaningless in a rule-based context. Since the action is not mandatory, an employee cannot be disciplined for not following it.
Technically, something that is permitted but not mandatory is “optional,” but the writer didn’t want to use that word here because it sounds too weak. Taken at its strongest, the password-changing statement is but a wishy-washy plea to do the right thing without making it a rule; at its weakest the statement is nothing more than a declaration of a best practice, and best practices belong in guidance documents.
In other words, a well-written policy either expressly mandates a practice, permits it, or prohibits it. What it doesn't do is sit on the fence.
4) Using the portmanteau “and/or”
Clarity in policy writing is primary, and ‘and/or’ is the poster child for unclear meaning. We see it in statements like the following:
“Information can be classified using a File Plan and/or metadata.”
“And/or" self-contradictory. Imagine using the expression ‘with/without’ in the following sentence:
"I’d like my sandwich with/without fries."
If you, the policy writer, can’t decide whether a statement should say “and" or “or," then how can you possibly expect the reader to make the right choice?
Clarity is key. Use “and” to mean both parameters, and “or” to mean at least one parameter. It is clear that you are offering alternatives with the possibility of combination when you use the following format:
“Information can be classified using a File Plan, metadata, or both.”
5) Using words like “absolutely," “never” and “always” to make a statement sound more strict.
Well written policies are not only clear and concise, but they are also respectful to the people they govern. Compare the following policy statements:
“Private photos are not permitted on the shared drive.”
versus
“Private photos are never permitted on the shared drive."
“Private photos are absolutely not permitted on the shared drive.”
“Never put private photos on the shared drive."
From all these statements, we understand that the shared drive may not house private photos. What we learn from the statements in the second group, however, is that management is frustrated with that fact that in the past employees have been breaking this rule. The extra words don't change the substance of the rule; instead, they tell us something about the level of compliance and management’s reaction to that level. If the point of this policy statement is to announce to everybody that management is frustrated, then those extra strict-sounding words do the trick. Most people would agree, however, that the policy is not the place to vent that frustration.
We reach for those strict-sounding words when we want people to know we mean business, but from a policy point of view they are actually somewhat demeaning. This I-am-in-charge-and-you-will-listen-to-me tone of voice is a product of the way we learned to make rules from our parents, who gave us rules when we were children.
But today we’re making rules for adults, and to adults those extra strict-sounding words sound aggressive and overbearing. They sound as if they were spoken by a drill sergeant. You are far more likely to get both employee and customer buy-in to your rules when they are worded respectfully.
Learning to write rules for other adults is a different skill from making rules for children. It's a skill every organization could benefit from when writing their IM/IT policies.
***This article was written by Lewis S Eisen, CIP. Lewis is a trainer and consultant based in Ottawa, Canada, and the author of the text Respectful Policies and Directives: How to Write Rules that People Want to Follow. He can be reached on LinkedIn at https://www.linkedin.com/in/lewiseisen/, or at www.perfectpolicies.org.***