Top 5 Posts by Views in 2019 (first half)

With June almost over a look at the five top views for 2019. Not all of these were written in 2019, but I find it interesting what folks keep ending up at my blog to read.

  1. FDA signals – no such thing as a planned deviation: Since I wrote this has been a constant source of hits, mostly driven by search engines. I always feel like I should do a follow-up, but not sure what to say beyond – don’t do planned deviations, temporary changes belong in the change control system.
  2. Empathy and Feedback as part of Quality Culture: The continued popularity of this post since I wrote it in March has driven a lot of the things I am writing lately.
  3. Effective Change Management: Change management and change control are part of my core skill set and I’m gratified that this post gets a lot of hits. I wonder if I should build it into some sort of expanded master class, but I keep feeling I already have.
  4. Review of Audit Trails: Data Integrity is so critical these days. I should write more on the subject.
  5. Risk Management is about reducing uncertainty: This post really captures a lot of the stuff I am thinking about and driving action on at work.

Thinking back to my SWOT, and the ACORN test I did at the end of 2018, I feel fairly good about the first six months. I certainly wish I found time to blog more often, but that seems doable. And like most bloggers, I still am looking for ways to increase engagement with my posts and to spark conversations.

Identify and engage stakeholders

Every change (and lets be frank, most everything involves change) requires understanding the individuals and groups that will participate or are affected – directly or indirectly.

Stakeholder analysis involves identifying the stakeholders and analyzing their various characteristics. These characteristics can include:

  • Level of authority within the organization and the domain of change
  • Attitudes toward or interest in the change
  • Attitudes towards the process
  • Level of decision-making authority

The goal of stakeholder analysis is to choose the best collaboration and communication approaches and to appropriately plan for stakeholder risks.

There are a variety of mechanisms for doing this and then mapping it out.

Start by brainstorming a list of the stakeholders by answering these questions:

  • Who will be impacted?
  • Who will be responsible or accountable
  • Who will have decision authority
  • Who can support
  • Who can obstruct
  • Who has been involved in something similar in the past?

Map these on a stakeholder matrix based on relative power and interest. This should be an iterative process.

Stakeholder Matrix
  • High influence/High Impact: these are key players and effort should be focused here to engage this group regularly
  • High influence/Low impact: these stakeholders have needs that should be met so engage and consult with them while also attempting to increase their level of interest.
  • Low influence/High impact: these stakeholders are supporters and potential goodwill ambassadors. Engage the group for their input and show interests in their needs.
  • Low influence/Low impact: the stakeholders can be kept informed using general communications. Additional targeted engagement may move them into the goodwill ambassador quadrant.

Another way to look at stakeholders is though an onion diagram.

A RACI is another popular way to look at stakeholders.

Once stakeholders are identified is is important to define how communication and engagement will achieved. There is usually no one sized fits all approach and it is important to meet the needs of each stakeholder group to ensure their interest and involvement is maintained. Some considerations include:

  • timing and frequency
  • location
  • tools
  • delivery methods (in-person or virtual)
  • preferences of the stakeholders
  • geographic considerations or impact

Document this in a communication plan, including:

  • what needs to be communicated
  • what is the appropriate delivery method
  • who the appropriate audience is
  • when communication should occur
  • frequency of communication
  • level of detail appropriate for the communication and stakeholder
  • level of formality of communication

Change Leader Competency

Luigi Sille on sharequality answered the June 2019 ASQ Roundtable Topic asks: “How can an individual become a successful Change Leader?” I’m a big fan of both blog carnivals and change management so here goes my answer, which is pretty similar to Luigi’s, and I would guess many other’s – just with my own spin.

A few things immediately come to mind.

Change management (and this is another great example of really meaning people change management) should be a competency on the ladder for any quality professional. It certainly needs to be a core area for anyone in a quality leadership position.

There are a lot of competency models out there for change management. Instead of pointing to just one, let’s try to find what they actually have in common. To do so it is important to set out the critical activities of change management:

  1. Define the change
  2. Ensure change delivers value
  3. Stakeholder strategy
  4. Communication and engagement
  5. Assess change impact
  6. Project management

In order to do these it is important to be able to provide education and learning support, facilitation, team effectiveness and understand how to sustain systems.

Change Management requires the seven skills we should all be developing: communication, content, context, emotional competence, teaching, connections, and an ethical compass

Change Management is part of the core for any quality leader, together with continuous improvement and knowledge management.

WCQI Day 4

Last day of the conference and for the first session I present on “Knowledge Enables Change.”

Similar to my BOSCON talk, which was the beta so I think I covered things better in this one.

Expand Your Impact on the Culture of Quality by Kathy Lyall

Solid focus on both external and internal signifiers of quality culture. A little basic but very worth reinforcing.

And then I left, skipping the last keynote to get to the airport.

Good conference this year. Overall I felt that many of my choices for sessions ended up being more basic than I thought, but there is a lot of value in that. I will hopefully make the time to turn my thoughts into better blog posts.

When troubleshooting causes trouble

I recently had a discussion with one of the best root cause investigators and problem solvers I know, Thor McRockhammer. Thor had concerns about a case where the expected conditions were not met and there were indications that individuals engaged in troubleshooting and as a result not only made the problem worse but led to a set of issues that seem rather systematic.

Our conversation (which I do not want to go into too much detail on) was a great example of troubleshooting going wrong.

Troubleshooting is defined as “Reactive problem solving based upon quick responses to immediate symptoms. Provides relief and immediate problem mitigation. But may fail to get at the real cause, which can lead to prolonged cycles of firefighting.” Troubleshooting usually goes wrong one of a few ways:

  1. Not knowing when troubleshooting shouldn’t be executed
  2. Using troubleshooting exclusively
  3. Not knowing when to go to other problem solving tools (usually “Gap from standard”) or to trigger other quality systems, such as change management.

Troubleshooting is a reactive process of fixing problems by rapid response and short-term corrective actions. It covers noticing the problem, stopping the damage and preventing spread of the problem.

So if our departure from expected conditions was a leaky gasket, then troubleshooting is to try to stop the leak. If our departure is a missing cart then troubleshooting usually involves finding the cart.

Troubleshooting puts things back into the expected condition without changing anything. It addresses the symptom and not the fundamental problems and their underlying causes. They are carried out directly by the people who experience the symptoms, relying upon thorough training, expertise and procedures designed explicitly for troubleshooting.

With out leaky gasket example, our operators are trained and have procedural guidance to tighten or even replace a gasket. They also know what not to do (for example don’t weld the pipe, don’t use a different gasket, etc). There is also a process for documenting the troubleshooting happened (work order, comment, etc).

To avoid the problems listed above troubleshooting needs a process that people can be thoroughly trained in. This process needs to cover what to do, how to communicate it, and where the boundaries are.

4 Cs of Trouble shooting from Art Smalley’s Four Types of Problems

Step

What we do

Things to be aware of

Concern

·       What do we known about the exact nature of the problem?

·       What do your standards say about how this concern should be documented?

o   For example, can be addressed as a comment or does it require a deviation or similar non-conformance

·       If the concern stems from a requirement it must be documented.

Cause

·       What do you know about the apparent (or root) cause of the problem?

·       Troubleshooting is really good at dealing with superficial cause-and-effect relationships. As the cause deepens, fixing it requires deeper problem-solving.

·       The cause can be a deficiency or departure from a standard

 

Countermeasure

·       What immediate or temporary countermeasures can be taken to reduce or eliminate the problem?

·       Are follow-up or more permanent countermeasures required to prevent recurrence?

o   If so, do you need to investigate more deeply?

·       Countermeasures need to be evaluated against change management

·       Countermeasures cannot ignore, replace or go around standards

·       Apply good knowledge management

Check results

·       Did the results of the action have any immediate effect on eliminating the concern or problem?

·       Does the problem repeat?

o   If so, do you need to investigate more deeply?

·       Recurrence should trigger deeper problem-solving and be recorded in the quality system.

·       Beware troubleshooting countermeasures becoming tribal knowledge and the new way of working

 

Trouble shooting is in a box

Think of your standards as a box. This box defines what should happen per our qualified/validated state, our procedures, and the like. We can troubleshoot as much as we want within the box. We cannot change the box in any way, nor can we leave the box without triggering our deviation/nonconformance system (reactive) or entering change management (proactive).

Communication is critical for troubleshooting

Troubleshooting processes need a mechanism for letting supervisors happen. Troubleshooting that happens in the dark is going to cause a disaster.

Operators need to be trained how to document troubleshooting. Sometimes this is as simple as a notation or comment, other-times you trigger a corrective action process.

Engaging in troubleshooting, and not documenting it starts to look a like fraud and is a data integrity concern.

Change Management

The change management process should be triggered as a result of troubleshooting. Operators should be trained to interpret it. This is often were concept of exact replacements and like-for-like come in.

It is trouble shooting to replace a part with an exact part. Anything else (including functional equivalency) is a higher order change management activity. It is important that everyone involved knows the difference.

CoversIs it troubleshooting?
Like-for- LikeSpare parts that are identical replacements (has the same the same manufacturer, part number, material of construction, version)

Existing contingency procedures (documented, verified, ideally part of qualification/validation)
Yes

This should be built into procedures like corrective maintenance, spare parts, operations and even contingency procedures.
Functionally equivalentEquivalent, for example, performance, specifications, physical characteristics, usability, maintainability, cleanability, safety

No

Need to understand root cause.
Need to undergo appropriate level of change management
NewAnything else No

Need to understand root cause.
Need to undergo appropriate level of change management

This applies to both administrative and technical controls.

ITIL Incident Management

ITIL Incident Management (or similar models) is just troubleshooting and has all the same hallmarks and concerns.

Conclusion

Trouble shooting is an integral process. And like all processes it should have a standard, be trained on, and go through continuous improvement.