Advertisement
Articles
Advertisement

A Tour Of Methods

Thu, 12/06/2012 - 1:09pm
Alan Nicol, Executive Member, AlanNicolSolutions

Establish a culture of continuous improvement around a central, common method for solving problems. Adopt one of the common or popular ones, or use them as inspiration for your own.

Each organization has its own culture. It is a natural phenomenon of any group of social creatures. We can either let our culture form around us as it may, or we can deliberately cultivate it to be what we desire. Because culture is an outcome of common beliefs and behaviors, we can influence our own organizational culture with common systems and practices.

Almost every improvement program or methodology has an easily communicated and followed approach to solving problems. In cultivating our own cultures of improvement, we can pick one of the many methods already in common practice. However, in examining the many methods available we see some common threads. We can use those observations to intelligently construct our own to meet the needs of our own organization and the culture we already have or the culture we want to produce.

Here are some brief descriptions of the various systems that I have encountered and used. They come from a number of different environments.

The famous Six Sigma roadmap uses the acronym, D.M.A.I.C., which represents the following steps to problem solving:

  • Define.
  • Measure.
  • Analyze.
  • Improve.
  • Control.

The Six Sigma method is an excellent one for us to explore, because it has all of the same elements as the other methods to examine, as well as some custom elements included for very specific methodological and cultural reasons.

The first and most important step is to define the problem. A clear and concise problem statement lends focus for a team or process group to quickly and effectively communicate the same idea so that they are all trying to solve the same issue. Six Sigma produces a culture of proving improvement and assessing the value of improvements, so it is critical to measure the current performance before making changes.

The analyze step is all about determining the root cause of the issue so that the cause can be addressed and the improvement will be genuine and sustainable. Once the root cause is understood, we can Improve upon the process. I believe that the word “improve” was selected for a very deliberate reason. It implies that perfection is not necessary to execute an improvement. Any significant improvement, even if incremental, is worthwhile. Also, it implies that no process is ever done being improved.

Finally, the method demands a control step. It recognizes that improvements will often revert to old ways if they are not decisively and deliberately maintained. It is a very insightful part of the methodology.

Many people perceive that executing these steps takes too long. It doesn’t have to be that way. Long execution is more a matter of proficiency and execution than the approach. The 5-step roadmap can be executed in five minutes for many simple problems. Likewise, we don’t need to be doing complex statistical analyses in order to warrant the approach. It can be used for any problem; for example, packing for your next trip to visit family.

Define the problem as packing the family for a stay with relatives. Last year it took six hours to pack everyone, several family members still weren’t finished when it was time to leave, and two people didn’t remember everything they needed when we got there. That’s enough of a measure for this exercise. This year we want different performance and results.

We analyze the root cause and determine that we didn’t do a good job of telling everyone what they needed to pack, especially the kids who have less travel experience than Mom and Dad. Our improve step for this year is to sit down with each family member and generate a list of things to pack. The list will be based on the activities that are expected or planned. Then each member will pack the items on their list.

We control the packing process with the lists. We will also endeavor to keep the kids (and parents) focused on packing and not playing. By declaring it to be packing hour and setting everyone to task at the same time, we get a little better focus. Every time we observe someone who does not appear to be packing, we ask if they have packed everything on their list. If they say “yes” we run through the list and check it off. If we find errors we send them back to finish the job.

We might not get completely done in an hour, but we are done in less than two, well ahead of when it is time to leave; and as long as our lists were well thought out, we don’t have any forgotten items this time. See? It’s simple to execute the process and no fancy statistics are required.

I offer the example as representative of any of the methods we will examine here. They are all simple and versatile that they can be applied to virtually any problem.

Let’s look at the popular Kaizen approach, which would be the best example of a method commonly applied to the Lean methodology. It lists out as follows:

  • Plan.
  • Do.
  • Check.
  • Act.

First, we plan our change or improvement. The plan step can be simple or complex as needed. It implies some analysis of the problem and some risk assessment and mitigation, as well as making arrangements for proper materials and supplies, again as necessary or appropriate. Plan is a little word that can mean a great deal.

Do means that we construct or enable the improvement or change we have planned, and then we check to make sure that it does what we intended. Only once we are sure that we like the change, do we act to execute the change and make it the official way forward henceforth.

It’s both simple and versatile, with deliberate measures to reasonably manage risk and make sure that changes are not “willy-nilly” but are carefully planned and verified before final execution. It implies a certain level of experimentation and testing, which demonstrates its birthplace on the production floor where it is often more productive to try and see than to analyze things to death.

We could just as easily see how the Plan-Do-Check-Act method could work for our packing the family for a trip problem. It is important to observe that there is no, one right method. The key is to find or design a method that inspires the behaviors that your organization most needs.

The Design for Six Sigma approach is less consistent than others. Several roadmaps or step-processes have been incorporated throughout its evolution and expansion. Perhaps the D.M.A.D.V. method is most common because it is so analogous to the D.M.A.I.C. method that already prevails in many Six Sigma cultures. It breaks down as follows:

  • Define.
  • Measure.
  • Analyze.
  • Design.
  • Verify.

Sometimes a “Control” step is added to the end of the approach. You see that, to accommodate a function, especially product development, where we are making new things instead of improving existing things, we change the language from improve and control to design and verify. There is an important observation to make here. The language of the method should be chosen or adjusted to meet the needs of the culture for which it is employed.

An earlier, and still popular method for Design for Six Sigma is I.D.O.V. or P.I.D.O.V. It has some significant implications of problem-solving process that warrant a brief review. The acronym means the following:

  • Plan.
  • Identify.
  • Design.
  • Optimize.
  • Verify or Validate.

It is a method born out of product development functions and represents a typical approach to product development. First we plan a product development effort, including assigning resources and funding and setting a deadline. We Identify the requirements and needs of the solution, and then proceed to design a solution.

Because design for Six Sigma centers on a philosophy of developing products that minimize variation and make the best use of existing processes or, adjusting processes to ensure consistent error-free production, it is important to experiment and adjust the design and accompanying processes for optimal performance. Hence, we deliberately communicate the need to optimize the design. Finally, we Verify that it performs to expectations before we launch it.

Notice that the two Design for Six Sigma models described are very similar in how they drive solutions, though the acronyms are very different. Likewise, they are similar to the Six Sigma and Kaizen methods in terms of approach, though the language is different. The language is adjusted to fit an environment of making new instead of fixing old.

I’ll include some comments concerning Dr. Robert Cooper’s famous Stage Gate process[1] for product development. It is rather self-explanatory and reads as follows:

  • Discovery (Idea Screening).
  • Scoping.
  • Business Case.
  • Development.
  • Testing and Validation.
  • LaunchPost-launch Review.

I include it only to make the point that the Design for Six Sigma methods, in particular, match up very nicely with the Stage Gate process. Discovery and scoping match up neatly with define or plan and identify. The rest of the correlation is easy to see. My point is that our human thought process for solving problems is basically the same, regardless of language or context.

Let me share one more engineering example, because I think it makes a great reference point either for selecting a method or developing our own. Then I’ll test my assertion that in different contexts the approach is still similar by describing some methods that are not engineering or product industry related.

The Value Methodology Job Plan[2] used within the context of the discipline of Value Engineering reads as follows:

  • Information Phase.
  • Function Analysis Phase.
  • Creative Phase.
  • Evaluation Phase.
  • Development PhasePresentation Phase.

To be more concise, I left the Pre-study and Post-study elements off of the job plan. I like to include this example because it describes the very important element of problem solving: creativity. This method emphasizes the discipline of breaking down a problem into functions and then exercising creativity to develop multiple solutions, which are then evaluated for either further improvement or selection for final development.

The Value Methodology also emphasizes two important decision points. The first is deciding what solution to use, and the second is deciding to finalize the execution and make the solution permanent in the presentation phase. For those of us desiring to inspire more creativity or innovation and better decision-making, this model is worthy of our examination.

Now, for something completely different, let’s look at a tactical process used by military and law enforcement units. Referred to as the “OODA Loop,” it addresses problems in the following way:

  • Observe.
  • Orient.
  • Decide.
  • Act.

It’s extremely simple since we are meant to use it as a decision process under condition of extreme urgency and stress. We are directed to observe the situation, including assessing risks and taking note of available resources. Next we orient ourselves to our surroundings, including re-evaluating our mission criteria. We decide, based on what we observe and what we know to be the mission priorities, what is best to do under the circumstances, and then we do it; we act.

This one is nice in the sense that it forces one to recognize that he or she is empowered to make a decision, is indeed expected to do so, is given a simple guide to first assess the situation, and then to follow through. I have worked in some corporate environments where a method such as this would have been very impactful. Those environments needed an infusion of responsibility and decision-making initiative.

Finally I’ll share one that is even simpler and implies a very different cultural attitude, though it still models a standard human problem-solving approach. I can’t verify an original source, but I was given it from a martial art instructor. It very well may be his own creation. It reads as follows:

  • Accept.
  • Adapt.
  • Act.

You will note its similarity to the OODA Loop in terms of its simplicity and utility in emergencies. I say that this one is different culturally, because the first word and action is to accept the situation. In western culture in particular, we tend to reject the status quo, which instigates our actions to change it.

Arguing over the truth or implications of the situation, or simply denying that things could be such a way generates a great deal of stress and wastes energy. If we need to develop an environment or culture that deals with situations calmly and with concerted focus, this method can be very influential.

By accepting that things are the way they are, we are instantly ready to deal with them. We adapt to the current situation. This might mean that we make changes or adjustments, or it might mean that we adjust our expectations to accommodate a new reality. It should not be taken to mean that we consign ourselves to a fate beyond our control without putting up a fight (remember that this comes from a martial art).

Finally, after we have adjusted to the new circumstance, we act accordingly with a mindset for victory or success. Put this one in the context of a production process that now needs to produce 30 percent more than it currently can, or adapting to a slow economy or a sudden increase in taxes. In any of these cases, there is a problem to address. Worrying about it isn’t going to change it, so simply proceed to adapting to the situation and moving forward.

The above examination reviews several and diverse problem-solving approaches. As I said, they are all valid and they are all versatile. We can adopt any one of them, or we can create our own.

If adapting one is more of your mode of action or thought, consider mixing and matching elements of one or more, or adjusting the language to meet your specific needs. For example, consider a rapid-response custom-machined-component business.

Quick problem solving is important, but if it doesn’t meet a customer’s expectations, it won’t matter. Perhaps a blend of the existing models with some characteristic language will make a good approach for this hypothetical organization:

  • Information.
  • Understand.
  • Design.
  • Verify.
  • Build.

Imagine that the process manifests with the business folks first gathering information about the contract and the needs from a customer. Then they consult with the customer to understand the needs and expectations of the parts to be machined. The business designs tooling, fixtures, and processes to create the machined parts and verifies a prototype with the customer before fulfilling the order. It’s simple and well adapted to that particular organization’s needs.

We can, of course, develop our own method model from scratch. To do that, take a quick look at what all of the above methods have in common. It gives us insight into the natural human way of addressing problems successfully.

In different terms or words, every model above begins with gathering information. We cannot successfully address a problem if we don’t know what the problem is, or what resources we have at our disposal to use. Some models describe several activities to encompass gathering information (Define-Measure-Analyze… ) while others use only one word with all-encompassing meaning (Plan).

Each of the models includes at least one step to describe applying our creative minds to arriving at one or more possible solutions. Some emphasize the creativity and selection process, while others emphasize acting quickly with a solution of some kind. The differences are the result of diverse cultural needs.

In each case, there is a decision to be made. In some cases the decision is explicitly called out while in others it is implied in the language of “Verify” or “Evaluate.” Again, the different emphases result from cultural values or needs, but the fact that a decision is made persists. We decide that we have a solution we can use, or we go back to the solving step.

Finally, we follow through with our decision. Where metrics are a large cultural element, we find language such as “Control.” Where urgency is vital, we see words as direct as “Act.”

So, if we are going to draft our own way of doing things, from scratch, to meet our specific cultural desires, we should at least expect to address four steps, somehow:

  1. Information.
  2. Solving.
  3. Decision.
  4. Execution.

To devise our own method is not hard considering the simplicity of those four natural steps. The power of our method model will come from the language and words we chose, so we must be very careful in doing so.

For environments demanding quick action and urgency, use direct language and action words, and keep the process as short as possible. Contrarily, for environments where discipline and risk management are more important, we should choose words that imply broad ideas or encompass a range of related actions or activity. Doing so implies careful thought and consideration, and greater planning.

To fuel the process of selecting your language, begin with the values you most want to promote or reinforce. Make a list of those values. In the method model, use words that explicitly or implicitly direct those ideals. Here is an example.

Let’s say that we want to devise a business improvement method model based on the following values:

  • Adaptability.
  • Responsibility for performance.
  • Thinking “outside of the box” or doing things in a new way.
  • Quick change, not long deliberation.
  • Deliberate change, not willy-nilly adjustments.

Let’s say further that metrics are not as important to us as morale and a general perception that things are better. How might we build a model from this? There must be hundreds of ways, but I’ll propose the following.

Because we want quick action over deliberation, we’ll keep our list short. We will be careful in deciding if we will try to develop a change because we don’t want to waste time changing without purpose so our first step will be a decision. We will also engender responsibility through a late-step decision. Finally, we will emphasize creativity.

How might the following work, just as a proposal?

  • Define problem.
  • Imagine.
  • Select.
  • Deploy.

The list is short. We can build in the correct behaviors within our education and expectations for each step. For example, the word “Select” implies a decision and some responsibility on the part of the team or the leader making the change. If the common practice becomes to demonstrate successful improvement or performance as part of the selection element, the test or verify idea is implied within that step, but it doesn’t necessarily become a dictated necessity for simple problems where the solution is fairly obvious, thus we avoid the impulse to waste time verifying something that doesn’t require it.

The language we choose is very influential. Troubleshoot your drafts before deploying them. Will the language imply actions you don’t want? Do they adequately convey the values and behaviors you are trying to engender?

A culture of continuous improvement is the most powerful way to ensure persistent business and process efficiency and effectiveness over the long term. The key to instituting a culture of our own choosing is to dictate the common practices and behaviors that make up that culture. By choosing an improvement model that engenders the ideals we want our culture to have, we begin the cultivation of the environment and behaviors we desire.

Examine the tour of improvement models above. Pick one that meets your needs, or modify one to meet your needs. If your needs are more unique, draft your own from scratch. Be sure that it includes the four key elements of human problem solving thought and choose language that drives the ideals you desire and value. It’s really not so difficult.

Stay wise, friends.

If you like what you just read, find more of Alan’s thoughts at www.bizwizwithin.com

1.    Cooper, Robert G. Winning at New Products, New York: Basic Books, 2001
2.    SAVE International Value Methodology Standard, May 1997

Advertisement

Share this Story

X
You may login with either your assigned username or your e-mail address.
The password field is case sensitive.
Loading