mrprocedure

Developing customer manuals–my new career stop–is a new experience for me, but in reality it is no different than what I did for so many years in the advanced materials world. I wrote operating procedures for processing equipment my organizations used to make materials. I knew the intent of the procedures I wrote: to enable workers to successfully operate equipment. It is this experience that informed my approach to operator manuals.

And this is where I found myself, as noted in the last post, asking, “what is it our organization is trying to accomplish through operations manual development?”

If the intent is to crank out manuals simply because customers of multi-million dollar capital equipment expect manuals, it really doesn’t matter what the manual contains. But if the manual is intended to make our customers competent users of the system, achieving the production end for which the system was purchased, then the structure, flow and most importantly content of the manual must reflect its purpose.

As a result, the manuals must facilitate learning. In essence, the system could be considered a “department,” and the manual is part of that department’s training program.

In the next post, I will discuss how the manual is structured to make the”department” function.

I have been terribly negligent in maintaining this blog. But now that I am linking with LinkedIn, and a frequent visitor to the “Technical Writer in Action” group, I shall endeavor to make more frequent stops. Thank you for your patience and I look forward to any comments!

For the first time in my life, I actually possess the title “Technical Writer.” My principal job duty is developing the operations manuals for laser and lithography systems sold by my present employer.

My whole career has been built on writing. As a trainer, I wrote the procedures and work instructions on which operational training was based. The larger courses were always accompanied by elaborate work books. My writing enabled my training career, which in turn enabled more writing.

Now, writing operational manuals for my current organization, I approached the job with one question: why are we even producing manuals? Was it just because customers expect manuals to accompany multi-million dollar pieces of capital equipment? I came to the conclusion that, in fact, I had not left the training profession, but in fact was developing our customers’ training program (at least as it concerned their use of our product).

The impact of that conclsuion on the development and evolution of manuals has been significant. In fact, it has led to products in addition to manuals.

In my next post, I will explore how treating manuals as training programs has affected my approach to manual development and the products our customers receive. My responsibilities have grown beyond the traditional boundaries of the “technical writer” position, and I wouldn’t have it any other way.

OK, I go to Hawaii for two weeks in July, and immediately after I began my new paying gig, which entails developing manuals for very sophisticated industrial equipment (I am bound by an NDA so I’ll play it safe and not say any more). And before I can recover from my good fortune, 2 1/2 months pass without a post. I will do better, I promise.

My new gig has been a wonderful experience so far and has expanded my sphere of communication development to include the “operation manual,” in which I describe my company’s equipment  for the benefit of our customers. The commonality between the operation manual and operating procedures I will explore in future posts. Let’s just say my eight or so weeks in the new role has taught me many things and confirmed many others.

Now, back to the glory of procedures!

In the last post, we focused on the reason for an operating procedure to exist. And it boiled down to two purposes:

To tell the learner everything they need to learn

To tell the teacher everything they need to teach

If these are truly the basic purposes of procedures, then it follows that the structure and content of the procedures be able to achieve the purpose.

We will talk about structure shortly, but let’s first focus on content. The content of a procedure should include:

All information necessary to perform the essential activities, and no more!

While that makes sense, it begs the question…how do I know what information belongs? That is sadly a question not so many people ask when confronted with writing a procedure, and the resulting procedure too often bears witness to the lack of forethought.

In my next post, we will talk more about content, and how content is also the basis of structure. Until then, happy writing!

Why does (or should) an operating procedure exist? The one and only reason I have identified is to facilitate learning of an activity.

Consider the following scenario: Joe is a new worker, and he is paired with Sheila, an experienced worker, to learn how to perform tasks in the department. Sheila has no document to work from, but has a lot of knowledge and is an excellent worker. So Sheila starts to “train” Joe. But what is she training Joe to do? Ideally, how to correctly do any and all of the tasks Joe will perform. But to what standard? As close as I can figure, to whatever standard Sheila has established for herself.

What if Sheila does not teach Joe everything? Then what? The reality in such a scenario is that Joe is completely at Sheila’s mercy in learning the job. If you have ever been in a situation where someone is training you, and they said, “Oops, I forgot to tell you this,” you should understand. What else did they forget to tell you?

The operating procedure, then, contains all of the content sufficient to transfer knowledge of task performance:

     It should contain everything the learner needs to learn

     It should contain everything the teacher needs to teach 

In essence, you can look at the procedure as a contract between the organization, trainer and trainee: it represents the organization’s assessment of the one current-state best way to perform the procedure. If the trainer has addressed all aspects covered in the procedure, he or she has done their job. If the trainee has learned all aspects covered in the procedure, he or she can be considered “trained” and equipped to perform the required tasks.

(Note: this is not to suggest that a task can be learned solely by reviewing the operating procedure. In my Seven-step Method to task training, the procedure is part of the process (a big part!) but not the whole process.)

An operating procedure is by its nature a training document. As such, it must fulfill its training intent. This is accomplished by the content and structure of the operating procedure. Simply put, any information not directly connected to performing the task should not be in an operating procedure. And identifying who is responsible to perform the procedure is not connected to successful task performance. Put that information back in the policy, where it belongs.

The emphasis on a procedure should be how an activity is performed. Period. This assertion is based on years of procedure-writing experience and wrestling with why a procedure exists and what an organization desires to gain from a procedure.

In over a quarter-century of writing, I have come up with one and only one valid reason for an operating procedure to exist: to convey knowledge of an activity to the person who needs to learn it.  

Operating Procedure audience: the audience for an operating procedure consists of two primary groups: those learning to perform the activity and those teaching others how to perform the activity. This may seem like a shockingly limited audience, but in light of that one legitimate purpose for the procedure, that pretty much captures everyone.

Now, of course, auditors look at procedures (even policies masquerading as procedures). And many of you work in environments where customers like evidence that your organization has documented processes. I am happy that auditors and others may also look at the operating procedures, but operating procedures do not exist for them.

That last point is very critical, even if it seems obvious. The true audience of a procedure must determine the content of the procedure. In the early days of ISO-9000, a disturbing trend took place, in which organizations pared down the content of their procedures to make them “audit-friendly.” In making them audit-friendly, the procedures ceased to perform their original function. The irony is that, in trying to make procedures sufficiently bare-boned that auditors could not identify missteps and record them as findings, organizations subverted the intent of  a Quality Management System altogether, as if the principal aim of an audit is to avoid findings. I refer to that as “ISO schizophrenia.”

In the next post, we will look further at operating procedures in the context of their purpose.

In the last post, I presented the following “procedure:”

 1. The receiving department receives the raw materials, checks for accuracy and then places the materials on shelves to be available for production.

2. The production clerk receives the work order, identifies and pulls the raw material for the order, and tags it for delivery to the assembly area.

3. The warehouse operator pulls the work order, gathers the raw material for the order into a tote box, checks the material against the order to ensure all materials are present, and delivers the materials to the assembly area.

4. The assembly area supervisor receives the order, and distributes materials to the assemblers based on the assembly work they will perform.

5. The assembly workers put together the finished units from the materials, and place them in a bin to go to the testing area.

6. The assembly supervisor delivers the bin of finished units to the testing area.

7. The test technicians perform quality assurance testing on the units, and place the acceptable units in a bin for delivery to the packaging and shipping area.

8. The packers place the units in boxes, with all necessary instructions and other paperwork.

9. The shippers place the boxed units on a pallet, and prepare the pallet for shipment to the customer.

And I made the assertion this is not a procedure, even though countless organizations have stacks of such documents like the one above, labeled as procedures and audited as such.

The Missing Element

While the “procedure” describes who does what, and when it is done (at least relative to another activity) it lacks the most important–and in this writer’s opinion, the only truly procedural–information: the “how.”

An operating procedure, as the second level (Tier 2) of the documentation pyramid (click to view again)  really should only describe how things are done. The “what” of the organization’s activities identify what needs to be described, and the operating procedure tells how each “what” is performed.

Looking back at the “procedure” above, it really functions as a policy statement, as its principal focus is on who does what. You cannot gain from the “procedure” how any activity is performed. Should that document be discarded? If the document is useful to the organization, then no, keep it. Just don’t call it a “procedure.”

In the next installment, we will discuss the audience and purpose for procedures. In the meantime, I would like to thank Jeff Hansen of Tamarack Scientific in Corona, CA for his interest in the Mr. Procedure blog. I hope that you find this information useful in your organization!

2. Operating Procedures

I have laid out what would pass for a “procedure” in many organizations. Take a look at it and decide, “does it function as a procedure?”

1. The receiving department receives the raw materials, checks for accuracy and then places the materials on shelves to be available for production.

2. The production clerk receives the work order, identifies and pulls the raw material for the order, and tags it for delivery to the assembly area.

3. The warehouse operator pulls the work order, gathers the raw material for the order into a tote box, checks the material against the order to ensure all materials are present, and delivers the materials to the assembly area.

4. The assembly area supervisor receives the order, and distributes materials to the assemblers based on the assembly work they will perform.

5. The assembly workers put together the finished units from the materials, and place them in a bin to go to the testing area.

6. The assembly supervisor delivers the bin of finished units to the testing area.

7. The test technicians perform quality assurance testing on the units, and place the acceptable units in a bin for delivery to the packaging and shipping area.

8. The packers place the units in boxes, with all necessary instructions and other paperwork.

9. The shippers place the boxed units on a pallet, and prepare the pallet for shipment to the customer.

Many organizations would hand such a document to a Quality System auditor, declaring that “this is our operating procedure for making our product.” (And to jazz it up, the document will also include a flow diagram that essentially identical to the verbal description).

What is particularly distressing is the willingness of the auditor to accept it.

True, the nine steps above look suspiciously like a procedure. They do lay out an order in which actions will take place (good). They identify who will do what (okay). It  summarizes the general order of events that result in product realization (good). 

Does it meet the requirements of an operating procedure? Not at all!

The “procedure” above is missing the key element that makes a procedure worth the paper it is printed on (or the electrons used to store it). In my next post, we will discuss what is missing.

Policies: 1st level of documents

In the documentation pyramid (as I drew it; see the link in the last post), policies are the foundation–the bottom layer. Policies are commonly referred to as “Tier 1” documents (though such terminology does not occur in Quality Management System standard texts).

An organization’s policies (or standards) form the foundation of the organization’s operations. Specifally, a policy describes how the organization (and people within the organization) are expected to behave. In other words, policies express who and what the organization is and intends to be.

Organizations usually have many policies, some driven by regulation, others are self-generated. For example, there are many Human Resources policies; there are also SHE (Safety, Health and Environmental) policies, financial policies and others.

The importance of policies vis-a-vis operating procedures is that the policies establish a framework around how “things are to be done.” If policies are used correctly, nothing in an operating procedure would violate a policy.

Policy audience: an organization’s policies have a global audience. Employees, applicants, customers, suppliers, regulatory agencies, even communities in which the organizations operate (audiences vary with policies, of course).

Issues addressed by policies: who is responsible to do what, the order in which actions will take place, limits around what will be done, and of course, what will not be done (in terms of behavior that is expected and behavior that will not be tolerated). 

In the next post, we will focus on the operating procedure itself.  

I would not have acquired the nickname “Mr. Procedure” if I did not have some passion for the art of procedure writing. In many quarters, procedure writing is something to be put off, avoided, or directed to the new guy or intern. But if an organization’s mission and effectiveness is maximized by doing every critical task as correctly as possible as often as possible, more people should take a keen interest in how their operations and activities are defined.

In the next series of blog posts (at least the next seven or so), I will discuss procedures in the following contexts:

Procedures and their relation to other documents in an organization

What differentiates a procedure from other documents 

The three essentials of an effective procedure program

To begin this discussion, let’s look at what is commonly referred to as a “documentation hierarchy,” or “documentation pyramid.” This type of illustration (click here to view) is commonly used when evaluating documents as part of a Quality Management System (such as ISO-9001). The diagram illustrates the relative positions of policies, operating procedures, work instructions and records.

Many readers viewing the illustration will recognize that I have inverted the documents. Rather than showing the documents the traditional way (relating to the relative numbers of each type of document),  I have placed policies at the base of the pyramid and built upward. This recognizes the reality that each type of document supports everything above it on the pyramid.

In Part 2, the purpose and audience for policies.

Now we consider the third element that defines the total capability required for a position:

3. Knowledge

Knowledge is a broad category that includes any supporting information a person needs to enhance the effectiveness (productivity, quality or safety of the task performance), where the specific information fits neither into the task performance or skill category.

For a sales professional, knowledge of a company’s product line, knowledge of the market, and knowledge of a customer’s use of the product are essential, to enhance the sales experience for the customer. For other professionals, knowledge of human resource law, best accounting practices, organic chemistry or some other subject area allows them to perform their work.

For nearly all employees in all situations, there is some component of safety training. Nearly all safety training is knowledge development, though of course many skill areas overlap safety concepts (e.g., forklift operation as discussed as a skill).

Knowledge development is similar to skills development, in that an individual’s required knowledge should demonstrate a direct connection to the tasks and activities the individual will be performing on the job. In terms of safety training for an operations worker, a detailed review of each task to determine safety impacts should be undertaken, with the safety training limited to topics that impact the employee’s actual work.