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.


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.

Every change is a project, every project is a change

Project Management, the structured approach for managing tasks, resources, and budget to achieve a defined deliverable, is an important part of the quality management toolbox, and an important aspect to build into your change management program.

There are a lot of project management methodologies, but they all boil down to having an understanding of the tradeoffs between time, cost, and scope of a change; and then motivating a team towards delivering the change.

project and change comparison

Evaluate is best seen as a gate at the end of the project’s design (or a phase of design). A well-designed project, with appropriate stakeholders and team members ideally will flow nicely into an evaluate change control (or set of change controls). Having this as part of your gate to develop will ensure that the right subject-matter-experts have been involved, that all potential risks and impacts are understood, and will ensure the site is ready to implement.

Small projects and the change management lifecycle are usually one and the same.

For projects with large impact, it is often important to create more than one change control, to ensure appropriate implementations. In these cases it is often useful to create a change strategy (or incorporate in a project deliverable, such as a gate document) which can include:

Scope Describe the project, indicating the current and future state.
Roles/ Responsibilities Indicate what functions/departments will serve what role in the change controls

Indicate the role and responsibilities of project management.

Methodology/ Strategy What activities are included and how they will be organized.

How many change controls will be created as part of this strategy.

How change controls will be organized and linked together (e.g. dependencies).

Provide a methodology for managing changes and ensuring all change control activities happen according to the provided timetable.

Things to Consider:

Are there other changes that affect the same room/area or equipment?

How are affected rooms/areas/equipment being taken out of and placed back into service as to not to interfere with provided timetable?

Will these change controls effect daily operations/sampling?

How will changes be organized? For example will changes be organized along install, validate and implement?

If multiple areas are to be effected, will there be changes in Material and Personnel Flow that will need to be modified to execute the multiple changes?

Effectiveness Review If the project will have one effectiveness review (e.g. a process validation, comparability protocol, stability study) indicate, provide the effectiveness review criteria and justify. Provide a timeline for completion of the effectiveness review.
Regulatory Strategy Regulatory strategy for filing the project (e.g. will changes be filed independently or together, at what point, which changes will require regulatory assessment)
Planned Timetable Timelines for writing, approving, implementing and closing change controls.

Take the dependencies written in the Methodology/Strategy into consideration when developing the timetable

Closure Plan How will the strategy be closed? What are the criteria for a successful project closure?

For larger projects, the change evaluation will start in the project design phase but can continue through implementation as individual changes are put in place.

The advantage of writing this strategy allows the project to consolidate deliverables and ensure the right level of effort is put into the changes across the project.

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.



Change Management and Communication

All changes need to be communicated to internal and external stakeholders. The development of the communication plan should be part of the change management system.

One of the better models I’ve used is Prosci’s ADKAR.


This is a good model because it matches very nicely to the 4 major phases of change.

  • In Propose we focus on Awareness and Desire
  • In Evaluate we focus on Knowledge and Ability
  • in Implement we focus on Ability and Reinforcement
  • And in Close, we focus on sustained Reinforcement and perhaps Awareness of a new change.

Not every change is the same size, and not every change uses the same tactics of communication. Often these tactics are training.

A table, such as the one below, can help.

Item Description of What it is Audience Publication Date
List each of the proposed elements of your communication plan Be sure to include key stakeholder outreach along with all other tactics Who List the date you want the communication delivered

There are lots of good tools out there for communicating. This post was prompted by this post on elevator pitches, which are one of my favorite items in my toolkit. Every change, big or small, should have an elevator pitch ready to go. And make sure it evolves according to the change/process improvement lifecycle.

Risk Management enables Change

Every change has a degree of risk. We cannot understand that unless we utilize risk management as a key enabler. Change management utilizes risk management to appropriately evaluate knowledge management.

risk and change management connections

First, we need to understand that not everything we do in a change is a risk. There are also impacts.

Impacts are the things that will be impacted by the change. if I revise my HVAC system, my air monitoring program will be impacted. Subject matter experts can easily identify these, they can be checklisted, they are easy to standardized. If I can X, Y needs to happen. All of these impacts end up on the action plan.

Risk management instead looks at what could happen as a result of the change. In change control it is important to evaluate both the future state and the process of implementing the future state.

In the diagram above the four major aspects of change are linked to the risk management activities we do.

When we propose a change we often are using an already existing risk assessment to drive the decision making. We can also conduct risk assessments as part of our option analysis, and design activities.

In change plan development (evaluation), we also add in the risk of implementing the change. Depending on the risk management activities that happened in propose the formality of this risk assessment will change. Our risk assessment drives an action plan, which manages the mitigations, the risk control.

In Implement, we do the work to mitigate the identified risks. By accepting the change we accept the mitigated risks. How we break the change into pre-implementation, implementation and post-implementation activities will be driven heavily by risk mitigation.

And in closure, we come back to ensure risks are appropriately mitigated.  If formal risk assessments (such as the FMEA) drove the change, we return and rescore the risks against their new, mitigated, state.

Effectiveness reviews can be tied back to risk review activities.


Change Management and Document Control

“If it isn’t documented, it didn’t happen” is an often-repeated and heavily loaded phrase. One that I want to unpack in a lot of ways on this blog.

Here I want to focus on the interaction between change management and document control, as I think the two are closely intertwined, and that close relationship can confuse you.

Change Management is all about how we assess, control and release our changes. Document control is how we create, review, modify, issue, distribute & access documents. Document control is part of knowledge management (an enabler of the enabler), it is a tool for change control, and is often a deliverable, but its important to understand that change management is broader than document control, and the principles of change management should enwrap and permeate a document control system.

Let’s start with a SIPOC.

SIPOC for document control

Change Management here is all about the how of the change:

  • Assess – What is the impact of our changes
  • Handle – Implementing our changes
  • Release- Using the change

All three these are a risk-based approach, the amount of effort and rigor depends on how risky the change is. There are a few principles to keep in mind when developing that risk based approach:

  1. Changes come in different sizes
  2. Keep your type of change control mechanisms to a manageable minimum.
  3. Have a consistent way of performing that assessment and moving between your change control mechanisms.

When I review 483s and other inspection trends one of the consistent areas is changes not going through a rigorous enough change management. They faltered on assessment, handling and/or release. It is pretty easy to put everything in the document control system and then miss a lot. (For example, those specification changes that don’t end up being filed in all appropriate markets).

So what do I recommend?

Ensure change management sits around and through document control. Build a set of standardized decision making principles that allow a document revision to end up in the right size change control process (which can just be a document change) and then ensure there is a way to document and review those decisions. This allows us to drive continuous process improvements in this decision making.

Knowledge Management

ICH Q10 “Pharmaceutical Quality System” describes a lifecycle approach, from development through product discontinuation. The knowledge about a pharmaceutical product and the processes required to reliably produce that product starts with product and process development. An effective pharmaceutical quality system (PQS) uses the knowledge acquired throughout the lifecycle of the product, builds on that knowledge, and applies it to:

  • Other stages of the product lifecycle
  • Other product lifecycles

A change management system is defined as an important element of a PQS as seen in this figure reproduced from ICH Q10.


There are two enablers to this quality system model, knowledge management and risk management. The thing about those enablers is that they are really intertwined. Or put another way, risk management is a powerful way to make use of your knowledge.

ICHQ12 “Technical and Regulatory Considerations for Pharmaceutical Product Lifecycle Management” (in draft) expands on knowledge management and provides more examples of its use. The below illustration is an adaptation of one found in the draft Q12.

knowledge and change

There are many ways to tap into knowledge management in change management. The subject matter experts are critical, as is checklists and risk ranking and filtering tools. Knowledge should drive the development of an effectiveness review.

One of my favorite is the Living Risk Assessment approach. Living risk assessments are a holistic view of a system, product, or process in an effort to prevent risk realization. They are updated throughout the product /system lifecycle to continuously assess risks that may arise or change.

In the context of change management, the living risk assessment is both an input and an output. A rigorous, maintained, living risk assessment allows us to prospectively mitigate potential risks as part of our change management program.

Living Risk Assessments have a schedule, a review period (for example, once a year) to evaluate how risk has changed, drawing from all the sources of knowledge. It is also important to have a way to trigger adhoc reviews (for example, major process changes or critical deviations).

living risk assessments

In my ASQ World Conference workshop I will be going into more detail on knowledge management, risk management and the pharmaceutical quality system. I’ll also be discussing what non-Pharma companies can learn from the PQS.