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.

 

 

Sometimes quality requires forgetting

DeHolan and Phillips introduced the concept of organizational forgetting to our concepts of knowledge management. While unintentional forgetting is something we usually want to avoid, there is a time when we want to intentionally forget.  Perhaps after a corporate merger we are combining systems or replacing systems. Perhaps it is the result of a large step forward in technology, or an out-right replacement. Some major cultural transformation comes along. And the last thing we want is for no-one to be able to forget the old. For those concepts to linger in our memory and our decisions. For that is a risk that can easily lead to deviations.

 

4529-si1-lo8

Take for example changes in document numbering. Fairly simple of the surface but remember that procedure number is the tag which we use in conversation. No-one ever gives the whole title; we throw around these tags left and right and for our own coded language (another topic worthy of a blog post). Then we change our numbering format and a year later everyone still uses the old number. And mistakes start creeping up. Or just the perception of mistakes builds. Or perhaps everyone still thinks in the manner of the old ERP’s logic, and forget to do crucial aspects of master data management when a change is made. You get the idea

This purposeful frogetting, an aspect of knowledge management (and change management) – that of the purposeful removal of knowledge — is a critical step in our systematic approach and an important part of our strategic toolkit. However, it is very difficult, as deeply embedded pieces of organizational knowledge are generally locked in place by various other pieces of organizational knowledge that depend on them, and removing one implies modifying the others as well. We need to develop the tools to dismantle the previous way of doing work — the unneeded routines and formerly dominant logics of our changed systems.

One of the best way to do this is to get rid of cues. All the little breadcrumbs left behind. If you want people to stop using old document numbers, ensure that no document folks would use on their daily basis has those numbers. However, this ideal model of radical elimination of all cues associated with the old routine seems rather unlikely in all changes from old to new . So when we are working on our change its important to select those cues that will have the biggest bang for our buck. Some general ideas to help inform this are:

  • Look for opportunities to drive out mix-messages – aim for consistency in message
  • Ensure there are positive reinforcements for use of the new routine
  • Actively constrain the to-be-forgotten activity. Reduce the time in two different processes. Do a radical transformation. Reduce the confusion.
  • Reward the individual for participating in the new way. The group can’t change faster than the sum of the individuals, so incentive the change.

When doing a change it is important to consider these as risks, and build into your change plan. Incorporate into your training. For the basis of your communications. Drive out the old, embrace the new. Otherwise you are just increasing the risks inherent in your new way of working. But like many aspects of change management, easy in concept, difficult in execution.

Knowledge management as continuous improvement

An effective change management system includes active knowledge management, leveraging existing process and product knowledge; capturing new knowledge gained during implementation of the change; and, transferring that knowledge in appropriate ways to all stakeholders.

Any quality system (any system) has as part of it’s major function transforming data into information; the acquisition and creation of knowledge; and the dissemination and using information and knowledge. A main pipe of process improvement is how to implicit knowledge and make it explicit. This is one of the reasons we spend so much time developing standardized work.

And yet I, like many quality professionals, have found myself sitting at a table or standing in front of a visual management board, and have some type of leader ask why we spend so much time training when we should be able to hire anyone with an appropriate level of experience and have them just do the job.

Systems are made up of four things – process, organization, people and technology. When folks think of change management, or root cause analysis, or similar quality processes and tools they tend to think the system is only about the activity we are engaging in. But change management (or root cause analysis or data integrity) is not that simple.

This is really two-fold. A person assessing a change is not just needing to be knowledgeable about how the change control process works, they need to be able to analyze the change to each and every process within the systems they represent, to understand how moving the levers and adjusting the buffers within this change influences each and everything they do, even it that’s to be able to make a concrete and definitive no impact statement.

So when we process improve our change management system (or similar quality processes) we are both improving how we manage change and how folks apply that thinking to all their other activities.

In less mature systems we end up having a lot of tacit knowledge in one person. You have that great SME who understands master data in the ERP and how changes impact it. In way to transfer that tacit knowledge to another person is a lot of socialization. It is experiential, active and a “living thing,” involving capturing knowledge by spending a lot of time with that person and having shared experience, which results in acquired skills and common mental models.

For example, my master-data guru needs to be involved in each and every change that might possibly involve the ERP or master-data. I might have reached the point where the procedure has large sections that give detailed instructions on when to involve the master-data guru in a change. The master-data guru spends a lot of time justifying no-impact. Otherwise I might be having change after change forget to update master data. Which leads to deviations.

At this stage of maturity I’ve recognized I need a master data guru. I’ve identified the individual(s). Depending on maturity I either involve the master-data guru on every change or I’ve advanced enough that I have a decision tool that drives changes to the master-data guru.

So now either the master-data guru is becoming a pain point or we’ve had one too many changes that led to deviations because we failed to change master data in the ERP correctly. So we enter a process improvement cycle.

What we need to do here is make the master-data guru’s tacit knowledge explicit; we need to externalize this knowledge. We start building the tools that better define what never has impact, what always has impact, and what might have impact or be really unique. When a change has no impact, the change owner is able to note that and move on (no master-data guru involvement necessary). When it has definite impact the change owner is able to identify the actions required, knowing exactly what procedures to follow and how to execute those within a change. We still have a set of changes that will trigger the master-data guru’s involvement, but those are smaller in number and more complex in scope.

The steps we took to get here also allow us to more easily develop and train master-data gurus. Maybe we have a skills matrix and it is on development plans. Our training program now has the tools to allow internalization, the process of understanding and absorbing explicit knowledge into tacit knowledge held by the individual.

At this point I have the tools for my average change owner to know when to change master data and how-to-do it (this might not involve them actually doing master data management it is really knowing when to execute, and the outputs from and inputs back into the change management system) AND I have better mechanisms for producing master data experts. That’s the beauty here, the knowledge level required to execute change management properly is usually an expert level competency. By making that knowledge explicit I am serving multiple processes and interrelated systems.

Knowledge management Circular_Process_6_Stages (for expansion)

To breakdown the process:

  1. Capture all the knowledge. Interview the SME(s), evaluate the use of the system, gather together all the procedures and training and user manuals and power point slides
  2. Assess what is valuable, what needs to be transferred
  3. Share this knowledge, make sure others can understand it
  4. Contextualize into standard tools (job aids, user guides, checklists, templates, etc.)
  5. Apply the knowledge. Train others and also update your system processes (and maybe technology) to make sure the knowledge is used.
  6. Update – make sure the knowledge is sustained and regularly updated.

Change management has lots of inputs and outputs. As does data integrity and may other quality systems. Understanding these interrelationships, ensuring knowledge is appropriate captured and utilized, is a big way we improve and thrive.

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:

  1. When the change is in use
  2. When the change is regulatory approved
  3. 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.

  1. Is there a written SOP covering the change control program that has been approved by the Quality Unit?
  2. 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?
  3. Does the SOP ensure that all GMP changes are reviewed and approved by the Quality Unit?
  4. If changes are classified as “major” or “minor,” do procedures clearly define the differences?
  5. Does your change management system include criteria for determining if changes are justified?
  6. Are proposed changes evaluated by expert teams (e.g. HSE, Regulatory, Quality…)?
  7. Is there a process for cancelling a change request prior to implementation? And Is a rationale for cancellation included?”
  8. Does your Change control management site procedure describe clearly the process to close a change request (After all regulatory approvals…)?
  9. Are any delays explained and documented?
  10. Is there a written requirement that change controls implemented during normal or routine maintenance activities be documented in the formal change control program?
  11. Is your change management system linked to other quality systems such as CAPA, validation, training?
  12. Does your change management system include criteria for determining if changes will require qualification/requalification, validation/revalidation and stability studies?
  13. 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?”
  14. Is there an allowance for emergency and temporary changes under described conditions in the procedures?
  15. Are the proposed changes evaluated relative to the marketing authorization and/or current product and process understanding?
  16. Does your change management system include criteria to evaluate whether changes affect a regulatory filling?
  17. When appropriate are regulatory experts involved? Does the regulatory affairs function evaluate and approve all changes that impact regulatory files?
  18. Are changes submitted/implemented in accordance with the regulatory requirements?
  19. Is there a defined system for the formalization, roles and responsibilities for change control follow-up?
  20. Is the effective date of the change (completion date) recorded and when appropriate the first batch manufactured recorded?
  21. Is there a periodic check of implementation of Change controls?
  22. 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?
  23. Is all documentation that provides evidence of change, and documentation of requirements, controlled and retained according to procedure?
  24. When necessary, are personnel trained before the implementation of the change?
  25. Are change controls defined with adequate target dates?
  26. If the change control goes beyond the target date, is there a new date attributed, evaluated and documented by Quality Assurance?
  27. Are there routine evaluations of the Change controls and trends (number, Change controls closure, trends as defined)?
  28. Are changes closed on due date ?
  29. 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.

Training assessment as part of change management

One of the key parts of any change (process improvement, project, etc) is preparing people to actually do the work effectively. Every change needs to train.

Building valid and reliable training at the right level for the change is critical. Training is valid when it is tied to the requirements of the job – the objectives; and when it includes evaluations that are linked to the skills and knowledge started in the objectives. Reliability means that the training clearly differentiates between those who can perform the task and those who cannot.

A lot of changes default to read-and-understand training. This quite bluntly is the bane of valid and reliable training with about zero value and would be removed from our toolkit if I had my way.

There are a lot of training models, but I hold there is no single or best method. The most effective and efficient combination of methods should be chosen depending on the training material to be covered and the specific needs of the target group.

For my purposes I’ll draw from Edgar Dale’s Cone of Experience, which incorporates several theories related to instructional design and learning processes. Dale theorized that learner’s retain more information on what they “do” as opposed to what is “heard,” “read” or “observed.” This is often called experiential or action learning.

dalescone

Based on this understanding we can break the training types down. For example:

  • Structured discussions are Verbal and some Visual
  • Computer Based Trainings are mostly Records
  • Instructor Led Trainings are a lot about Demonstration
  • On-the-job training is all about the Experience

Once we have our agreed upon training methods and understand what makes them a good training we can then determine what criteria of a change leads to the best outcome for training. Some example criteria include:

  • Is a change in knowledge or skills needed to execute the procedure?
  • Is the process or change complex? Are there multiple changes?
  • Criticality of Process and risk of performance error? What is the difficulty in detecting errors?
  • What is the identified audience (e.g., location, size, department, single site vs. multiple sites)?
  • Is the goal to change workers‘ conditioned behavior

This sort of questioning gets us to risk based thinking. We are determining where the biggest bang from our training is.

Building training is a different set of skills. I keep threatening a training peer with doing a podcast episode (probably more than one) on the subject (do I really want to do podcasts?).

The last thing I want to leave you is build training evaluations into this. Kilpatrick’s model is a favorite – Level 4 Results evaluations which tell us how effective our training was overtime actually makes a darn good effectiveness review. I strongly recommend building that into a change management process.