Failure Mode Effects Analysis

To understand the FMEA Project’s scope it is essential for the sponsors, stakeholder, and project manager to know how to measure success. However, it’s necessary to understand what part of the project scope is not.

The project scope tells the project team what the project needs to be considered a success. It can also help avoid that unnecessary work. Deliverables are the foundation of project scope because they describe what the project is supposed to deliver. For FMEA project we want to identify and reduce risk.

It’s helpful to have a project scope statement that describes the project’s deliverables and the work required to create those deliverables in detail. It makes a common reference point for stakeholders and is often used to manage stakeholder expectations. A scope statement includes the

• product scope description

• product acceptance criteria

• project deliverables

• Are their constraints

• If there are any exclusions

These need to be considered when initiating a discussion with the FMEA Project sponsor.

When a well-thought-out scope statement is created it bridges any communication gaps that could rot later in the project. With everyone on the team, understanding the scope helps keep them focused on what needs to be done and discourages people from doing more than is required. If someone wants to add something to the project, you can use the scope statement and project objectives to decide whether the addition makes sense.

This is so common there is a name for it. It is called “Scope Creep.” What is scope creep? Well, to say it lightly, scope creep is poison to any FMEA project managers’ existence. If you’ve ever added work to the project without accounting for it, you have been a victim of scope creep. Unfortunately, it is easy to fall prey because you usually don’t realize it’s happening until it’s too late. That’s the nature of scope creep. But what exactly is it? Well, in simple terms, scope creep is theft by another name. In other words, you’re stealing money and time from other areas of your project to fund your scope escapades. Scope creep officially defined as the uncontrolled expansion to product or project scope without time, cost, and resources adjustments. To look at this in another way, scope creep requires the project manager to do more work with the same amount of time and money as estimated initially. See how this could be a problem? Working on unauthorized work is risky. It can be tempting, but scope creep should never be allowed. If for no other reason than its terrible project management practice to lose control of any of your project constraints, particularly scope. Don’t get me wrong. There’s nothing wrong with wanting to improve products and services. You need to make sure you properly document them.

On the other hand, one option is to reduce the project scope if you run into trouble with the budget, schedule, or availability of resources. Add the scope statement to your project definition. Throughout the project, you’ll use it to help keep it on track at which stage the of the FMEA Project. Entering the Optimization and Project Execution is then scope further solidify on how the team will proceed. This can make a project manager cringe because scope creep can derail your project faster than you can push the panic button. Knowing why scope creep happens and what you can do about it can help leverage the blow. Scope creep will thrive when the gap between what the sponsor and stakeholders expect and what the project delivers. The word expect is critical.

FMEA Projects, either Design or Process, can be scoped into two manors. Project Scope or Product Scope, and yes, there is a difference.

Project Scope: The Project Scope is the work that must be performed to deliver a product, service, or result with the specified features and functions in a Design or Process FMEA.

Product Scope: The Product Scope features and functions are characterized as either a product, service or result.

Notice that product scope is all about the characteristics of the product, service, or result of the project. Project scope, on the other hand, is concerned with the work that must be completed to deliver that product, service, or result. As with all the project plans, the scope management plan defines how they manage that particular project area. The scope management plan answers questions:

• How will you determine the product scope for the project? This includes the specific requirements during the optimization and controlling stage.

• How will you balance the needs of all your stakeholders?

• What tools and techniques will the project team specifically use?

The key to the scope control process is remembering that it is a very proactive process. Sometimes this means determining the root cause of change in order to prevent future issues. Remember that the project manager does not function simply as an intermediary who processes change requests. The Project Managers’ job is to control the FMEA project so they can meet all the baselines. To succeed, the Project Manager must manage the project scope! This has been a look at Project Scope from FMEA Project.

FMEA Team Charter

Developing a well-formed project charter is important to the overall success of the FMEA. However, FMEA project charters are often not done well in the real world — or even done at all. To understand why they are usually not done correctly, we have to begin understanding the purpose of the FMEA project charter. The primary purpose of the FMEA project charter is to authorize work to start on the project. However, the charter also provides some other basic information. In addition to assigning work to begin, the charter does the following:

• Names the FMEA project manager and project sponsor

• Explains how the project supports the organizational strategy

• Explains the business need and why the need exists

Defines any constraints and assumptions that exist (this includes any deadlines, budget limitations, resource limitations, any known risks, and scope must-haves)

Establishes the project success criteria (it is always recommended that success criteria be quantitative as subjective success criteria usually lead to project failure). The charter does NOT include detailed requirements, the project schedule, the project budget, or other detailed information.

The charter is the document that authorizes the FMEA leader to begin the planning process and determine what it will take to complete the project. Once the plan is submitted, the sponsors maintain the right to cancel the project if they deem it not what they desire.

Team Assembly and Resource Management

When dealing with teams, the FMEA leaders must negotiate for the resources they need to deliver the project successfully. They also must have the experience to manage and develop people. One of the biggest problems real-world project managers face either not understanding the organizational culture or estimates being based upon having more experienced resources than are assigned to the project. A good FMEA leader knows how to avoid this issue.

Each FMEA needs to have a team charter that establishes the basic ground rules the team agrees to use to function as a collective unit. It includes the team's values, agreements, and operational guidelines in communication, decision making, conflict resolution, and meetings.

Once the team is determined, the next step is to develop the team, so they have the necessary skills to complete the FMEA successfully. A vital goal of the FMEA leader is to improve skills, team interaction, and overall team environment. In any FMEA project, teamwork is a critical factor for success. Team development is an FMEA project leader's responsibility. The development of the team is focused on learning about the risk since their knowledge should already be demonstrated in their role on the team.

Having good interpersonal and team skills is a benefit to the FMEA project. Those skills are used to relate with people and engage with them one-on-one or in small groups. Remember, teamwork is critical to the project's success, and no tool is more important to developing good partnership than interpersonal skills.

As you do the FMEA project, there will be times the conflict is created. Understanding and confront is a key to a great FMEA Leader. A conflict represents a difference of opinion between two or more parties. Within an FMEA project, disagreements are common between team members, stakeholders, or the project manager and any of the above. The fact that conflict exists does not in and of itself represent a negative. However, how the people experiencing the conflict choose to deal with the issue can dramatically impact FMEA's success.

Agilists often cite five Dysfunctions of a Team Assessment based on Patrick Lencioni’s best-selling book to describe common dysfunctions OR conflicts experienced by even the best team. Lencioni identified five specific but all too common dysfunctions. All groups can become dysfunctional because they are made up of people whose needs must be met. Understanding what the potential dysfunctions are and how to overcome them is critical to the success of any team.

• Inattention to results

• Avoidance of accountability

• Lack of commitment

• Fear of conflict

• Absence of trust

To review these further, let first look at the absence of trust. The absence of trust can be a real problem in the FMEA team structure. Often members don’t feel comfortable enough with the other members to fully disclose or share information needed for the team to succeed. Common indicators that your FMEA team is struggling with an absence of trust include:

• Concealing weaknesses or mistakes

• Not asking for help or providing constructive criticism

• Not offering to help other team members outside their areas

• Quickly jumping to conclusions

• Failing to recognize others’ capabilities

• Holding grudges from previous meetings/projects

• Dreading meetings and finding reasons to avoid each other

If you identify that you have an absence of trust within your FMEA team, here are some tools for getting the team back on track:

• Personal Histories Exercise — Have each team member review what they did before becoming part of this team. This will allow everyone to understand the strengths of each member better.

• Team Effectiveness Exercise — Use team-building exercises to allow each member to gain personal and team insight into how they act in the team setting.

• Personality and Behavioral Preferences Profiles — Team Dimensions Profile

• 360 Degree Feedback — Reviews by team members, managers, and subordinates on your performance.

These tools will provide team members with valuable information about their performance. These exercises and activities will not be the root of the problem but rather the first step for the team to recognize the issues and realize that they all need to resolve the team’s trust issue.

Fear of conflict with team members is surrounded by competition from other team members and stakeholders because of the varying points of view that naturally exist throughout a project. Not all conflicts are harmful. On the contrary, constructive conflicts can allow the team to identify issues, solutions, and potential problems. When determining the ranking of RPN that conflict does exist and should be encouraged to a healthy point.

The entire team must recognize conflict as a potentially beneficial thing. If your team often suffers from any of the following, you likely have a fear of conflict:

• Boring meetings.

• Backchannel politics.

• Personal attacks.

• They are ignoring critical and controversial topics.

• Opinions and perspectives of all team members are not heard or are silenced.

To be able to deal with the fear of conflict, try the following techniques:

• Conflict Mining — Create situations within the meeting to make the conflicts come into the conversation and force people to talk about them.

• Real-Time Permission — You must have a culture where it is acceptable to have a difference of opinion, and your people must be willing to express those opinions. — This tool is similar to a personality test but brings out conflict in a thought-provoking way for the team to discuss.

Lack of Commitment is the third significant dysfunction of a team is a lack of commitment. When an organization suffers from a lack of commitment, they rarely stick with difficult decisions or finds it impossible to make the decisions necessary to ensure project success. Often these issues create exponentially increased problems as project resources become more and more frustrated. Each of the following represents telltale signs of a lack of commitment within an organization:

• Ambiguity about direction and priorities.

• Paralysis by analysis. This is when the group is overanalyzing or overthinking a situation can cause forward motion or decision-making to become "paralyzed", meaning that no solution or course of action is decided upon.

• Lack of confidence and fear of failure.

• Revisiting discussions and decisions repeatedly.

• Second-guessing among the team.

If you identify that you have a commitment issue within your team or organization, implement the following:

• Cascading Messaging — Ensure messaging flows from the top of the organization. Senior management must have belief in their ideas and set a consistent direction for the organization.

• Deadlines — Set deadlines and make everyone live up to them.

• Low-risk Exposure Therapy — Identify the risk exposure tolerances within the organization and your team.

Avoidance of Accountability Without committing to a clear plan of action, even the most focused and driven team members will hesitate to call out actions and behaviors that seem counterproductive to the good of the project and organization. Members will hold deep-seated resentment for team members that fail to live up to their standards, although they may say nothing. The following indicators exemplify the avoidance of accountability:

• Resentment among team members of different performance standards.

• Encouraged mediocrity.

• Missed deadlines and key deliverables.

• The team leader is the sole source of discipline.

If you identify that you have an accountability issue within your team or organization, implement the following:

• Publish goals and standards for all team members.

• Simple and regular progress reviews.

• Team rewards.

Inattention to results occurs when team members put their individual needs (such as ego, career development, or recognition) above the team's collective goals. This will cause the team to fail to meet most, if not all, of the project's original objectives. Any of the following can indicate inattention to results:

• The team stagnates and fails to grow.

• The organization rarely defeats a competitor.

• Loses achievement-oriented employees

• Team members are encouraged to focus on their own goals.

• Easily distracted.

If you identify that you have an inattention to results issue within FMEA your team or organization, implement the following:

• Public share results

• Develop a results-based rewards

While each FMEA project and people are different, using some of these tools can help mitigate the problem early and support your FMEA project's success.

It is helpful also to have people on the team who have different levels of familiarity with the product or process. Those who are most familiar with it will have valuable insights but may overlook some of the most obvious potential problems. Those who are less familiar with the process or product will bring unbiased, objective ideas into the FMEA process. Be aware that those with an emotional investment in the process or product may be overly sensitive during

the critiquing process and may become defensive. Deciding whether to include these emotionally invested people on the team must involve weighing the disadvantages against the advantages that their experience and knowledge will bring to the process.

Peter Drucker is often quoted as saying that "you can't manage what you can't measure." Drucker means that you can't know whether you are successful unless success is defined and tracked.

Understanding process measurements helps project teams know what and if they are working on the right failures. Understanding process metrics gives a clue to help FMEA Project.

These metric measure equipment or asset performance based on actual availability, performance efficiency, and product quality or output when the asset is scheduled to operate. Overall equipment effectiveness (OEE) is expressed as a percentage. It is a lagging indicator of the inputs and outputs.

This metric identifies and categorizes significant losses or reasons for poor asset performance. It provides the basis for setting improvement priorities and beginning root cause analysis. OEE also fosters cooperation and collaboration between operations, maintenance, and equipment engineering to identify, reduce, and eliminate the major causes of poor performance. They are primarily used in a process FMEA to track the efficiency of current throughput.

The formula for Overall Equipment Effectiveness (%) = availability (%) × Performance Efficiency (%) × Quality Rate (%)

The OEE percentage should be used primarily as a relative, internal improvement measure for a specific asset or single-stream process. To better understand the OEE, let us look at the inputs to the OEE, what they are, how they are essential, how they can be affected, and other leading metrics that affect the process performance.

Availability is defined as the percentage of the time the asset is operating (uptime) compared to when it is scheduled to run. Also called operational availability.

Next is Performance Efficiency, which is the degree to which the equipment operates at historical best speeds, rates, and cycle times. These are the standards and should never be adjusted without site leadership and engineering support.

The last input to OEE is Quality Rate. The degree to which product characteristics meet the product or output specifications.

To better understand, let look at an example. Our Pepperoni Pizza Factory Pizza filler is available to operators seven days a week, 24 hours a day. However, due to the failures of the cheese dispenser, the availability is 50%. Next, we look at Performance Efficiency. Everything was running fine when it could run. This gives the performance efficiency a high mark of 100%. The last input was quality rate, and we found out that due to a problem with the cheese dispenser, we occurred many rejects, which was determined to be 98%. Knowing these three inputs, the availability (50%), X Performance Efficiency (100%), and Quality Rate (98%), we determine the Overall Equipment Effectiveness of the process was at 49% last week.

For the FMEA Project, understanding different leading metrics can benefit failure analysis.

Let look at few more inputs.

Idle Time

The time an asset is idle or waiting to run. The sum of the times when there is no demanded

administrative idle time (e.g., not scheduled for production). Idle times do not include equipment downtime (scheduled or unscheduled) and no feedstock or raw materials.

Downtime Event

A downtime event occurs when the asset is down and not capable of performing its intended function.

Scheduled Downtime

The time required to work on an asset that is on the finalized weekly maintenance schedule.

Unscheduled Downtime

The time an asset is down for repairs or modifications that are not on the weekly maintenance

schedule.

Uptime

The amount of time an asset is actively producing a product or providing a service. It is the

actual running time.

Mean Time to Repair

The average time needed to restore an asset to its full operational capabilities

after a failure. Meantime to repair or replace (MTTR) is a measure of asset maintainability,

usually expressed as the probability that a machine can be restored to its specified operable

condition within a specified interval of time regardless of whether an asset is repaired or

replaced.

Mean Time Between Failures

MTBF is the average length of operating time between failures for an asset or component.

Failure

An asset is losing its functionality to perform at its predetermined standard.

Scheduled Downtime

The time required work on an asset that is on the finalized weekly maintenance schedule.

Total Downtime

The amount of time an asset cannot run—the sum of scheduled and unscheduled downtime.

When knowing this causing will help FMEA Project during the failure analysis stage. This has been a look at Process Performance Metrics in FMEA Project.

REFERENCES

Baldwin, R. (2006). Secrets of effective maintenance. Paper presented at Society for Maintenance and Reliability Professionals Annual Conference, Birmingham, AL. Retrieved from the SMRP Library.

Humphries, J. B. (1998). Best-in-class maintenance benchmarks. Iron and Steel Engineer, 1. Mitchell, J. S. (2007). Physical asset management handbook (4th ed). South Norwalk, CT: Industrial Press, Inc

Gulati, R. (2009). Maintenance and reliability best practices. South Norwalk, CT: Industrial

Press, Inc.

Another tool to help structure your data is called a Pareto analysis or called the Pareto principle. The Pareto principle implies that a small percentage of the causes produce a large portion of the problems. To better understand this tool, we will look at an example.

Let's say you run a small company that makes frozen pizzas, or we will call it or Pepperoni Pizza Factory. You have noticed your complaints are increasing and revenue has been dropping as a result. To correct these problems, you have a meeting with your senior staff to understand the complaints. The first question that comes to mind is what the most common complaint is? At the same time, which type of pizza has the most significant number of complaints? To answer these questions, this is where a Pareto chart can help. It has been used in sales for many years. Salespeople focus their attention and sales efforts on the top few customers, perhaps the top 20% who account for 80% of total sales. This is appropriately known as the 80/20 rule. The 80-20 rule, or the Pareto Principle, is a precept that 80% of outcomes (or outputs) result from 20% of all causes (or inputs) for any given event. Back to our pizza company. Here's the Pareto chart of complaints. Since this may be the first time you see a Pareto chart, let me explain.

The top line is the cumulative percentage line referencing the right axis. The left axis is the actual frequency count as shown by the height of each bar for each category. The categories or bars are prioritized from highest to lowest. In this chart, the biggest complaint category shows the total number of complaints. The second highest is next to the first. If we had 10 categories, it would be common to see the first 2 represent about 80% of the total. The other categories make up less than 20%. So, to work innovative, the leadership team should focus on analyzing the top 2 factors. The key metric is what's stated in the goal statement for your project charter. By asking what type of complaint and where the number of complaints is highest, I am stratifying the data on the key metric. During the measure phase, stratify the information on the key metric to focus the problem. In addition, by stratifying by what and where you can also stratify using who and when such as using a Pareto chart of complaints by team or by day of the week. Here's a tip on stratification. The Pareto chart is appropriate when the data type is categorical count data. In our example, the total count or percentage of complaints can be divided into categories such as location, style, shift teams, day of the week. Simply put, Pareto charts help your team focus your project efforts.

A block diagram or a boundary diagram is a system in which the principal parts or functions representing the blocks are connected by lines that show the relationships of the blocks. This tool is popular in engineering, hardware design, electronic design, software design, and process flow diagrams. Block/boundary diagrams are a great tool to help you better understand how the processes function visually for both a process and design FMEA. It is simple and, at the same time, so worthwhile. So, what is a block diagram anyway? A block diagram is just a series of figures that flow together. Let's look at an example. Let's say we want to design a new type of seat for a hoverboard. We'll put the seat for the hoverboard on the block diagram. Now, what are some of the things that need to happen before we start selling out hoverboard seat? In a Design FMEA, you might want to start idea screening.

• Gather information about seat and hoverboards

• Determine the type of material

• Understand the safety requirement

• Listen to what customers might want

Next, we may want to create a design before we build a prototype. Now that we have a prototype, we are going to need to test the hoverboard seat. Lastly, we are going to sell the hoverboard seat. Now realize that the block diagram is a tool to get the team talking. It's not meant to have all the details but a little structure. We will continue to expand on the details when we build a design tree, and function tree and further determine the risks. The block diagram is a great tool to get them to start to think about the design process.

The block diagram helps us understand how this works and impacts those processes. You see, business process improvement often requires collaboration with the other folks in our block diagram. If I want the very hoverboard seat design, you will need to reach other to other that know about seat and hoverboards. What is the best seat to fly your flying hoverboard? What material will hold up when flying, do we need seatbelts, can we have a drink holder?

Those are all questions our customers may ask when buying. The team can help us better understand the process and help our employees to prepare questions and problems. They can tell us what the customer's needs are. These are all questions we can ask? Things that we can do. And, perhaps, something that we can say while designing the world's best hoverboard seat.

Block diagrams are excellent. They help you understand the network of stakeholders and goals. And they demonstrate that improving a business process can be a group effort.

After developing your functional block diagram, your Design FMEA Project will move into building a Design Tree. A Design Tree provides an outline view of the active part, assembly, or drawing. This visual makes it easy to examine the various ideas and thoughts in the design. The Design Tree helps to break down the overall system and components of a structure. Remember in our Functional Block Diagram; we discussed designing a seat for a hoverboard. If we expand on our block diagram, begin to look at the components that make up a seat for our hoverboard, we see three primary details that go into our design: the Back System, the Seat System, and the Fasteners System. From these systems, we can expand our approach to components. We are beginning with the seat system that now has a cushion, frame, and fabric. Now the back system also has a structure and material. Finally, the fastener system will be made up of fasteners, glue, and stitching.

After putting this together, we now have a design tree. And this is a look at Design Tree in FMEA Project.

Henry Ford has said, "If I had asked my customers what they wanted, they'd have asked for a faster horse." While this quote may not demonstrate the improvement by listening to the customer, it does show customer's perspective has played an essential role in organizations for many years. The Voice of the Customer (VOC) and Critical Customer Requirements helps to focus the improvement effort to achieve breakthrough improvements to serve the customer better. Using the voice of the customer (VOC), the voice of the business (VOB), and the voice of the employee (VOE) can support your Design and Process FMEA. What does the customer want from use? During the FMEA Project Structure and System stage, developing this information will allow for fluid discussion in later stages of the FMEA Project.

Now to build you need to collect VOC, first, list your customers. Review your scope so that not expand beyond your primary customer. The customer is anyone who benefits from using your product and services or the output of your process. Customers can be internal or external. A Design FMEA could be both internal and external. A Process FMEA would often be internal, primarily within the supply chain. There several ways to collect the VOC or voice of the customer. Let's start with surveys. Surveys have the advantage of reaching a lot of people quickly, but low response rates often negate this. Think About it. Do you remember the last time you filled out a survey from a restaurant, hotel, or call center? Exactly. Unless you were very dissatisfied and upset or you were so impressed that you want to applaud them. It was okay or pretty good; we usually don't bother filling out a survey.

Another method for collecting the voice of the customer is focus groups. Focus groups give you a more in-depth understanding of customer needs. A good facilitator can interact with participants with focus groups to clarify and ask follow-up questions. Try to have all customer segments represented in each focus group or series in the groups. With internal customers, focus groups are often conducted as VOC workouts or brainstorming events. These can be very effective in your projects. While in-depth is time-consuming, interviews also suffer a similar disadvantage as surveys can be inadequate and skewed responses where people who choose to participate are mostly folks who are very dissatisfied or super delighted. The use of Kano analysis can be helpful. A Kano analysis allows you to identify segments by the type or level of quality that customers expect. Finally, observations provide an understanding of how customers interact with a service or process. Such observations offer an independent perspective. One disadvantage is that the observation itself may affect the behaviors being observed. This will lead to bias in the findings. Whether you want to understand customer needs or obtain feedback, collecting the voice of the customer or VOC is your first step.

Once you have your VOC, Critical Customer Requirements. This summarizes critical issues and translates them into specific and measurable requirements. In a Design FMEA, think about the key components if they are listed as components but can't define the function to support the design. It should be removed. The same is true for Process FMEA; each step in the process should add value. If it doesn't, it also should be removed. You want to make sure you keep those features in your design or process. You will want to look for trends that can be used later when focusing on optimization. If you find a problem and can be fixed right away, go ahead; but as a good FMEA Project manager, keep lessons learned log or best practices log. And if something is going well, you want to make sure you emphasize this to the people who are designing your products or improving your processes. You want to keep those high-quality features in mind as your FMEA Project will need to review later in the project. And this has been The Voice of the Customer for the FMEA Project

Since we learned how to create our project scope or process boundaries in the Initiating and Planning phase, we have a picture that provides a familiar and cohesive understanding of the process. Next, we will create a process map that provides a visual representation of the sequence of activities or steps in a process from start to finish. Have you ever bought furniture that requires assembly? Did you open the instruction or try to assemble it on your own? You might have wanted to put it together if you like me, but I referred solely to the instructions after one or two reworks. The same can hold when trying to understand a process. Having the visual to show the step-by-step flow makes it easier to understand and saves time. A process map or flowchart is a tool to help the FMEA Project team understand the process by creating a map showing the flow of valued added steps. Process Maps are great because they allow us to see points of entry and exit into a process step. Allows the Project team to see where stakeholder decisions might lead in different directions. And we have steps where we might exchange data or collect information. We also have symbols that notify us of deliveries, inspections, and even other processes that might be right in the middle of this process. But whether you follow all of these flowchart conventions or not, the important thing is that a process map or flowchart is an excellent visual tool. Let's, for example, say we have a frozen pizza factory; a process designer can see all of the activities at the pizza factory. A Process Map shows the decisions, all the points where value is created, and each step enters or exits the process. There are different types of process maps. A high-level process map, a detailed process map, a swimlane or deployment process map, and a value stream map (is a tool that lets you illustrate the final approach). The Process Map is a quality improvement tool. It enables you and others to see points of confusion and sections of the process that need additional improvement. It might also help you identify things that you forgot and also redundant steps. Developing a list of all the activities in a process might seem like an excellent way to understand what needs to happen in a business process. Still, to develop a business process that is effective and efficient, you'll want to use a Process Map.

So how do we create a Process Map?

Before you put pen to paper, you must understand that Flowchart or process maps should always trace back to their parent cross-functional flow diagram.

It is these subprocesses that are expanded further and detailed now in your Process Map. Firstly, you need to use the oval as the symbol used as the start and endpoints, also known as a terminator. You may also see the round-cornered rectangle used. Either way is fine as long as you're consistent and your project team knows, and your stakeholders understand what you mean by your symbols. The second step, which is the actual multiple steps in one, is to map out each part of the process. To do this, you use the process box symbol until the activity’s workflow is complete. The trick is never to have more than one step in each box. Here you can break down the process into the finest detail. Another trick to remember is that your flowchart diagram or process map doesn't need to flow from left to right. It can switch back-formation or up and down the page as long as it is logical, and the reader can interpret the flow of the events. The third step as you map out each activity is to note where a decision is required. This will alter the flow of events, and it is where you need to use your decision diamond. The diamond symbolizes that the pathways are not broken, and the normal flow of work can continue.

In the same way, the decision diamond is used in the cross-functional flow diagram; you need to choose the best way to annotate your response. Remember to try and be consistent wherever possible across all your maps. The fourth and final step is never to assume anything. Always run workshops. Talk to the people who are responsible for the work that you are trying to capture. Keep your sessions on track focusing on the normal process first and then considering the alternate flows. This will save you a lot of time and effort. I would also encourage you to ask one of your stakeholders to step you through the process and follow it on your Process map if they deviate from the sequence you have captured. This will give you a greater insight into how different people interpret executing the process and keeping you all from falling into the murky waters of inaccurate process and flowchart mapping.

Here's an example. Let's imagine we want to build a process map for a Frozen Pepperoni Pizza Company. Starting with our oval, used to represent the start and end of a process. We will say that our factory received an order for some frozen pizzas. This will initiate the process flow. The rectangle represents any step in the process we are diagramming and is the workhorse of the flowchart diagram. Use rectangles to capture process steps. So, in this case, our Pizza factory will put rectangles around

• Receiving the supplies and storing

• Mix the dough

• Flatten the dough

Then at this point, we need to make a decision. A decision is a symbolled with a Diamond. In this case, we need to know what toppings to add to the pizza. It could be pepperoni, onions, tomatoes, or all the above. After the decision, the process continues

• Add toppings

• Package the pizza

• Freeze the pizza

• Ship the pizza

In the end, the process map would have a second oval indicating the end. Which for use would be payment of the pizza. Following each step, we would also add an arrow pointing to the process direction. We used four basic symbols with our Pizza Factory, you will find that these are all you need to visualize a process in many cases. However, there are others.

A detailed process map provides sufficient granularity to enable the project team to understand what is going on, not going on and display where the decisions, rework loops, delays, bottlenecks, and workarounds occur. This is where you show the nitty-gritty detail. It's vital to be comprehensive here to see what is going on in the current state. It's a map describing the process as it is currently, not what it should be.

The SIPOC is an acronym for Supplier, Input, Process, Output, Customer. The SIPOC's purpose is to build a diagram is to help the project team identify process boundaries, key outputs, inputs and determine what is critical to quality.

It gives a high-level view of the suppliers and your customers. In other words, you could consider these the stakeholders of the project. A SIPOC diagram is constructed with five columns with the headings of the supplier, input, process, output, and customer.

Creating the SIPOC diagram is especially useful at the beginning of a project. The overview is necessary to understand the critical dimensions of a process and analyze how they contribute to the organization and FMEA project objectives. It is therefore considered an important part of the FMEA Project Structure and System analysis phase.

The way to look at a SIPOC is to start with the middle column, the P or Process column. From our learning in previous lectures on flowcharts, you can input your flowchart to show the process. Remember, this process is usually documented as few steps as possible but enough to describe the high-level process. It's not meant to take a lot of time but something that can be mapped out with a group in a single sitting. Let's look at an example using our Pepperoni Pizza Company; There are few steps for a pizza processing factory to produce frozen pizzas. The first is to receive the supplies, batch the dough, add topping, box, and deliver to customers. This could be considered our process. Next, move to the left to the supplier column and list the people, departments, or companies who supply the process. The term supplier is not limited to outside vendors. Suppliers can be any person or department upstream who provides inputs through the process in the P column. Suppliers could include:

• The flour manufacturer.

• The food processing companies that provide the ingredients.

• Even the vendor who calls in to place orders.

The next column captures the inputs that go into the process to be transformed. Inputs can be materials, people, items, information, or data. The pizza factory uses flour, water, and other ingredients. Which is the order information provided by customers. Now, having the Process column completed, begin the Output column that lists the outputs produced by the process, and outputs can be completed; forms, issued checks, products, or a pizza.

Finally, the Customer column lists the people, departments, or companies who receive what the process produces. The term customer is not limited to customers of the company or vendor you are supplying; it can also include people or departments downstream who accept what the process made. In our example, it could be pizza restaurants, grocery stores, and the general consumers. Here's the completed SIPOC diagram for our Pepperoni Pizza Factory. That's how to develop a SIPOC diagram. Once it is completed, you can benefit from knowing and communicating the scope of the process, what's involved and who's involved. You also benefit from knowing which stakeholders to engage during the FMEA project.

Brainstorming is bringing a group problem-solving, team members or stakeholders together to discuss spontaneous ideas from all group members to generate ideas about risk in both a design and process FMEA. In an FMEA Project, you will need to need to build content, data, list potential causes of trouble and failures so your team can bring structure before analysis and determining risk. Holding a brainstorming session is an excellent opportunity to get those minds working. Right? Listen, you can plan your session to the second and still have no idea what will come from it. It can be both great and so annoying. There are times when the pictures are coming fast and furious, and there are dozens of great ideas hitting the table. Other times, crickets. Why are some sessions great while others fall flat? In Alex Osborn's book, Your Creative Powers. Which, by the way, was released over 70 years ago but still relevant today. It discusses we have three factors at work within any group session. One, brainstorming is a process and, as such, requires time to develop. Two, the goal of a brainstorming session is to offer possibilities, not solutions, and three, brainstorming sessions are made up of people with their perspectives, experiences, and opinions, which means the group dynamic of interpersonal relationships plays a huge role in the effectiveness of the session. These factors make every session unique but also make every session unpredictable, but fear not. There are ways to minimize the causes of these fluctuations by giving your team something to react to. If I asked you to draw a picture of how they feel today on a blank piece of paper, you might struggle with the exercise, but if I drew a squiggle on the paper and then asked you to turn that squiggle into their emotions, the activity just got much more manageable. This is a psychology of reaction. Humans find it easier to react to something than they do to create something from scratch. So, in your brainstorming session, if you develop mechanisms to give your team something to respond to, you'll generate more conversation, leading to more ideas, which leads to even more to react. We're going to explore several basic brainstorming techniques that you can use to put that dot on the blank page of your brainstorming session. While these aren't exhaustive by any means, they'll serve to get you started towards an active session. This is a psychology of reaction. Humans find it easier to react to something than they do to create something from scratch. So, in your brainstorming session, if you develop mechanisms to give your team something to respond to, you'll generate more conversation, leading to more ideas, which leads to even more to react. We're going to explore several basic brainstorming techniques that you can use to put that dot on the blank page of your brainstorming session. While these aren't exhaustive by any means, they'll serve to get you started towards an active session. This is a psychology of reaction. Humans find it easier to react to something than they do to create something from scratch. So, in your brainstorming session, if you develop mechanisms to give your team something to respond to, you'll generate more conversation, leading to more ideas, which leads to even more to react. We're going to explore several basic brainstorming techniques that you can use to put that dot on the blank page of your brainstorming session. While these aren't exhaustive by any means, they'll serve to get you started towards an active session. Leading to more ideas, which leads to even more to react. We're going to explore several basic brainstorming techniques that you can use to put that dot on the blank page of your brainstorming session. While these aren't exhaustive by any means, they'll serve to get you started towards an active session. Leading to more ideas, which leads to even more to react. We're going to explore several basic brainstorming techniques that you can use to put that dot on the blank page of your brainstorming session. While these aren't exhaustive by any means, they'll serve to get you started towards an active session.

The only prerequisite for an ideal brainstorming candidate should be their willingness to say stupid things. Remember, your goal is a possibility, not the solution. Possibility means that there are times when ideas aren't fully formed.

Typically, a brainstorming session starts with someone reading the problem and then asking for ideas. Instead, try this. Start with an input exercise before you get to the output exercise of the imagination. Put the participants in the world of the problem. Focus on the audience or the industry, and ask for characteristics or descriptions. Avoid starting with the obvious question of; "Does anyone have any list of problems? What are the defects?" a good input exercise might be to start with a target audience and ask, "This the project" X "What is the worst that could happen?" or, "If your five-year-old self and had to run it what would you need to know?" This puts everyone in the audience's frame of mind. Now, when you ask, "What could happen or what would you need to know?" Spend the first third of your brainstorm setting the stage with an input exercise, and then the last two-thirds reacting to that stage. You'll have something deeper to start with, and the ideas produced will be anchored in something more substantial than just the brief.

One of the essential roles in any brainstorm session is the role of the scriber, documenter, or notetaker, the person designated to make sure that all the ideas presented are captured in some way. Usually done on a whiteboard, in a notebook, or on a laptop, but assigning this role to one person creates a set of challenges, the least of which is that there is only so much that one person can do.

Many information-gathering techniques may be used. However, some methods are more dominant. These techniques include the following.

Brainstorming: Many situations require the team to discuss various ideas or options for addressing issues within the project. Many of these situations warrant the use of some form of brainstorming. Faickney Osborn first popularized the term brainstorming in the 1953 book Applied Imagination. This book defines brainstorming as a group creativity technique by which efforts are made to conclude a specific problem by gathering a list of ideas contributed by its members. Keep that in mind when selecting.

To get your session started, here are several techniques with which you should become familiar. Would you please not use them all but pick the one you think your team will best respond to?

• Quiet Writing: This is a brainstorming technique where the individual team members are given time to generate a personal list of ideas before sharing them with the team. This technique has the advantage of limiting peer influence in the initial creation of concepts which often results in a more significant initial list. ⇒Round-Robin Brainstorming - This brainstorming technique requires the team to take turns suggesting one or more ideas to address specific project needs. It is often used in conjunction with the Quiet Writing technique, and it continues to the bias towards ensuring each team member participates in the process.

• Free-For-All - This is the most common brainstorming technique. However, many do not even think about it when deciding how to conduct a brainstorming session; it just happens. A free-for-all occurs whenever team members shout out ideas without any rules or constructs. In many cases, team members shout out over each other, making it difficult for team members to hear each other.

• Green Zone / Red Zone- This is a model first described by Lyssa Adkins. It represents more than a simple brainstorming technique but a way of establishing organizational guidelines for positive performance. In the model, Atkins describes two states of being in which we all exist, a red zone and a green zone. The red zone is a space where we become defensive and act strictly. When we become rigid, we typically stop thinking and turn to use most of our abilities to protect ourselves from the other members of our team. Our need for self-preservation is essential, but we must learn to control it and turn it towards a positive direction. To do this, we must learn to recognize when we are entering the Red Zone. The defensive response pattern can take many forms, but it is most commonly highlighted by a response to fight, flee, or freeze. Physically, emotionally, and intellectually team members are in a heightened state that focuses on self-protection and defending. When in the Red Zone, there are several possible tendencies: Blaming others for the circumstances of their life.

• • They are feeling threatened or wronged.

  • Our actions trigger defensiveness in others.

  • We do not seek or value feedback from others.

  • We regularly communicate a high level of disapproval and contempt for our teammates.

The Red Zone is not likely to be a place of collaboration, trust-building, mutual problem solving, or deeper self-reflection and shared accountability. According to most agile thought leaders, each of these are critical for project and team success. The alternative to the Red Zone is the Green Zone. When we are in the Green Zone, we feel relaxed, safe, alive, emotionally significant, competent, and likable. Being in the Green Zone allows team members to be intellectually open and honest. They can consciously operate in a non-defensive, cooperative, problem-solving, accountable state. When we are in the Green Zone, we do not see conflict situations as threatening. When a team member is in the Green Zone they exhibit the following qualities:

• They take responsibility for the circumstances of their life.

• They seek to respond to the actions and words of others in a non-defensive manner.

• Team members seek solutions rather than blame. They welcome feedback.

• They communicate a caring attitude to the other members and stakeholders.

Checklists: Checklists are often used as reminders of things the team needs to examine or consider. Most are based on historical information. The group begins with a list of items they believe need to be considered. As other projects are completed, the team gains experience and finds things they think the checklist missed. These items are then added to the checklist for future use.

Additionally, many industries have standardized checklists that provide an excellent starting point for the team. However, be careful. The danger of a checklist is that users often believe it to be a complete list. The team must look beyond the checklist for potential risks. Delphi Technique - The Delphi Technique is a survey methodology that targets subject matter experts in a three-step process.

1. Survey the subject matter experts about the subject in question

2. Aggregate the survey results and

3. Feed them back to the experts for review.

Have the experts consolidate the responses to a consensus opinion. When using the Delphi Technique, this process is repeated until a single position is established. This technique is helpful because it reduces bias.

Interviews - Interviewing is a less structured process than the Delphi Technique but is more structured than the brainstorming techniques.

When brainstorming, there are some dos and don'ts.

DO

• In the early part of the session, go for quantity and do not worry about quality.

• Ensure everyone is allowed to finish their thoughts

• Build on ideas of offers and encourage wild ideas to flow

• Have a scribe or note taker. But this position should be determined early as they have an essential role to visualize during the session.

• Keep all notes or take pictures of everyone's thoughts.

Don't

• Don't criticize ideas or make a judgment (All ideas are welcome if relevant to the topic). There's a greater chance for idea judgment and a better opportunity for personal judgment.

• Don't allow one person to dominate the session.

• Move off-topic

• Don't spring the meeting onto the group. Have the session scheduled at least a week in advance, along with clarifying the goal and provide any relevant information such as

• • Questions that will be asked; so they can start to prepare

  • Length of the meeting

  • If you're expecting someone to scribe, make sure you talk to them prior

• Don't expect your scriber to be the main contributor. They are trying to visualize ideas.

• Don't have at the end of the day or after lunch. Morning work best to keep energy levels high and minds working.

You follow these guidelines, and your brainstorming session will generate a lot of ideas. Following the brainstorming, you will need again capture and organize the team's ideas that make sense to the project's objective. Please don't throw any ideas out, but you can prioritize not offending those who would have been left off and affecting their contribution in the future.

This is the Function Tree FMEA Project. If you remember, back when we were building our structure and system for our seat on our hoverboard, we created a block diagram and design tree. These tools help bring visuals to the group, the development process and define the components. Once our design tree is done, we need to go back and consider what every piece of your design does and its function. If a piece does not have a function, it should not be part of your design. We need to be able to list at least one function for that component. We begin by looking at the overall function, diving into the systems, and then moving to the component level. When we look at our hoverboard seat, we have a couple of things we need to do

It needs to provide safety; we don't want to fall off once we start hovering; we need to feel safe.

We need it to provide comfort as we want to enjoy our hoverboard, and having a seat plays a significant role.

Lastly, we need to understand how to support the user's needs.

This is what we would call the overall system function. Next, we want to break the overall system function down into groups. For this example, we are looking at three groups. We will call it the Seat System, Back System, and Fasteners System. Each group or system offers a function, and we want to identify them at this time. For the seat system

Provide seat comfort

Support user's weight and height

Next, the back system will also need to.

Provide seat comfort

Support user's weight and height

And finally, the Fasteners system needs to hold the parts together.

Now that we have the systems developed, we can define the functions of the components. Taking our three systems, we will further break down what makes each of them. The seat systems include the seat and aprons. Next, the back system comprises the headrest, back cushion, and frame. The third system is the fasteners, all the nuts, bolts, thread, and glue holding everything together. Having developed all this information, we can take it and build our Function Tree. As you can see, it tends to spread out. You can have a tree that expands from the system to the component level for each of our functions at a hoverboard seat function. You can do this for each of your high-level functions and begin to see how complex and many things have to work at the component level to work at the design level. Having created a function tree allows the team to begin to determine failures. And this is a look at the Function Tree for a Design FMEA Project.

If you remember, in Function Point Analysis, we discussed the function tree, which was made by producing a design tree that we could create since we made a block diagram. In a Design FMEA, before moving into risk analysis, we need to determine how a function can fail and cause your overall design to fail. Let's begin by defining what a design failure is. Any design doesn't satisfy the user, or the design doesn't perform its intended function(s). It could be due to

• No Function

• Partial Function - This is when the user isn't delighted.

• Intermittent Function - Work sometimes; however, the user wants it to work all the time.

• Over-function - It worked so well that it no longer does what the user initially expected and therefore is not functioning correctly

In a Design FMEA, a failure is NOT just when something breaks. It is more than that; the product doesn't do what the user expected.

To look at failure, we need to look at a high level of the overall function. If we review our seat for the hoverboard, we have three functions. It provided safety for the user, offered comfort, and allowed the user to ride the hoverboard to sit. Now for each function, we define what could fail; we determine that the user falls out of the seat while hovering or the seat becomes detached from the hoverboard, which would fail the customer's expectation. (as you would expect). Therefore we say they would have no function or zero tolerance. Next, we say it's essential to sit on the hoverboard. We could call this a partial function or no function.

The last is to provide comfort to the user. If the user is uncomfortable, the design would have no or partial function. These are at the top of the failure mode and are called the effects of the failure mode that the user experiences. If we move down a level in your tree, we are at the system functions. The system functions lead to system failures. We want to identify all the possible shortcomings of the system. And finally, at the component level, we look at the function and determine the failures. These are the things in your design detail. These components you can change. Having this, you know, have a Design Tree (Overall, Systems, and Components). We have built a Function Tree, and lastly, we just created a list of failures for every function. We are now ready to work to determine the Risk for your Design FMEA. As the best practice, try to break this process out into a few meetings with the project team to avoid groupthink or other problems that could occur due to the group's fatigue in a long meeting that everyone is expected to contribute.

We are fishing for failures! An Ishikawa or Fishbone diagram is simply a diagram to organize the potential causes of a particular effect. The keyword here is likely, not proven yet. The impact that you base them on should be as specific as possible. This is an effective tool in the failure analysis stage. Taking the information from your System Analysis and Function Point Analysis, we have the knowledge to build Fishbone.

First developed by Dr. Kaoru Ishikawa, the Ishikawa or fishbone diagram is a graphical tool used to identify potential root causes. The category of process inputs represents the most significant source of variability in the output. A completed fishbone diagram includes a central spine and branches resembling a fish skeleton. The components are used to categorize the causes, either by process sequence or function. The potential causes are listed in each category and then tested for validity using evidence or another analytical tool. The advantage of the fishbone diagram is that it shows relationships between potential causes and is an excellent way to involve people in problem-solving.

To create an Ishikawa or Fishbone diagram.

1. Take the flow chart created in the early steps and define each problem to be solved.

2. The FMEA Project team finds all possible causes of the problem. Having subject matter experts can accelerate this process.

3. Organize the results into categories. Logical categories could include

   1. Environment

   2. Process

   3. Design

   4. Assembly

   5. Fabrication

   6. Facilities

   7. Equipment

   8. Policies

   9. Workforce

   10. Material

(It is common to see a fishbone categorized as a 5M+P = Material, Methods, Machines, Measures, Mother Nature, and People)

· Material: The raw materials used in a process; in services, usually information or data of some kind.

· Methods: This relates to the processes, procedures, work instructions, or how the job is done.

· Machines: This can include equipment and tools of all kinds.

· Measure: any methods for measuring the quality of process and outputs, including inspections.

· Mother Nature: The physical and management environment in which work is done, the marketplace at large, and the natural environment.

· People: anyone involved in the process, including customers, employees, managers, regulators, or shareholders.

4. Build the Ishikawa or fishbone diagram. Start by drawing a box on the right side of a large piece of paper or board. Draw a horizontal arrow that points to the box. Inside the box, write the description of the problem that is trying to be solved.

5. Next, write the names of the categories above and below the horizontal line. These give the diagram the appearance of a fishbone.

6. Draw in the detailed cause data for each category. These would be the bones. Good diagrams have many “bones,” which reflect a good brainstorming session.

Let’s look at an example from our Pepperoni Pizza Company. For our example, we will say that the Pepperoni Pizza Company has received many complaints about how many pieces of pepperoni are on each pizza. To do this, we want to bring our team together and start with the problem statement, “Complaints about lack of pepperoni.” Next, we would brainstorm ideas. One way to help facilitate this is to have one person writing and using the 5M+P approach. Ask the team to list all the reasons material is the reason for the complaints. Document until all causes are registered, and all ideas have been depleted, then move on to the next category until the six categories have been built. Use this as a starting point, and if more types need, feel free to expand. The objective is to develop as many causes as possible.

A good Ishikawa or Fishbone will have many bones to demonstrate a list of causes.

For FMEA Project, the team can ask why these are causes or save this information for the Optimization and Project Execution stage if it is viable to have the teamwork to root cause. This a been a look at Fishbone Diagram from FMEA Project.

We have all probably facilitated a meeting or group session of some type in the past. This facilitation responsibility is core to the role of the FMEA Project Manager. However, comfort levels with facilitation vary from person to person. Ensuring that a meeting runs well and achieves consensus is an art and a science. The science is all in the pre-planning for the meeting; the art comes when the session begins, facilitating the discussion, moderating the disagreements, and motivating the team to make decisions.

Research shows that more than 35% of employee time is spent in meetings every day. Making this time productive is a challenge and takes effort and planning. It is challenging to bring even a small team together for a dedicated focus on a specific topic. This can hamper the productivity of the project. To be productive means you want clear results. To get clear results, you need to know your objectives, research information to help you in the meeting, and plan. In addition, be ready to handle the team. This means planning the meeting objectives and format and determining tools and tactics to build consensus and deal with conflicts.

For the FMEA project, the team will have several meetings to create objectives, scope, and schedule for success. Begin by establishing a purpose for each meeting. Scheduling a meeting to have a placeholder on the team's calendar disrespects your team's time and tells others you're not interested in others' objectives. Each session should have a purpose. Following the FMEA Project format gives the project manager the guidelines. Meetings require planning if you want to achieve a goal during the session. Consider each event as a mini-project where you must clearly define the scope and deliverables you want to obtain. Identify your stakeholders and work with them to develop the objectives for your meeting. Formalizing these types of arrangements can help the team understand the importance of their participation.

As you define the purpose of your meeting, consider the meeting as a cost to the project team. How much time will the meeting take for everyone involved? What is the hourly rate of each person's time worth? How expensive is the meeting? To make the most of your meeting time, help attendees prepare ahead of time so that you can focus on the purpose of the meeting when the meeting starts. The information can be distributed ahead of time that can make meetings more efficient working sessions.

What Needs to Happen

When defining the scope, develop a list of what needs to happen in your meeting. Do you need to identify risks? Get the team to decide? Persuade a stakeholder? Further analyzing what needs to occur and documenting it in a plan is essential for meeting planning. The meeting agenda should identify who is attending, how long the meeting will take, a timeline of what you will be doing during the session, and a clear call to action for the team members or stakeholders who must be active participants.

Conducting the Meeting

Conducting the meeting is exercising the art of facilitation. Established meeting scope, defined who, what, when, where, why, and how for your meeting, you are about to stand in front of a group of people and help drive them toward your project objectives.

The number one fear of most people is public speaking. To stand in front of your peers and speak clearly on a topic of interest can strike fear into the hearts of most presenters.

Know Your Team

Before you start working with your team, take the time to get to know the individuals. What are their strengths and weaknesses? Personality types? Consider using checklists to help you learn about personal meeting/communication style preferences.

For project teams that are just starting to form, consider ice-breaker activities to help the team members make interpersonal connections and gain trust. These activities can help you identify people who may need encouragement during discussion or more management during meetings because of their forceful personalities. Starting your team off in a positive direction can help them work toward becoming a high-performing team. Consider the Myers-Briggs personality assessment that categorizes individuals on four dimensions and can help a team bond through discussions about their "type" and give your insight into the profile of your team members.

Set the Ground Rules

At the start of each meeting, you should set the ground rules. These rules should explain appropriate behavior and etiquette for the meeting. How will someone have the floor for presenting their ideas? Who is recording decisions and action items? How will disputes be managed? What process will you use to build and reach a consensus?

Stick to Your Promises

As an FMEA Project Manager, you have established the scope of the meeting through your plan, and by establishing ground rules, you have given everyone a standard code of conduct. Stick to these promises by conducting the meeting by the plan. Stay on topic and on time, and keep the guarantee of your plan. If the team wanders into issues that were not part of the original plan, stop the discussion and put it on a "parking lot" for further discussion at a meeting dedicated to the topic and return to the goal established for the meeting at hand.

Difficult people come in many varieties—

· Snipers - Those who throw out jabs at other team members.

· Steamrollers - Are those who ignore everyone else's idea and keep going with their plan.

· Pleasers are those who agree with everyone and everything even when it contradicts—but they all have one thing in common: they want attention and want to be heard.

Most difficult people are not trying to throw the meeting off course; often, they have a firm belief that they know how it "should be done" and are passionate about helping the team. As a facilitator, your job is to help the team stay on track but not lose the ideas of a problematic team member. You can help them get the attention they want and the listening ears they are hoping for and still accomplish the objectives of the meeting. If they have more to contribute, suggesting a separate side meeting where the two of you can collaborate is a positive way to recognize their contribution but allow the conversation to move forward.

Build Consensus

The facilitator can use additional tools during the meetings, including the nominal group technique, affinity diagrams, and prioritization matrices, to bring about decisions and build consensus.

Remember to start any facilitation session on time, distribute the plans ahead of time, and make the participants as comfortable as possible. Make sure that everyone knows why they are there and what the expected outcome is.

Closing

Stick to your plan, keep any necessary records of the event, and do not forget any follow-up. A good facilitator is worth their weight in gold. Provide the best venue with the right equipment, clearly define who, what, where, when, why, and how you will meet. Do not waste anyone's time, including your own, and plan, plan, plan to succeed

If you are familiar with the FMEA, you have probably heard of the Risk Priority Number. After all, it is the staple of what the FMEA is built on it. The Risk Priority Number or RPN is the primary data set or deliverables of an FMEA. It is how we take subjective opinions, beliefs, and theories and turn them into quantitative information. It gives a scale we can track, graph, measure, and share. We will be looking at the Risk Priority Number of our FMEA Project. Take in mind that the objective of an FMEA is to look at ways a process or product can fail. It is important to remember that just because your team has created a list along with a Risk Priority Number, it should not be standpoint as a finished product. The objective of an FMEA Project is to identify and medicate risk. You have assembled the best team that is available. You have several subject matter experts that are key stakeholders that will give you the best perspective of the product or process risk. Therefore the team is well versed in determining a product, function, or component failure occurs when the product does not function as it was designed or the process does not happen. As we will review, even the most straightforward products have many opportunities for failure.

Anything that can stop the failure can ensure the product works correctly, regardless of how the user operates it and will move the product to meet customer satisfaction. Ways in which a product or process can fail are called failure modes. The FMEA process identifies the failures, effects, and risks within a process or product and then eliminates or reduces them. Evaluating the Risk of Failure to the relative risk of a failure and its effects are determined by three factors that make up the Risk Priority Number:

1. Severity—This is the consequence of the failure should it occur.

2. Occurrence—Looks at the probability or frequency of the failure occurring.

3. Detection—The likelihood of the failure being detected before the impact of the effect is realized.

They assess the Risk Priority Number using the data and knowledge of the process or product, from the severity, occurrences, and detection. The team will review the potential failure mode, and the effect is rated in three factors on a scale from 1 to 10 or low to high. These three inputs (severity × occurrence × detection) are then multiplied, and the team will determine a risk priority number (RPN) based on the potential failure mode and its effect. A risk priority number can range from a low risk of 1 to an extreme risk of 1,000. The high risk will need corrective actions to eliminate or reduce the potential failure modes. Failure modes with the highest RPNs have priority first; although RPN may be below the team, tolerance still needs special attention when the severity ranking is high (9 or 10) regardless of the RPN. Following corrective action, a new RPN for the failure is determined by reevaluating the severity, occurrence, and detection rankings. This new RPN is called the “Resulting RPN.” Improvement and corrective action should continue until the resulting RPN is acceptable for all potential failure modes.

This has been a look at the Risk Priority Number for FMEA Project.

Ok, are we ready to do your risk analysis? Do we have

· Design tree with the overall system, and components

· Function tree

· And a list of failures for every function

If we do; great!

Let's go through the Risk Analysis of the FMEA. Now you can use the same form for either a processor design. Here are the steps for completing an FMEA — one: Starting with the first column. In our example, we have place alphabetic letters at the top for reference. The columns list with the letter "a" represents the information we already built when we did our system, function, and failure analysis. We will enter the process step or Item list from our defined systems or structure. Next, in column "2a," we will list all the functions with the system or structure. Column "3a" will include the requirements on why it's a function. This is simply taking your list of systems, and functions and adding to the form.

· Column "a" is to answer the question of "what and where."

· Column "b" is asking what the potential failure mode to the system or structure is. This is what could fail, consider this the input.

· Column "c" is the potential effect of the failure. Think of this as the output if the failure occurs. What could happen if this failure occurred. Could it affect the final product or the experience of the customers?

· Column "d" is the severity (S) of the failure. This will be used to develop the Risk Priority Number. It is a numerical value between 1 and 10 used to indicate the seriousness of the failure. We will discuss more severity in another lecture.

· Column "e" is classification. It's used to identify unique characteristics in the manufacturing process or product.

· Column "f" is the potential cause of failure. Think of this as the input to the failure mode.

· Column "g" is what is currently the system or structure preventing the potential failure.

· Column "h" is an occurrence (O). This is the numerical value between 1 and 10 used to indicate the possibility that a cause can occur. We will go into more detail in occurrences and frequency.

· Column "i" is asking what the current detection controls are. Think about the mechanism that is currently in place to detect failure from happening.

Column "j" is detection (D) which is the numerical value between 1 and 10 for the effectiveness of the listed detection control method.

· Column "k" is the Risk Priority Number. This is multiplying (Severity X Occurrence X Detection) = Risk Priority Number. This will give a range from (1 to 1000). Having this number, we have quantified our risk. At this point, the team and sponsor will need to determine of effects what they will further work on.

· Column "l" is recommended preventive actions.

· Column "1m" is who is the individual or organization responsible for the recommended action.

· Column "2m" is the target completion date of those recommended and approved items.

· Column "3m" is the action taken to implement the recommended actions.

· Column "n, o, p" the reassessed severity, occurrence, and detection after or if the recommended preventive action is implemented

· Column "q" is the new RPN. Show the shift from before and after optimization work

As you build is living form, consider it in 4 stages.

1. Pre-FMEA data population columns a - c.

2. Determine the risk of the failures d - k.

3. Develop action plans to support the Risk I - m

4. The last is the controls and improvements n - q

This form can easily be constructed in excel; However, navigation around the FMEA form can be clunky, and often further software applications are used. You can message me through this site if you are interested in further examples or have an FMEA Project Tracker.

When using the FMEA form can be used in four steps.

1. Pre-FMEA Data Input: This is all the pre-work that the team has put together. From the Initiating, Structure, Function, and Failure Analysis.

2. Determine Risk Failures

3. Develop action plans

4. Improvement and Controls

The Pre-FMEA data inputs to the FMEA Form can be tasked to a team individual or Project Manager to build. Make the meeting effective; the team member will appreciate it when you value their time. This is the process step or item. If we are doing our Design FMEA for our seat for our hoverboard, our FUNCTION might be our Support Seat Back System. This is the part you rest your back.

Column 1a is the Function of the seatback system. A couple of things to consider when writing the Function. The Pre-FMEA should write the Function in verb-noun context. So, SUPPORT would be the verb, and SEATBACK is the noun. Have the Function to have associated measures. This describes the main reasons for the system or design of given equipment. There are seldom more than three primary functions. The Pre-FMEA can define the functions as primary or secondary. Examples might include

• Environmental integrity

• Safety / structural integrity

• Control / containment / comfort

• Appearance

• Protection

• Economy/efficiency

This may not be a complete list, but you can get the idea.

After the Function is the Failure Mode in column a2, this is important as you will create your Severity and Occurrence off this statement. Similar to the Function, it should be written in a verb-noun contest. Our hoverboard might be “Seatback system Support and Protection. Column a3 describes the different elements of why you need this Function. Displaying this can give strength or weakness behind the scoring of the risk priority number. This can help determine if you need the process or Function listed depending on how this is answered.

For “column b,” the Failure modes should be written as “anti-functions,” and there are five types of failure modes.

1. complete failure,

2. partial failure,

3. intermittent failure

4. over-function

5. unintended Function

In our example, if the seat is uncomfortable, that would describe how the Function is a failure.

The last of the Pre-FMEA inputs is the Potential Failure Mode. This would be the worst-case failure if it were to occur. For our seat, it might be the back following off.

Are you in suspense? Don’t worry. We will solve this in the following lecture on Determine Risk Failures.

One last nugget of information on Process-FMEA is that in some cases when working with a Process FMEA, you may have the capability to have digital or historic tracking systems and what is the cost of failure. In those cases, adding additional columns that show the meantime to repair (MTTR), cost of failure, and mean time to failure (MTTF) can be helpful. Inputting these in columns c2, c3, and g2 give the team more information to work on. If you’re interested in learning more about how please send me a message.

When determining the ranking for the Severity, Occurrences, and Detection, having specific, measurable, and realistic criteria on your scale can make the difference between an FMEA flop and a successful FMEA Project. If the ranking doesn't reflect what the business would consider necessary or less critical, it can change the perspective of the business and customer. The three inputs are based on a scale of 1 – 10 or low risk to high risk. Define what good is, then define the worst criteria for the Severity, Occurrences, and Detections. Start by defining the rank of what a nine is defined, which will help you will lead to a ten and therefore keep the ranking in scope. A couple of things to think about in developing the rank has to do a lot with your business acceptance of risk. An aircraft parts producer versus a paper bag manufacturer criterion would be much different. This is not to say one FMEA is better; however, will the FMEA add value to the business, which means the high-quality product, safe production, and reliability to the customer in a manner the business can afford the risk. No, one wants their grocery bag to break, but no one wants planes to start dropping out of the air. We will give some ideas to your ranking but make sure your sponsor supports the team decision. The team needs to be able to example WHY each criterion received that ranking.

If this is the business's first FMEA, spend time developing the ranking. Consider expending the stockholders as you don't want to muddy the data years from now. If you're not able to standardize the three inputs for future FMEA Projects, it can create doubt about the effectiveness of your previous FMEA Projects.

Let's look at the three inputs that make up the Risk Priority Number. Starting with Severity, you are solving how severe the effects would be if failure or risk occurs. In the example of a manufacturing process for Pepperoni Pizza Company, the severity score is rated against the impact of the effect caused by the failure mode on the batch quality of the pizza dough.

How significant is the failure effect on the customer? Remember, customers can be internal and external. Internal would be the process step following a batch of pizza dough. External it could be the buyer and consumers. A 10 in Severity would include complete failure in Safety, Regulatory, Quality, or Production, and these would be considered Disastrous. Early I said the team should define what a 9 or 8 is first as they will create discussion around the criteria of Severity. FMEA Project will include several examples of Severity, Occurrences, and Detection available, and this can help as an excellent starting point to determine each of the rankings.

Severity:

• In general, a nine would be around the potential failure is compromised or his control is questionable.

• An 8 is the loss of primary function or customer goodwill in the design and process of FMEA. This could include a disruption in the process. If a nine is Extreme, an eight is Serious.

• And seven would be considered HIGH for the loss of function in a design or reduced customer loyalty in both types of FMEA.

• We will consider a six as Significant to a loss of a secondary function in design. The consumer might experience discomfort and will complain. In a process FMEA, this could also include some increase in rework and scrap. The FMEA team would need to define the limits.

• Now 5 represents the middle, and we would call it Moderate. The consumer might experience discomfort and will complain. In a process FMEA, this could also include some percent of rework and an increase in scrap. If a 6 represents 100% rework, a five would be defined as less than that 100%. The same would hold for scrap.

• Less Moderate is a four and could be an annoyance. Might be dissatisfied customer due to reducing performance. The process could still have the opportunity for rework and scrap.

• A 3 rank is a Minor Annoyance which could include irritated customers on the performance. It could consist of some rework and scrap.

• A 2 ranking is Slight Annoyance with slight inconvenience to process or operators. The customer may not notice the effect even if it's present.

• And finally, a 1 represents No Effect, and the customer would not notice any problems with the product.

Please continue this series next, looking at Occurrences from FMEA Project.

Suppose we look at occurrences ranking numbers associated with the likelihood that the failure mode and its associated cause will be present in the analyzed item. For System and Design FMEAs, the occurrence ranking considers the probability of occurrence during the design life of the product.

Occurrences:

• The likelihood of Very High would be a 10 for occurrences. A Design FMEA might include new technology or design with no documented history. In a Process, FMEA Very High or ten could be the failure occurrences occurring in the process. This would depend on the process and how the business determines events as a risk. An example might be that a 10 in the process step means 100 occurrences per day.

• A 9 is called High. A Design FMEA could include inevitable failure with a new design, application, or change in operating conditions. Process FMEA could represent a 10% reduction in occurrence from a ten, which can pattern itself until it is down to an acceptable event that would rank as a one. Nevertheless, it is the team to decide.

• An eight would still be considered Less High. Failure is likely with a new design, application, or change in operating conditions.

• The next is a seven, which we would call Elevated Risk. We are unsure about failure, but there is a new design or application. We may even have some test data to support it; however, it may not be promising.

• We will call six More Moderate. Frequent failures are associated with a similar design.

• A 5 is Moderate but a similar design as occasional failures.

• Less Moderate is 4, which might be defined as isolated failures to a similar design or process. We can simulate and test.

• The likelihood for a 3, which we will call Low, would reflect some isolated failures. The design might be almost identical to another, and we have a design simulation and testing information.

• A 2 is considered Lower, and it would have no observed failures, identical to another design, and we have simulation and testing information to support it.

• Finally, one would mean that failure is eliminated through preventative controls, and we would consider the likelihood of failure as None.

We have now reviewed building a ranking for Severity and Occurrences. Our last of our serious is Detection. Furthermore, this has been FMEA Project.

A third of the ranking we will have to deal with is Detection. How likely is it that with an existing system or process, we could detect the cause if it occurs? Starting from the highest to the lowest.

• A 10 on Detection would mean the effect is Completely Uncertain. This means failure is impossible to detect, or failure is not inspected. In a Design FMEA, there would be no design controls, it cannot detect failures, and the function has not been analyzed. You could also look at the probability of a defect reaching the customer if not detected. For a 10, we would consider it to be 90% to 100% certain. Similar to Occurrences, you can apply a reducing percentage for each rank.

• Moreover, a 9 is the effect of Detection is Uncertain. For a Design FMEA, it could be that the detection controls have a weak detection capability. A Process FMEA may have a near to impossible to detect failure.

• An eight, we will say a Remote change of Detection. It is still challenging to detect failure. The product may be accepted based on no defects found in samples.

• Detection of 7 is considered Very Low due to a change of Detection. It is improbable to detect before reaching the customer.

• Now six is considered Low, meaning the low chance of Detection and unlikely to be detected before reaching the customer.

• A 5 represents a Moderate opportunity for Detection. In a Design FMEA, there is product validation before the design freeze. For a Process FMEA, there is a chance of Detection before it reaches the customer.

• A Moderately High is 4 with a chance of production validation before the design freeze or is likely to be detected before it reaches the customer.

• A 3 is a Moderately High chance or better chance than 4 of the following.

• Very High is a 2, meaning Design FMEA has strong controls to detect opportunities.

• Furthermore, it is Almost Certain for a 1, which means failure cause and modes cannot occur because it is entirely prevented through Design or Process solution.

Keep these in mind when creating your ranking, and this has been a look at How to Determine SOD Ranking in FMEA Project.

The second step in building your FMEA form for your FMEA Project is determining your risk factors. At this point, you have pre-populated your structure, functions, and failures, and the team is coming together to assess risk. You could consider this the “heart” of your entire project. It is what a traditional FMEA is considered, and much is followed. However, for FMEA Project, we are looking at the whole lifespan, which would be a part of the FMEA Project process.

Referring to our form, we are at column “c,” which is the Potential Effect(s) of Failure. When populating this with the team, try to use language everyone can understand. It is a best practice to use basic descriptions. Some of your subject matter expects maybe resources that are not technical and could divide the group. The effects of the failure can be visible at three levels in a Process FMEA.

Local, which means effect occurs at the function or process

Upstream, before function or process. An example might be a defect that does not affect the process until it reaches that step.

Downstream, from the function or process, the effects occur.

The Potential effects of failure for a Process FMEA would have an impact.

Safety/regulatory – which could include recalls, warranty

Environment

Productivity

Quality

Customer orders (internal or external)

In addition, a Design FMEA Potential effects may also include

Unsatisfied customer experience

Loss of customer

Poor reviews on that function

As an FMEA Project Manager, continue to ask the question(s) on what of the 3 levels is the effect of failure and the worst-case impact of that function failure. This could often be a time the teams start to drift out of scope. FMEA Project Manager may have to be very active during this time to avoid groupthink or following out of range.

Next, it is time to determine Severity (S). This is in column “d” of the FMEA Form. The severity is based upon internally defined criteria or is based upon standard with specification modifications, a reference to rating tables with an explanation for use on the FMEA. The rating is (1 – 10) or low to high. Represents the seriousness of the failure of the operation after it has occurred.

We will look at two types of severity. One is Process FMEA. Another is Design FMEA. The team can modify as they see appropriate; however, I would include sponsors and as many stockholders as possible before dramatic changes. We will also have several examples in the documents section of this lecture.

“Do not say it cannot be done, rather say, you don’t know how to do it yet.” ​– Tomas Bata. We have the RPN (Risk Priority Number). We are still in the Risk Analysis. We build the FMEA documents transposed into action items, matrix, communication plans to a process, or other optimization strategies we will cover in the next phase.

We are up to column “l,” which is the recommended action. The column can fill this out in two ways. The first manor is to add what the team suggests to reduce the risk of failure, or the second is the team will accept the risk. This is often determined based on the Risk Priority Number, where this failure lies in priority, but also consider corrective actions if this failure scored at 9 or 10 regardless of if RPN remained low as this could still be regarded as a severe threat. Next, column “1m” adds responsibility for completing the actions in column “l.” In the column “2m,” add the target completion date. While these dates and activities will have to have a level of flexibility since these are rough estimates, they are meant to bring attention and be included in the FMEA Form for ease of access. Updates are expected as more learnings occur. Moving this to an optimization and project execution tracker can be helpful. It’s essential to commit the sponsor and individual stakeholders that will be taking on the action. Column “4m” is where the actual completion data occurred.

Following the completion of “l and M,” the team will re-access the Result Severity, Result Occurrence, and Result Determination. After the re-access, it will show a new Resulting Risk Priority Number. This FMEA Form needs to be cared for as a living document and be accessible to others for review only. Also, plan to link the FMEA Form and the design process for historical tracking and ease of access. We will discuss this further in FMEA Project Monitoring and Controls. This has been a look at Action and Improvement Plans for FMEA Project.

Let us go through the Risk Analysis of the FMEA. Here are the steps for completing a process FMEA. One: Starting with the first column, list all the process steps of interest on the FMEA worksheet. Two: In the next column, list and describe all potential ways the process can fail. These are the failure modes. There may be multiple failure modes for each process step. List one failure mode per row. Use multiple rows if needed. Three: For the effects column, describe the effect of each failure, then ask: How severe is the effect of that failure? Four: In the next column, rate the severity of the effect on a one to 10 scale, where 10 is the most severe. Five: Brainstorm and list all potential causes for each failure mode. Six: Rate the likelihood of occurrence of the causes. One is least likely, and 10 most likely to occur. Seven: Ask what current controls are in place today to deter the failure mode when it occurs. List the current process controls. Controls may include Inspection, checklists, or error-proofing such as automatic spell checking of a document. Eight: In the next column, rate the likelihood of detection. How likely that the current process controls will be able to detect each failure mode prior to customer delivery. Rate it using a one to 10 scales. One equals most likely to detect, and 10 equals unlikely to detect. Be careful with this scale, as a high score means high risk. So if the detection capability is outstanding, a score of one. Poorest detection capability is a 10. Nine: The RPN, or risk priority number, is occurrence times severity times detection. The FMEA spreadsheet automatically scores the risk priority number. The higher the risks, the higher the RPN. 10: The FMEA will then be revealed by the project team to identify high-risk areas based on the highest RPN scores. Your Black Belt or Green Belt project leader will facilitate the development and completion of the FMEA. As a team member, you will be tapped for your collective expertise and experience in combination with invited subject matter experts, process owners, and stakeholders. The group's consensus is used to quantify risks, and if data is available, it will be used to assist in the scoring. Be consistent in the scoring of severity, occurrence, or detection. The scores are all relative, but be consistent. Now you're not done yet. There are two final steps. 11: After reviewing the FMEA, your team has prioritized the risks, and recommendations are made. List recommendations in the recommendations column. Recommendations can be made to prevent failure mode and improve the detection. This can be done with error proofing, better controls, Inspection, and checklist procedures. For example, airline pilots execute a pre-flight checklist for every flight before pulling away from the gate. 12: Recommendations that are implemented are then scored, and RPN is updated. These are the 12 steps of completing any FMEA. To summarize: FMEA is a handy tool to identify, prioritize and mitigate risk or potential failures.

We left off having built our Risk Analysis and determining what work needs to be done based on our RPN ranking. While every business has different circumstances and priorities, focusing on the Risk Analysis around the top 20% of the failure modes in common. However, also reviewed any categories that had scores of 9 or 10. To develop an action plan, begin by identifying a wide range of potential solutions. Evaluate and select the best alternatives. Flesh out the solution idea, establish criteria and evaluate the possibilities. Think about organizing the priority and developing an FMEA Matrix, Decision Tree, and Experiment Design. Later lectures will show you how to do each of these, but communication becomes an essential tool to deliver with execution. As you work to develop action plans, you are going to need to focus on the following

• Identify the actions necessary to reduce the risk; As an FMEA Project Manager, your job is to minimize risk.

• Determine those responsible and have deadlines for action.

• Document the actions taken and lessons learned

• Implement action and work to remove roadblocks for the team

• Reassessment of risk following the change

While delivering on these actions will mitigate risk, the continuous improvement of the product and process will be ongoing. Your job in this phase is of a traditional project manager, which means you are responsible for planning, organizing, and directing the completion of specific tasks while ensuring they are on time and within scope.

This has been a look at how to optimize FMEA Project.

We will discuss a tool that can help build logic to your decisions The Decision Tree! We are not talking about your typical backyard tree. We are talking about a high-powered, data-hungry decision-making machine. The Decision Tree is an impressive tool to add a quantitative perspective to decision-making. I like this tool because it gives an easy understanding of the final decision based on the data; based on a series of questions, you can input the outcome to build the Decision Tree. There is a great book called "Decision Tree Primer" by Craig Kirkwood. Craig Kirkwood says, "The analysis of complex decisions with significant uncertainty can be confusing because

1. The consequence of any specified decision alternative may not have certainty in the decision.

2. There are often many different factors that must be taken into account when making the decision.

3. It may be helpful to consider reducing the uncertainty in the decision by collecting additional information.

4. A decision maker's attitudes towards risk-taking can impact the relative desirability of different alternatives.

Making decisions with incomplete information is challenging. Humans are imperfect at it, and they do not like it. Still, it is essential to go through the exercise of doing this because the alternative will be a political decision based on people's opinions. So just because it is hard to make decisions with uncertainty, it does not mean we cannot reason about them. We can reason about them and write down the basis for making decisions. Furthermore, we can even factor in our cognitive biases, such as risk aversion.

A decision tree is a decision support tool that uses a tree-like model of decisions and possible consequences, including chance event outcomes, resource costs, and utility. It is one way to display an algorithm that only contains conditional control statements. A decision tree is a flowchart-like structure in which each internal node represents a "test" on an attribute (e.g., whether a coin flip comes up with heads or tails), and each branch represents the outcome of the test. Each leaf node represents a class label (decision taken after computing all attributes).

We use the decision tree in optimization and execution to determine outcomes before investing time and resources. In an FMEA Project, you may not have all the information, or you do not need to have all the information to determine the actual cost of risk. In the optimization and execution phase, determining the cost of failure or risk will give a clearer perspective on action items requiring more investment in a processor design. A Decision Tree can help businesses understand your need to pursue this action item.

Decision trees provide a visual methodology to calculate outcomes involving a chance event and the implications of each available choice. Decision Trees incorporate cost, probability, and results. For FMEA Project, you and your team need to make a choice. You can either accept the risk or invest in the alternative, but some chance event might impact the project results regardless of your decision.

Let's look at an example. Let's take our design to the seat of our hoverboards. Choosing to accept risk and the chance event happens, like not changing the material of the seat, we could say there is a 30% chance you will not see any problems. However, if you choose material "A," the initial investments from the decision will cause no initial cost to testing new material, which will call a $0 worth of choice. However, if you and failure happen, the team might decide there is a 70% chance you could see a problem resulting in failure, warranty, or lost customer would be a $500,000 loss to the business.

The tree is broken into columns. The first column is the decision point and should be ignored. Column A shows the costs of the two choices. Because they are expenses or outflows of capital for the organization, the values are negative ($-200K and $ 0). Column B shows the probability of getting the outcome should the choice (either accept risk or test and develop) be made and the result, or payout, from making that choice. Column C shows the net outcome, which is column B minus the cost of making that choice (Column A). Column D takes the net result from Column C and multiplies it by the probability of having that outcome found in Column B. The product for each choice is derived by summing the two possible effects for each branch. In our seat for our hoverboard, the best choice is to invest in test and development because it has a payout of $340 versus the risk option, which only has a value of $-320K.

This tool relies on several assumptions about the unknown. Still, it offers the best analysis of what could happen by showing financials to the business. Therefore, it gives a quantitative study that helps give confidence when determining action plans and the next step.

This has been a look at the Decision Tree by FMEA Project.

"The smarter you play, the luckier you will be"- Mark Pilarski. Gambling is defined as the betting or staking of something, with the consciousness of risk or an uncertain event whose result may be determined by chance or accident. Remember in the beginning when I said FMEA could help you predict the future? Well, Monte Carlo simulation helps you with those odds. A Monte Carlo simulation is a model used to predict the probability of different outcomes when introducing random variables present. Given its name after the Monte Carlo Casino in Monaco only as a code name to hide its secrecy as it was initially developed for statistically sampling for nuclear weapons testing. It is a helpful tool in verifying analysis, gaining information about process sequences and expected values, determining the critical components in complex systems, studying the effects of change without risk, and cost versus running experiments in real systems. Today Monte Carlo simulation can be run with advanced analytics techniques in Microsoft Excel. With no need for basic visual application (VBA), no macros, straight-up cell formulas, and data tables.

If you want to learn more, please check out some useful links to build your Monte Carlo Simulation that you can try.

https://support.microsoft.com/en-us/office/introduction-to-monte-carlo-simulation-in-excel-64c0ba99-752a-4fa8-bbd3-4450d8db16f1

https://www.linkedin.com/pulse/monte-carlo-simulation-excel-vba-cihan-barut/

https://theexcelninja.wordpress.com/2012/10/14/excel-monte-carlo-simulation/

The Design of an Experiment is a tool for understanding and reducing variation in any process. A Design of Experiment (DOE or DOX) takes an idea, hypothesis, or assumption and works to produce a conclusion by creating experiments to solidify or debunk a theory. It is excellent to help determine process settings that make the best product. It can also help identify factors that have the most significant impact on the output. It can be used to quickly sample many factors to determine the most critical aspects. Reducing the time and number of experiments needed to test multiple factors is good. The experiment design is related to a SIPOC we reviewed in the structure and system analysis. For a Design of an Experiment, you have Inputs, Processes, and Outputs; in a mathematical term, we would say Y=f(x). The experimental methods of a DOE or DOX have a structured approach that can be defined in 8 steps.

1. Defining the problem to be addressed – (This is based on your RPN)

2. Determine objectives – (In the case of the FMEA project, it could be to reduce the risk to the RPN)

3. Selection of response variable and factors (Are the characteristics of data Continuous or Discrete, meaning are we measuring a range or is it Pass or Fail)

4. Choice of experimental design (This could involve some creativity, and good to involve those stakeholders responsible for this quality)

5. Conduct the experiment and collect data (The experiment varies in time or unit, but try to make it large enough to see trends)

6. Statistical or graphical analysis of the data

7. Interpret results

8. Determine the optimal level of each element.

To apply a DOE, let us look at our Pepperoni Pizza Factory, for example. If we were looking at reducing the waste of cheese used for each pizza, we might look at each step as follows.

1. We would take a high RPN which might increase ingredient yield.

2. Next, select the variable and factor, which would be to reduce the loss of cheese that misses getting on the pizza.

3. Following select response variables and factors. How much cheese are we losing per day? In our case, in the Pepperoni Pizza Factory, we are looking at the cheese application process. For a DOE, we want to narrow the inputs of the experiment so we can see changes. However, before we do our DOE, we might need to know.

1. 1. Amount of cheese added. Is it consistent? Is there a difference, and if so, how much? Knowing this may push the DOW objectives and scope of the DOE.

   2. Understand if there are different types of cheese?

   3. How fast is the conveyor moving compared to the cheese dispenser?

   4. How far is the cheese dropping? Could the distance be dropping too high from the crust?

   5. Is there any vibration; is the pizza traveling smooth?

In this case, it would be a continuous sample size.

1. In choosing a design, look at these different factors and determine which aspect you want to change? Look at either the logistical factor to change or, if not sure, decide which one would be the fastest, easiest, or least cost to perform. For our Pepperoni Pizza Factory, we might start by changing the distance the cheese drops.

2. We could run a sample for the day or hour and statistically see a difference in loss based on historical data. We will collect and weigh all the cheese we dropped for our Pepperoni Pizza factory.

3. Inspect the results and see if there is a difference.

4. Then, determine a new standard.

5. Implement new standards. This could be done through Poke-Yoke, visualization, or training.

The DOE or OFAT, one factor, can be done similarly. When doing these experiments, you must include stakeholders in the process. They often have valuable insight into why past practices often lead to factors in the experiments and also help put sustainable controls into place.

When was the last time you felt you had all of the answers? My answer is never. Project direction can change fast. Rules about how we use technology are continually emerging. How do we keep up? How do we learn which decisions are good and bad without leaving a trail of destruction behind us? The answer might be something you learned in grade school. Scientific thinking. Scientific thinking is the deliberate practice of comparing what we expect will happen and learning from the differences between the two. The four-step improvement PDCA can help you stay on the right path when meeting a big goal. Edward Demings first developed this four-step process to create the Plan, Do, Check, Act, or use it as Plan, Do, Study, Adjust. Whatever we call it, it is about taking complex and making it simple to follow. The PDCA can be traced back to the Tokyo Institute of Technology in 1959. To understand how it works, we must understand each step. So let's take a closer look. We are starting with the PLAN. This is to know where you eventually want to end up. What does success look like in the end? Step 2 is DO. This is analyzing the data and going out to get facts. Moving to step 3 is CHECK. Is the problem fixed? And finally, the last step is ACT.

How can the solution be standardized and reapplied? When Demings developed this process, he wanted components of knowledge. He wanted data of experience in which the process of knowing. Then to have a prediction in terms of data that they would expect to get if they performed experiments. This would lead to a firmer belief in the prediction based on the original data or evidence. Since knowledge begins with the original data and ends in new data, these future data constitute the operationally verifiable meaning of the original data. Did you catch all that? Let's see if we can piece this together a little differently. This theory is often applied in building quality controls in manufacturing as specifications, production, and judgment of quality.

Let us dive deeper into the idea of experimentation in four steps. Good experiments have limited changes so that you know precisely what causes the outcome of the investigation. So, to begin, choose one small important step that you want to take, the PLAN. Then, it would be best if you had a clear hypothesis about what will happen when you take that step, the Do. It would help if you also were explicit about how you'll measure the results. What metric will you use to gather data to tell you if your hypothesis was correct or not? At this point, it's a good idea to go through a coaching cycle to make sure the experiment is sound, or as we call it, the CHECK. Let's see it in action. Going through the coaching PDCA questions helps ensure that you thought through the experiment and will be able to learn from it. When it's time, compare the actual results to your expected results and capture what you learned.

Did you get to your target condition? If not, take what you've learned, design the next experiment, and keep up the cycle until you get there. Once you've successfully reached the target condition, you repeat the four-step improvement PDCA all over again. Revalidate your goal, grasp your new current state, establish a new target condition, and begin to experiment your way there. Repeat this until you've reached your end goal. This PDCA doesn't necessarily feel natural at first, but with deliberate practice and persistence, teams learn how to craft low-risk experiments and, most importantly, how to learn from them. When there is confidence in the ability to learn, organizations are much more likely to distribute decision-making authority throughout the ranks, allowing the organization to move exponentially faster.

Teachers teach, bakers bake, and project managers WELL; they communicate. An FMEA Project manager will spend most of their time communicating for a good reason. A successful FMEA project depends on good communication; when there are problems, they are almost always blamed on lousy communication. An FMEA Project can move quickly after the Risk Priority Number is determined, and many different groups will clamor for that information. It can get easy to get overwhelmed by all the emails and voicemails. When you think about communication, it is an exchange of information, intended or involuntary. The conversation can be in the form of ideas, instructions, or emotions. This exchange can use a variety of mechanisms such as written or verbal, formal or informal, gestures, media, or the choice of words.

Communication is about how your sponsors, supporters, and stakeholders get their information; having well-written documents will make them more likely to be read and understood.

We will look at what communication is about both as a receiver and informer. We will also look at how to avoid common communication gaps.

So, let us start talking about project communication.

Communication can have different dimensions. It can be.

• Internal — Communications is internal if the focus is on the stakeholders within the project and the organization.

• External — Communications is said to be exterior as the focus is on stakeholders such as customers, vendors, other projects, other organizations, the government, the public, or environmental advocates.

• Formal communication uses reports, formal meetings (both regular and ad hoc), meeting agendas and minutes, stakeholder briefings, and presentations.

• Informal — Informal communication represents general communication using emails, social media, websites, and informal ad hoc discussions.

Think of communication also as a hierarchical focus. When discussing communication, hierarchical priority refers to the position of the stakeholder or group concerning the FMEA project team. This positioning affects the format and content of the message in several ways. It would help if you thought about the direction of your communication. The guide can go into several different manners.

• Upward — Communication to senior management stakeholders tends to be more formal and structured.

• Downward — Downward communication represents communication directed to the team and other resources contributing to the project.

• Horizontal — Horizontal communication refers to communication done with peers of the project manager or team.

• Official — Official communication typically uses a formal structure exemplified by annual reports or reports to regulators or other government bodies.

• Unofficial — Unofficial communication is focused on establishing and maintaining the profile and recognition of the project and building strong relationships between the project team and its stakeholders using flexible and often informal means.

• Written and oral — The words and voice inflections we use (verbal) and body language and actions (non-verbal) represent our oral communication. Written communication is defined by anything written on paper or with social media, websites, media releases, or other print means.

As an FMEA Project manager, you are a leader, and as a leader, you need to listen intently. Project managers receive many types of communications. Written and verbal communication needs to be "listened to" intently; one definition of listening is to "hear with thoughtful attention." Anything that is done intently is done with strained or eager attention. Thus, the project manager needs to focus on communication, being careful not to be distracted.

Think Clearly. Ready. Fire. Aim. Have you ever been guilty of this process? Results-oriented people often begin to formulate and even express their opinions or solve perceived problems before they have thought about the information they have just received. Some of us even start our responses before the message is completely transmitted. When we do so, we jump the gun—we fire—and severely hamper our ability to manage communications.

When you receive verbal communication, wait until the person is finished before you begin. Don't interrupt except to gain clarification, then ask the person to continue. Make sure the person knows you are trying to understand, not argue about, what is being communicated. When the person is finished speaking, pause for at least three seconds before you proceed. When you first try this delay, it may seem like an eternity, but it gives you a chance to process the information you have just received.

Discuss Openly. Not every message needs to be discussed. Some messages are clear and concise, and follow-up discussions are not necessary. However, some messages, for various reasons, need follow-up discussions. Discussing openly goes beyond active listening techniques.

Develop Sensitivity. One definition of developing is "to bring into being or make active." In this case, the appropriate definition of sensitive is "to be susceptible to the attitudes, feelings, or circumstances of others."

Respond Quickly to Needs. "Just do it." The first four steps—listen intently, think, discuss openly, and develop sensitivity—are associated with receiving and understanding messages or communications. The last step—responding quickly to needs—involves action. After the message has been received and understood, prompt action is appropriate. Nothing is more frustrating than knowing a message has been communicated, understood, and not acted upon.

Look, performing an FMEA Project is more than data analysis and fixing problems. FMEA Project Managers cannot do this on their own. They need to show the "soft skills" to bring success to the project deliverable, which will help the project succeed.

This has been a look at Project Communication for FMEA Project.

What is a Process, FMEA Control Plan? To complete a project and hand off new processes to owners with maintenance procedures requires delivering on controls that stockholders and project team have agreed on. A new FMEA Project development program consists of setting basic policy and goals. The most difficult question at this stage is how to measure objectives.

The control plan in a Process FMEA differs slightly from a Design FMEA in applied applications. In a Design FMEA, the control often reduces or eliminates failure in a component or function of a device. In the Process, FMEAs uncover the process problems related to manufacturing the product. For example, a component of assembly equipment may misfeed parts, resulting in products not being assembled correctly. Alternatively, in a chemical manufacturing process, temperature and mixing time could be sources of potential failures, resulting in an unusable product. The control plan takes the risks that the team has determined to address, which in the FMEA Project Control Plan would be the inputs , and creating solutions or countermeasures will result in corrections or outputs.

Some of the apparent control is to change out an inefficient part of the process, but that does not address the control plan. The control plan is how we will reduce that risk from ever happening.

Think about this. Have you ever forgotten where you placed your keys? Then when you need them, you are in a rush, and you have to spend the time looking all over your house, bending over backward, trying to find them. Then you finely find them, but now you're going to be late. Is the correct control plan to get another set of keys. Well, that might work for a while, but you're going to end up going down that rabbit hole again. Instead, you might look to improve what you can control where the keys are, like having a key holder at the door that you and everyone else know to put the keys on the key holder when they walk in the door. It is a simple visual that everyone can understand; it is visible and easy to implement. It is also easy to check.

A Process FMEA Control Plan can be very similar. Process improvements are often around developing a new way of working. This could be

• Mistaking proofing

• Having Standard Operating Procedures (SOP)

• Growing or developing Maintenance, Reliability, Operations Plan

• Rolling out TPM (Total Productive Maintenance)

• Visualize or 5s

• Implement new measurement systems

These improvements ask, how can we control these improvements that will reduce risk? Well, this is about having policies for our process. These could include

• Audits (ISO or 5S). Remember, 5S is not about sweeping dirt into a dustpan. It is visually creating standards that everyone agrees to and will abide by. It can be an effective transformation tool, significantly if you are growing a TPM culture.

• Management walkabout or GEMBA walk. This is when leadership walks the factory looking for improvements.

• Start-up checklist

• Automated mistake proofing

If we wanted to cut this PIE of inputs, KPIs, results, and outputs, we could further look at controls that are Fixed and Variable. Fixed might be the speed of a conveyor exiting a press machine, while variable might be the schedule on when that press is running and need to run the conveyor. We might also break these out into internal versus external to the process. The Internal might be the production schedule, while the external could include the weather that could cause storms. Understanding these elements can lead to control plans. For example, if we know something is fixed and internal meaning operations have a lot of control, the control plans could include

• Having start-up check or at some frequency

• Periodic audits

• Preventive maintenance strategy

If the risk is fixed and external controls could include audits or a certification (possible from suppliers or vendors). If we determine, the risk can be variable, and you can build internal control plans around

• Mistake-proof product (Poke yoke)

• Mistake-proof process

• Control Charts

• Sort the outputs

Examples of these are when human error is the identified risk. The last piece of the Control Plans PIE has an external variable. This could include variabilities from the suppliers. Control plans to include

• Supplier Statistical process control

• Receiving inspections

• Supplier sorting

• Mistake-proof product

As the team determines the best manner of building the control plan, remember to include your stakeholders in this process as they are the subject matter experts.

The Control Plan will provide process owners and operators with the means to control a process. It offers a guarantee that you will reduce causes and failures when the plans are followed.

If you work for an organization that takes FMEA seriously, you must share this successful project with leadership. It's not every day you get to show off your capabilities as an FMEA Project Manager. Remember, success is in the eye of the beholder. Even if the project's scope changes several times, your team had a complete turnover; it lasted three months longer than expected, but you met the demands of your stockholders, and your sponsor is pleased you have the project, you have been successful. You need to pat yourself on the back. You don't have to play your perfect game to win the match. Still, communication, adapting, listening to constructive feedback, and showing professionalism demonstrate a high level of positive perception and impress those in the C-suites. Creating reports for the C-suite is no small task. Knowing what to look for and offering the proper context makes all the difference.

Part of the role of an FMEA Project Manager is keeping executives informed to make proper business decisions. Appeasing executives is complicated by the varying needs of the C-suite.

Matching project reporting to these needs is a constant endeavor of the Project Manager: Some executives eschew detailed project information in favor of concise, candid statements; others prefer high-level updates, and some seek face-to-face briefings. Nevertheless, the crux of the issue rests on two key reporting elements: content and presentation.

Reporting the right content is a perpetual battle between high-level information and finer details that help others understand the issue at hand.

Many managers struggle to define what constitutes an intelligent report. Err on the side of gathering too little information, and the team cannot measure the quality of the data.

The most intelligent approach is to try at the beginning of the project for leadership to understand—in detail—the business case and scope. You want to tell a story that is both informative to your audience and value-added to those receiving the report. Here are some ways to think about telling your story in a statement that shows the core components of analytics. This is about dividing out into the following.

The first part of your report should be Descriptive. Show the cause of your FMEA Project. How does it bring value to the business? Be able to answer questions about what has happened in the past. Have your historical data available. Next, you lead into the diagnostics of the project. This walks through some team findings, lessons learned, and best practices. Next, it is time to predict what could happen if this project did not occur. The part can do it in the form of a graph or chart. Use similar information that you used to build this case as a project. Show a visual of what the team did with a couple of high-level examples. The fourth part of your story is your prescription on what more could be done. Remember you have met your scope's objective, so you might be offering more work for yourself or giving suggestions on additional tasks or projects that can be beneficial to the business. If done right, you will have all their attention but be cognitive to dive deeper if needed and be honest if you are not sure. Offer to follow-up or divert questions to a subject matter expert that you should have available.

Getting the right balance between content details and context is something Project Managers must master if they are to remain relevant in the executives' eyes.

Here are some additional tips

· Have a cover page. Show a level of professionalism, and they are quick and easy to make.

· Have a summarization of the core of the FMEA project deliverables. Make it easy for executives to scan the document for relevant information.

· Stick to the facts and avoid emotional language. Like "You MUST change this, or This is the WORST process in the business."

· Find a standard business template. It makes it easier to build the report the leadership like to see standards in their organization. Also, they probably had some input, like to see their stuff being used.

· Try to use block formatting. Make it visual for leaders to scroll through the report.

· Pareto reports are good a telling a story.

If you follow these guidelines, your FMEA Project will be a success that will open future opportunities.

Monitoring and Controlling is the final phase of the FMEA project, but how do you ensure your FMEA Project was successful? Several quality characteristics demonstrate an effective FMEA Project. Conducting a Quantitative Audit gives your reassurance and indicates to your stakeholder and sponsor your capability and thoroughness of your project management skills. The best way to use this audit is to do it as a self-audit on your project. Clean up any loose items, so the FMEA flows well to those reviewing and for ease during monitoring and controlling. Think about a pre-scheduled audit. Ask to have someone experienced with the content and quality of good FMEAs perform the audit from either management or an FMEA subject matter expert perspective.

If you want to learn more about FMEA auditing, check out the book Effective FMEAs by John Wiley & Sons.

Below are FMEA quality problems that can occur if FMEA lacks in quality.

The Quantitative Audit looks for specific process-related issues that underlie deficiencies in achieving the FMEA Project scope, such as lack of training, procedure, facilitation skills, determining standards, the need for resources, or other support. Action items from the FMEA Project should improve the overall FMEA process. Instead, work to maintain steady improvement. Consider these questions for the different phases of your FMEA Project.

1. FMEA Project Initiating and Planning:

a. The FMEA drives product design or process improvements as the primary objective. Look at reviewing the recommended actions and determine whether or not they are design or process improvement.

b. The FMEA addresses all high-risk failure modes with practical and executable action plans. Look at the high severity and high RPN issues to see if they correspond to the recommended actions to reduce risk. Talk with the project team members to ensure they are satisfied and aligned with all high risks. Ask the subject matter experts for one or more of the most critical considerations on the project and then verify that these concerns address the action priority of the FMEA Project.

c. The right people, adequately trained in the procedure, participate on the FMEA team throughout the analysis, execution, and control. This can be done by looking at the FMEA Project team membership roster and stakeholders. FMEA Project needs adequate representation or subject matter experts. Understanding who they are initially and who attended the project meeting shows confidence in the project deliverable. Ask to see the attendance log or invite notification and acceptance.

d. The project team needs to consider warranty and campaigns in the lessons learned. This helps determine the cost of quality for the FMEA project. Review the team's failure modes and causes to ensure that they contain failure data. Look for a visual way to see which failure methods.

2. The FMEA Project Structure and System Analysis: The Project team should be able to show process flows in tools such as block diagrams, design trees, Voice of the Customers, Process mapping, and SIPOC for analysis. Look at determining that the use of these tools' flows into function, failure, and risk. Review with the team and have them walk through the determination process. It's essential to show if process steps were and are not developed before solutions are created. This could indicate the action items' pre-dated inputs and those that offer a partial solution and should immediately be reevaluated.

3. FMEA Project Optimization and Execution: The FMEA adequate detail is understood to get root causes and corrective actions. Review the different columns of the FMEA to see if the overall level of detail is easily understandable. Determine if there is too much non-value information on FMEA material; there should be a match between the root cause and function point. Having too little detail shows up as under-defined functions, system to failure modes, causes or controls, or areas of unaddressed concern from one or more FMEA team members.

4. FMEA Project Monitoring and Controlling:

a. Ensure the Report or Control Plan addresses the FMEA Project's failure modes. Review the recommended actions to see improvements to the Design Verification Plans or the Process Control Plans based on the risk associated with detection conditions.

b. The FMEA is completed during the project window. Review the timing of the FMEA project phases. Having the FMEA Project started and ended with a designed window is another sign of project success and ensures it is done in a suitable timeframe for maximum value to the business.

c. FMEA Project followed the process. They are meeting the scope and deliverables of each phase. Can the Project Team show documents from each phase that flows into the next?

d. Did the FMEA Project team effectively and efficiently use time with a value-added result? Talk to the project sponsor if they feel that result meets the project's final scope.

A Quantitative Audit for FMEA will help ensure that FMEAs effectively achieve quality and reliability objectives for the business. The audit will analyze the actuals in the FMEA to understand the characteristics of a good FMEA.

Nominal Group Technique

The nominal group technique (NGT) is a highly versatile technique used in several analysis steps. NGT can be used in the problem formulation and needs assessment phase to discover and refine the problem statement and determine its causes and consequences. It helps to obtain and refine the problem statement and its major causes and effects.

NGT has six steps that are followed:

1. Determine the questions to be asked of the participants.

2. Select the participants.

3. List ideas in silence.

4. Have each participant read aloud their ideas one at a time.

5. Discuss the ideas.

6. Vote on the priority of ideas.

NGT has several attributes that distinguish it from other methods for generating ideas and achieving group consensus. Those attributes include the following:

NGT maximizes the creativity of the participants.

NGT allows for group members' balanced participation and minimizes the chances that a select few will dominate the group.

NGT has been demonstrated to be a valid method for determining group consensus in a reasonable period.

Consensus Seeking

Consensus is a creative decision-making process in which everyone involved makes a decision. Because all members agree to the final decision, a consensus is the most powerful of all decision-making processes. Because all participants have direct vote and veto power, this is genuinely radical democracy.

Consensus can work with groups as small as five and as large as 300, or even with over 500,000 people. Within a small group, consensus tends to be simpler if all the group participants are kept abreast of each other's activities and all the decision factors. Within groups of 300 or more, consensus takes a different shape. For instance, the small group may have a single facilitator. In contrast, the 300-person group may be arranged into mini-groups of five using consensus with one spokesperson who speaks in the larger group setting. In short, the agreement considers and validates each participant. Everyone gets the opportunity to voice her opinion or block a proposal if she feels strongly enough about a decision.

Consensus usually takes longer than voting. However, since all parties participate and either accept or agree, the chance of buy-in is greater, and decisions will tend to be stronger and last longer.

Build Facilitation Behaviors

The following is a list of behaviors and learned skills that will help you successfully facilitate. To increase your effectiveness as a facilitator, you should practice these behaviors and develop these skills.

Compassion—Try to see things from another person's perspective (e.g., having empathy and looking at situations from another's point of view)

Tolerance—Allow others to be different (e.g., understanding individual differences and appreciating them)

Congruence—Have an awareness of yourself and your feelings and an ability to communicate straightforwardly (e.g., walking the talk and making sure your actions are aligned with your thoughts)

Giving—Being able to go with the flow (e.g., not stubbornly refusing to go with the group; this does not mean taking the lead always, it means having a proper amount of flexibility)

Self-expression—Communicating both verbally and non-verbally (e.g., being honest and direct, not an open book but open)

Involvement—Becoming involved, when necessary, and objective, leaving personal aspects out (e.g., not forcing the group to go with your way of thinking)

Assisting—Preparing participants to contribute (e.g., giving everyone a chance to contribute and managing the meeting so all can and want to participate)

Keeping everyone safe—Establish an environment where everyone feels comfortable contributing ideas

Allowing the thought process—Allowing individuals to think through their responses; some members will need more time to consider issues and will be quieter when they do so

Paraphrasing—Repeating members' contributions in your own words to make sure they are understood and to show that you are engaged in the group work

Pushing—Not accepting a wrong answer or point and not allowing the group to settle for the first thing they can agree on; groups may want to determine to save time or because they do not want to deal with an issue, especially an important one.

Learn Facilitation Skills

A good facilitator is developed by practicing and improving some different facilitation skills. These skills include:

Responding—Responding in appropriate ways and at the correct times (e.g., knowing when to intervene and how). Responding is both a learned skill and dynamic behavior.

Stimulating—Asking primarily open-ended questions that encourage thinking and discussion

Summarizing—Giving a shortened version of what was said and checking for understanding

Dealing with conflict—Knowing and applying appropriate resolution techniques, including avoidance, pushing, accommodating, withdrawing, and confronting.

Keeping your opinion to yourself—Not backing up any one person or offering your idea (you are the facilitator, not a group member)

Modeling—Demonstrating ways of behaving in the group

Listening—Being fully engaged in listening actively for facts, emotions, and intentions, using all senses (not just hearing)

Observing—Being objective and seeing from many different viewpoints; watching the group to diagnose the group's current level of performance and where it needs to go

Solve the Disputes

Dealing with difficult or dominant people is the job of the facilitator. Dealing with any heated conflict is best done after the meeting, whether that conflict was caused by a heated discussion or stemmed from a difficult team member.

The Reverse FMEA can occur as soon as the final Process is operational.

The Reverse FMEA’s team selects the production line where the Reverse FMEA will take place, preparing the necessary inputs (Documentation, Flowchart, current PFMEA, Control Plan, Work Instructions, Drawings, etc.). Regarding the “how-to,” there is no specific way to do it. Some customers request particular procedures, but most organizations define their methodology in their FMEA standards. Companies like General Motors, Ford, and Continental require their suppliers to perform Reverse FMEA. As a result, many organizations started including it in their standards to satisfy customers because this method has proven effective. It is recommended that users follow a Reverse FMEA checklist, and to verify the included points, here are some examples:

• Verify the coherence between documentation (Flowchart, FMEA, Control Plan) and the existing production line

• Verify the existence/ maintenance of PFM

• EA measures (preventive actions, detection actions) for identified failures. Identify new risks by creating failure modes at workstations and testing the effectiveness of detection methods.

• Re-rate occurrence / Detection according to the production Data and the team’s observation

The team’s observation and the new risks identified will be documented and used as inputs for Process FMEA reviews. The project team must add all unknown risks or measures to the FMEA and the new ratings to guarantee that your FMEAs are up to date and reflect the reality of field operations.

Reverse FMEA Benefits

The systematic application of the Reverse FMEA tool brings many benefits to the company, such as:

• Gain experience and knowledge of the production teams

• Maintain, review and systematically improve the FMEAs

• Reduce risks and costs of non-quality

• Build a structured knowledge base

• Improve production processes.

Please review the packet included for the checklist and templates on Reverse FMEA.