Quality Management as a Program

Quality System Management should be viewed and governed as a program

Program management is commonly defined as “a group of projects that contribute to a common, higher order objective.” The projects in a program are related, and the intent of achieving benefits would not be realized if the projects were managed independently.

Program management includes the practices and processes of strategic alignment, benefits management, stakeholder management, governance, and lifecycle management. Program governance creates the control framework for delivering the programs’ change objectives and making benefit delivery visible to the organization’s control.

There are different styles of program management and what I am focusing on here is what is sometimes called “heartbeat”, which aims to achieve evolutionary improvement of existing systems and processes or organizational change. This program type creates value by reconciling contradicting views and demands for change from various organization actors in order to enhance existing systems and practices while sustaining operations.

Heartbeat program management is all about awareness of the contexts of the program and requires knowledge of strategy, competition, trends in the industry, and differences in management practices between the business units of the company. A good heartbeat program manager is highly concerned about their program’s long-term effects and implications for the company’s business.

Magic triangle of a program manager

Programs exist to create value by improving the management of projects and to create benefits through better organization of projects. The fundamental goals of program management are:

  • Efficiency and effectiveness: Aspects of management that a proficient project manager should address and benefit from coordination.
  • Business focus goal: The external alignment of projects with the requirements, goals, drivers and culture of the wider organization. These goals are associated with defining an appropriate direction for the constituent projects within a program as well as for the program as a whole.
GoalDescription
Efficiency and effectiveness goals
Improved co-ordinationAssist in identification and definition of project inter-dependencies and thereby reduce the incidence of work backlogs, rework and delays
Improved dependency managementReduce the amount of re-engineering required due to inadequate management of the interfaces between projects
More effective resource utilizationImprove the effectiveness and efficiency of the allocation of shared resources
Assist in providing justification for specialist resources that deliver an overall improvement to program delivery and/or business operations
More effective knowledge transferProvide a means to identify and improve upon transferable lessons.
Facilitate organizational learning
Greater senior management ‘visibility’Enable senior management to better monitor, direct and control the implementation process
Business focus goals
More coherent communicationImprove communication of overall goals and direction both internally and externally to the program
Target management attention clearly on the realization of benefits that are defined and understood at the outset and achieved through the lifetime of the program and beyond
Assist in keeping personal agendas in check
Improved project definitionEnsure that project definition is more systematic and objective, thereby reducing the prevalence of projects with a high risk of failure or obsolescence
Enable the unbundling of activities in a strategic project-set into specific projects
Enable the bundling of related projects together to create a greater leverage or achieve economies of scale
Better alignment with business drivers, goals and strategyImproves the linkage between the strategic direction of organizations and the management activities required to achieve these strategic objectives
Provide an enabling framework for the realization of strategic change and the ongoing alignment of strategy and projects in response to a changing business environment (via project addition/culling, etc.)

The Attributes of a Good Heartbeat Program Manager are the Attributes to a Good Quality Leader

As quality leaders we are often ambassadors to ensure that the quality program is progressing despite the conflicting requirements of the various stakeholders. We need to actively influence quality-related decisions of all stakeholders, including people holding superior positions. Having a well-developed personal network within the organization is particularly helpful.

It is critical to always be communicating about the quality program in a visionary way, to be seen as passionate ambassadors. Playing this role requires constant attention to differing expectations of the stakeholders and various ways to influence stakeholders for the benefit of the quality system. To always be striving to build quality, to advance quality.

As advocates for Quality, it is a core competency to be able to stand up and defend, or argue for, the quality program and team members. This ability to challenge others, including their superiors, in a productive way is a critical ability.

A key focus of the quality program should be on engagement with a conscious and sustained drive to secure buy-in from key stakeholders (including senior management) and win over the hearts and minds of those responsible for execution to make changes feel less painful and inflicted. As quality leaders our aim should always be to engender a climate of comprehension, inclusion and trust, and to draw upon expertise globally to create fit for purpose processes and systems

Effective quality leaders need to be “heavyweight” organizational players.

Core Competencies of the Heartbeat Manager

  • Contextual awareness
  • Scenario planning
  • Political skills
  • Courage
  • Networking

A note on program life

Many standard approaches perceive programs to have a finite life. This is constraining given that the strategies themselves, especially as applied to quality, have long lifetimes. I believe that program management has as much to learn from quality management,  and there is a lot of value in seeing an indefinite time horizon as beneficial.

Quality management is an evolutionary approach, and utilizing program management methodologies within it should be taken in the same light.

Layering metrics

We have these quality systems with lots of levers, with interrelated components. And yet we select one or two metrics and realize that even if we meet them, we aren’t really measuring the right stuff nor are we driving continious improvement.

One solution is to create layered metrics, which basically means drill down your process and identify the metrics at each step.

Lots of ways to do this. An easy way to start is to use the 5-why process, a tool most folks are comfortable with.

So for example, CAPA. It is pretty much agreed upon that CAPAs should be completed in a timely manner. That makes this a top level goal. Unfortunately, in this hypothetical example, we are suffering a less than 100% closure goal (or whatever level is appropriate in your organization based on maturity)

Why 1Why was CAPA closure not 100%
Because CAPA tasks were not closed on time.

Success factor needed for this step: CAPA tasks to be closed by due date.

Metric for this step: CAPA closure task success rate
Why 2Why were CAPA tasks not closed on time?
Because individuals did not have appropriate time to complete CAPA tasks.

Metric for this step: Planned versus Actual time commitment
Why 3Why did individuals not have appropriate time to complete CAPA tasks?
Because CAPA task due dates are guessed at.

Metric for this step: CAPA task adherence to target dates based on activity (e.g. it takes 14 days to revise a document and another 14 days to train, the average document revision task should be 28 days)
Why 4Why are CAPA task due dates guessed at?
Because appropriate project planning is not completed.

Metric for this step: Adherence to Process Confirmation
Why 5Why is appropriate project planning not completed?
Because CAPAs are always determined on the last day the deviation is due.

Metric: Adherence to Root Cause Analysis process

I might on report on the top CAPA closure rate and 1 or 2 of these, and keep the others in my process owner toolkit. Maybe we jump right to the last one as what we report on. Depends on what needs to be influenced in my organization and it will change over time.

It helps to compare this output against the 12 system leverage points.

Donella Meadows 12 System Leverage Points

These metrics go from 3 “goals of the system” with completing CAPA tasks effectively and on time, to 4 “self organize” and 5 “rules of the system.” It also has nice feedback loops based on the process confirmations. I’d view them as potentially pretty successful. Of course, we would test these and tinker and basically experiment until we find the right set of metrics that improves our top-level goal.

Coherence and Quality

Sonja Blignaut on More Beyond wrote a good post “All that jazz … making coherence coherent” on coherence where she states at the end “In order to remain competitive and thrive in the new world of work, we need to focus our organisation design, leadership and strategic efforts on the complex contexts and create the conditions for coherence. “

Ms. Blignaut defines coherence mainly through analogy and metaphor, so I strongly recommend reading the original post.

In my post “Forget the technology, Quality 4.0 is all about thinking” I spelled out some principles of system design.

PrincipleDescription
BalanceThe 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.
CongruenceThe 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.
ConvenienceThe 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.
CoordinationSystem 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.
EleganceComplexity 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.
HumanParticipants in the system are able to find joy, purpose and meaning in their work.
LearningKnowledge 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.
SustainabilityThe 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.

I used the term congruence to summarize the point Ms. Blignaut is reaching with alignment and coherence. I love her putting these against the Cynefin framework, it makes a great of sense to see alignment for the obvious domain and the need for coherence driving from complexity.

So what might driving for coherence look like? Well if we start with coherence being the long range order (the jazz analogy) we are building systems that build order through their function – they learn and are sustainable.

To apply this in the framework of ICHQ10 or the US FDA’s “Guidance for Industry Quality Systems Approach to Pharmaceutical CGMP Regulations” one way to drive for coherence is to use similar building blocks across our systems: risk management, data integrity and knowledge management are all examples of that.

Materials Receipt Controls

Significantly, your firm failed to perform identification testing for all incoming glycerin lots to verify identity and determine whether diethylene glycol (DEG) or ethylene glycol (EG) was present. Because you did not test each lot and container of glycerin using the USP identification test that detects these hazardous impurities, you failed to ensure the acceptability of component lots used in drug product manufacture. DEG contamination in pharmaceutical products has caused lethal poisoning incidents in humans worldwide.

 FDA Warning Letter of 02-Nov-2018 to Product Packaging West, Inc.

First of all, ouch. This brings to mind an old investigation that drew a lot of attention a few years back. It involved a tanker truck and a hurricane, but still, lots of memories.

This Warning Letter brings to mind questions about receipt of materials. So here are some top level thoughts.

Choosing tests should be a risk based approach evaluating what the material is, what it is used for, supplier qualification level and history of test results. A critical raw material with custom chemistry from a supplier that has had issues is a different matter than an off-the-shelf component that hasn’t had a problem in 10 years. But there always should some basic identity testing, especially if that is listed in an pharmacopeia. This should be done through a formal process, with periodic review.

Have a process in place for delivery of material to ensure that each container or grouping of containers of material are examined visually for correct labeling (including correlation between the name used by the supplier and the in-house name/code, if these are different), container damage, broken seals, and evidence of tampering or contamination. A good in-coming receipt inspection includes:

  • Each lot within a shipment of material or components is assigned a distinctive code and an unique internal number so material or component can be traced through manufacturing and distribution
  • A check to guarantee the origin of materials from approved manufacturers and approved distributors
  • Start inspection with visual examination of each shipping container for appropriate labelling, signs of damage, or contamination
  • Use a predefined checklist for inspection

Incoming material should be quarantined prior to approval for use. I recommend a separate quarantine area for incoming versus material segregated for investigations or issues.

Supplier qualification deserves a post of it’s own.

Change Management of multi-site implementations

A colleague asks in response to my post Group change controls:

… deploying a Learning + documentation system … all around the word [as a global deployment]  … do we I initiate a GLOBAL CC or does each site created a local CC.

The answer is usually, in my experience, both.

Change management is about process, organization, technology and people. Any change control needs to capture the actions necessary to successful implement the change.

so at implementation I would do two sets of changes. A global to capture all the global level changes and to implement the new (hopefully) harmonized system And then a local change control at each site to capture all the site impact.

System Element Global Local
Process Introduce the new global process

Update all global standards, procedures, etc

How will local procedures change? How will local system interactions change – clean up all the local procedures to ensure the point to the new global procedures and are harmonized as necessary.
Technology Computer system validation

Global interfaces

Global migration strategy

Local interfaces (if any) and configurations

Are local technologies being replaced? Plan for decommissioning.

Local migration (tactical)

People What do people do on the global level?

How will people interact within the system in the future?

Global training

What will be different for people at each individual site?

Localized training

Organization Will there be new organizational structures in place? Is this system being run out of a global group? How will communication be run.

System governance and change management

Site organization changes

How will different organizations and sub organizations adopt, adapt and work with the system

If you just have a global change control you are at real risk of missing a ton of local uniqueness and leaving in place a bunch of old ways of thinking and doing things.

If you just do local change controls you will be at risk of not seeing the big picture and getting the full benefits of harmonization. You also will probably have way too many change controls that regurgitate the same content, and then are at risk of divergence – a compliance nightmare.

This structure allows you better capture the diversity of perspectives at the sites. A global change control tends to be dominated by the folks at each site who own the system (all your documents and training folks in this example), while a site change will hopefully include other functions, such as engineering and operations. Trust me, they will have all sorts of impact.

This structure also allows you to have rolling implementations. The global implements when the technology is validated and the core processes are effective. each site then can implement based on their site deliverables. useful when deploying a document management system and you have a lot of migration.

Multisite changes

As part of the deployment make sure to think through matters of governance, especially change management. Once deployed it is easy to imagine many changes just needing a central change control. But be sure to have thought through the criteria that will require site change controls – such as impact other interrelated systems, site validation or different implementation dates.

I’ve done a lot of changes and a lot of deployment of systems. This structure has always worked well. I’ve never done just a global and been happy with the final results, they always leave too much unchanged elements behind that come back to haunt you. In the last year I’ve done 2 major changes to great success with this model, and seen one where the decision not to use this model has left us with lots of little messes to clean up.

As a final comment, keep the questions coming and I would love to hear other folks perspectives on these matters. I’m perpetually learning and I know there are lots of permutations to explore.