Group change controls

A colleague asks:

hoping you can provide your perspective on “grouping changes”. That is, rules or guidance on when it is appropriate to lump several small changes into one change control.

There are lots of reason’s to want to group changes into one change control – ease of implementation, a perception of “reducing work” or just convenience. I apply three general rules for when this is a good idea:

Implementation

All changes should have the same “Change in Use” and “Regulatory Approval”

I talked about this is in “Changes become effective“:

	Tell and Do	Do and Tell	Do and Report
Change in use	After regulatory approval. When change is introduced to the ‘floor’	When change is introduced to the ‘floor’	When change is introduced to the ‘floor’
Regulatory approval	Upon approvals	After use, before send to market	Upon reporting frequency (annual, within 6 months, within 1 year)
Sent to market	After regulatory approval and change in use	After regulatory approval and change in use	After change in use

Ideally chose all changes that are “Do and Tell” or “Do and report”, I strongly do not recommend blending “Tell and Do,” there are just so many complexities here and it can lead to a constant revision of change controls and even increase risk of inadvertently sending products to the market.

Release of Product

All changes bundled together need to be releasable at the same time. Look at PQ/PV requirements and other testing that can be different and keep them in segregated change controls. Putting product on stability (or even needing stability data) is another good reason to separate changes.

Similarly, keep changes that have different internal product segregation requirements unbundled.

Concreteness of Work Bundles

The best reason to bundle changes is that they involve changing the same things: same documents, same automation, same piece of equipment. Once the bundling starts increasing scope of the change, it is time to have separate change controls.

If bundling changes starts changing your project management triangle (resources, time, scope) then do a deep evaluation. You probably have separate change controls, even if they are under the same project.

Evaluate effectiveness reviews. Chances are totally separate effectiveness reviews for same impacted area are really separate changes.

What about risks?

You might notice that I do not call out risks as one of the criteria. Risks drive mitigations, which drive impact to the three criteria I gave. If a high risk’s mitigation does not trigger one of these criteria, it is usually not a problem to group the changes together. Though I’d pause and consider why the addition of a change that adds high risks does not drive mitigations that change the amount of work I am doing and ensure that is appropriately documented.

Conclusion

Sometimes bundling changes make sense. other times you will curse the day you agreed to bundle. I find these three rules provide a framework for making the decision.

Liminal – ‘In Between’ Words and Phrases

Words to describe those in-between, stuck in the middle, between the devil and the deep blue sea, liminal kinds of things.
— Read on www.merriam-webster.com/words-at-play/in-betweens-words-and-phrases/liminal

As a quality professional I can use threshold, interstice and even liminal and occasionally be-twixt. But now I need to be ‘between the devil and the deep blue sea’ more often at quality management reviews and the visual management boards.

What is in a title

Recently I’ve seen a few inspection observations that have provided an observation on the title of quality record (e.g. deviation, CAPA, change control).

The title might seem the most basic part of a quality system record – a simple task – but instead it should receive some serious thought. This is any inspector’s first interaction, it serves as a historical flag that generations of readers will use to become familiar. And everyone falls prey to “judging a book by its cover.” This cognitive bias tends to make readers considerably susceptible to allowing the quality systems title to function as the sole factor influencing their decision of whether to read or skip a record. A bad title could shape an inspection or deprive an important historical record from being evaluated in the future. We can do better.

A good quality systems record title:

Condenses the record’s content in a few words
Differentiates the record from other records of the same subject area

Some general tips:

Keep it simple and brief: The primary function of a title is to provide a precise summary of the record’s content. So keep the title brief and clear. Use active verbs instead of complex noun-based phrases, and avoid unnecessary details. Moreover, a good title for a record is typically around 10 to 12 words long. A lengthy title may seem unfocused and take the readers’ attention away from an important point.

Avoid: Wrong label issued

Better: Sample ABCD was issued label 1234 instead of label X4572

Use appropriate descriptive words: A record title should contain key words used in the record and should define the nature of the quality systems event. Think about terms people would use to search for your record and include them in your title.

Avoid: No LIMS label for batch ABDC

Better: Batch ABDC was missing label Y457 as required by procedure LAB-123

Avoid abbreviations and jargon: Known abbreviations can be used in the title. However, other lesser-known or specific abbreviations and jargon that would not be immediately familiar to the readers should be left out.

It sometimes surprises folks how simple things can have ripple effects. But they do, so plan accordingly and ensure your users are trained on writing a good title. Trust me; it will make things easier in the long run.

Forget the technology, Quality 4.0 is all about thinking

Quality 4.0 is Industry 4.0 which is really just:

A ton of sensors (cheap, reliable sensors for everyone)
Data everywhere! (So much data. Honest data is good. Trust us.)
Collaboration (Because that never happened before technology)
Machine learning (this never ends well in the movies)

However, Quality 4.0 is really a lot more than the technology, it is all about using that technology to improve our quality management systems. So Quality 4.0 is really all about understanding that the world around us, and thus the organizations we work in, is full of complex and interconnected challenges and increasingly open systems of communication, and that we can no longer afford to address complex issues as we have in the past. The very simple idea behind Quality 4.0 is that current and future challenges requires thinking that is consistent with a living world of complexity and change.

As such there is nothing really new about Quality 4.0; it is just a consolidation of a lot of themes of change management, knowledge management and above all system thinking.

System Thinking requires quality professionals to develop the skills to operate in a paradigm where we see our people, organizations, processes and technology as part of the world, a set of dynamic entities that display continually emerging patterns arising from the interactions among many interdependent connecting components.

There are lots of tools and methodologies for managing systems. Frankly, a whole lot of them are the same that have been in use in quality for decades; others are new tools. The crucial thing to remember about Quality 4.0 is that it is an additive and transformative way to look at quality, and quite frankly one can go back and read Deming and see the majority of this there.

When I work on systems (which is according to my job description my core function), I keep some principles always in mind.

Principle	Description
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.
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.
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.
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.
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.
Human	Participants in the system are able to find joy, purpose and meaning in their work.
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.
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.

In order to be successful utilizing these principles when designing systems and processes we need to keep user at the forefront — striving to be sensitive to the user, to understand them, their situation and feelings: to be more empathetic.

components of empathy

We leverage both the affective component and the cognitive component of empathetic reasoning, in short we need to both share and understand.

We are in short asking 5 major questions:

What is the purpose of the system? What happens in the system?
What is the system? What’s inside? What’s outside? Set the boundaries, the internal elements and elements of the system’s environment.
What are the internal structure and dependencies?
How does the system behave? What are the system’s emergent behaviors and do we understand their causes and dynamics?
What is the context? Usually in the terms of bigger systems and interacting systems.

Think holistically, think empathetically with the user, and ask questions about system behavior. Everything else falls into place from there.

ASQ Round up of quality blogs – change management

The ASQ Voices of Quality roundup on change management was posted today. I wrote my thoughts last week. After reading all of the consolidated blog posts I have a few more thoughts:

Avoid being reductive on change management. Everyone focuses on people, and then mentions how hard it is. I think part of this is the lack of system thinking. People use processes in an organization enabled by technology.
If you only pull out change management for the transformational projects you aren’t exercising it enough. It needs to be built into all continuous improvement activities.
Change Management is enabled by knowledge management and risk management. Without these in place and well understood, change management will be much harder than it should be.