The Wrong People on the Team

Quite often we tend to load up the team with professionals who have a world of experience and knowledge. While subject matter experts are needed, it is just as important to have the person who knows nothing about nothing about the problem. This person brings innocence about the subject to the table and should be encouraged to ask “why”. I have seen this work very effectively when the person asks “why” and the only answer from the experts is “because” or “its always been done that way”. Experts tend to have blinders on when it comes to their area of expertise and don’t see the forest for the trees. By having to explain why something is done or not done, it forces them to analyze the answer. I have seen some remarkable ideas come from people who don’t have education, experience or job titles clouding their thought patterns.

No Ground Rules

Ground rules are critical to the effectiveness of any team whether it is five members or two. Meeting times, task completion, note taking, length of meeting, and agendas are all important. They need to be stated and agreed to at the beginning.

The one rule that that I found to be most important is the “one person, one vote” rule. Just because someone has a bigger business card than someone else does not make their opinion more important. If they have a valid reason for not doing something, then it is their responsibility to explain or show data why that should not be done to the rest of the team. Nothing will sidetrack a team faster than someone who uses their authority to run the team and the results. If that person goes into a problem solving exercise with a solution already in mind, then the team concept is the wrong one. In this case it would be better just to assign someone the responsibility to implement what that person wants.

Ineffective Leader/Facilitator

The role of the leader is to ensure that the team stays on track and follows each step to completion before moving on. Most problem solving environments that I have seen everybody wants to move directly to the solution and get that done. Each step must be covered before moving on. Even though the solution is the destination, we must walk the road to it.

The leader’s role is to also ensure that everyone has a chance to speak and more importantly to be heard and understood. “One person, one vote”. The subject non-expert has to be allowed to ask “why” as many times as it takes to clarify their question.

Not Being Specific Enough

Merely saying something broke is not enough. It is usually pretty evident that something is not working. Being able to eventually reach root cause and implementing solutions requires that the problem is clearly stated beyond the obvious. Statements that include the ramifications, impact and consequences are important. When things go wrong, mistakes are made, or time is being wasted, it is rare that there is only one underlying issue. A proper problem statement will provide guidance for the team during root cause analysis and solution implementation. A statement such as “The grapple grommet machine failed when the electrical breaker that controls the grapple lever overheated causing a periodic short. The short caused the machine to miss a step in assembly causing a scrap rate of 18%. Several of the faulty grapple grommets were shipped to the customer which resulted in having to make up for the faulty units”.

The above statement tells a lot more than a statement such as “electrical breaker overheated”. The more complete statement will take the team in different directions and will likely result in solutions being implemented in more areas. It also provides measurable data that the team can use to justify their solutions. The first statement will help to install solutions that go beyond the grapple grommet machine. Even if we fix the breaker issue, another component that is non-electrical in nature could occur and result in bad product being shipped out again. Nothing irritates a customer more than repeat issues whether it is a product, service or a report.

Failure To Stop The Bleeding

When a problem occurs it is critical to stop the flow of bad information, product or service. That may take more time and effort but the results will be worth it. In the auto parts industry, when a bad part reaches the assembly line all product must be sorted, scrapped or quarantined and then replaced by certified parts. That ensures that everything from a stated point is defect free. The supplier then has a specific amount of time to present the corrective action. Until the solution is implemented, each and every part must be manually sorted and marked as certified. In that industry the procedures are well documented and the consequences are clear.

In service industries such as thermography it may not be clear until your customer goes elsewhere. If you have one customer complain about something, chances are several of them are not happy. Containing the problem causes you to collect data on the frequency of the problem and how far it reaches. Hanging up the phone after a complaint and saying we will look into it is not containment. Have someone review reports and do a specific survey - in short, make sure that the problem is not continuing.

As I stated above, when a team attempts to solve the problem too quickly and jump into root cause analysis and solutions, they fall into the pitfall of a vaguely defined problem. The example problem statements above will lead a team into two different directions and will likely result in two different types of solutions. A well defined problem is almost half the battle in closing out the issue. It is not unusual for a team to go back and redefine the problem once they have contained the problem and identified the issue.

Jumping to solutions without verifying the root cause. The true test of root cause is being able to turn it on and off at will. Only once that is done can solutions be developed. There will be times when because of safety you cannot attempt to recreate the problem.

Placing blame on a person is the most destructive pitfall a team can fall into during this phase or any other phase. The entire exercise needs to be executed in an atmosphere where the basic principle of “focus on the situation, issue or behavior not on the person” is followed.

Dealing only with symptoms during root cause will cause teams to go into directions that will most certainly create ineffective solutions. Asking “why five times” and utilizing cause and effect diagrams will assist in determining what a cause is and what is an effect. I have seen many times where a team has confused the effect with the cause and put a solution into effect only to have the issue come back at a later date.

Too Few Alternatives

Bring everything to the table no matter how off the wall it may appear. The greatest inventions in the world would not be part of our lives if inventors stopped at only one or two ideas. During the brainstorming phase there is no such thing as a bad idea.

Unimaginative Ideas

This is one of the reasons we bring in a person who knows nothing about nothing. From the mouths of babes, etc. Remember that education, experience and subject matter expertise only prevent us from pushing the envelope.

Focusing On Constraints

There are hundreds of reasons why ideas are killed. If we think hard enough we can kill any idea we want by looking up a reason. For a list of 35 of the most popular ones see the end of this paper.

Fixing On Only One Solution

This is another area that I have seen teams and individuals run into problems. Spending all their time on one idea only to find that for whatever reason it won’t work. Analyze the solution the same way you looked at the problem. Throwing money at a problem is not the best way to go. Don’t fall into the trap of bells and whistles; if the bells and whistles don’t do anything about the problem, reevaluate what you are proposing. Gluing feathers onto a man’s arms was not the way to achieve flight. If mankind had fixed on this as the only way to fly because that’s the way birds did it we would still be earthbound. Quite often the best solution is one that is a combination of several potential solutions.

Arguing Solutions Before Discussing Criteria

It is absolutely necessary to discuss the criteria that the solution needs to fit into. What is the solution expected to solve? Depending on the issue, timing might be the most important aspect to removing the problem. In another one it might be cost or durability.

Jumping To A Solution Without Careful Evaluation Against Criteria

Does the proposed solution fit the constraints that were identified? If you have a budget of $100 then a $10,000 solution will not be the answer. If a solution has to be in place tomorrow then a full engineering study by an outside consultant won’t work either.

Failure To Consider Unanticipated Consequences

Again we need to consider cause and effect. Will the solution create more problems than it will solve. What will happen next year or the year after that? Who will be affected? How will they be affected? Changes in technology or methods may not be in the grasp of those who may have to incorporate it into their daily routines.

Not Considering Creativity Before Capital Spending

This is one of the mantras that I used over and over. Duct tape and wire can sometimes accomplish better results than a brand new, shiny, expensive new widget. In my time of overseeing the corrective action and continuous improvement efforts, the absolutely best ideas were the cheap ones. Not only were they effective, but by being cheap they automatically remove a lot of the constraints that companies are under.

Failing To Involve Others

If they have done their job right the team is all in agreement on the solution and it is truly the best thing to do. I have seen very good solutions go down the drain because they failed to involve others during implementation and failed to get the needed support. This is one of the unanticipated consequences when the team is told that because of another project this one is of low priority. Not good when time may have been the primary criteria.

Vague Assignments And Being Unprepared

Everyone needs to know what they have to do and what they need to have prepared. The team needs to assist everyone when needed to ensure that assignments are completed so the solution is implemented on time and in the manner envisioned. Don’t leave anyone out. The person who “knew nothing about nothing” needs to be involved. By now they have a far better understanding of the situation. I used to use this person who was quite often a machine operator from outside the department that had the problem to run errands, photocopy, confirm meetings and other things that are important. Set deadlines and make sure that they happen.

Over Commitment By Members

While it is nice to have that person who will volunteer for every assignment, it is not feasible to count on everything being completed. Break down big tasks into bite-sized portions and let everybody do sub-tasks and report to the person responsible for the main line item task.

Failure To Consider Restraining Forces

Is summer shutdown coming up? Are there new product launches underway? People on vacation? These are all things that need to be considered while planning and setting deadlines for implementation.

Failure To Look Forward In Time

A system is required that will act as a check and balance. Initially, the new process should be checked regularly for effectiveness. A solution that calls for “retraining of operator” works for that person but when they are replaced how are you going to remember that the new person will require training or at the very least an explanation of why a certain procedure is in place and must be followed. ISO/QS 9000 documentation requirements demand periodic review of all documents with the affected personnel and revision as needed. PFMEA’s, engineering control plans and operator work instructions are updated as part of preventing recurrence of issues. Even for small companies a manual should be initiated and kept current of how things are done and why. As a company grows, this will form the basis of training that new secretary and help prevent that person from doing something that you found out the hard way loses customers.

Failure To Communicate, Communicate, Communicate

Enough said.

In larger companies make sure that everyone knows who solved the problem. Have the general manager make an appearance and state how grateful they are for the hard work and resourcefulness shown. Buy them dinner, a hat, time off. In my experience the best reward was the plant manager calling in each person and personally thanking them one at a time. Done in a sincere manner and with a few details on each person’s contribution it goes a long way to encouraging others to participate.

Even if it was only yourself that had the problem, looked at the problem, fixed the problem and made it go away, pat yourself on the back, brag about it, write a paper on it, get recognized for it. Be proud about the effect it will have.

 

35 WAYS TO KILL IDEAS

1) Don’t be ridiculous.
2) We tried that before.
3) It costs too much.
4) It can’t be done.
5) That’s beyond our/your responsibility.
6) It’s too radical a change.
7) We don’t have the time.
8) That will make other equipment obsolete.
9) We’re too small/big for it.
10) That’s not our problem.
11) We’ve never done it before.
12) Let’s get back to reality.
13) Why change it; it’s still working OK.
14) You’re two years ahead of your time.
15) We’re not ready for that.
16) It isn’t in the budget.
17) Can’t teach old dogs new tricks.
18) Do the best you can with what you’ve got.
19) Too hard to sell.
20) Top management would never go for it.
21) We’ll be the laughing stock.
22) Let’s shelve it for the time being.
23) We did all right without it.
24) Has anyone else ever tried it?
25) It won’t work in our industry.
26) Will you guarantee it will work?
27) That’s the way we’ve always done it.
28) What we have is good enough.
29) But we would also have to change the
30) It’s in our future plans.
31) We’ll have somebody study that problem.
32) It’s against our policy.
33) The supplier would never do that.
34) The customer wouldn’t accept that.
35) When did you become the expert?