Measures of success for changes

A colleague asks:

Is it a compliance risk to extend timelines on a change control?

I want to take a step back to an important fundamental of change management to answer this question. All changes are done to realize strategic purposes; a good change management system is all about accelerating change. From the big transformations to the emergency changes to keep product being made each and every change has a strategic goal.

changing business environment

From this alignment to the strategy, each change has success metrics. Success metrics include economic, quality, technical and organization (among others) and they drive the how and the when of our change.

For example, a change driven by a CAPA to prevent reoccurrence will potentially have a different timeline than a change tied to a strategic goal to leverage a new way of working. But both have timelines driven by strategic to the tactical needs, usually filtered through a risk based prioritization tool.

And sometimes these change. The compliance aspect is not so much did you extend, it’s did you know what was happening with the change control in enough time to influence it in such a way to assure meeting the how.

The KPIs and other measures built into your system should monitor and ensure your changes reach the intended benefits.

manage for success

To return to the original question. Unlike deviations/conformances where there is a specific requirements to complete in a timely way, and CAPAs where the root cause needs to be dealt with as soon as possible, change controls have their own internal timeline based on the drivers (which may be a CAPA). Extensions are not bad in a specific one-by-one change control approach. Instead they are indicative of larger troubles in the system and should be dealt with holistically to ensure you get the maximum benefit from your changes in the best possible time.

Group change controls

A colleague asks:

hoping you can provide your perspective on “grouping changes”. That is, rules or guidance on when it is appropriate to lump several small changes into one change control.

There are lots of reason’s to want to group changes into one change control – ease of implementation, a perception of “reducing work” or just convenience. I apply three general rules for when this is a good idea:

  1. Implementation
  2. Release of product
  3. Concreteness of work package

Implementation

All changes should have the same  “Change in User” and “Regulatory Approval”

I talked about this is in “Changes become effective“:

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

Ideally chose all changes that are “Do and Tell” or “Do and report”, I strongly do not recommend blending “Tell and Do,” there are just so many complexities here and it can lead to a constant revision of change controls and even increase risk of inadvertently sending products to the market.

Release of Product

All changes bundled together need to be releasable at the same time. Look at PQ/PV requirements and other testing that can be different and keep them in segregated change controls. Putting product on stability (or even needing stability data) is another good reason to separate changes.

Similarly, keep changes that have different internal product segregation requirements unbundled.

Concreteness of Work Bundles

The best reason to bundle changes is that they involve changing the same things: same documents, same automation, same piece of equipment. Once the bundling starts increasing scope of the change, it is time to have separate change controls.

If bundling changes starts changing your project management triangle (resources, time, scope)  then do a deep evaluation. You probably have separate change controls, even if they are under the same project.

Evaluate effectiveness reviews. Chances are totally separate effectiveness reviews for same impacted area are really separate changes.

What about risks?

You might notice that I do not call out risks as one of the criteria. Risks drive mitigations, which drive impact to the three criteria I gave. If a high risk’s mitigation does not trigger one of these criteria, it is usually not a problem to group the changes together. Though I’d pause and consider why the addition of a change that adds high risks does not change drive mitigations that change the amount of work I am doing and ensure that is appropriately documented.

Conclusion

Sometimes bundling changes make sense. other times you will curse the day you agreed to bundle. I find these three rules provide a framework for making the decision.

Knowledge Work is the product

Johanna Rothman recently provided some insightful thoughts about Project Work vs Product Work. While focused on software, Johanna has some points that are valuable outside of software as she focuses on the importance of long-lived teams, applying a product work mindset to team functions.

The more we create long-lived teams who have already learned how to work together, the easier it is to work together. Even if that work is project-based work.

I think the critical thing for me is how much we have to view each team, each project as having as one of it’s key deliverables knowledge management.

However, we also need to recognize that in this day-and-age the modern corporation is  a transient collective. Companies do not do a great job of showing loyalty, there are a lot of options for the modern knowledge worker, and people regularly move on.

For me, this is why it is so important for not just projects, but day-to-day work to have as part of the inherent ways of working, processes to bring the tacit to explicit. The lessons-learned is a great place to start but we should be constantly be striving to identify “what have we learned”, “what do we need to make explicit” and “how do we make it explicit” as part of our work.

Knowledge management Circular_Process_6_Stages (for expansion)

Returning to the 6 stages of knowledge management:

    1. Have a way to capture what knowledge bits. For example, if you have a visual board, make sure this is explicitly part of the board. Make it part of your day-to-day.
    2. As a team assess the collected captured (and generated) knowledge and determine what is suitable for retaining.
    3. Share it – pass it up, pass it down. Make it available by tying it into your companies knowledge management system.
    4. Turn it into artifacts that are reusable. Pre-job briefings, procedures, work instructions, whatever is relevant.
    5. Live it. Confirm you are using it.
    6. Remember knowledge management artifacts are living. Things change and need to be updated. We can always refine. Continuous improvement is key.

 

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.

 

 

Gamestorming

Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers by Dave Gray, Sunni Brown, and James Macanufo

Like The Quality Toolbox, this is a book chock-full of usefulness. This book provides a fun approach that makes it possible for collaborative activities to get everyone participating in creative and design-oriented activities. From planning meeting, generating ideas, understanding customers, creating prototypes, or making better decisions, Gamestorming is a way for groups to “work better together.”

Divided into Opening, Exploring and Closing sections, the structure of the book will be familiar to anyone with a facilitation background. I am constantly dipping into this book for activities for team meetings, project kickoffs, development meetings, lessons learned and a whole lot of other meetings.

This book delves into the usage of visual thinking to increase effectiveness and I find dramatically shorten the length of time needed for a group to solve a problem. This book proposes that visual thinking can:

  • Using a simple, shared visual language to increase understanding and information retention;
  • Applying improvisational discovery to keep participants engaged;
  • Mapping the big picture, solving problems and innovating as a team;
  • Creating visual meeting artifacts to drive decisions forward.

What is especially cool is that there is a great webpage dedicated to these games that I hope you will find as useful as I do. It is full of exercises, activities and advice.