Policy Author/Sponsor

The name of the individual, or in some cases, group, that sponsors or develops a policy should be included on the policy document. Any questions of interpretation, minor wording changes, or clarifications can best be communicated directly to the author or sponsor, thus relieving the organization of the formal process for amending or replacing a policy after initial approval has been given.

Reference to Other Policies and Regulations

Often, policies are related to other policies that already exist or are being developed concurrently. Because changes to these referring policies may affect related policies, this reference makes maintenance of the policy structure easier to administer and more responsive to normal changes.

Measurement Expectations

Conforming to policies is not always followed with a “Yes” or “No” answer. Sometimes policies can be followed in degrees. For example: a policy states that “All departments with over 100 employees must have two named security officers.” If a department has 80 full-time employees and 25 half-time employees, should they be counted as over or under the 100? In this instance, a clarifying statement can be added as a measurement expectation that describes what constitutes an employee: actual head count or full-time equivalent. It should also clarify whether the security officer must be a full-time or a part-time employee.

Even if adherence with policy is a binary state, whether the answer is “yes” can be somewhat judgmental. It is best to avoid wording that leads to judgment calls, but sometimes these issues are unavoidable. Consider a policy that states that each employee with over 10 years of experience must register as a “key employee.” If employees complete an established “key employee” registration form, but complete it incorrectly, are they registered in actuality? Again, a measurement of what constitutes a legitimately registered key employee should be included in the policy.

In general, conditions that serve to clarify the policy but would make the wording overly complicated or long-winded can be included in this item of the document.

Process for Requesting Exception

Just as important as stating the policy, is stating the process for which exceptions can be requested. If no exceptions are possible, this should be so stated. It is important not to describe the conditions under which exceptions are granted, only the process. Being too explicit in defining the acceptable exclusions will lead to receiving an abundance of similarly worded exception requests, many with a marginal basis for authorizing the exception.

Process for Requesting Change of Policy

Very few policies stay unchanged forever. Successful policies have a built-in procedure for spawning their successors. In some instances the change may only require a technical review — in others, a full justification may need to be presented including a process for retrofitting old methods, grandfathering previously approved processes, or revalidating and reinforming the intended audience. Either end of the spectrum or any point in between is likely and acceptable, so long as it is stated in the original policy itself.

Action Upon Violation(s)

The only action item that should not be included in this part of the document is “None.” A policy with no action upon violation should not be made a policy. It should rather be part of a suggested procedure or advisory comment. At the very least, action upon violation should be an acknowledgment by the violator’s supervisor that the policy has not been followed. From there, repeated violation may result in either employee job performance action or in a change of policy to make it more in line with the apparent procedures that work best.

This item should not restrict the organization’s capacity to act, especially if the policy is regulatory in nature. A policy that is written to require compliance must show penalty if violated. Failure to do so may result in the organization being held responsible for the violator’s actions by virtue of nonenforcement. It is advisable in appropriate situations that the policy state something to the effect of: “...violation may result in termination of employment and/or legal action.”

Effective Date

All policies should be given a date for which they will be effective. This should not be earlier than the release date of the policy, but prior events can be included as a Measurement Expectation or actually stated in the Policy Statement itself.

Sunset or Review Date

Finally, every policy should be subject to an expiration date, or at least a reconfirmation date. Including this date in the policy statement assures that the document will be given a periodic review. In that way, old policies can be updated, obsolete policies cleared out, and new requirements smoothly blended into a living document more likely to be held in high regard by the intended audience.

POLICY WRITING TECHNIQUES

Writing a policy is like writing legislation. Very few people have the knack for it right away, but with some experience and guidance, nearly everyone can start writing policies and, in time, become fairly proficient at turning out a document that is easy to understand and holds substantive weight in the organization. The following are a few tips to jump-starting your policy writing methods. With practice, the concepts will become second nature and will literally flow into each policy statement.

Jargon-Free, Simple Language

Often, computer policies are written by computer people. This presents the common complaint that only computer people can understand them. This condition is not really an industry issue. For years, the public has been aggressively trying to remove legal jargon from general laws, insurance jargon from insurance policies, and other technical jargon from documents that should be read by nontechnical people. Any organization’s policy statements should be written to follow the same guidelines. Technical terms, especially acronyms and abbreviations, should be avoided if possible, and if their use is absolutely necessary they should be defined as an additional part of the policy statement. The language should be written in the subjective form with as much general conversational language as feasible. For example, the policy worded: “Before using a new diskette, it must be formatted” is easier for a nontechnical person to understand than “The execution of a DOS FORMAT is required prior to the initial use of a DSHD diskette.”