Author: Jeremiah Genest

Quality professional with over 20 years of experience. Gamer and storyteller with forty years of practice.

The difference between complex and complicated

We often think that complicated and complex are on a continuum, that complex is just a magnitude above complicated; or that they are synonyms. These are actually different, and one cannot address complex systems in the same way as complicated. Many improvement efforts fail by not seeing the difference and they throw resources at projects that are bound for failure because they are looking at the system the wrong way.

Complicated problems originate from causes that can be individually distinguished; they can be address­ed piece by­ piece; for each input to the system there is a proportionate output; the relevant systems can be controlled and the problems they present admit permanent solutions.

Complex problems result from networks of multiple interacting causes that cannot be individually distinguished and must be addressed as entire systems. In complex systems the same starting conditions can produce different outcomes, depending on interactions of the elements in the system. They cannot be addressed in a piecemeal way; they are such that small inputs may result in disproportionate effects; the problems they present cannot be solved once and for ever, but require to be systematically managed and typically any intervention merges into new problems as a result of the interventions dealing with them;  and the relevant systems cannot be controlled – the best one can do is to influence them, or learn to “dance with them” as Donella Meadows said.

Lets break down some ways these look and act different by looking at some of the key terminology.

Causality, the relationship between the thing that happens and the thing that causes it

Complicated Linear cause-and-effect pathways allow us to identify individual causes for observed effects.
ComplexBecause we are dealing with patterns arising from networks of multiple interacting (and interconnected) causes, there are no clearly distinguishable cause-and-effect pathways.

This challenges the usefulness of root cause analysis. Most common root cause analysis methodologies are based on cause-and-effect.

Linearity,  the relationships between elements of a process and the output

ComplicatedEvery input has a proportionate output
ComplexOutputs are not proportional or linearly related to inputs; small changes in one part of the system can cause sudden and unexpected outputs in other parts of the system or even system-wide reorganization.

Think on how many major changes, breakthroughs and transformations, fail.

Reducibility, breaking down the problem

ComplicatedWe can decompose the system into its structural parts and fully understand the functional relationships between these parts in a piecemeal way.
Complex The structural parts of the system are multi-functional — the same function can be performed by different structural parts.  These parts are also richly inter-related i.e. they change one another in unexpected ways as they interact.  We can therefore never fully understand these inter-relationships

This is the challenge for our problem solving methodologies, which mostly assume that a problem can be broken down into its constituent parts. Complex problems present as emergent patterns resulting from dynamic interactions between multiple non-linearly connected parts.  In these systems, we’re rarely able to distinguish the real problem, and even small and well-intentioned interventions may result in disproportionate and unintended consequences.

Constraint

Complicated One structure-one function due to their environments being delimited i.e. governing constraints are in place that allows the system to interact only with selected or approved types of systems.  Functions can be delimited either by closing the system (no interaction) or closing its environment (limited or constrained interactions).

Complicated systems can be fully known as a result and are mappable.
Complex Complex systems are open systems, to the extent that it is often difficult to determine where the system ends and another start.   Complex systems are also nested they are part of larger scale complex systems, e.g. an organisation within an industry within an economy.  It is therefore impossible to separate the system from its context.

This makes modeling an issue of replicating the system, it cannot be reduced. We cannot transform complex systems into complicated ones by spending more time and resources on collecting more data or developing better maps.

Some ideas for moving forward

Once you understand that you are in a complex system instead of a complicated process you can start looking for ways to deal with it. These are areas we need to increase capabilities with as quality professionals.

  • Methodologies and best practices to decouple parts of a larger system so they are not so interdependent and build in redundancy to reduce the chance of large-scale failures.
  • Use storytelling and counterfactuals. Stories can give great insight because the storyteller’s reflections are not limited by available data.
  • Ensure our decision making captures different analytical perspectives.
  • Understand our levers

PIC/S on Change Review and Effectiveness

Starting from the end, let’s review some of the requirements in the new draft PIC/S guidance.

Prior to change closure

RequirementImportant Points
Changes meet their intended objectives and pre-defined effectiveness criteria. Any deviations from those criteria are adequately assessed, accepted and managed/justified. Whenever possible, quantitative data are leveraged to objectively determine change effectiveness (e.g. statistical confidence and coverage).Clearly delineating what effective means as a date is critical to generate data.

CQV activities can tell you if the intended objective is met. Effectiveness reviews must be made up of:

Sufficient data points, as described in the implementation plan, gathered to a described timeline, before an assessment of the change is made.

The success criteria should be achieved. If not, reasons why they have not been achieved should be assessed along with the mitigation steps to address the reasons why, including reverting to the previous operating state where appropriate. This may require the proposal of a subsequent change or amendment of the implementation plan to ensure success.

Data and knowledge gathered from implementation of the change should be shared with the development function and other locations, as appropriate, to ensure that learning can be applied in products under development or to similar products manufactured at the same or other locations
As part of the quality risk management activities, residual risks are assessed and managed to acceptable levels, and appropriate adaptations of procedures and controls are implemented.These are action items in the change control.

As part of the closure activities, revise the risk assessment, clearly delineating risk assessment in two phases.
Any unintended consequences or risks introduced as a result of changes are evaluated, documented, accepted and handled adequately, and are subject to a pre-defined monitoring timeframe.Leverage the deviation system.

Prior to or after change closure

RequirementImportant Points
Any post-implementation actions needed (including those for deviations from pre-defined acceptance criteria and/or CAPAs) are identified and adequately completed.If you waterfall into a CAPA system, it is important to include effectiveness reviews that are to the change, and not just to the root cause.
Relevant risk assessments are updated post-effectiveness assessments. New product/process knowledge resulting from those risk assessments are captured in the appropriate Quality and Operations documents (e.g. SOPs, Reports, Product Control Strategy documents, etc.)Risk management is not a once and done for change management.
Changes are monitored via ongoing monitoring systems to ensure maintenance of a state of control, and lessons learned are captured and shared/communicated.Knowledge management is critical as part of the product management lifecycle.

Lessons learned are critical.

Regulatory Focus on Change Management

November was an exciting month for change management!

ICH Q12 “Technical and Regulatory Considerations for Pharmaceutical Product Lifecycle Management” was adopted by the ICH in Singapore, which means Q12 is now in Stage 5, Implementation. Implementation should be interesting as concepts like “established conditions” and “product lifecycle management” which sit at the core of Q12 are still open for interpretation as Q12 is implemented in specific regulatory markets.

And then, to end the month, PIC/S published draft 1 of PI 054-1 “Recommendation on How to Evaluate / Demonstrate the Effectiveness of a Pharmaceutical Quality System in relation to Risk-based Change Management.”

This draft guidance is now in a review period by regulatory agencies. Which means no public comments, but it will be applied on a 6-month trial basis by PIC/S participating authorities, which include the US Food and Drug Administration and other regulators across Europe, Australia, Canada, South Africa, Turkey, Iran, Argentina and more.

This document is aligned to ICH Q10, and there should be few surprised in this. Given PIC/S concern that “ongoing continual improvement has probably not been realised to a meaningful extent. The PIC/S QRM Expert Circle, being well-placed to focus on the QRM concepts of the GMPs and of ICH Q10, is seeking to train GMP inspectors on what a good risk-based change management system can look like within the PQS, and how to assess the level of effectiveness of the PQS in this area” it is a good idea to start aligning to be ahead of the curve.

“Changes typically have an impact assessment performed within the change control system. However, an impact assessment is often not as comprehensive as a risk assessment for the proposed change.”

This is a critical thing that agencies have been discussing for years. There are a few key takeaways.

  1. The difference between impact and risk is critical. Impact is best thought of as “What do I need to do to make the change.” Risk is “What could go wrong in making this change?” Impact focuses on assessing the impact of the proposed change on various things such as on current documentation, equipment cleaning processes, equipment qualification, process validation, training, etc. While these things are very important to assess, asking the question about what might go wrong is also important as it is an opportunity for companies to try to prevent problems that might be associated with the proposed change after its implementation.
  2. This 8 page document is really focusing on the absence of clear links between risk assessments, proposed control strategies and the design of validation protocols.
  3. The guidance is very concerned about appropriately classifying changes and using product data to drive decisions. While not specifying it in so many words, one of the first things that popped to my mind was around how we designate changes as like-for-like in the absence of supporting data. Changes that are assigned a like-for-like classification are often not risk-assessed, and are awarded limited oversight from a GMP perspective. These can sometimes result in major problems for companies, and one that I think people are way to quick to rush to.

Much of my thoughts on implementing this can be found in my presentation on change management and change control.

It is fascinating to look at appendix 1, which really lays out some critical goals of this draft guidance: better risk management, real time release, and innovative approaches to process validation. This is sort of the journey we are all on.