Ron C Johnson Communications

Building Procedures with the SOP Toolkit – #3

I.       What types of SOPs do you need?

Only you can answer that question, but maybe we can break it down into categories.

In general, are your needs primarily in the areas of plant operations? What about maintenance-related procedures? What about administrative policies and procedures? Do you already have a satisfactory set of safety procedures? It is worth your time to stop and answer these questions. The answers will have a practical influence on decisions and activities you will embark on later.

II.      How will your SOPs be used?

You should also consider what the range of uses you have in mind for your SOPs. Will these documents be used exclusively in the field, as a reference or checklist by the personnel executing the procedures? Will they be reviewed during toolbox meetings, operations planning meetings, etc? Will your SOPs become a key element in your training program? Do you see your SOPs as simply reference material that can be consulted when necessary?

III.     What level of detail do you require?

What level of detail will be suitable for your situation? Some “experts” will be happy to tell you the level of detail you need, but ultimately you will have to decide that for yourself. One useful way to view procedures divides them into three levels of detail: Guidelines, Best Practices and Detailed Procedures. Think of these in terms of “distance” from the actual tasks to be accomplished.

Guidelines are the “thousand foot” viewpoint. They simply express what you want to accomplish, with very little detail on how to go about it. Guidelines allow for more than one method or procedure. Personnel who understand their roles and have experience, can typically “connect the dots” between the guideline and its execution.

Best practices bring you closer to the detail but still allow some latitude in how to execute a procedure. Out of a number of possible ways to accomplish a task there may be more than one “best practice”. Again, experienced personnel who are given the option of selecting their preferred best practice, can make the choice themselves.

Detailed procedures represent the closest viewpoint. When it is critical that a task is executed exactly as specified, an SOP should be written at this level. While detailed procedures may be considered unnecessary by experienced personnel, they provide the inexperienced worker with a level of confidence and comfort in knowing exactly how he or she is to execute the procedure.

There are additional benefits to detailed procedures. They can be used for training purposes. They can be used as the reference specifications in meeting compliance requirements. They also can be used by management as the baseline to define expectations of personnel. (Ultimately, it is our view that detailed procedures should always be written, maintained and kept for reference, even if the decision is made to simplify them in working documents.)

The concept of “policy” should be mentioned here, in the context of levels of detail. It is seldom enough to simply define a set of procedural steps that will accomplish a task, and verify the steps with an SME. Someone must examine the procedure in light of company, division or group policy. There may be differences of opinion as to the best way to accomplish a task. Someone must be accountable for deciding whether a SOP should be a guideline, best practice or detailed procedure. As the level of detail increases, that person may have to decide what best practices are acceptable, or if a specific detailed procedure will be adopted as THE procedure. These decisions cannot be left to the technical writer, or even one or more SMEs. Someone in authority must make this decision and sign the final document. This process–called validation–will be discussed in more detail later…

Building Procedures with the SOP Toolkit #2

Getting Started

Considerable planning, on several levels, goes into developing an SOP documentation system. There is no “cookie cutter” approach. Your SOP needs may be similar to other organizations, but they will never be the same. Personnel at several levels and in several areas of the organization should work together to determine your needs. The process will involve asking some important questions.
Let’s look at some of those questions…

What is an SOP?

Here’s one definition: An SOP is an accurate, approved document that provides steps for accomplishing a task according to established standards, formats, level of detail, and policy. An SOP is accurate. Above all, an SOP is a procedure that works. It achieves the goal specified in its title. All aspects of the procedure have been verified by the appropriate subject matter experts (SME). The SOP has been checked and (to the extent possible) tested to ensure it is accurate.
An SOP is approved. The appropriate levels of authority have checked the SOP to ensure it conforms to organizational policy. It has been accepted as the approved method of performing the task. It has been adopted into the organization’s systems.

An SOP is a document. Typically an SOP is a paper document, for portability. But increasingly, SOPs are both paper and electronic documents. This adds functionality AND complexity to its creation and maintenance.An SOP is standardized. SOPs must be written in a consistent, accessible style, to ensure they are usable. The document structure must be predictable so that information is easy to find, and simple to follow. The language used in an SOP must be understandable by all personnel, whether they are experienced or inexperienced, technically inclined or not, and whether or not English is their first language.
An SOP must follow a standard format. All SOP documents should follow the same format, and as much as possible look the same. All headings must be consistent in order, style and format. For practical purposes, the document style and format must be established, documented and maintained in style guides.
Most importantly, an SOP is a LIVING DOCUMENT. It must be seen as an entity that can and must evolve.

Building Procedures with the SOP Toolkit – #1

A wise old philosopher said “The only constant is change” and this has never been more true than in the water and wastewater treatment industry. Even if we only look back twenty years we can easily see tremendous changes. Technology continues to evolve. Environmental concerns continue to grow. Public expectations of safety, quality and service become more demanding. Workforce demographics shift.

These, and other factors, are driving public utilities to deliver more services at a ever more demanding levels of quality and accountability, while contending with limited budgets and an aging and increasingly mobile workforce. Utilities grappling with these challenges are looking for ways to remove inconsistencies and risk from their operations and processes. One of the solutions is to capture and retain the knowledge, skills and best practices, and use them to standardize and train personnel to as high a level of consistency as possible.

Standard operating procedures, or SOPs, are a key tool in these efforts. Utilities, institutions, corporations and organizations of all types see the value in capturing, standardizing and documenting the activities and tasks performed by their personnel. However, that process presents its own set of unique challenges. Most organizations do not have the necessary in-house expertise to design, research, write and produce documentation. Nor do they have expertise in managing documentation processes. And most organizations have not factored the time needed for developing documentation into their staffing strategies.

Technical Writing/Editing: Pain or Pleasure

I have noticed a few things about technical writing in Saskatoon, and Saskatchewan in general.
First, there aren’t very many of us in Saskatoon…especially not freelancers or tech writing companies…compared with Calgary, for example.
Second, most people still think a technical writer writes about “technical stuff”–electronics, software, IT, mechanical, etc., which is only partly true, some of the time.
Third, most people here don’t think of writing as something you would contract out. Usually they either have the “anyone can write” perspective, or they look at it as a necessary evil and do as little of it as possible.
I’m trying to change that, to show businesses that there is value and ROI in getting a professional to write their user manuals, policies, procedures, case studies, white papers, etc.
I’d be interested in hearing your thoughts on this.

Presenting at the SWWA Conference

Yes, I know it’s short notice, but I hope we will get a chance to meet you at the Saskatchewan Water and Wastewater Association conference on November 3 to 6 in Saskatoon. We don’t have a trade show booth this time around but we will certainly be there, mingling and trying to learn more about the industry.

If you are already signed up for the conference you may know that we will be presenting twice. On Wednesday morning at 10:40 am we’ll be presenting “Developing Plant Documentation”, a 45 minute technical session that will provide an overview of the considerations and processes involved in creating operations manuals, SOPs and other documents. We’ll approach the subject from the perspective of lessons we have learned in real life project situations.

On Thursday, Nov 5 at 1:00 pm we will be presenting Introduction to Building Procedures with the SOP Toolkit. This 3 hour workshop picks up from the technical session and explores how to use our SOP Toolkit to get you started in creating standard operating procedures.

Hope to see you there!

News: Now located at Innovation Place, Saskatoon

We’re pleased to announce that we are now settled into our new office at Innovation Place (102F 116 Research Drive, Saskatoon).

An interior view of the Concourse Building, near RCJC offices

Innovation Place was recently named the 2009 Outstanding Research Park by the Association of University Research Parks (AURP) in recognition of their role in supporting the growth of science and technology related economic development.

Our new location will support several new initiatives that we are currently implementing. As we incorporate new clients and additional staff, and embark on our new marketing plan, we expect the move to enhance the services we can offer.

Need a writer? Or do you just need some help?

Someone said “There’s no such thing as writing…just re-writing” and as time goes on I’m realizing this is true in several ways. I was reminded of this while talking to people at a trade show I recently attended. I engaged several people from various booths in conversation and mentioned that I “write” manuals, procedures, training materials, and other documents. As usual, the response was, “We write our own manuals.”

What can I say to that? You shouldn’t! You should let me do it! I’m a professional! I also can’t really tell them their writing isn’t good enough. At that point for all I know they may be very effective communicators. Obviously these wouldn’t be the most effective marketing techniques.

But experience has shown me that most small to medium sized companies who do their own technical writing are not entirely happy with their results. Usually they know their documentation needs improvement but several factors are holding them back from getting what they need. First, they don’t know where to find someone who they are confident can help. Second, they are not sure whether the price they will pay will be worth the benefits of better documentation.

So I have realized that often what the client needs is not a technical writer, but a technical re-writer. Other ways to describe it is editor or documentation consultant–someone who can meet them at the point where they need help, and can provide cost-effective recommendations and assistance. The client knows the content they want in the documents, and they often have good ideas about how it can be best organized for their customers. I know how to organize, present and clarify information so it has the effect the client wants.

As for the cost of my services? Usually, the savings realized from reduced product support (telephone, in-house and field service) and decreased product returns pays for my fees in the first few months after completion of the document upgrades.

“Do I really need a tech writer?”

Well…no, actually.  But do you really want to do this nasty job yourself?

I’ve lost count of the number of people to whom I have offered my technical writing services, who look at me like I must be crazy. After all, they have smart people working for them…people who understand the content that needs to be written, who have great computer skills, who know how to write a sentence. Why would they pay someone from the outside to do what they could do themselves?

The only honest response I have come up with is: “Great! Enjoy the experience.” The truth is, these organizations probably do have people with skills, and with some effort they could probably turn out a  manual, procedure, or other document. However, further down the road they may wish they had brought in an expert.

Writing a manual or procedure is not simply the process of putting a series of steps into words. And a tech writer is not simply a person who writes sentences. Typically, a capable and experienced “technical communicator” (the correct description of the role) performs most of the following tasks in the process of producing documentation:  assesses the clients documentation needs, analyzes the content/tasks/etc to be documented, determines the scope of the project (especially if multiple documents are involved), gathers resources, identifies subject matter experts (SME), designs the document format and style, does research, writes the content, works with SMEs to verify and edit one or more drafts, publishes a final draft, maintains records, files, style guides, document plans, and many more aspects of the project. Throughout this process the technical communicator often assumes the role of project manager/leader and, if the project is large, may manage several personnel with specialized skills (illustrators, photographers, IT support, etc). If the project is smaller, most of these tasks still have to be handled at some level, and the person handling them needs to know how not to get bogged down in them.

So if you have someone who can handle these tasks, and you are willing to free the person up to become your in-house technical writer…good for you. But don’t expect that person to manage a documentation project AND do the job they were doing before. Something will break, and chances are you won’t end up with documentation at the level of quality that you had hoped for.

Access to SMEs a key ingredient in a successful project

One of the most important steps that a client can take to ensure the successful and timely completion of a writing project is to make sure the technical documentation team has good access to subject matter experts (SME). All SMEs needed for the project should be considered part of a resource team that meets periodically and is kept up-to-date on the project. If management takes the project seriously, and intends to make sure it is successful, they will communicate by word and example that attendance at these meetings is a high priority. They will also make sure that team members are allocated time to spend working with the documentation team and given clear instructions that they are expected to cooperate and support the tech writers’ efforts.

Ideally, the documentation team is able to spend adequate time on-site, working directly with the SMEs. Several factors must be in place to make sure on-site time is used effectively. The SMEs must be available, and know they are expected to cooperate. From the tech writer’s perspective, having full-time access to an SME who has a wide range of knowledge and experience would be ideal. Sometimes that is possible. For example, I have worked closely with an experienced plant operator who was on a work accommodation. Unfortunately, he was often pulled away from working with me to assist with other projects and situations as they arose.

It’s important to remember that one SME does not have all the answers. SMEs participate in several phases of the project. In the data gathering phase the doc team brings together information about the plant and how it is operated. This includes facts, specifications, how equipment and systems work, tasks and procedures. The next phase includes fact verification, but also verification of policies. A third phase–validation–involves confirmation that the document is acceptable. A plant operator may be able to answer questions about facts and procedures, but he or she probably cannot provide definitive rulings on operating policies. Those answers may have to come from supervisory or management staff. Sometimes there can be differences of opinion on best practices. Who makes the final ruling on what is the best practice for a given procedure? Who validates a procedure as complying with company policy? Without access to the appropriate SME the technical writer’s hands are tied.

Developing procedures for water and wastewater

One of the most contentious and polarized issues I have come across regarding developing procedures is that of minimalist versus comprehensive content in standard operating procedures. Sit down with a group of plant operators and maintenance personnel and ask them what they would like to see in an SOP and then watch what happens. One camp wants a single sheet of paper with less than a dozen basic procedural steps. The other pushes for a comprehensive set of instructions suitable for standardizing the procedure and training new recruits.

I fall into that second camp–probably because of my training background. I see the value to making sure the document targets the lowest common denominator, and can be used to train (or retrain) anyone at any level of competence. That said, I like to include a simple checklist that the more experienced personnel can take with them into the field and use as necessary to make sure everything is covered.