Effective Change Management

Both Curious Cat and A Lean Journey tell me that the ASQ Influential Voices blogs are covering change management. I do love a good blog carnival, and change management is sort of my thing, so I am going to jump in.

It’s often said that people don’t resist “change” so much as they resist “being changed.” So, the job of change management is clear: In a nutshell, you must explain why the affected people should want to change, and thereby cultivate readiness instead of resistance.

What are some recommended strategies or tactics to help achieve successful change management?

My first piece, of advice, abandon the idea that change management only involves people. Just as all systems are made of people, organization, process and technology; all changes impact all four and need to be viewed holistically.

Second, get rid of the artificial barriers between change management and change control. Change management is the how of change – assess, handle and release. Change control is the what, the execution steps. Remember that all changes are really just projects, and vice versa. The level of change determines the level of activity.

Level of Change	Change Management	Change Control
Transactional	Minor	Few Closely clustered
Operational	Major	Several Across several areas
Transformational	Fundamental	Many Iterative Often in waves

Simplify your variety of change controls and strive for scalability within one change management (and control) system. Utilize the levers, which include: regulatory (compliance), product release and risk.

Knowledge Management

Change Management and Knowledge Management are closely entwined. An effective change management system includes active knowledge management, in which information from multiple sources is integrated to identify stimuli for changes needed to improve product and/or process robustness.

There are key interactions with document management and training.

Risk Management

Risk management enables changes and helps assess:

The proposed change
The effectiveness of the change once implemented

Change Is

Propose the Change

curent and future

Make it SMART:

Specific – The proposal needs to be accurate and leave no doubt as to what the change will achieve.
Measurable – How will the system owner (sponsor) know when the project is complete.
Achievable – Make the change as small as possible after all it is easier to eat an elephant one bite at a time. It is far easier to manage a few smaller change than one big one. This is why operational and transformational changes are many changes and often iterative.
Realistic – Make the change easy to deliver, if it is over complicated then it is likely to hit problems and run over budget, be delivered late or of poor quality.
Timely – Does the change have to be complete by a certain date? If so put it in the scope that the project has to be complete by that date. Are there dependencies and independencies?

Evaluate

The change Project team leverages SMEs to harness the collective intelligence (synergy) for the benefit of the site.

Relevancy – The information gathered is of value
Reliability – The process by which the information is collected should be consistent
Accuracy – The data should be expressed in a manner that most accurately reflects its information content
Efficiency – The design and implementation of the tasks should minimize the burden

Evaluates all four areas (process, technology, people and organization). Includes communication of the change and training.

Vision	Importance
What is the vision for this change	Why is this change important to our organization
Success Measurements	Process Measurements
How will we measure success	How will we show progress towards our vision?
Who and what is affected?
What people, departments and processes need to change in order to realize our vision?
How will we support people?
What actions will we do to support people through the change?
What is our plan?
Detailed action plan

Build in effectiveness reviews to your plan.

Implement

Execute the change plan, provide evidence of completion. Escalate significant risks or delays.

Close

Ensure change plan was executed and benefits realized.

Hold a lessons learned.

lessons learned

Conclusion

Change management is a system. It should have its own cycles of improvement and grow as you execute changes. Change is a fundamental pillar of a quality system and spending the time to build a robust system will reap dividends and prove itself a good idea again and again.

Master and Transactional Data Management

Mylan’s 483 observation states that changes were being made to a LIMS system outside of the site’s change control process.

This should obviously be read in light of data integrity requirements. And it looks like in this case there was no way to produce a list of changes, which is a big audit trail no-no.

It’s also an area where I’ve seen a lot of folks make miss-steps, and frankly, I’m not sure I’ve always got it right.

There is a real tendency to look at the use of our enterprise systems and want all actions and approvals to happen within the system. This makes sense, we want to reduce our touch points, but there are some important items to consider before moving ahead with that approach.

Changes control is about assessing, handling and releasing the change. Most importantly it is in light the validated and regulatory impact. It serves disposition. As such, it is a good thing to streamline our changes into one system. To ensure every change gets assessed equally, and then gets the right level of handling it needs, and has a proper release.

Allowing a computer system to balkanize your changes, in the end, doesn’t really simplify. And in this day of master data management, of heavily aligned and talking systems, to be nimble requires us to know with a high degree of certainty that when we apply a change we are applying it thoroughly.

The day of separated computer systems is long over. It is important that our change management system takes that into account and offers single-stop shopping.

Changes become effective

Change Effective, implementation, routine use…these are all terms that swirl in change control, and can mean several different things depending on your organization. So what is truly important to track?

regulatory and change

Taking a look at the above process map I want to focus on three major points, what I like to call the three implementations:

When the change is in use
When the change is regulatory approved
When product is sent to a market

The sequence of these dates will depend on the regulatory impact.

	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

I’m using ‘floor’ very loosely here. “Change in use” is that point where everything you do is made, tested and/or released under the change. Perhaps it’s a batch record change. Everything that came before is clearly not under the change. Everything that came after clearly is.

You can have the same change fit into all three areas, and your change control system needs to be robust enough to manage this. This is where tracking regulatory approval per country/market is critical, and tracking when the product was first sent.

A complicated change can easily look like this (oversimplification).

building actions

Is this 1, 2 or 3 processes? More? Depends on so many factors, the critical part is building the connections and make sure your change control system both receives inputs and provides outputs. Depending on your company, the data map can get rather complicated.

29 questions to ask about your change management/change control system

While these questions are very pharma/biotech specific in places, they should serve as thought process for your own system checkup.

Is there a written SOP covering the change control program that has been approved by the Quality Unit?
Do procedures in place describe the actions to be taken if a change is proposed to a starting material, product component, process equipment, process environment (or site), method of production or testing or any other change that may affect product quality or reproducibility/robustness of the process?
Does the SOP ensure that all GMP changes are reviewed and approved by the Quality Unit?
If changes are classified as “major” or “minor,” do procedures clearly define the differences?
Does your change management system include criteria for determining if changes are justified?
Are proposed changes evaluated by expert teams (e.g. HSE, Regulatory, Quality…)?
Is there a process for cancelling a change request prior to implementation? And Is a rationale for cancellation included?”
Does your Change control management site procedure describe clearly the process to close a change request (After all regulatory approvals…)?
Are any delays explained and documented?
Is there a written requirement that change controls implemented during normal or routine maintenance activities be documented in the formal change control program?
Is your change management system linked to other quality systems such as CAPA, validation, training?
Does your change management system include criteria for determining if changes will require qualification/requalification, validation/revalidation and stability studies?
Are “like for like” changes (changes where there is a direct replacement of a component with another that is exactly the same) clearly defined in all aspects (including material of construction, dimensions, functionality,,,) ? Are they adequately documented and commissioned to provide traceability and history?”
Is there an allowance for emergency and temporary changes under described conditions in the procedures?
Are the proposed changes evaluated relative to the marketing authorization and/or current product and process understanding?
Does your change management system include criteria to evaluate whether changes affect a regulatory filling?
Are appropriate regulatory experts involved? Does the regulatory affairs function evaluate and approve all changes that impact regulatory files?
Are changes submitted/implemented in accordance with the regulatory requirements?
Is there a defined system for the formalization, roles, and responsibilities for change control follow-up?
Is the effective date of the change (completion date) recorded and when appropriate the first batch manufactured recorded?
Is there a periodic check of the implementation of Change controls?
Following the implementation, is there an evaluation of the change undertaken to confirm the change objectives were achieved and that there was no adverse impact on product quality?
Is all documentation that provides evidence of change, and documentation of requirements, controlled and retained according to procedure?
When necessary, are personnel trained before the implementation of the change?
Are change controls defined with adequate target dates?
If the change control goes beyond the target date, is there a new date attributed, evaluated and documented by Quality Assurance?
Are there routine evaluations of the Change controls and trends (number, Change controls closure, trends as defined)?
Are changes closed on due date ?
Are the Change controls and follow-up formalized in a report and/or periodic meetings?

These sort of questions form a nice way to periodically checking up on your system performance and ensuring you are moving in the right direction.

Regulatory Impact of Changes

In a regulated industry, such as pharmaceuticals or medical devices, knowing your changes impact your regulatory partners is a critical aspect of change management. For example, the MHRA in their yearly summarizations of GMP inspection deficiencies consistently cites failure to perform adequate review of need of regulatory notification (for example, see 2016 trends). And to be frank, we in the industry are often looking for more guidance, which drives responses like ICHQ12 and the FDA’s March 2018 draft guidance CMC Changes to an Approved Application: Certain Biological Products and all the other similar guidances out there.

These all follow a similar risk-based approach, and this approach should be built into your change management system (and applicable change control process).

regulatory structure2

The major difference between Supportive Information and Do-and-Record is usually what goes in your product quality report (APR/PQR). Fro example, I often see qualification of facility fit into the Do-and-Record area. These changes may not be fillable, but you certainly want to review and account for.

Many companies manage this through their regulatory affairs organization, but that can be time consuming. It is better to take the time to identify the supportive and do-and-record categories out front, thus removing the need for an extra assessment. The PQR review process is a great tool for ensuring consistent execution.

This risk based approach should look at the dossiers, taking into account any special market considerations, as well as current best practices in the regulations. For those companies lucky enough to be more towards the QbD model, established conditions will greatly help here.

Then build a matrix to help guide your changes. An example could include items like these:

Facility, Equipment, Manufacturing Systems, Utilities & Automation	Equipment/instrument maintenance
	Decommissioning of equipment not classified as critical equipment
	Computer programming that affects non-production equipment
	Alarms (i.e., notification system for out of tolerances)
	Cleaning and Sanitization of Manufacturing facilities and non-product Contact equipment
	Upgrade of Application Software or operating system
	Alarm setpoint changes
	Creating user groups and modifying user group privileges
	Tuning parameter, adjustment to the gain, reset and rate of a PID controller
Manufacturing Processes	In-process labeling
	Changes to Process Control and Operating Parameters (tightening/shifting) within current non-established conditions
	Change in equipment sterilization times
	The addition of in-process or final product samples
	Changes to sample volume for in-process or finished product samples
	Addition of new ancillary equipment (e.g. no product contact, does not control process steps) to the process

You can then further delineate between Supportive Information and Do-and-Record on a few other criteria, such as qualification/validation impact.

Like many areas of good system management, this is an area where a forethought and design can reap dividends in making your changes more nimble while preventing a compliance mishap. Tapping into the PQR makes all this part of your knowledge management system, and allows you to grow as your needs grow. This is definitely not a once-and-done process.