Between January 2016 and May 2019, you recorded approximately 397 customer complaints related to container closure issues (e.g., approximately 60%), product separation, lack of effect and adverse events. Your quality unit failed to adequately review these complaints, identify trends, and implement effective CAPAs. During the inspection you explained that these lapses in quality system performance were due to underperforming staff, who had since been dismissed. In your response, you attributed these and other quality related issues to under staffing of the quality unit as your business expanded.
Your response is inadequate because you failed to appropriately address your quality unit not performing their required duties. Your firm must provide the quality unit with the appropriate authority, sufficient resources, and staff to carry out its responsibilities to consistently ensure drug quality.
Continuing the trend of making me petrified about generics, this warning letter is a roller coaster read. One big set of failures to actually investigate and apply appropriate resources to the quality unit. And then the management had the gall to blame the employees.
80+ years of quality principles ignored. I personally thought the FDA was being overly nice.
There are basically three questions to answer:
Do you have a properly established, staffed, and managed Quality Unit?
Does your Quality Unit have appropriate responsibilities and authority?
Does your Quality Unit have access to the data it needs to make informed decisions?
We gather for a meeting, usually around a table, place our collective attention on the problem, and let, most likely let our automatic processes take over. But, all too often, this turns out to be a mistake. From this stems poor meetings, bad decisions, and a general feeling of malaise that we are wasting time.
Problem-solving has stages, it is a process, and in order for groups to collaborate effectively and avoid talking past one another, members must simultaneously occupy the same problem-solving stage. Clear communication is critical here and it is important for the team to understand what. Our meetings need to be methodical.
In a methodical meeting, for each issue that needs to be discussed, members deliberately and explicitly choose just one problem-solving stage to complete.
To convert an intuitive meeting into a methodical one take your meeting agenda, and to the right of each agenda item, write down a problem-solving stage that will help move you closer to a solution, as well as the corresponding measurable outcome for that stage. Then, during that part of the meeting, focus only on achieving that outcome. Once you do, move on.
A Template for Conducting a Methodical Meeting
Pair each agenda item with a problem solving stage and a measurable outcome.
Problem Solving Stage
Select a venue for the offsite
List of potential venues
Discuss ERP usage problems
Implement new batch record strategy
Plan for Implementation
List of actions / owners / due dates
Review proposed projects
List of strengths and weaknesses
Choose a vendor
If you don’t know which problem-solving stage to choose, consider the following:
Do you genuinely understand the problem you’re trying to solve? If you can’t clearly articulate the problem to someone else, chances are you don’t understand it as well as you might think. If that’s the case, before you start generating solutions, consider dedicating this part of the meeting to framing and ending it with a succinctly written problem statement.
Do you have an ample list of potential solutions? If the group understands the problem, but hasn’t yet produced a set of potential solutions, that’s the next order of business. Concentrate on generating as many quality options as possible (set the alternatives).
Do you know the strengths and weaknesses of the various alternatives? Suppose you have already generated potential solutions. If so, this time will be best spent letting the group evaluate them. Free attendees from the obligation of reaching a final decision—for which they may not yet be ready—and let them focus exclusively on developing a list of pros and cons for the various alternatives.
Has the group already spent time debating various alternatives? If the answer is yes, use this part of the meeting to do the often difficult work of choosing. Make sure, of course, that the final choice is in writing.
Has a decision been made? Then focus on developing an implementation plan. If you’re able to leave the conversation with a comprehensive list of actions, assigned owners, and due dates, you can celebrate a remarkably profitable outcome.
Let’s cut right to the heart of the report’s recommendations:
“The panel makes six policy recommendations that are intended “to move the organization to a place where safety is a priority and is culturally integrated into every aspect of their mission.” They include establishing better safety performance indicators, identifying the areas where maintenance is being deferred, implementing stronger data collection, and strengthening the MBTA’s leadership team with “more seasoned” transit professionals.“
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 addressed 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
Linear cause-and-effect pathways allow us to identify individual causes for observed effects.
Because 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
Every input has a proportionate output
Outputs 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
We can decompose the system into its structural parts and fully understand the functional relationships between these parts in a piecemeal way.
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.
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 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.