My Answers from LinkedIn–A Difference Between Policies and Procedures?

(This is the sixth in an occasional series on instructional communication topics.)

I am an ardent viewer of the group discussions in my LinkedIn account. Most of the discussions I don’t follow. Many I follow, quite a few I will comment on, and every now and then a discussion comes that–to borrow terminology from baseball–is thrown right into my wheelhouse.

Anyone who has followed mrprocedure knows I am passionate about procedures doing what they are supposed to do, and policies doing what they are supposed to do, and that what they are supposed to do is different.

So along came a discussion with a title similar to the one above, with the following requests for advice (I have done some editing):

We are in the process of re-engineering our policy and procedure environment and processes and updating our Policy Framework. We purchased How to Write Policies and Procedures from Bizmanualz, Inc and it is a very useful document. The document clearly describes how to create/structure a SOP but not a Policy.

Definition (I am not certain where this definition came from): A policy is a guiding principle used to set direction in an organization. A procedure is a series of steps to be followed as a consistent and repetitive approach to accomplish an end result. Together they are used to empower a process with the direction and consistency necessary for successful process improvement.

Now my question: 

1.  Is a policy document and procedure (SOP) document one and the same thing or is there clearly a difference when writing the content?

2. If different, when should they be separate and when together?

My concern is that we have, over the years, clouded the difference.

I did respond in LinkedIn but promised a more detailed discussion here at mrprocedure.com. First of all, I can live with the definition this individual posted with the discussion. Policies define the expected behavior of the organization, procedures define how work is to be performed. So, if the definition is to be believed and accepted at face value, the answer to question 1 is a resounding NO, policies and procedures are NOT one and the same. And there is clearly a difference when writing the content.

When I write a policy or a procedure, I have to be focused on two things: the subject matter and the audience.

The subject matter of any policy is always related to expected behavior. Think about the various policies in your organization: safety policies, ethics policies, HR policies and the like. What do these policies tell an individual? This is how to behave and in some cases how not to behave (and the potential consequences for not behaving properly). Mission Statements and Quality Policies (as required by ISO) are also, in effect, policies. Some policies are unwritten: I may not have a formal policy that says, “We intend to avoid defects as often as possible,” but it would be a clear expectation of the employee.

The audience for a policy must be understood as well: the audience for an organization’s policies is global. Certainly employees are the most important audience. But applicants, suppliers, customers, regulatory agencies, persons living or operating in proximity to your site, and even potential investors will be legitimately concerned about the organization’s manner of operation, what it believes and how it behaves.

Consequently, policies by their nature should be brief statements, not detailed descriptions of how to do things related to the policy. I don’t want to confuse employees with, for instance how a sexual harrassment investigation will take place, when all they need to know is such behavior will not be tolerated and whom to contact if an issue arises.

Policy Structure

A useful structure to communicate policies is a format similar to the following:

Policy Title

I.      Scope (who is impacted by the policy, in terms of behavior only)

II.    Responsibility (functional group charged with carrying out the policy)

III.   Policy of the Organization (statement of the organization’s expectations)

IV.   Employee Responsibilities (what they are expected to do if an issue related to the policy arises)

V.     Procedure (this is a very generalized, usually bullet-pointed list of actions that are taken in support of policy enforcement; this is not a detailed description of how any activity is carried out)

VI.   Supporting Procedure Documents (procedures developed to carry out the policy expectations; again this is a list).

Remember, I am aiming this information at a global audience. A critical component of the global audience is the new employee that I am orienting to the organization. If I have to introduce the employee to 25 policies, I would rather have 25 two-page policies than 25 15-page policies.

The format I describe above is what I refer to as “Policy Format,” and true to its name, it is an excellent format for policies.

That sounds simple enough, but the original discussion starter lamented the fact that the issue had become clouded. And it has become clouded. In tomorrow’s follow-up, I will discuss how the clouding occurred and how to escape the corners we have inadvertently painted ourselves into.

 

 

Advertisements

About Tim James "Mr. Procedure"

A communicator; all-purpose capability in writing, designing and presenting training for all facets of organizational function. While my focus has been manufacturing, my training/development experience includes supervisory and lead person development, audit processes, continuous improvement and Lean, and Quality Management System implementation.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s