Engineers are bred to solve problems. From the first day of school, it is part of the professional identity of engineers. It is difficult to imagine an engineer of any type that would not consider themselves to be a problem solver, to take pleasure in problem-solving and be proud of their problem-solving skills.
In addition, there are many, many methodologies of problem-solving. Kepner Tregoe has an excellent methodology. In the automotive industry, the “8D” methodology popularized by Ford has many adherents. Design for Six Sigma (DfSS) incorporates problem-solving methodologies and is used with good success. Red X is another methodology that can be used effectively. There are many more.
So, what is the big deal? Just pick one, train your engineers and let them solve problems – what could be simpler?
The truth is, it’s not that simple. Today’s engineering problems are more complex than ever. Using a suboptimal methodology will generate sub-optimal solutions – solutions that don’t give the most effective results, that cost too much, that may take too much time. Because problem-solving is so ubiquitous to engineering, you can gain a significant competitive advantage simply by using the optimum problem-solving process in your daily work.
I think by now you can agree that a problem-solving process that routinely gives an advantage over others, gives optimal solutions, on time and with the best cost – would be very desirable. Does it exist?
The answer is yes and it is consistently used across world-class Product Development organizations. The reason it’s not well-known is because it is embedded in the culture of these organizations, it has not had a snappy name and the training happens in thousands of interactions between senior and junior staff every day. For clarity, I have codified this into what I call “the Basic Engineering Process” or BEP.
What is the BEP?
There are 2 critical prerequisites for the BEP:
- Work as a team
- Create real-time documentation, with everyone’s participation (use a whiteboard, take a picture and transmit the meeting notes immediately after the meeting)
Working as a team is absolutely critical for any complex problem. The synergy of having multiple disciplines in the room both for ideating solutions, to evaluate solutions and to rapidly implement the chosen solution is immensely powerful. It does not matter how smart one individual is, their idea will always fall short of a solution optimized by a well-trained and functional team.
Basic Engineering Process
Plan “Work as a team, use the whiteboard”
- Define Problem or Objective
- Grasp the situation, go and see
- Use actual parts, drawings, data, location, situation, history
- Understand customer and program requirements
- Establish targets
- What is the best measurement scale?
- Clarify system targets, flow down targets to subsystems and components
- Quantify and consider variation
- List important assumptions
- Understand the Physics
- What is actually happening? What should be happening?
- What is the root cause?
- Diagram or graph the physics with the target and variation
- Develop hand calculations, simulations, transfer functions to describe the physics and variation
- Brainstorm Alternatives
- Get others involved with non-basic problems
- Capture the manufacturing process requirements
- Work as a team, build consensus
- Analyze and rank alternatives
- Use Pugh Analysis, tradeoff curves, or other appropriate method and actual data
- Use understanding of physics and manufacturing process to meet targets
- Evaluate impact in all areas
- Consider unintended consequences for selected concept
- Consider constraints, trade-offs, interactions, variation, etc. to mfg, cost, mass, timing etc.
- Revise the Pugh Analysis
- Create Visual, Detailed, Double-ended Schedule
- Work back from critical objectives and forward from current state to create the schedule
- Clarify risks (technical, commercial & timing) and plan to mitigate risks
- Input who, what, when, where, how, measures (process & results)
- Identify and obtain support or resources from others
- Execute Solution
- Conduct trails as needed
- Implement according to plan
- Minimize product performance variation. Set tolerances for ease of manufacturing and low cost
- Confirm Results
- Go and see results, confirm with data
- Check against targets
- Assure manufacturing processes are capable
- If not what expected, then…
-Revise plan, develop and execute again
- Reflect & Transfer to Knowledge Base
- Document and standardize
- Prevent recurrence
- Educate others
Like all things Lean, the BEP outlined above is essentially a variation of the Deming Circle. The above steps may seem to be obvious, or simplistic, but in my experience the biggest messes – or simply sub-optimised solutions – have been generated by teams that have skipped one or more of the above steps. The inevitable result is spending an enormous amount of time in rework of the solution that was executed in a hurry, by a team that was sloppy in their problem-solving methodology.
Some key points to bear in mind:
- Don’t assume that everyone understands what the problem is. The act of writing it down can be magical in aligning a team. If there is confusion, going to the actual place, or looking at the actual part or test can greatly help with generating a clear problem statement.
- Likewise, setting clear targets – numerical if at all possible – is critical to success. Many times, I have seen a great deal of money and time spent on “directionally correct” solutions – only to find that the problem still existed and was only partially solved. Framing the problem with a clear target stimulates the right kind of brainstorming in later steps. Additionally, setting a target should prompt discussion of variation – environmental, customer use, and manufacturing – and what margin is required to completely solve the problem.
- “Understand the Physics” is essentially saying “find root cause” – but framing it in terms of physics seems to keep teams from fuzzy explanations of root cause. This is the heart of any problem-solving methodology. Typically, the physics are simple – if the team struggles here it is likely they do not have a clear understanding of the problem, and there is no point in proceeding further until this is resolved.
- Brainstorm alternatives – with a strong cross-functional team, and with the interactive environment fostered by the whiteboard there is an optimal environment to not just generate many approaches, but for team members to build on each other’s ideas as well as “mash-up” solutions to create a new approach. Critical to Lean is to get ALL good ideas out on the table as soon as possible – to “blow up” the problem into many possible approaches, then quickly “narrow down” into a preferred approach.
- The “narrowing down” occurs by analyzing alternatives with a Pugh analysis, using simple symbols (circle, triangle, “batsu” or X) to rate each potential solution for all key attributes (timing, risk, estimated effectiveness, cost, weight, any other key measure). A sign of a great team is (ahem) “lively” discussion of how to rank alternatives. The facts should rule, but inevitably some judgment is needed and passionate discussion should occur. In the end, the team should stand behind their ratings and come to consensus or define a hypothesis and gather more data to confirm or refute. One key is to not become lost in an elaborate weighting and/or numerical system of rating – these tend to create a great deal of work and argument with no discernible improvement over simpler methods.
- Evaluate impact in all areas. In my experience, this is something at which, by culture, Japanese are particularly gifted. Simply, evaluate risk – risk of the solution not being effective, of it disrupting another system or performance measure, of timing being compromised, of manufacturability issues, and so on. So many times, problem-solving creates other problems – and ironically in many cases, these are avoidable in many with 10 minutes of the team brainstorming for risks and addressing these up front whenever possible.
- Create a visual, detailed double ended schedule – with clear activities and responsibilities. This is critical for timely execution. Best practice is for the entire team to interact in creating a whiteboard schedule with separate “swim lanes” for functional activities, and very clear deliverables and responsibilities. Key are touch points – when is a deliverable passed to another person or function? What exactly is being passed? Double ended means to start with the deadline and work back in addition to starting from the present and working forward – and ensure that there are ways to compress the schedule if things do not turn out as predicted. A pet peeve: I have rarely seen good team behavior engendered by one “Program Manager” using a Microsoft Project file with several hundred blue bars, no matter how exquisite the embedded logic (and this typically takes a week or more to create). Typically, no one understands this type of plan. Team engagement in optimizing the plan is as important as team engagement in optimizing the solution – and in my experience a whiteboard allows for everyone, regardless of rank, to create a robust plan in minutes.
- Execute – usually not a problem if a robust and thorough plan was created.
- Confirm results – and if results fell short do a 5 why? analysis
- Reflect to knowledge base – very important for continuous improvement – and the topic of future articles.
Importantly, with some reasonable meeting prep by team members, and a high capability cross-functional team, I have seen very complex problems well organized and solved using the above method in 1-3 hours.
Where do we go from here?
Simply, compare the above to whatever methodology you prefer – and I will suggest using a Pugh analysis, with the following criteria:
- Team-based problem solving, with specific methodology to encourage team engagement (whiteboard, brainstorming)
- Near real-time documentation, allowing the entire team to interact in creation.
- Streamlined methodology – including all key problem-solving activity, and eliminating any cumbersome or non-value-added activity (ex: numerical Pugh ranking)
- Explicit focus on target setting, including consideration of variability
- Explicit focus on the physics
- “Blow the problem up” to ensure every good idea is generated, and the team can build on and combine ideas.
- Narrow it down, using a symbol-based Pugh analysis – simple, effective, and quick method of optimization
- Risk assessment as an explicit step (“Consider impact in all areas”)
- Team-based real-time schedule creation using a whiteboard
- Closing the loop – comparison of actual vs projected results and analysis of any difference
- Reflection to knowledge base as an explicit step
- Scales from small problems to large, strategic problems
Many problem-solving methodologies exist, many are used to good effect, and almost anyone is better than random “try and test”. In my experience, the methodology outlined above both empowers the team and consistently generates world-class results. In my next article, I will tell the story of how a global team solved a monstrous problem in a compressed timeframe using the BEP process above. As part of this, they used the Pugh analysis to reject my suggested approach in favor of their own, despite my idea meeting functional targets as well as being better for cost, timing, and investment. They ultimately proved that they made the right choice, and thru superb teamwork executed the solution flawlessly. Stay tuned! – and in the meantime give me feedback on any problem-solving methodologies that you feel may be better than the BEP (and please argue using your Pugh).
Just starting out with Lean product development? Read Charlie's article on how to take the first steps: https://theleadershipnetwork.com/article/taking-the-first-step-getting-started-on-your-lean-product-development-journey