mrprocedure

(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.

I apologize for the delay in following up part 1. As discussed in part 1, I considered how software might be documented as part of the larger project documenting a task (usually related to the operation of equipment). In such an environment, the software used to control the equipment is rightly described as a control.

Now the question becomes: when the software itself is the focus of the document, to what depth do I discuss the software functions? I would assume that, at some point, every function has to be described. I will go out on a limb and figure every feature of a software program is there because some user will need it, and if that user needs it, I (as software describer) had better provide a description of its use, how to access it, etc. In short, make sure that the user even knows it exists.

As a result, my axiom to ensure I describe everything that needs describing threatens to run headlong into my axiom to support the adult learner in acquiring information. As a result, my outline to develop a software guide is going to be structured something like this:

1. Introduction to the software (describe its basic abilities, what it does or can do at a high level; explain why the software even exists)

2. General outline of the features (major screens or menus, their function)

3. More specific discussion of features, in which the features will be connected to the basic and intermediate tasks a user of the software would perform

4. How to perform basic tasks (set up, enter data, review data, save data)

5. How to perform what may be termed intermediate tasks (more advanced than basic)

Sections 2-5 would collectively cover what I would call “Layer 1” of software usage. Assuming the user learns and masters the content of Layer 1, subsequent sets of sections can discuss subsequent layers (the number of layers would depend on the complexity and/or capabilities of the software itself).

As for dissecting individual features, I would attempt to limit my discussion of features, initially at least, to those actually used in the tasks described. But further on, separate from the layered discussion above, I would have as needed detailed discussion of the other functions. Each I would attempt to set up as follows:

     Name of feature

     What the feature allows the user to do

     Access and use of the feature

     Other features associated with this feature

Since a lot of these features would most likely be accessed by an index, I would want the user to see right up front what the feature is intended to do. If the feature does not do what the user is researching to see if the feature does, the user should understand that right away instead of after spending several minutes reading about the feature and playing with it.

Anyhow, that is my take. As I wrote this, I did not have a specific type of software in mind. Again, I have not previously written software descriptions except for cases where the software was part of the equipment’s control system. My thought process is based on the idea that the organization’s needs (what they need done) is the independent variable and the software capability (how the software accomplishes what the organization needs) is the dependent variable, as opposed to the other way around. That is, the organization has task-related needs to have the software they have purchased, and their first priority is getting those tasks accomplished, not learning some cool new software. I may be completely wrong in that assessment; maybe to the software developer, the software is “the thing” and the user is expected to rearrange their operations to fit into what the software supports.

Of course, thinking of my experience with ERP (enterprise resource planning) software, I may be spun 180° around in my thinking. This is where I expect those of you with more experience and understanding to comment back to me. Just be nice about it.

For those of you waiting for my MadCap adventures, I apologize. It’s been a difficult transition but I am working on it and will be writing about it shortly. Meanwhile, I have been involved in a lot of discussions about Quality Systems and related documentation. In the LinkedIn group Technical Writer of Writers, the following question was posed by a member named Oana:

Does the Quality Manual depend on the business field and organization?

I was asked to create a Quality Manual template. After some research I did, my conclusion is that you cannot create a Quality Manual template to be used by businesses operating in different fields. A Quality Manual template is specific to business. I would appreciate your expertise here.

Very good question, Oana! I answered in the group (and can only hope I rose to the level of “expertise” she desired), but I will expand on my discussion here.

If you are concerned about ISO certification, clause 4. 2.2 requires that the organization have a Quality Manual. The Manual must document the scope of the quality management system, the documented procedures established for the quality management system (see clause 4.2.1) and a description of interactions between processes. And that is pretty much the extent of it.

This is really good news for those wanting to develop their quality systems. The lack of rigid structure means organizations can develop a structure that works for them, not for some auditor.

The answer to Oana’s question is yes, the quality system will be specific not just to the type of business, but the individual organization as well. The issue is not so much to develop and define a template, but to study their operation and determine what is done, how it is best done and how it is best controlled, and develop their documentation based on what will enable success for the organization. Designing a “template,” which I presume means a standardized structure, would actually be secondary.

Oana, if you are reading this, first of all thank you for reading it, and second, you will want to get ahold of my Writing Operating Procedures course/book. In Section 4 I discuss task analysis, which is foundational to identifying the documents you need. You or anyone else interested can obtain it, free of charge, by writing me at mrprocedure@gmail.com.

I apologize that I have not had any updates on my MadCap adventure. I will return to that shortly, and I do thank those of you who have chosen to follow or have “liked” Mr. Procedure.

But this is about the free offer I have made before in this space as well as in several groups on LinkedIn. Over the past four or so months, I have been offering my course called Writing Operating Procedures free to anyone who wrote. Those who originally replied received a course-in-preparation (it was about 3/4 complete). I have since completed the course, made it a course/book format (meaning it functions as a stand-alone book as well as for a text for in-person training), and cleaned up a lot of stuff I am embarrassed to have provided the first time. I have distributed slightly over 100 copies of the course, in .pdf format, and have received some very complimentary comments back.

If you have not yet received the course, please write me at mrprocedure@gmail.com, and I will send it along (as a .pdf, I am not in danger of running out). To those of you who have received the course, thank you for your support. And I would love to have any feedback you care to provide. Someone wrote back and assumed I was not interested in comments. I told them that is far from the case! As an offering to the technical writing community, I want to hear what people have to say. This book is one element of a larger set of books related to what I term instructional communication. As more of these come to fruition, I will announce them here.

Thanks for reading, Mr. Procedure