Problem-solving 101: Machines don’t have issues – people do

I recently received a distressed call from a client: “We have an issue with a leaking fuel tank, and the team is stuck. We need your help right away.”

I knew the nature of the “issue” as soon as I got to the client site at 10 p.m. that same night. There were more than 20 people sitting around the boardroom. They were, for the most part, well-meaning engineers and suppliers doing their best to represent the best interests of their company or department. But how many competent engineers does it take to figure out why a few fuel tanks, returned after several weeks in the field, are leaking? Two or three is all it should take.

Two engineers had been assigned to work with this large group, but could not make progress because they were part of a committee assigned to resolve an issue, not a team organized to complete a project. The tactics were not in phase with the business strategy. And management’s interest in a fix was in conflict with the approach of a committee assigned to resolve an issue. Resolution is not a fix. A team working on a project has to have a specific, well-defined tactical approach that management understands.

In the room, there were representatives from every supplier that provided a component or material for the tank. There were people from every department involved in purchasing, engineering and approving changes. Each saw it as his responsibility to defend his turf and make sure there was no blame for his company or department.

I then asked all but three to leave. Twenty brilliant people cannot effectively work on a project that should be completed by two or three, especially if they have competing goals.
This was not an issue that had to be resolved by a committee; but rather a problem that needed to be converted to a project, then executed to a conclusion by a small, effective team.

I was not interested in resolving any issues. I don’t work on issues. This was not a complex project. It deserved answers, and fast. To get those answers, we needed a good tactical plan. Sure, some projects are complicated. That means we need to be even more disciplined at the tactical level; more focused on making certain that the project has a leader who clearly understands sound tactics, and makes sure they are integrated with the business strategy.

By noon we had answered the following questions:
1. How is the tank supposed to function? How many functions does it perform? Which are high-risk functions?
2. Which function is it failing to perform?
3. Where is the energy supply coming from that caused the function to fail?

By the end of the day we had: replicated the failure and proven we understood the physics of failure; and proposed tactical fixes, which were consistent with the business strategy.
I left at the end of the first day, but stayed in contact with the small team that continued the work over the weekend. They implemented a temporary fix, tested a permanent fix and began the approval process.

The leader then included a few of the people who had earlier been asked to leave. The size of the team, however, was kept small by removing those no longer needed.
As the tactics changed, the people on the team changed. A good leader knows how to roll people on and off a team, keeping the team small, lean and effective, while making certain that roles and responsibilities are understood and respected. By including everyone that might be involved, instead of changing team members as the roles change, a team becomes a committee and loses focus.

I have never seen a large team assigned to a narrowly defined technical project work well in a factory that has to continue to operate. I have, however, seen small teams solve complex problems without interfering with operations.

Issues are, by nature, a forum for arguments. Goals, once defined at the tactical level, are not. If we never admit that we have a problem, we can argue about it endlessly. But this is not a model for engineers to think their way through a technical problem.

When given an assignment, you have to determine if the project deals with an issue or a problem. They are not the same thing. The tactical approach for one will fail for the other.
Solving technical problems is a lot easier than resolving issues. That being the case, why would one think in terms of issues when there is an easier, more efficient way? The foundation of technical problem solving, specifically at the engineering level, is always based upon the laws of physics.

Think about this for your next project, whether you lead the team or are a team member. It will make it a lot simpler if you can keep it out of the convoluted world of issues.

John Allen specializes in the application of engineering principles within the context of product performance, product durability and reliability improvement in manufacturing companies. You can visit his website at http://johnallenllc.com. He can be reached at john@johnallenllc.com.