Identification via Isolation

Recently I had an interesting conversation with a software developer who was particularly frustrated with the people complaining about the end results of her software program.  At a high level, this software process looked something like this:

These complaints were not her big problem. Taking every feedback seriously, she would delve into her code and later identify that the problems were not due to programming errors or “bugs”. Rather, these problems were originating further upstream from the inaccurate data records which were used as an input to her program. So, her main frustrations were:

1. Why do the database people keep providing incorrect data?
2. Why is programming first to be blamed at?

Issue #1 is a classic process issue known as “Garbage In, Garbage Out”.  And #2 is due to general human tendency. Whenever we see an erroneous result, we tend to dig (or even blame) the step which immediately precedes the final result. 

An ideal and easy way to resolve #1 is to establish the service level agreements (SLAs) among the internal supplier & customer. In this case, the programmer is the internal customer of the database analysts (DBA). So, she defined a clear set of requirements/expectations from the data streams which are the inputs to her programming process. And the DBAs were instructed to achieve those expectations before providing their outputs. The DBAs can develop their own internal quality checks to validate the data and provide those results along with the data-stream to the programmer. In manufacturing world, this is similar to suppliers providing completed inspection checklists and test results with their parts shipments to the next customer.

Issue #2 is a bit complex one to deal with. Here, programmer is up against the general human tendency rather than any logical argument. After some thought, she came up with her own solution. She created a controlled sample of the data-sets by validating them herself first. Then, every modified version of her program was first tested by using that “controlled sample” and the results were analyzed. Now if the new, current data-sets (which were also being modified in parallel) do not produce the same results as being produced by the controlled sample, it is easy to conclude that problem lies in the data integration and not system-level programming. This is what I call, “identification by isolation”.

Situations like these keep reminding me of the importance of root-cause analysis in our daily lives. We don’t need a fancy formal training or certificate in order to become an effective problem-solver. In fact, being humans, this skill is hard-wired in our brain. We need to recognize and sharpen it by using common sense and a focus on resolving the issue, and not just whining about it.

Process-Mapping on YouTube

Sometimes, the wealth of real knowledge freely available on WWW just amazes me. It just depends on us, how we choose to spend our time and utilize the power of Web 2.0 in enhancing our knowledge base and honing our skill-set. For instance check this video on "Process-Mapping in Lean Six Sigma". Gone are those days, when companies had to higher highly paid consultants to train their work-force in process improvement tools, when the good quality stuff is available online...free. However, it does a lot of motivation and focus to do such things online. Maybe that's why the classroom training still exists. Anyway, enjoy the video:

Think Process!!! ....But how?

In those rare cases, where an explanation of Process & Process Management (per my previous post) is able to generate the other person's interest, the conversation usually goes this way:

Him: "Interesting! So, you are a process improvement professional."
Me" "Yeah! sounds like fun ..isn't it?"
Him: "Maybe for yourself..... So, tell me one thing.."
Me: "Sure"
Him: "What is your general approach when you are doing problem-solving and/or process-improvement?"
Me: " Well...The mantra of success is always: Think Process!. One has to develop his process-based thinking and the ability to visualize a process, no matter how complicated the problem is."
Him:"Hmmm.....but how do you do that?"
Me: "Well, maybe it just comes naturally...or ...aaaannn...I don't know. Seriously!"

This conversation sent me through the thinking path: How do you develop the process based thinking? And the answer came in the form of a SIPOC, an acronym for Supplier, Inputs, Process, Outputs, and Customers. In Six-Sigma DMAIC roadmap, SIPOC analysis is used the Define phase to map the high-level process and the relationships among suppliers, process, & customer via respective inputs & outputs. A quick search over Google brought this excellent link on SIPOC Analysis and the steps needed to perform one. A typical SIPOC diagram for a project looks like this:

Now coming back to the point, how does SIPOC help to generate process based thinking? Whenever you are trying to understand a problem symptoms, try to identify what is the main process involved here and what are it's inputs and outputs. Next, think about who is supplying the inputs and how can they impact the quality (in either positive or negative way) of the process and it's outputs. Next, identify the outputs and whom and what they impact, i.e. the customers or other processes. Let me give a simple example:

Say, one fine morning, your coffee doesn't taste good, or rather let's say it tastes real bad. Now the Process here is coffee-making. The equipment used is the coffee-maker and the process parameters are temperature, length of time for brewing, etc. The Inputs of the process are coffee beans, and water (and sugar, creamer, etc.). Suppliers are coffee-bean company, & water supply (or bottled water company). Output is off-course the coffee (which is of bad quality) and the Customer is the coffee-drinker (in this case, is yourself).

I agree that this is a very simple example compared to the processes we deal with in a business or organization, but the idea is that one's thought process has to be aligned in a SIPOC way. This will help you a lot in ....guess what...."thinking process".

Surveys & Data-Collection

Conducting surveys is a widely used method of data-collection, especially when one is trying to use the opinion of people regarding a product or service. The biggest advantage of this technique is the direct hold of "Voice of Customer". It also proves to be a useful tool in those situations where the data actually doesn't exist is very difficult to get hold of, like salary surveys, college rankings etc. In such cases, certain organizations conduct a survey of professionals, or colleges to gather the data, analyze it, quantify the results, and make interpretations.

This is where the problem occurs, the interpretation, and not the data. Recently I read the IndustryWeek's 2009 Salary Survey. Conducted and published annually, this survey targets the professionals in the manufacturing industry. This survey is quiet detailed and presents the average salary results by industry, education level, geographic region, race, company-size, and what not. You can see the detailed Charts & Tables here. But writing about this survey is not my point, however the interpretation is.

The summary of the survey, as expected due to the current economic scenario, is:

"As the U.S. economy gets leaner and meaner, IndustryWeek's 2009 Salary Survey reveals that the average salary for manufacturing management has dropped to $95,248."

But what prompted me to think about the survey methodology is this:

'When asked, "How satisfied are you with your current job?" 76% say they are "very satisfied" or "satisfied," which is actually a slight bump up from the 74% response rate in both 2007 and 2008. And when asked about their choice of manufacturing as a career path, 80% say they are "very satisfied" or "satisfied," a slight dip from the 83% in 2008 but slightly better than the 79% in 2007. Clearly, both resiliency and pride are still alive and well in the U.S. manufacturing industry."

Now this is a contradiction, isn't it? How come the people are satisfied even when the salaries are going down, and rather worse, even jobs are going away by thousands? The answer lies in the paragraph immediately following the above, which, in my opinion, is the biggest pitfall of "Survey & Interpretation" technique.

"In this year's survey, nearly 1,700 readers participated in our anonymous survey, ........"

Now guess, who are the regular readers of IndustryWeek??? The professionals in manufacturing world...obviously. So the survey itself is limited to only those who are somehow related to manufacturing profession. no wonder, so many of them are "satisfied" or "very satisfied". Probably the people who are not satisfied have already changed their profession or didn't bother to respond to the survey.

Isn't it similar to Apple sending a survey to all iPhone users asking how much they like their iPhone? Probably the people who don't like it have already switched to some other phone.

Thus, one needs to be extremely careful in selecting the sample from which (s)he wants to draw his survey results. Your objective is to get the best out of this tool and use the results to improve your products or services. And be aware of your sampling constraints while drafting the survey questions.

Cause & Effect Relationship

As a Quality Engineer & Six Sigma Black Belt, I have learned a lot of tools useful in improving processes & problem-solving area. The most important concept with multiple application across different business processes is definitely establishing right "Cause & Effect Relationship" among various events. A good majority of the time, I have seen that people confuse between an event and a process.

Simply stated, an event is a single occurrence whereas a process is collection of such events linked to each other in time and space. In a root-cause analysis or problem-solving investigation, our job is to establish the right cause & effect relationship among various events which ultimately result in a problem, defect, or poor performance. Always remember that a whole process is almost never a cause of any problem. A particular event (or in some cases, a collection of events inside that process) are usually the cause of the problem.

Consider the following example:

A car slipped on a patch of ice while taking a turn. The driver lost control and the car hit a tree. Thankfully no-one was hurt in the accident.

The effect is very clear here, i.e. the accident. But what was the cause? Is it driver losing control, speed of the car, or patch of ice? The patch of ice resulted in the slipping of car. Where did the patch of ice come from? A nearby broken water resulted in the water leakage. How did ice formed? Sub-zero temperatures in the wee hours of morning resulted in the transformation of ice to water.

This is where the real investigation comes in. You need to focus on the details, collect data, and establish C&E relationship among the events resulting in the problem or failure.

Tools for C&E:
The best tool to master this concept is Apollo RCA. Check this link for details on their books & training material.

Another tool, I have found to be of great use for this purpose is Inter-Relationship Diagram. though it looks a bit complex, but is actually very easy to perform with a team of people.

Hope this post was helpful to you.

Root Cause Analysis

Often, outside my work, I come across people who are curious about problem-solving and root-cause analysis (RCA). Most of the time I have observed that they do have a basic idea about RCA, but do not know exactly how to do it. As a Quality Engineer in my previous role, I have conducted RCAs and trained people on the various tools for this purpose. These days a lot of material is available on internet with very good step-by-step process on using the Quality tools like 8D, Fishbone, Affinity Diagram etc. But before starting such investigation or quality improvement initiative, it is imperative for one to thoroughly undertsand a few things. From my experience, I would summarize following:

1. Do not focus your on the problem or issue as visible to you. No matter whether you are fixing a manufacturing or transactional process, often the problem as seen or observed is a mere symptom of a bigger problem hidden underneath. For example, a fever is a measurable symptom of a disease. The disease can be a simple flu, a stomach infection or something else. Combination of such symptoms help a doctor to identify the root-cause, i.e. the disease itself.

2. Avoid the human tendency to run to fix the most easily identifiable causes while failing to see their impacts on other processes. Such a behavior can result in creating other problems in future. Essentially, get rid of "fix it" or "putting a band-aid" or "jumping to solutions" mentality. Rather, try to develop investigative mind-set.

3. Avoid to rush to do what you yourself really like to do. This is the most common pitfall. Depending on our own area of expertise and sometimes our passion, we try to find root-cause(s) in areas/processes we like ourselves.

4. Make sure to dig deeper into a problem to identify the root-cause or causes. Root cause is most fundamental underlying cause of a problem. Use tools like 5-Why, and Process-maps for this purpose. Be prepared to dig a few levels to find it. See the figure above. I took this screen-shot from a slide I prepared to conduct RCA training for other employees.

In continuation to this post, I will write about Cause & Effect relationships in problem-solving.

TRIZ - Theory of Inventive Problem Solving

Recently, I came across an interesting problem-solving methodology called TRIZ or Theory of Inventive Problem Solving. TRIZ is originally a Russian term and was developed by a Soviet engineer and researcher Genrich Altshuller. This theory uses the structure of the problem itself to find its solution.

TRIZ states that:

• Technical systems evolve towards the increase of ideality by OVERCOMING CONTRADICTIONS, mostly with minimal introduction of resources.
• Most of the innovations are transpositions of known solutions in other fields

It can be stated as:

Somebody someplace has already solved this problem(or one very similar to it.)
Creativity is now finding that solution and adapting it to this particular problem.

For more information on this technique, please refer to The TRIZ Journal. I have read about it online, but not seen any application or real-world example yet. however, from what I have read, this appears to be a relatively new technique and is making its way into the problem-solving arena. Please let me know, in case you find a good real world example which can aid in understanding TRIZ.