PM Articles > PM Perspectives > Holistic Methodologies: Odd bed partners (Six Sigma and PMLC/SDLC), but Harmonious Relatives

Holistic Methodologies: Odd bed partners (Six Sigma and PMLC/SDLC), but Harmonious Relatives

Poka-Yoke without Getting Egg on Your Face

Why are wall power outlet receptacles in the wall carrying dangerous voltages recessed versus protruding? Why are guards put in front of moving parts on a machine? What may seem like an obvious question may not have been so obvious before some accident happened to drive a specific design change.

Poka-yoke is at the heart of prevention or mistake-proofing in product manufacturing. It plays heavily into industrial design and as we will see has a strong analog in the development of technology solutions for the customers. This article will focus on Poka-yoke in software design and delivery. The consequences of omission in a technology solution may not result in death or bodily injury in most cases. But a poorly designed software product which does not protect the user from making mistakes can still have serious consequences, including rework, business process impedance, distrust of the product, or creation of latent errors that are yet to be discovered. In broad terms, Poka-yoke is fool-proofing or idiot-proofing your product.

"Houston we have a problem"

One famous example of product design failure was tragically illustrated in Apollo 1, when 3 astronauts lost their lives on the launch pad because of a wiring fault that created a spark in a pure oxygen environment. Before that accident, no one stopped to question if a pure oxygen environment was even required in a space craft. It was just assumed. The design of the main hatch prevented it from being opened in an emergency, so the astronauts were unable to escape. The wiring design and quality that caused the spark to begin with were also contributing factors. Hundreds of design changes were implemented as a result of that disaster.

I have heard it said that most mistakes in design happen in requirements gathering. Usually, that involves taking what the customer is asking for and turning request into a design that can be built or purchased. Those requirements may not take into consideration what can go wrong if you give the customer just what they asked for instead of what they really need. The key concept we will explore in this article is reducing defect opportunities for the customer. First, let's discuss what a defect opportunity is, as it ties directly into what Six Sigma is all about.

Defect opportunities and Six Sigma

In simple terms, defect opportunities are error points that are built into a process due to poor design, poor user training, or lack of knowledge. Each defect opportunity is any possible error that can occur executing that process step. For example, the display length of a field on a screen truncates what can be typed into it, preventing the user from seeing all the characters in the field without scrolling through it. This can be seen when a very long URL address is too long for the field. Another example can be during data entry of a field; if focus does not fall on the first logical field within the screen, when the user starts typing the data may go into the wrong field or be lost completely. Sometimes defect opportunities can be caused by a sloppy user interface design or a lack of understanding of the way the user interacts with the screen.

So how does this apply to Six Sigma? Without getting into the statistics, the definition of Six Sigma is specifically 3.4 defects per million defect opportunities (DPMO). Therefore it stands to reason that the more defect opportunities that are presented, the greater chance mistakes can occur, which is directly proportional to the complexity and number of steps in the process. (The lower the Sigma rating, the higher the defect rate.)

Applied Problem Solving Methodology (APS)

APS can be broken down into 3 steps:

  1. Identification of the need
  2. Identification of possible mistakes
  3. Management of mistakes before satisfying the need

Typically APS concepts are applied during brainstorming sessions with the customer; however they can be used more holistically throughout the whole product development lifecycle.

Identification of the Need

Consists of defining what is critical to the customer (CTC) and Critical to Quality of the product (CTQ). Both are at the heart of why you are doing the project to begin with. In other words, what are the business needs that are to be solved by the product of the project and what are the quality specifications the product will be delivered within?

Identification of Possible Mistakes

Jidoka is the Japanese art of problem solving by finding problems before they can arise and solving them so they cannot happen again. Jidoka also plays into the Kanban or continuous improvement culture within an organization. It is considered part of the Lean Enterprise Institute Lexicon.

Quality Function Deployment (QFD) and Failure Modes and Effect Analysis (FMEA)

These are topics we discussed in earlier articles. They sit at the heart of analysis, being the primary tools for looking at what can go wrong. Deploying a feature or function in a product along with the design elements is included in several of the rooms within the "House of Quality." Using our data entry example above, what could you add to the design to prevent loss of focus to that first logical field? How can you prevent the user from typing the wrong data or typing in the wrong field? Addressing those examples and other nonfunctional requirements as part of the functional requirements gathering process is critical to the application of Poka-yoke. Poka-yoke is used at the earliest opportunity to eliminate defect opportunities before they have an effect on the delivered product. Requirements gathering does not have to be limited to functional requirements when working with the customer. Business requirements should also include how to make the product foolproof as well as easy to use correctly. Fundamentally, it is just the same as not making the assumption that a pure oxygen environment is needed in a space capsule.

In FMEA this concept can be explored in significant detail while asking the customer simple questions:

  • How will you use this screen?
  • Who should have access to it? (Training and security/segregation of duties)
  • What editing criteria should be used on each of the fields?
  • Does the tab order make sense to prevent data entry errors?
  • Should the cursor advance to the next field when a value has been entered?
  • Should field validation be on the fly or when the data is committed by pressing Enter?
  • How should the user be informed when they have made a potential mistake?
  • What fields should be read only to prevent inadvertent updates?
  • Should the user be prevented from leaving the screen without key data being provided?

All of the above are relatively straightforward questions that may or may not be asked before the engineer builds the screen and delivers it to the customer as a final product or prototype. But team members sometimes say "I am just giving them what they asked for in the business requirements!" rather than truly understanding and questioning how the product will be used and how it can be misused. Understanding usage should be a core tenet of delivering a better product that protects the user from themselves and thereby reduces defect opportunities.

Other Tools and Data Sources

Any or all of these tools can be used to capture measurements and analyze defects throughout the process or product delivery and operational usage:

  • Pareto charts help with visually identifying the biggest issues that can arise from a design flaw
  • IT root cause analysis or Fishbone diagrams can help map out the root causes
  • Post-implementation product defect lists will assist with future enhancements or requirements for the next version.
  • Business process throughput metrics that are baselined prior to the improvement provide a retrospective return on investment, and also confirm that the process's capability is within specification.
  • Business process defect tracking and root cause analysis reports are inputs into design of experiments improvements
  • The 5 Whys are used to ensure that each probable cause is appropriately interrogated. The 5 Whys are typically answered with 3W and 2H: Who, What, When, How and How much.
  • Statistical Process Control monitors the process using Control Charts to eliminate rework and scrap.
  • Charting (Histograms Radar maps and Scatter diagrams) show the modality of the data as well as seeking out common and special cause variations in the data.

Management of Mistakes before Satisfying the Need

You may have heard of the concept that it takes a penny to fix in design, a dollar to fix in the prototype, one hundred dollars to fix it before it leaves the factory. But the reputation cost is immeasurable if the customer finds the defect before you do -- or worse still if you pretend the defect does not exist.

Other Continuous Improvement Methodologies to Consider

Deming Wheel (PDCA or PDSA)

The Deming Wheel is a precursor to Six Sigma -- DMAIC (Define Measure, Analyze, Improve and Control) -- and part of TQM (Total Quality Commitment) process improvement methodology. The Deming Wheel is also used extensively within the ITIL methodology.

  • Plan: Plan ahead for change -- identify the work to be done
  • Do: Execute the plan -- Make the change
  • Check/Study: Check the results
  • Act: Act on any defects that occur and then return to Plan

Eight Disciplines of Problem Solving (8Ds) or Team Oriented Problem Solving (TOPS)

The 8Ds variation on the Deming Wheel was developed by the Ford Motor Company for solving engineering problems that span departments and manufactured components. 8D's purpose is to identify, correct and eliminate reoccurring problems.

  • D0 - Plan: Develop a plan for solving the problem and map out the prerequisites
  • D1 - Use a Team: Create a team of subject matter experts who are authorized to solve the problem
  • D2 - Describe the problem: document the problem in quantifiable terms -- who, what, where, when, why, how, and how many (5W2H)
  • D3 - Develop an Interim Containment Plan: What can be done right now to stop it getting worse until a permanent fix can be found and implemented
  • D4 - Determine, and verify root causes and escape points: Identify all applicable causes for the problem and identify why the problem was not detected earlier (5Whys, and Ishikawa diagrams)
  • D5 - Verify Permanent Corrections (PCs) for the problem: Validate that the chosen resolution will actually fix the problem permanently (Design of Experiment, Pilot or Proof of concept)
  • D6 - Define and implement corrective actions: Implement the corrective action(s)
  • D7 - Prevent reoccurrence: Modify the operational system, practice or process to eliminate the defect opportunity from the environment
  • D8 - Congratulate the team: Recognize the individual and team efforts to fix the problem, typically through a formal recognition at an enterprise level.

There are also relationships between 8D and FMEA that can be explored further:

  • Problem statements deriving from (D2) set the parameters or entry criteria for conducting root cause analysis whereas (D4) brainstorming will set the stage for the FMEA to be created.
  • Data collected from the "team think" during brainstorming (D2-D4) is considered input into the FMEA.
  • The process controls within FMEA tie directly to the analysis within (D5) Verify Permanent Corrections by mapping out the failure modes that can still occur within the corrective action(s) taken.

GE Workout

Workout is a problem solving facilitation methodology from the Jack Welch period during the 1990s. It is a hybrid of the GE CAP model {link to article} discussed in an earlier article. The approach of Workout is to create a safe, blame-free "time-out" for the tactical and strategic actors in the process who will brainstorm the problem and its possible solutions. This safe environment creates a problem-solving dream team characterized by "Boundarylessness" -- able to break through the bureaucracy which exists in any large organization and prevents a holistic solution. Typically workouts take place over several days and require professional facilitation to maintain the focus on the problem solving and keep the politics and turf wars to a minimum.

  • Phase 1 - Design and Preparation
    • The challenge and expected value to be derived
    • Scope statement
    • Leadership and logistics
    • Participant identification and confirmation
    • Decision making panel
    • Stakeholder considerations and perceived risks
  • Phase 2 - Conduct the event
    • Day 1 - Identify Problems and Opportunities
    • Day 2 - Find solutions
    • Day 3 - Decide on recommendations/launch implementation
  • Phase 3 - Implement the decisions - Post implementation, the team will reconvene at 30-, 60- and 90-day intervals to confirm that the corrective action solved the problem. This post implementation timetable also drives delivery of the improvements to prevent teams from dragging the implementation out and creates a sense of urgency.

Summary

Poka-Yoke is more of an approach verses a hard and fast prescribed methodology. It can be a result of careful analysis and relationship building with your customer, truly becoming a student of their business and how they execute their core business processes using the technology your project delivers. Delivery using this mindset will eliminate obvious failure modes. It will also prevent you from getting egg on your face the next time you deliver a solution to your customer that does not work for them, and could have been addressed just by asking simple questions. Done correctly, Poka-yoke will allow you to deliver your solution sunny side up instead of scrambled.

Further Reading



Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

Post a comment




(Not displayed with comment.)









©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.