- Consistency with organizational objectives: The team vision should be aligned with and derive from the organization’s overall purpose and strategy. Teams are sub-elements in a wider organization structure and their success will be judged on the extent to which they make valuable contributions to the overall purpose of the organization. In some circumstances a team may decide that it is important for its own values, purposes and orientations to act as a minority group which aims to bring about change in organization objectives – perhaps like a red team.
- Receiver needs: Teams focus on providing excellence in service to its customers, whether internal or external.
- Quality of work: A major emphasis within organizations is the quality of work. The relationship between quality and other functions like efficiency is important.
- Value to the wider organization: Understanding the importance of the team just not for the wider organization but beyond, leads to team cohesion and greater team effectiveness. Team members need a clear perception of the purposes of their work.
- Team-climate relationships: Team climate refers to aspects such as the warmth, humor, amount of conflict, mutual support, sharing, backbiting, emphasis on status, participation, information sharing, level of criticism of each other’s work and support for new ideas.
- Growth and well-being of team members: Growth, skill development and challenge are central elements of work life and teams can be a major source of support. Teams provide opportunities for skill sharing and support for new training. Teams need to be concerned for the well-being of its members, including things like burnout.
- Relationships with other teams and departments in the organization: Teams rarely operate in isolation. They interact with other team and departments within the organization. Teams must be committed to working effectively and supporting other teams. Avoid silo thinking.
In episode 48 of the Deming Len’s podcast, the host refers back to Deming’s last interview, “Dr. Deming: ‘Management Today Does Not Know What Its Job Is‘”
Deming Len's Episode #48 – Management (Still) Doesn't Know What Its Job Is – The W. Edwards Deming Institute® Podcast
The source of innovation is freedom. All we have—new knowledge, invention—comes from freedom. Somebody responsible only to himself has the heaviest responsibility. “You cannot plan to make a discovery,” Irving Langmuir said. Discoveries and new knowledge come from freedom. When somebody is responsible only to himself, [has] only himself to satisfy, then you’ll have invention, new thought, now product, new design, new ideas.Dr. W. Edwards Deming
The structured what-if technique, SWIFT, is a high-level and less formal risk identification technique that can be used independently, or as part of a staged approach to make bottom-up methods such as FMEA more efficient. SWIFT uses structured brainstorming in a facilitated workshop where a predetermined set of guidewords (timing, amount, etc.) are combined with prompts elicited from participants that often begin with phrases such as “what if?” or “how could?”.
At the heart of a SWIFT is a list of guidewords to enable a comprehensive review of risks or sources of risk. At the start of the workshop the context, scope and purpose of the SWIFT is discussed and criteria for success articulated. Using the guidewords and “what if?” prompts, the facilitator asks the participants to raise and discuss issues such as:
- known risks
- risk sources and drivers
- previous experience, successes and incidents
- known and existing controls
- regulatory requirements and constraints
The list of guidewords is utilized by the facilitator to monitor the discussion and to suggest additional issues and scenarios for the team to discuss. The team considers whether controls are adequate and if not considers potential treatments. During this discussion, further “what if?” questions are posed.
Often the list of risks generated can be used to fuel a qualitative or semi-quantitative risk assessment method, such as an FMEA is.
A SWIFT Analysis allows participants to look at the system response to problems rather than just examining the consequences of component failure. As such, it can be used to identify opportunities for improvement of processes and systems and generally can be used to identify actions that lead to and enhance their probabilities of success.
What–If Analysis is a structured brainstorming method of determining what things can go wrong and judging the likelihood and consequences of those situations occurring. The answers to these questions form the basis for making judgments regarding the acceptability of those risks and determining a recommended course of action for those risks judged to be unacceptable. An experienced review team can effectively and productively discern major issues concerning a process or system. Lead by an energetic and focused facilitator, each member of the review team participates in assessing what can go wrong based on their past experiences and knowledge of similar situations.
|What could go wrong?||What would happen if it did?||How likely?||Consequences||What will we do about them Again – prevent and monitor|
Steps in a SWIFT Analysis
- Prepare the guide words: The facilitator should select a set of guide words to be used in the SWIFT.
- Assemble the team: Select participants for the SWIFT workshop based on their knowledge of the system/process being assessed and the degree to which they represent the full range of stakeholder groups.
- Background: Describe the trigger for the SWIFT (e.g., a regulatory change, an adverse event, etc.).
- Articulate the purpose: Clearly explain the purpose to be served by the SWIFT (e.g., to improve effectiveness of the process).
- Define the requirements: Articulate the criteria for success
- Describe the system: Provide appropriate-level textual and graphical descriptions of the system or process to be risk assessed. A clear understanding is necessary and can be is established through interviews, gathering a multifunctional team and through the study of documents, plans and other records. Normally the
- Identify the risks/hazards: This is where the structured what-if technique is applied. Use the guide words/headings with each system, high-level subsystem, or process step in turn. Participants should use prompts starting with the phrases like “What if…” or “How could…” to elicit potential risks/hazards associated with the guide word. For instance, if the process is “Receipt of samples,” and the guide word is “time, timing or speed,” prompts might include: “What if the sample is delivered at a shift change” (wrong time) or “How could the sample be left waiting too long in ambient conditions?” (wrong timing).
- Assess the risks: With the use of either a generic approach or a supporting risk analysis technique, estimate the risk associated with the identified hazards. In light of existing controls, assess the likelihood that they could lead to harm and the severity of harm they might cause. Evaluate the acceptability of these risk levels, and identify any aspects of the system that may require more detailed risk identification and analysis.
- Propose actions: Propose risk control action plans to reduce the identified risks to an acceptable level.
- Review the process: Determine whether the SWIFT met its objectives, or whether a more detailed risk assessment is required for some parts of the system.
- Document: Produce an overview document to communicate the results of the SWIFT.
- Additional risk assessment: Conduct additional risk assessments using more detailed or quantitative techniques, if required. The SWIFT Analysis is really effective as a filtering mechanism to focus effort on the most valuable areas.
The facilitator and process owner can choose any guide words that seem appropriate. Guidewords usually stem around:
- Wrong: Person or people
- Wrong: Place, location, site, or environment
- Wrong: Thing or things
- Wrong: Idea, information, or understanding
- Wrong: Time, timing, or speed
- Wrong: Process
- Wrong: Amount
- Failure: Control or Detection
- Failure: Equipment
If your organization has invested time to create root cause categories and sub-categories, the guidewords can easily start there.
Whataboutism is the common term for a version of the tu quoque fallacy, a diversionary tactic to shift the focus off of an issue and avoid having to directly address it by twisting criticism back onto the critic and in doing so revealing the original critic’s hypocrisy.
Whataboutism often results in a comparison of issues as pure deflection. We see it when individuals are always focused on why others get ahead and they don’t, looking for comparisons and reasons they are being treated unfairly instead of focusing on their own opportunities for improvement. It is so easy to use when we are faced with criticism, “Well, what about … ?”
We also see whataboutism in our cultures. Maybe it is a tendency to excuse your own team’s shortcomings because obviously the sins of another team is so much worse. This is a result of, and strengthens, silo-thinking.
Building the feedback process to reduce and eventually eliminate whataboutism is critical.
When I first joined my current company I spent a lot of time introducing myself. I’ve been here now a year, and there are new folks, new relationships and most important we are getting ready to change our way of working by introducing hybrid work.
As a leader it’s important to be honest in who you are and how you work. The best technique I’ve seen for this is a user manual, a quick way to express what works and what does not work for interacting with me.
Mine looks like this:
I’ll be updating this as part of my team establishing a new team governance charter.