The White Paper in the Quality System

Eventually there will be a thorny topic that needs to be teased out, directed at an audience beyond those involved. This isn’t quite a technical report, or a risk assessment or a program document. It is that chameleon, the white paper.

A white paper can play several important roles in a quality management system:

Establish standards and best practices: White papers can outline recommended procedures, methodologies, and standards for quality within an organization or industry. They can provide detailed guidance on implementing quality processes.
Educating stakeholders: White papers serve as educational tools to inform employees, management, and other stakeholders about quality principles, new technologies, or approaches to improving quality. They help build a shared understanding of quality objectives.
Problem-solving: White papers often follow a problem-solution structure, identifying quality issues and proposing detailed solutions backed by research and data. This can help organizations address specific quality challenges.
Documenting processes: As part of a quality management system, white papers can provide in-depth documentation of complex processes, procedures, or systems. This documentation is crucial for consistency and compliance.
Promoting continuous improvement: By presenting research findings and innovative approaches, white papers can drive continuous improvement efforts in quality management.
Supporting decision-making: The authoritative and data-driven nature of white papers makes them valuable resources for informed decision-making about quality initiatives.
Demonstrating expertise: For organizations, publishing white papers on quality topics can establish thought leadership and demonstrate expertise to clients, partners, and regulatory bodies.
Compliance support: In regulated industries, white papers can help explain how an organization’s quality system meets regulatory requirements or industry standards.
Change management: When implementing new quality processes or technologies, white papers can help communicate the rationale and benefits to stakeholders, supporting change management efforts.
Benchmarking: White papers often include industry data and best practices, allowing organizations to benchmark their quality performance against peers or industry standards.

White Papers and Standards

A standard in a quality system is a documented set of requirements, specifications, or guidelines that define the criteria for quality in processes, products, or services. They offer precise descriptions that serve as an objective basis for organizations and consumers to communicate and conduct business globally. Standards provide organizations with shared procedures, terminology, and expectations to meet stakeholder requirements.

A white paper usually defines what will end up being in a standard, or defends the decision making of the standard. It is a why document.

White Papers and the Program Level

The program is a document that maps requirements to show the various ways to interpret the requirements to specific needs. Program documents, like a validation master plan or contamination control strategy, define the strategic plan that tie the entire program into a pretty package. A white paper then provides more in-depth justification of the rationale.

White Papers are Outward Orientated

When we write a white paper we are usually taking all the decision making a team made and the rationale behind them. It is a place to draw together all those articles and consensus standards we utilized, all the internal technical studies and risk management. White papers are written often aimed for health authorities, auditors, clients and partners.

How to Write a White Paper

Clear goals and target audience

A well-defined purpose is crucial for any white paper. Ask yourself:

What do you want to achieve with this document?
Who is your primary audience? Common ones are health authorities, clients, other parts of the organization.
What action do you want readers to take after reading? Usually it answers questions, but other times there is a translation necessary (e.g. update SOPs)

Concise summary

The executive summary or abstract should:

Be no more than 200-250 words
Highlight the main problem, solution, and key takeaways
Entice the reader to delve into the full document

Strong introduction

A compelling introduction should:

Provide context for the topic
Establish the relevance and importance of the issue
Outline the structure of the paper
Hook the reader with an interesting fact, statistic, or scenario

Problem statement

When defining the problem:

Use data and real-world examples to illustrate its scope and impact
Explain why existing solutions were inadequate
Highlight the consequences of not addressing the issue

Well-researched content

To ensure credibility:

Use a mix of primary and secondary sources
Link to requirements and obligations (i.e. regulatory regulations, consensus standards, industry best practices)
Include recent data
Reference industry reports and academic studies
Conduct original research and risk management as appropriate

Solution(s)

When presenting solutions:

Explain the rationale behind each option
Discuss pros and cons objectively
Provide evidence of effectiveness, such as case studies or pilot results
Clearly state why the recommended or chosen solution is superior

Logical flow and structure

Organize your content with:

A clear, logical progression of ideas
Subheadings and sections for easy navigation
Transitional phrases between sections
A balance of text, visuals, and white space

Visual elements

Effective visuals can include:

Infographics summarizing key data
Process diagrams explaining complex concepts
Comparison charts for different solutions
Relevant photographs or illustrations

Conclusion and call-to-action

A strong conclusion will:

Recap the main points without introducing new information
Reinforce the urgency of addressing the problem
Provide clear, actionable next steps for the reader, as appropriate
Include contact information or resources for further engagement

References

Properly cite sources by:

Using a consistent citation style (e.g., APA, MLA)
Including a bibliography or reference list at the end
Using footnotes or endnotes for additional context if necessary

Objective tone

Maintain credibility by:

Using a professional, authoritative voice
Avoiding overly promotional language
Acknowledging potential limitations or challenges
Presenting a balanced view of the topic

Should Have, Could Have, and Would Have

Avoiding the Word Should in GxP Documents

Generally, it’s best to avoid using “should” in a GxP document (e.g., SOP, plan, report, etc.). The word “should” can come across as non-committal or indicate a preference rather than a firm intention or goal.

GxP Documents are meant to be clear, concise, and direct. A more definitive language and active voice are preferred.

When writing about your goals and plans, it’s better to use more confident and assertive language rather than tentative words like “should.”

If you need to express a goal or aspiration that isn’t mandatory, consider rephrasing it more directly or using alternative constructions that show commitment and motivation.

Focus on using active voice and present tense verbs to describe your experiences, goals, and reasons for applying to the program.

Remember that a GxP Document, like a plan or SOP, is your opportunity to demonstrate your clarity of purpose and commitment. Using more decisive language can help convey this.

In summary, while “should” might be appropriate in some contexts, it’s generally best to avoid it in a GxP document in favor of more direct and confident language that propels into action.

Modals of Lost Opportunity

The term “modals of lost opportunity” refers to the modal verbs should have, could have, and would have. These modals express regret or hypothetical scenarios about past events that did not occur. They allow speakers to reflect on what might have been different if specific actions had been taken. They can be used in business and technical writing to express regret, hypothetical scenarios, and constructive feedback. But they should be used very carefully in GxP writing.

Should have indicates that a different action was recommended or expected in the past. It often implies a sense of regret or criticism about what was done or not done.

Example: “I should have left my house earlier.” This implies that leaving earlier would have been the better choice, possibly to avoid being late.

Could have is used to talk about possibilities or abilities that existed in the past but were not realized. It often reflects on missed opportunities or potential outcomes that did not happen.

Example: “If I had gone to college, I could have gotten a better job.” This suggests that attending college was a possibility that could have led to a better job, but it did not happen.

Would have is used to imagine a specific result that would have occurred if a different action had been taken. It often expresses a more certain outcome compared to “could have.”

Example: “If we had arrived earlier, we would have caught our flight.” This indicates that arriving earlier would have definitely resulted in catching the flight.

Usage in Sentences

Should Have: “You should have completed your training.” This implies that training was the recommended action that was not taken.
Could Have: “She could have won the race if she hadn’t fallen.” This suggests that winning was a possible outcome if not for the fall.
Would Have: “I would have called you, but I didn’t know your number.” This indicates a definite action that would have occurred if the number was known.

Avoiding Logical Pitfalls

When documenting a root cause analysis or risk assessment or any of the myriad other technical reports we are making a logical argument. In this post, I want to evaluate six common pitfalls to avoid in your writing.

Claiming to follow logically: Non Sequiturs and Genetic Fallacies

Non-sequiturs and genetic fallacies involve statements that are offered in a way that suggests they follow logically one from the other, when in fact no such link exists.

Non-sequiturs (meaning ‘that which does not follow’) often happens when we make connective explanations without justification. Genetic fallacies occur when we draw assumptions about something by tracing its origins back even though no necessary link can be made between the present situation and the claimed original one.

This is a very common mistake and usually stems from poor use of causal thinking. The best way to address it in an organization is continuing to build discipline in thought processes and documenting the connections and why things are connected.

Making Assumptions: Begging the Question

Begging the question, assuming the very point at issue happens a lot in investigations. One of the best ways to avoid this is to ensure a proper problem statement.

Restricting the Options to Two: ‘Black and White’ Thinking

In black and white thinking or the false dichotomy, the arguer gives only two options when other alternatives are possible.

Being Unclear: Equivocation and Ambiguity

Lexical: Refers to individual words
Referential: Occurs when the context is unclear
Syntactical: Results from grammatical confusions

Just think of all the various meanings of validation and you can understand this problem.

Thinking Wishfully

Good problem-solving will drive down the tendency to assume conclusions, but these probably exist in every organization.

Detecting the Whiff of Red Herrings

Human error is the biggest red herring of them all.

Problem Statement Framing

A well-framed problem statement opens possibilities, while a bad problem statement closes down alternatives and quickly sends you down dead ends of facile thinking.

Consider a few typical problem statements you might hear during a management review:

We have too many deviations
We do not have enough people to process the deviations we get
45% of deviations are recurring

You hear this sort of framing regularly. Notice that only the third is a problem, the other two are solutions. And in the case of the first statement it can leave to some negative results. The second just has you throw more resources at the problem, which may or may not be a good thing. In both cases we are biasing the problem-solving process just as we begin.

The third problem statement pushes us to think. A measurable fact raises other questions that will help us develop better solutions: why are out deviations recurring? Why are we not solving issues when they first occur? What processes/areas are they recurring in? Are we putting the right amount of effort on important deviations? How can we eliminate these deviations?

If a problem statement has only one solution, reframe it to avoid jumping to conclusions.

By focusing on a problem statement with objective facts (45% of deviations are recurring) we can ask deeper, thoughtful questions which will lead to wisdom, and to better solutions.

To build a good problem statement:

Begin with observable facts, not opinions, judgments, or interpretations.
Describe what is happening by answering questions like “How much/How many/How long/How often.” This creates room for exploration and discovery.
Iterate on the problem statement. As you think more deeply on the situation modify your first version. This is a sign that you understand more about the situation. This is the kind of data that will join with the facts you discover to lead towards sound decisions.

The 5W2H tool is always a good place to start.

5W2H	Typical questions	Contains
Who?	Who are the people directly concerned with the problem? Who does this? Who should be involved but wasn’t? Was someone involved who shouldn’t be?	Roles and Departments
What?	What happened?	Action, steps, description
When?	When did the problem occur?	Times, dates, place In process
Where?	Where did the problem occur?	Location
Why is it important?	Why did we do this? What are the requirements? What is the expected condition?	Justification, reason
How?	How did we discover. Where in the process was it?	Method, process, procedure
How Many? How Much?	How many things are involved? How often did the situation happen? How much did it impact?	Number, frequency

Remember this can be iterative as you discover more information and the problem statement at the end might not necessarily be the problem statement at the beginning.

Elements	Problem Statement
Is used to…	Understand and target a problem. Provide a scope. Evaluate any risks. Make objective decisions
Answers the following… (5W2H)	What? (problem that occurred) When? (timing of what occurred) Where? (location of what occurred) Who? (persons involved/observers) Why? (why it matters, not why it occurred) How Much/Many? (volume or count) How Often? (First/only occurrence or multiple)
Contains…	Object (What was affected?) Defect (What went wrong?)
Provides direction for…	Escalation(s) Investigation

How we tell our story

“If it Isn’t Written Down, then it Didn’t Happen” is a guiding principle of the quality profession.

There are four major types of writing in quality: instructional, informational, persuasive and transactional. When evaluated against the three major document types instructional is a functional document, informational is a report and transactional is a record. This is not to say that all transactional business writing should be considered a record, the traditional argument against emails in quality systems for example.

It is important to understand these differences as they require differences in writing style, format and grammar. An SOP (instructional/functional) is very different that an informational/report). When building your writing competencies it is important to remember these are different (with a common foundation).

We utilize reports in our quality systems (and everywhere else) to act, to communicate information, to capture work completed, to record incidents, to finalize projects and recommendations, and to act as an archive. A well written report allows the reader to easily grasp the content and, if applicable, make informed decision. Report writing is a cornerstone of a CAPA system (from incident identification to root cause through CAPA completion and effectiveness review), validation, risk management and so much more.

In short, reports are our stories, they form the narrative. And how we tell that narrative determines how we think of an issue, and how we will continue to thing of it in the future.

We tend to mix and match two modes in our report writing — Story thought and system:

Story thought emphasizes subjective human experience, the primacy of individual actors, narrative and social ordering, messiness, edge cases, content, and above all meaning.
System thought emphasizes 3rd-person descriptions of phenomena from a neutral perspective, the interchangeability of actors and details, categorical or logical ordering, measurements, flow, form, and above all coherence.

We tend to lean more heavily on system thought in quality,the roots of the discipline and the configuration of our organizations make us predisposed to the system thought mode. This means that over time, best practices accumulate that favor system thought, and many of our our partners (regulatory agencies, standard setting bodies, etc) favor the measurable and the reducible. However, by favoring the system thought mode we are at jeopardy of missing how human beings function in our organizations and how our organizations need to deal with society. And we make mistakes. Me make bad decisions. We fail to deal with the truly complicated problems.

It is time to learn how to utilize story though more in quality.