The Attributes of Good Procedure

Good documentation practices when documenting Work as Prescribed stresses the clarity, accuracy, thoroughness and control of the procedural instruction being written.

Clarity and Accuracy: Documentation should be clear and free from errors, ensuring that instructions are understood and followed correctly. This aligns with the concept of being precise in documentation.

Thoroughness: All relevant activities impacting quality should be recorded and controlled, indicating a need for comprehensive documentation practices.

Control and Integrity: The need for strict control over documentation to maintain integrity, accuracy, and availability throughout its lifecycle.

To meet these requirements we leverage three writing principles of precise, comprehensive and rigid.

Type of Instruction	Definition	Attributes	When Needed	Why	Differences	Example
Precise	Exact and accurate, leaving little room for interpretation.	– Specific – Detailed – Unambiguous	When accuracy is critical, such as in scientific experiments or programming.	Regulatory agencies require precise documentation to ensure tasks are performed consistently and correctly	Focuses on exactness and clarity, ensuring tasks are performed without deviation.	Instructions for assembling a computer, specifying exact components and steps.
Comprehensive	Complete and covering all necessary aspects of a task.	– Thorough – Inclusive – Exhaustive	When a task is complex and requires understanding of all components, such as in training manuals.	Comprehensive SOPs are crucial for ensuring all aspects of a process are covered, ensuring compliance with regulatory requirements.	Provides a full overview, ensuring no part of the task is overlooked.	Employee onboarding manual covering company policies, procedures, and culture.
Rigid	Strict and inflexible, not allowing for changes.	– Fixed – Inflexible – Consistent	When safety and compliance are paramount, such as batch records	Rigid instructions ensure compliance with strict regulatory standards.	Ensures consistency and adherence to specific protocols, minimizing risks.	Safety procedures for operating heavy machinery, with no deviations allowed.

When writing documents based on cognitive principles these three are often excellent for detailed task design but there are significant trade-offs inherent in these attributes when we codify knowledge:

The more comprehensive the instructions, the less likely that they can be absorbed, understood, and remembered by those responsible for execution – which is why it is important these instructions are followed at time of execution. Moreover, comprehensive instructions also risk can dilute the sense of responsibility felt by the person executing.
The more precise the instructions, the less they allow for customization or the exercise of employee initiative.
The more rigid the instructions, the less they will be able to evolve spontaneously as circumstances change. They require rigorous change management.

This means these tools are really good for complicated executions that must follow a specific set of steps. Ideal for equipment operations, testing, batch records. But as we shade into complex processes, which relies on domain knowledge, we start decreasing the rigidity, lowering the degree of precision, and walking a fine line on comprehensiveness.

Where organizations continue to struggle is in this understanding that it is not one size fits all. Every procedure is on a continuum and the level of comprehensiveness, precision and rigidity change as a result. Processes involving human judgement, customization for specific needs, or adaptations for changing circumstances should be written to a different standard than those involving execution of a test. It is also important to remember that a document may require high comprehensiveness, medium precision and low rigidity (for example a validation process).

Remember to use them with other tools for document writing. The goal here is to write documents that are usable to reach the necessary outcome.

Global versus Local Process and Procedure and the eQMS

Companies both large and small grapple with how and when to create standard work at the global level, while still having the scalability to capture different GXP activity families and product modality.

I’ve discussed before on document hierarchy and on the leveling of process and procedure. It is really important to level your processes, and this architecture should be deliberate and shepherded.

This really gets to the heart of work-as-imagined and prescribed, and the concept of standard work.

Benefits of Standard Work

Ensures all work is done according to the current best practice
Consistency is the essential ingredient of quality
Allows organizations to scale rapidly
Puts the focus on the process and not an individual or team
Makes improvements easier and faster

Global versus Local Process and Procedure in the Document Hierarchy

Most Quality Hierarchies look fairly similar.

Excluding the Program level (which becomes even more important) we can expand the model in the process band to account for global versus local.

Global and local process within the document hierarchy

Quality Manual and Policy remains global with local input and determine the overall structure of the quality management system.

Global Process is created when a process is majority task and role driven at a global level. It is pan-GXP, pan-modality, pan-geography. It is the standard way of work to drive consistency across and through the organization.

Local Process is created when a process is specific to a specific GXP, product modality, geography.

Procedure, which describes the tasks, can be created off of local or global process. When the global process has localizations (a CAPA is a CAPA but how I build action items may differ across sites), I can build local versions off the global process.

For an example, Document and Record Management.

This approach takes real vision among leaders to drive for consistency and simplicity. This activity is a core component in good system design, no matter the size of the organization.

Principle	Description	Application for Global and Local Process
Balance	The system creates value for the multiple stakeholders. While the ideal is to develop a design that maximizes the value for all the key stakeholders, the designer often has to compromise and balance the needs of the various stakeholders.	The value of standard work really shines here.
Congruence	The degree to which the system components are aligned and consistent with each other and the other organizational systems, culture, plans, processes, information, resource decisions, and actions.	We gain congruence through ensuring key processes are at the global level.
Convenience	The system is designed to be as convenient as possible for the participants to implement (a.k.a. user friendly). System includes specific processes, procedures, and controls only when necessary.	The discussion around global versus local will often depend on how you define convenience
Coordination	System components are interconnected and harmonized with the other (internal and external) components, systems, plans, processes, information, and resource decisions toward common action or effort. This is beyond congruence and is achieved when the individual components of a system operate as a fully interconnected unit.	How we ensure coordination across and through an organization.
Elegance	Complexity vs. benefit — the system includes only enough complexity as is necessary to meet the stakeholder’s needs. In other words, keep the design as simple as possible and no more while delivering the desired benefits. It often requires looking at the system in new ways.	Keep this in mind as global for the sake of global is not always the right decision.
Human	Participants in the system are able to find joy, purpose and meaning in their work.	Never forget
Learning	Knowledge management, with opportunities for reflection and learning (learning loops), is designed into the system. Reflection and learning are built into the system at key points to encourage single- and double-loop learning from experience to improve future implementation and to systematically evaluate the design of the system itself.	Building the right knowledge management into the organization is critical to leverage this model
Sustainability	The system effectively meets the near- and long-term needs of the current stakeholders without compromising the ability of future generations of stakeholders to meet their own needs.	Ensure the appropriate tools exist to sustain, including regulatory intelligence. Long-term scalability.

Pillars of Good System Design for Gloval and Local Process

Utilizing the eQMS to drive

The ideal state when implementing (or improving) an eQMS is to establish global processes and allow system functionality to localize as appropriate.

So for example, every CAPA is the same (identify problem and root cause, create plan, implement plan, prove implementation is effective. This is a global process. However, one wants specific task detail at a lower level, for example GMP sites may care about certain fields more the GCP, medical device has specific needs, etc. These local task level needs can be mainted within one workflow.

The Key is Fit-For-Purpose Fit-for-Use

A fit for purpose process meets the requirements of the organization.

A fit for use process is usable throughout the lifecycle.

Global and localizing processes is a key part of making both happen.

Flow Chart

The flow chart is a simple, but important, graphic organizer. Placing the states or steps of an event or process into the correct sequence allows you to reach conclusions and make predictions.

However, its simplicity means we don’t always work to be consistent and can benefit from a little effort to ensure users are aligned.

I am a huge fan of including flow charts in all process and procedure documents.

Steps for Building a flow chart

Capture

Capture the events or steps of the process. Resist the urge to arrange them sequentially and concentrate on capturing the events/steps only.

Cull

If there are more than eight steps in a flow chart we start creating cognitive overload. If a process or procedure has more than eight steps you need to:

Ensure the steps are at the right level, sometimes we have substeps represented and we can cull that. Ensure they are all on the same level of process/procedure/task.
Decide we need to break the procedure into multiple documents. This is a great way to decide what work instructions are necessary.
Look for opportunity for process improvement.

Sequence the events and draw the flow chart

The focus now shifts to temporal relations. The correct sequential arrangements of steps or events helps to reach conclusions about past events and prepare for future events.

Example

I’m writing the procedure for my mornings, I capture the following:

Eat breakfast
Take shower
Take dog out
Get dressed
Decide on tea
Heat water
Drink tea
Read for 30 minutes
Deal with morning email
Snuggle with dog

Taking a look at the list I realize that not everything is on the same level of process/procedure/task and end up with a shorter list.

Breakfast
Take shower
Take dog out
Get dressed
Read for 30 minutes
Deal with morning email
Snuggle with dog

Notice how I combined all the tea stuff into a breakfast category. When brainstorming my list I put a lot of weight on tea, because it is important to me (yes I have been using tea as a training example since 2005, I just love tea).

I can then put them in sequence:

When I was making things sequential I realized that two of my activities (read and dog snuggle) were concurrent, so I combined them as one step.

Understanding How to Organize Process

Process drives the work we do. We can evaluate processes on two axis – complexity and strategy – that help us decide the best way to manage and improve the processes.

Process complexity and dynamics are what types of tasks are involved in the process. Is it a simple, repetitive procedure with a few rules for handling cases outside of normal operation? Or is it a complex procedure with lots of decision points and special case rules? Think of this like driving somewhere. Driving to your local grocery is a simple procedure, with few possibilities of exceptions. Driving across the country has a ton of variables and dynamism to it.

While complexity can help drive the decision to automate, I strongly recommend that when thinking about it don’t ask if it can be automated, only ask what would be involved if a human were to do the job or how it is done with current technologies. Starting with the answer of automation leads to automation for automation’s sake, and that is a waste.

Dynamics is how much the process changes – some change rarely while others change rapidly to keep pace in response to changes in product or external factors (such as regulations).

Strategic importance asks about the value the process contributes to meeting requirements. Is the process a core competency, or an enabling process that needs to be accomplished to ensure that you can do something else that meets the core requirements? Needless to say, one company’s strategic process is another company’s routine process, which is why more and more we are looking at organizations as ecosystems.

Processes are in a hierarchy, and we use levels to describe the subdivision of processes. We’ve discussed the difference between process, procedure and task. At the process level we usually have the high-level process, the architecture level, which are the big things an organization does (e.g. research, manufacture, distribute), mid-level processes that are more discrete activities (e.g. perform a clinical study) to even more discrete processes (e.g. launch a study) which usually have several levels (e.g. select sites, manage TMF) to finally procedure and task.

Level of Process	Includes	Key Ways to Address
High-Level Process	How key objectives are met, highly cross functional	Organization design. System Design
Mid-level Process	How a specific set of departments do their major work blocks	Process Improvement
Low-level process	How individuals conduct their work in sub-blocks	Knowledge management, task analysis, training

Levels of Process

To truly get to this level of understanding of process, we need to understand just what our process is, which is where tools like the SIPOC or Process Scope diagram can come in handy.

To understand a process we want to understand six major aspects: Output, Input, Enablers, Controls, Process Flow, People.

Complex and Complicated as Tools for Process Understanding

Simple processes usually follow a consistent, well-defined sequence of steps with clearly defined rules. Each step or task can be precisely defined, and the sequence lacks branches or exceptions.

More complicated processes involve branches and exceptions, usually draw on many rules, and tend to be slightly less defined. Complicated processes require more initiative on the part of human performers.

Complex processes are ones that require a high level of initiative and creativity from people. These processes rapidly change and evolve as time passes. Successful performance usually requires a connection to an evolving body of knowledge. They are highly creative and have a large degree of unpredictability. Most complex processes are viewed at the system level.

Sources

Benedict, T. et al. BPM CBOK Version 4.0: Guide to the Business Process Management Common Body of Knowledge. ABMP International, 2019.
Harmon, Paul. Business Process Change. Morgan Kaufmann, 2019.
Nuland, Y. and Duffy, G. Validating a Best Practice. Productivity Press, 2020

Procedure is Work-as-Prescribed

Written procedures with their step-by-step breakdown are a fundamental tool for ensuring quality through consistent execution of the work. As a standardized guideline for tasks, procedures serve many additional purposes: basis of training, ensuring regulatory requirements are met, ensuring documentation is prepared and handled correctly.

As written prescriptions of how work is to be performed, they can be based on abstract and often decontextualized expectations of work. The writers of the procedures are translating Work-as-Imagined. As a result, it is easy to write from a perspective of ideal and stable conditions for work and end up ignoring the nuances introduced by the users of procedures and the work environment.

The day-to-day activities where the procedures are implemented is Work-as-Done. Work-is-Done is filled with all the factors that influence the way tasks are carried out – spatial and physical conditions; human factors such as attention, memory, and fatigue; knowledge and skills.

Ensuring that our procedures translate from the abstraction of Work-as-Imagined to the realities of Work-as-Done as closely as possible is why we should engage in step-by-step real-world challenge as part of procedure review.

Steven Shorrock calls this procedural level “Work-as-Prescribed.”

Work-as-Prescribed gives us the structure to take a more dynamic view of workers, the documents they follow, and the procedural and organizational systems in which they work. Deviations from Work-as-Prescribed point-of-view are not exclusively negative and are an ability to close the gap. This is a reason to closely monitor causes such as “inadequate procedure” and “failure to follow procedure” – they are indicators of a drift between Work-as-Prescribed and Work-as-Done. Management review will often highlight a disharmony with Work-As-Imagined.

The place where actions are performed in real-world operations is called, in safety thinking, the sharp-end. The blunt-end is management and those who imagine work, such as engineers, removed from doing the work.

Our goal is to shrink the gap between Work-as-Imagined and Work-as-Done through refining the best possible Work-as-Prescribed and reduce the differences between the sharp and the blunt ends. This is why we stress leadership behaviors like Gemba walks and ensure a good document change process that strives to give those who use procedure a greater voice and agency.