A fairly traditional document hierarchy, in line with ISO 9001 and other standards looks like this:
Document hierarchy
This process tends to support best an approach where there is a policy that states requirements to do X, a procedure that gives the who, what, when of X, and work instructions that provide the how of X, which results in a lot of records providing X was done.
But life is complicated, and there are sets of activities that combine the Xs in a wide variety, and in complicated environments there may be multiple ways to bundle the Xs.
This is why I add a layer between policy and procedure, called the program, which is a mapping requirement that shows the various ways to interpret the requirements to specific needs.
Document hierarchy with Programs
The program document level shouldn’t be a stranger to those in the GMP world, ICH Q11 control strategy and the Annex 1 (draft) contamination control strategy are two good examples. What this document does is tie together processes and demonstrates the design that went into it.
The beauty of this document is that it helps translate down from the requirements (internal and external) to the process and procedures (including technology), how they interact, and how they are supported by technical assessments, risk management, and other control activities. Think of it as the design document and the connective tissue.
The format is pivotal. The difficulties we have in quality are really not much different from elsewhere in society in that we are surrounded by confusing documentation and poorly presented explanations everywhere we look, that provide information but not understanding. Oftentimes we rely on canards of “this is what is expected,” “this is what works” – but rarely is that based on anything more than anecdotal. And as the high incidence of issues and the high cost of training shows, less than adequate.
There is a huge body-of-knowledge out there on cognitive-friendly design of visuals, including documentation. This is an area we as a quality profession need to get comfortable with. Most important, we need to give ourselves permission to adapt, modify and transform the information we need into a shape that aids understanding and makes everyone a better thinker.
Work-as-Prescribed (and work-as-instructed) is the creation of tools and technologies to help us think better, understand more and perform at our peak.
Locus of Understanding
Looking at the process at the right level is key. Think of Work-as-Prescribed as a lens. Sometimes you need a high-powered lens so that you can zoom in on a single task. Other times, you need to zoom out to see a set of tasks, a whole process, or how systems interact.
This is the locus of understanding, where understanding happens. When we take this position, we see how understanding is created. Adopting the locus of understanding means going to the right level for the problem at hand. When we apply it to Work-as-Prescribed we are applying the same principles as we do in problem-solving to developing the right tools to govern the work.
An important way to look is distributed cognitive resources, which means anything that contributes to the cognitive work being done. Adjusting the locus of understanding means that you can, and should, treat an SOP as a cognitive resource. Some of the memory is in your head and some is in the SOP. Work-as-prescribed is a cognitive resource that we distribute, routinely and casually across the brain and our quality system in the form of documents and other execution aids.
Other tools, like my favorite whiteboard, also serve as distributed cognitive resources.
So, as our documents and other tools are distributed cognitive resources it behooves us to ensure they are based on the best cognitive principles possible to drive the most benefit.
As an aside, there is a whole line of thought about why some physical objects are better at distributed cognitive resources than electronic. Movement actually matters.
Taking it even further (shifting the locus) we can see the entire quality system as a part of a single distributed cognitive system where cognitive work is performed via the cognitive functions of communicating, deciding, planning, and problem-solving. These cognitive functions are supported by cognitive processes such as perceiving, analyzing, exchanging, and manipulating.
Cognitive Activity in Work-As-Prescribed
The tools we develop to provide distributed cognitive activity strive to:
Provide short-term or long-term memory aids so that memory load can be reduced.
Provide information that can be directly perceived and used such that little effort is needed to interpret and formulate the information explicitly.
Provide knowledge and skills that are unavailable from internal representations.
Support perceptual operators that can recognize features easily and make inferences directly.
Anchor and structure cognitive behavior without conscious awareness.
Change the nature of a task by generating more efficient action sequences.
Stop time and support perceptual rehearsal to make invisible and transient information visible and sustainable.
Aid processibility by limiting abstraction.
Determine decision making strategies through accuracy maximization and effort minimization.
Driving Work-As Prescribed
As we build our requirements documents, our process and procedure, there are a few principles to keep in mind to better tap into distributed cognitive resources.
Plan for the flow of information: Think about paths, relationships, seams, edges and other hand-offs. Focus on the flow of information. Remember that we learn in a spiral, and the content needed for a novice is different from that of an expert and build our documents and the information flow accordingly. This principle is called Sequencing.
Break information down into pieces: Called, Chunking, the grouping together of information into ideally sized pieces. When building Work-As-Prescribed pay close attention to which of these chunks are reusable and build accordingly.
The deeply about context: How a tool is used drives what the tool should be.
Think deeply about information structures: Not all information is the same, not every example of Work-as-Prescribed should have the same structure.
Be conscientiousabout the digital and physical divide: Look for opportunities to integrate or connect these two worlds. Be honest of how enmeshed they are at any point in the system.
We are building our Work-as-Prescribed through leveraging our quality culture, our framework for coordinating work. Pay attention to:
Shared Standards – Ways we communicate
Invisible Environments – Ways we align, conceptually
When design process, procedure and task documentation leverage this principles by build blocks, or microcontent, that is:
about one primary idea, fact, or concept
easily scannable
labeled for clear identification and meaning, and
appropriately written and formatted for use anywhere and any time it is needed.
There is a common miscomprehension that simple means short. That just isn’t true. Simple means that it passes a test for the appropriateness of the size of a piece of content of providing sufficient details to answer a specific question for the targeted audience. The size of the content must effectively serve its intended purpose with efficiency, stripping off any unnecessary components.
We need to strive to apply cognitive thinking principles to our practice. The day of judging a requirements document by its page length is long over.
Constituents of cognitive thinking applied to Work-As-Prescribed
A month back on LinkedIn I complained about a professional society pushing the idea of a document-free quality management system. This has got to be one of my favorite pet peeves that come from Industry 4.0 proponents, and it demonstrates a fundamental failure to understand core concepts. And frankly one of the reasons why many Industry/Quality/Pharma 4.0 initiatives truly fail to deliver. Unfortunately, I didn’t follow through with my idea of proposing a session to that conference, so instead here are my thoughts.
Fundamentally, documents are the lifeblood of an organization. But paper is not. This is where folks get confused. But fundamentally, this confusion is also limiting us.
Let’s go back to basics, which I covered in my 2018 post on document management.
When talking about documents, we really should talk about function and not just by name or type. This allows us to think more broadly about our documents and how they function as the lifeblood.
There are three types of documents:
Functional Documents provide instructions so people can perform tasks and make decisions safely effectively, compliantly, and consistently. This usually includes things like procedures, process instructions, protocols, methods, and specifications. Many of these need some sort of training decision. Functional documents should involve a process to ensure they are up-to-date, especially in relation to current practices and relevant standards (periodic review)
Records provide evidence that actions were taken, and decisions were made in keeping with procedures. This includes batch manufacturing records, logbooks and laboratory data sheets and notebooks. Records are a popular target for electronic alternatives.
Reports provide specific information on a particular topic on a formal, standardized way. Reports may include data summaries, findings, and actions to be taken.
The beating heart of our quality system brings us from functional to record to reports in a cycle of continuous improvement.
Functional documents are how we realize requirements, that is the needs and expectations of our organization. There are multiple ways to serve up the functional documents, the big three being paper, paper-on-glass, and some sort of execution system. That last, an execution system, united function with record, which is a big chunk of the promise of an execution system.
The maturation mind is to go from mostly paper execution, to paper-on-glass, to end-to-end integration and execution to drive up reliability and drive out error. But at the heart, we still have functional documents, records, and reports. Paper goes, but the document is there.
So how is this failing us?
Any process is a way to realize a set of requirements. Those requirements come from external (regulations, standards, etc) and internal (efficiency, business needs) sources. We then meet those requirements through People, Procedure, Principles, and Technology. They are interlinked and strive to deliver efficiency, effectiveness, and excellence.
So this failure to understand documents means we think we can solve this through a single technology application. an eQMS will solve problems in quality events, a LIMS for the lab, an MES for manufacturing. Each of these is a lever for change but alone cannot drive the results we want.
Because of the limitations of this thought process we get systems designed for yesterday’s problems, instead of thinking through towards tomorrow.
We get documentation systems that think of functional documents pretty much the same way we thought of them 30 years ago, as discrete things. These discrete things then interact through a gap with our electronic systems. There is little traceability, which complicates change control and makes it difficult to train experts. The funny thing, is we have the pieces, but because of the limitations of our technology we aren’t leveraging them.
The v-model approach should be leveraged in a risk-based manner to the design of our full system, and not just our technical aspects.
System feasibility matches policy and governance, user requirements allow us to trace to what elements are people, procedure, principles, and/or technology. Everything then stems from there.
It is pretty standard advice that relevant references to other documents should be listed in a separate section of the procedure. The reasoning is that when some standard operating procedures are intimately linked to others – the information contained in more than one document is necessary to complete a task – it is useful to include a cross-reference section in each document. Many also say that this section reinforces the SOP’s authority.
Another fairly common piece of advice is to have this, or another, section in the procedure identify the documents used in the development of the procedure, such as regulatory documents or technical/validation reports.
My take is that neither belongs in a process/procedure (SOP/WI). We should be looking to streamline requirements documents, and these sections are just cruft.
If you have electronic document control systems then cross-references should be handled trough hyperlink. Users are quite comfortable with hyperlinks and will easily navigate between documents.
Listing of regulations and other requirements belongs in a separate design document (ideally part of the document control system), and again add little value to the execution of the document.
There are a lot of so-called “best practices” about documents that stem from the days where everything is paper, and it is okay to move beyond them.
Investigations of a Dog 