Implementing a Quality Ambassador Program

Quality ambassadors can influence their peers to prioritize quality, thereby strengthening the culture of quality in the organization. Quality leaders can use this guide to develop a quality ambassador program by identifying, training, and engaging ambassadors.

Utilizing Kotter’s eight accelerators for change, we can implement a Quality Ambassador program like this:

Accelerator	Actions
Create a strong sense of urgency around a big opportunity	Demonstrate the organizational value of Ambassadors by performing a needs analysis to assess the current state of employee engagement with quality.
Build and evolve a guiding coalition	Bring together key stakeholders from across the organization who will provide input in the program’s design and support its implementation.
Form a change vision and strategic initiatives	Identify the key objectives for implementing a Quality Ambassador program and outline the lines of effort required to successfully design and pilot it.
Enlist a volunteer army	Reach out and engage informal leaders at all levels of the organization. Find your current informal Ambassadors and draw them in.
Enable action by removing barriers	Be vigilant for factors that impede progress. Work with your Ambassadors and senior leaders to give teams the freedom and support to succeed.
Generate and celebrate short-term wins	Pilot the program. Create success stories by looking at the successful outcomes of teams that have Quality Ambassadors and by listening to team members and their customers for evidence that quality culture is improving. Your goal will be to create an environment where teams that do not have Quality Ambassadors are asking how they can participate.
Sustain acceleration	Scale the impact of your program by implementing it more broadly within the organization.

Define the Key Responsibilities of Quality Ambassadors


What activities should Quality Ambassadors focus on?	Example: Reinforce key quality messages with co-workers. Drive participation in quality improvement projects. Provide inputs to improve culture of quality. Provide inputs to improve and maintain data integroty
What will Quality Ambassadors need from their managers?	Example: Approval to participate, must be renewed annually
What will Quality Ambassadors receive from the Quality team?	Example: Training on ways to improve employee engagement with quality. Support for any questions/objections that ariseTraining on data integrity
What are Quality Ambassadors’ unique responsibilities?	Example: Acting as the point of contact for all quality-related queries. Reporting feedback from their teams to the Quality leadership. Conveying to employees the personal impact of quality on their effectiveness. Mitigating employee objections about pursuing quality improvement projects. Tackling obstacles to rolling out quality initiatives
What responsibilities do Quality Ambassadors share with other employees?	Example: Constantly prioritize quality in their day-to-day work
Expected time commitment	Example: 8-10 hours/month, plus 6 hours of training at launch

Metrics to Measure Success

Type of Metrics	List of Metrics	Direct Impact of Ambassador’s work	Recommendations
Active Participation Levels	Percentage of organizational units adopting culture of quality program. The number of nominations for quality recognition programs. Quality observations were identified during Gemba walks. Participation or effectiveness of problem-solving or root-cause processes. The number of ongoing quality improvement projects. Percentage of employees receiving quality training	High	Ambassadors should be directly held responsible for these metrics
Culture of Quality Assessments	Culture of quality surveys. Culture of quality maturity assessments	Medium	The Quality Ambassador program is a factor for improvement.
Overall Quality Performance	Key KPI associated with Quality. Audit scoresCost of poor quality	Low	The Quality Ambassador program is a factor for improvement.

Design Lifecycle within PDCA – Planning

In the post “Review of Process/Procedure” I mentioned how the document draft and review cycle can be seen as an iterative design cycle. In this post I want to expand on the design lifecycle as a fundamental expression of PDCA that sits at the heart of all we do.

PDCA, a refresher

PDCA (and it’s variants) are a pretty tried and true model for process improvement. In the PDCA model a plan is structured in four steps: P (plan) D (do) C (check) A (act). The intention is create a structured cycle that allows the process to flow in accordance with the objectives to be achieved (P), execute what was planned (D), check whether the objectives were achieved with emphasis on the verification of what went right and what went wrong (C) and identify factors of success or failure to feed a new process of planning (A).

Conceptually, the organization will be a fast turning wheel of endlessly learning from mistakes and seeking to maximize processes in order to remain forever in pursuit of strategic objectives, endlessly searching for the maximum efficiency and effectiveness of the system.

PDCA cycle driving continuous improvement

Design Lifecycle

This design lifecycle just takes the PDCA spiral and spreads it across time. At the same time it breaks down a standard set of activities and recognizes the stage gates from moving between startup (or experiment) and continuous improvement.

Identifying the Problem (Plan)

At it’s heart problem-solving requires understanding a set of requirements and building for success.

I always go back to the IEEE definition of “A requirement is a condition or capability needed by a user to solve a problem or achieve an objective; a condition or capability that must be met or possessed by a system or system component to satisfy a contract ,standard, specification , or other formally imposed document; a document representation of condition or capability “

A requirement can be explicitly stated, implicit, inherited or derived from other requirements.

The first place to look for requirements is the organization itself.

Understanding the needs of the organization

The cultural needs of the organization drives the whole problem-solving and requirement gathering activity and it starts by being clear on Strategy and understanding the goals and objectives and how these goals percolate to the different business processes that we are improving. This gives a good starting point to focus on what opportunities to be explored and what problems to be solved.

It is not uncommon in the problem-solving phase that the objectives/needs are not known, so we must work our way through figuring out what the initial need is. Go back to the fundamentals of understanding the business processes “as-is” and review existing regulations, standards, guidelines and other internal sources of requirements followed currently. This is the time to interview stakeholders and go the GEMBA.

We state the problem, and re-frame it. And now we can move on to Requirement Elicitation.

Requirement Elicitation

Requirement Elicitation is the process of probing and facilitating the stakeholders to provide more clarity and granular details pertaining to the (usual) high-level requirement gathered so far. This is a discovery process, exploratory in nature, focusing on finding enough details so that a solution can be envisioned and developed. Elicitation is not an isolated activity, and has been happening throughout the process by all the discussion, interaction, analysis, verification and validation up to now.

You should be engaging with knowledge management throughout the cycle, but ensure there is specific engagement here.

It is a progressive process where the requirement clarity ushers in increments and may need multiple rounds of probing/discussions. As the new details are uncovered the requirements are further elaborated and detailed. There are a whole toolbox of elicitation techniques and like any engagement it is important to properly prepare.

Requirement Analysis

Requirement Analysis pertains to extracting the requirement out of the heaps of information acquired from various stakeholders and communicated and turned into documentation in a form that is easily understood by the stakeholders, including the project team. Here we are engaging in requirement refinement, modification, clarification, validation & finalization and engaging in extensive communication.

A requirement can be classified as:

External or Internal Obligation
Business requirement: The organizational need
Stakeholder requirement
Functional Requirement
Non-Functional Requirement
Transitioning requirement

We build for traceability here, so as we build and test solutions we can always trace back to the requirements.

Design the Solution

Building for the solution includes change management. Any solution focuses both on the technical, the organization and the people.

Ensure you leverage risk management.

The Place of Empathy

In this design process, we address and use empathy to acquire insight into users’ (stakeholders) needs and inform the design process and create a relevant solution. Using an approach informed by cognitive empathy, we apply different methods to build up that competence and insight, enabling us to prioritize the needs of the users and make the results of the process more desirable.

Psychological safety, reflexivity and sense-making inform our work.

Prepare for Startup

By engaging in Design Thinking we are ready for Startup. Moving through the three steps of:

Problem-Solving
Requirement Elicitation
Design Solution

We have created a plan to execute against. Startup, which can often be Experimentation, is it’s own, future, post.

Team Effectiveness

With much of the work in organizations accomplished through teams it is important to determine the factors that lead to effective as well as ineffective team processes and to better specify how, why, and when they contribute. It doesn’t matter if the team is brought together for a specific project and then disbands, or if it is a fairly permanent part of the organization, similar principles are at work.

The input-process-output model of teams is a great place to start. While simplistic, it can offer a good model of what makes teams works and is applicable to the different types of teams.

Input factors are the organizational context, team composition, task design that influence the team. Process factors are what mediates between the inputs and desired outputs.

Leadership: The leadership style(s) (participative, facilitative, transformational, directive, etc) of the team leader influences the team toward the achievement of goals.
Management support refers to the help or effort provided by senior management to assist the project team, including managerial involvement and resource support.
Rewards are the recompense that the organization gives in return for good work.
Knowledge/skills are the knowledge, experience and capability of team members to process, interpret, manipulate and use information.
Team diversity includes functional diversity as well as overall diversity.
Goal clarity is the degree to which the goals of the project are well defined and the importance of the goals to the organization is clearly communicated to all team members.
Cooperation is the measure of how well team members work with each other and with other groups.
Communication is the exchange of knowledge and information related to tasks with the team (internal) or between team members and external stakeholders (external).
Learning activities are the process by which a team takes action, contains feedback and makes changes to improve. Under this fits the PDCA lifecycle, including Lean, SixSigma and similar problem solving methodologies..
Cohesion is the spirit of togetherness and support for other team members that helps team members quickly resolve conflicts without residual hard feelings, also referred to as team trust, team spirit, team member support or team member involvement.
Effort includes the amount of time that team members devote to the project.
Commitment refers to the condition where team members are bound emotionally or intellectually to the project and to each other during the team process.

Process Factors are usually the focus on team excellence frameworks, such as the ASQ or the PMI.

Outputs, or outcomes, are the consequences of the team’s actions or activities:

Effectiveness is the extent a project achieves the performance expectations of key project stakeholders. Expectations are usually different for different projects and across different stake-holders; thus, various measures have been used to evaluate effectiveness, usually quality, functionality, or reliability. Effectiveness can be meeting customer/user requirements, meeting project goals or some other related set of measures.
Efficiency is the ability of the project team to meet its budget and schedule goals and utilize resources within constraints Measures include: adherence to budget, adherence to schedule, resource utilization within constraints, etc.
Innovation is the creative accomplishment of teams in generating new ideas, methods, approaches, inventions, or applications and the degree to which the project outputs were novel.

Under this model we can find a various levers to improve out outcomes and enhance the culture of our teams.

Personal Audits as part of team building for Projects

The personal audit is a tool used in change and project management (and such) to help team members and sponsors judge their strengths and weaknesses with respect to change leadership. It illustrates some skills from the full range necessary to introduce change into an organization.

This exercise is great to do at the beginning of the project, where it can help team members begin to understand some of the human issues applicable to all projects. As one mentor once told me – If this exercise strikes team members as inapplicable, then they really need to do it.

Domain	What I do Well	What I Need to Work On
Manage Attention: To what extent do I manage my time, energy, passion, focus and agenda?
Adopt change roles? How much attention do I pay to matters like: Creating a need, Shaping a vision, Mobilizing commitment, Monitoring progress, Finishing the job, Anchoring the change)
Technical competence: To what extent to I demonstrate competence in technical abilities?
Interpersonal competence: how skilled am I at interacting with others?
Vision: How well can I articulate the desired outcome of the project and the benefits to others?
Teamwork: How often do I recognize good work done by teammates?
Diplomacy: How closely am I working with all the groups affected by this project?
Conflict management: Can I deal with disagreement without avoiding it or blowing up?
Summary: Overall strengths and weaknesses

Risk Management leads to Change Management, Change Management contains Risk Management

We did an FMEA for the design of the room. Why do we need a risk assessment for the change control to implement the design features?
We have an environmental risk management plan, including a HAACP. Why does this change control require a new risk assessment?

If I received a nickel……

I want to expand on my earlier thoughts on risk management enabling change.

Risk Management is a key enabler of any quality by design, whether of product, facility/equipment or study. We do living risk assessments to understand the scope of our ongoing risk. Inevitably we either want to implement that new or improved design or we want to mitigate the ongoing risks in our operation. So we turn to change management. And as part of that change management we do a risk assessment. Our change management then informs ongoing risk review.

Risk Management Leads to Change Management

Design Implementation

Through the iterative design lifecycle there is a final design ready for introduction. Perhaps this is a totally new thing, perhaps it is a new set of equipment or processes, or just a modification.

All along through the iterative design lifecycle risk management has been applied to establish measurable, testable, unambiguous and traceable performance requirements. Now your process engages with change management to introduce the change.

And a new risk assessment is conducted.

This risk assessment is asking a different question. During the iterative design lifecycle the risk question is some form of “What are the risks from this design on the patient/process.” As part of risk management, the question is “What are the risks to SISPQ/GMP from introducing the change.”

This risk assessment is narrower, in that it looks at the process of implementing. Broader that it looks at the entirety of your operations: facility, supply chain, quality system, etc.

The design risk assessment and risk management activities informs the change management risk assessment, but it cannot replace them. They also can serve to lower the rigor of the change management risk assessment, allowing the use of a less formal tool.

Living Risk Reviews

In the third phase of risk management – risk review – we confirm that the risks identified and mitigated as planned and are functioning as intended. We also evaluate to see if any additional, previously unpredicted risks have appeared. Risk review is the living part of the lifecycle as we return to it on a periodic basis.

From this will come new mitigations, targeted to address the identified risks. These mitigations inevitably lead to change management.

We again do a new risk assessment focusing on the risk of implementing the change. Informed by the living risk assessment, we can often utilize a less formal tool to look at the full ramifications of introducing the mitigation (a change).

Change Controls contains Risk Management

Effective change management is enabled by risk management.

Each and every change requires a risk assessment to capture the risks of the change. This ICHQ10 requirement is the best way to determine if the change is acceptable.

This risk assessment evaluates the impact on the change on the facility, equipment, materials, supply chain, processes. testing, quality systems and everything else. It is one of the critical reasons it is crucial to involve the right experts.

From this risk assessment comes the appropriate actions before implementing the change, as well as appropriate follow-up activities and it can help define the effectiveness review.

What about grouped change controls?

Depends. Sometimes the risk management looks at the individual implementations. Othertimes you need to do separate ones. Many times the risk assessment lead you to breaking up one change control into many. Evaluate as follows:

Are the risks from the separate implementations appropriately captured
Are the risks from pauses between implementations appropriately captured
As the ripples appropriately understood

Change Management Leads back to Risk Management

Sometimes a change control requires a specific risk assessment to be updated, or requires specific risk management to happen.

What about HAACP?

Hazard Analysis Critical Control Point (HACCP) are great tools for risk assessments. They are often the catalyst for doing a change, they are often the artifact of a change. They should never be utilized for determining the impact of a change.

A hazard is any biological, chemical, or physical property that impacts human safety. The HAACP identifies and establishes critical limits. But a HAACP is not the tool to use to determine if a change should move forward and what actions to do. It is to static.

In Closing

Risk Management is an enabler for change, a tenet enshrined in the ICH guidances. We are engaging in risk management activities throughout our organizations. It is critical to understand how the various risk management activities fit together and how they should be separated.