By Tim Brennan

In my nearly 20 years as a technical writer for pharmaceutical and biotechnology companies, I’ve often been asked how writing for these industries differs from other industries.

“Really? What the heck kind of writing do you do for them?” they ask.

In this blog post, we’ll dive into that very question. The answer is a bit more complex than you may think.

Difference #1: Think SOPs Not User Guides

Prior to my time in biotech, I spent the previous decade and half working for Fortune 1000 companies (GE, Blue Cross Blue Shield, Liberty Mutual), small software startups (Digital Delivery, OpenSite Technologies), and I even did a stint in higher ed (MIT).

As a technical writer for these organizations, I was primarily responsible for documenting step-by-step instructions for various systems, software applications, and processes. More often than not, these instructions would go into some form of a user guide, such as a User Manual, Installation Guide, Troubleshooting Guide, etc.

Pharma and BioTech companies are different in that the main deliverable is typically some form of a standard operating procedure or SOP.

Depending on who you ask, you will get a ton of different answers on the definition of an SOP. Just Google “definition of an SOP” and you’ll get a sense.

Merriam Webster does a decent job of defining an SOP in general terms:

“Established or prescribed methods to be followed routinely for the performance of designated operations or in designated situations.”

The IOSR Journal of Pharmacy provides a more relevant definition for pharma and biotech in my view:

“A Standard Operating Procedure (SOP) is a set of written instructions that document a routine or repetitive activity that is followed by employees in an organization. The development and use of SOPs are an integral part of a successful quality system. It provides information to perform a job properly, and consistently in order to achieve pre-determined specification and quality end-result. SOPs should allow for the continual improvement of standards of service, and provide evidence of commitment towards protecting patients. Additional benefits are:

· Help to assure quality and consistency of service;

· Help to ensure that good practice is achieved at all times;

· Provide an opportunity to fully utilize the expertise of all team members;

· Help to avoid confusion over who does what (role clarification);

· Provide advice and guidance to locums and part-time staff;

· They are useful tools for training new members of staff;

· Provide a contribution to the audit process.”

Biopharma SOPs vary widely in size depending on the complexity of the system or process being documented. I’ve worked on some three-page SOPs, and I’ve worked on some that were over 300 pages.

SOPs typically include the following major sections at a minimum:

· Purpose

· Scope

· Definition

· Procedure /Operations

· References

· Attachments or Appendices

The meat of the SOP is in the Procedure / Operations section. This is where the step-by-step instructions are documented.

A Parenteral Drug Association (PDA) survey found that a typical pharmaceutical company must, on average, manage a whopping 1250 SOPs with the average maintenance burden at 15,000 hours.

One final note on SOPs, these are by no means “fancy” documents. And technical writers have very little creative license with them. They are typically written in Microsoft Word, have no cover page, very little formatting, and are in Times or Times New Roman font.

Difference #2: Good Quality Practices (GxP) Rule the Roost

GxP stands for ‘good practice’ quality guidelines and regulations. The purpose of the GxP quality guidelines is to ensure a product is safe and meets its intended use.

The little x in the acronym is used to denote the various fields of governance.

For example, GMP standards for Good Manufacturing Practice, GLP stands for Good Laboratory Practice, and GDP stands for Good Documentation Practice. Check out this Wikipedia page if you want to see additional examples of GxP guidelines (there are several).

Most GxP practices provide some level of governance around documentation and some, like GDP, provide governance across multiple practices. For example, if you work in a lab (and need to follow GLP), your SOPs must also conform to GDP.

Confused yet?

The bottom line is that in the highly regulated Pharma and BioTech industries, there are multiple practices and standards than need to be followed. If companies deviate from the standards, they can be served up hefty penalties and even fines from the FDA and other regulating authorities. Even worse, potentially life-saving products can be delayed in getting to market or even shelved for good.

Difference #2: Tons of Project Documentation

In order to satisfy FDA and other regulatory requirements, all internal projects require a heap of documentation to ensure that biopharma systems and projects are up to snuff. This is especially true for IT Systems, many of which must adhere to some form of the Systems Development Lifecycle (SDLC). Wikipedia does a nice job of defining SDLC:

“The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used in systems engineering, information systems, and software engineering to describe a process for planning, creating, testing, and deploying an information system.”

To give you a sense of the scope, below is a partial list of the types of documents that might be required to implement a GxP-compliant IT system in a lab. For example, this could be a laboratory information management system (LIMs) that collects data from drug discovery experiments.

Note: The specific requirements and actual deliverables depend on system complexity and internal quality requirements and processes.

· Project Charter

· Business Case

· Cost-Benefit Analysis

· Project Resource Plan

· Statement of Work

· Risk Analysis

· Procurement Plan

· Roles and Responsibilities Matrix

· Work Breakdown Structure Resource Planning Template

· Project Plan

· System Impact Assessment

· Business Requirements Document

· Functional Requirements Document

· Software Architecture Plan

· Use Case Template

· Requirements Traceability Matrix

· Service Level Agreement Template

· System Design Specification

· Database Design Document

· Data Migration Plan (for an upgrade to a new system)

· Test Plan

· Test Scripts (there could be dozens or even hundreds of these! )

· Testing Bug Report

· Testing Bug List

· Project Acceptance Document

· Change Management Log

· Project Status Report

· Production Implementation Plan

· Production Turnover Approval

· Disaster Recovery Plan

· Global Application Support Summary

· Developer Knowledge Transfer Report

· System-Level Standard Operating Procedure

Again, this is a partial list. The list of documents is actually twice this size! For the long list of SDLC artifacts, see the SDLC Forms website.

So, as you can see, there is quite a bit to the SDLC—and no shortage of opportunities for technical writers to become involved in the process. Sadly, a problem often faced by IT project managers is a lack of resources to help maintain the quality and consistency of SDLC documents. Consequently, they end up doing the work themselves or delegating to a member of the project team. Since each project team member’s writing skills and word processing skills vary, this can pose some serious challenges to overall quality.

Good templates can help, but those organizations that are committed to quality SDLC deliverables should insist on involving technical writers in their projects.

Difference #4: Quality Oversight

The fourth key difference is quality oversight.

While any company with a commitment to quality will have some form of QA process in place, the internal governance for biopharma is much more strict and rigid than in other industries.

Of course, strict adherence to quality is crucial for this sector due to the correlation between product quality and public health/safety. Defects in pharmaceutical drugs pose a risk to human health and life.

And on a lighter note, someone needs to police all these documentation standards, right?

The trouble is that internal quality can often slow down the overall process flow, because of multiple checks and balances along the way. For example, if errors are found in a test script during an SDLC testing phase, the QA department would typically get involved. They will provide oversight on how to correct the defects and often require additional paperwork, such as a Test Incident Report, to document the errors and ensure compliance. While necessary, these extra steps can often cause delays in the process.

Another role of the quality organization is to create standards and processes around documentation requirements. In IT, this comes in the form of IT Controls, or a set of standards that everyone in IT must follow around documentation governance.

Difference #5: Formal Document Management

Lastly, another major difference is that all documents need to be reviewed, approved, maintained, and retired using some form of a document management system.

For most documents, multiple approvals are required. For IT systems, reviewers and might include but are not limited to:

· Document Coordinator or Initiator (Often a technical writer)

· The Business Process Owner (BPO)

· The IT System Owner (ITSO)

· The IT Project Owner (ITPO)

· One or more IT Project Analysts (ITPAs)

· Technical Project Lead

· IT Quality

· Global Quality (e.g., for GXP systems)

Once everyone approves the document, it is stamped with an official watermark. It then cannot be changed unless a document coordinator executes a new workflow to change it. The document would then go back into a draft state in the document management system.

All changes to the document must be made in accordance with the workflow of the system, and the changes would need to be approved by all relevant parties before it is made official. This process is called document control.

In my work in other industries, the approval process was often much less formal. Typically, a document would be peer-reviewed by another technical writer or by a manager. It would then be given a verbal “looks good” or sometimes even a physical “thumbs up.”

Conclusion

I hope this helps paint a picture of some of the key differences between technical writing for biopharma and other industries. I would love to hear about your experiences and whether they are similar to or different than mine.

Feel free to write to me directly at tim@writeinteractive.com or leave a Comment below.

Oh, and if you are up to your eyeballs in writing and revising SOPs and project documents, and you would like some help, feel free to reach out as well. 😉

Last updated 1/1/2019