Engineers solve problems. Good problem solving skills are essential for successful engineering projects. From the initial scoping phase through detailed design and implementation phases, important decisions must be made. So how are good decisions made in practice?
I enjoy working with small teams, as team member, facilitator or team leader, to solve pressing technical problems using common decision making techniques. After many years of trial and error approaches, I favor using the Kepnor – Tregoe (KT) method with some adjustments in approach based on the situation. It is not my intent to teach or explain the KT method, you can read the book or visit their website for that. My objective is to share five key lessons I have learned related to determining the best engineering solution to resolve problems:
- When and how to apply a structured approach?
- Selection Criteria
- Brainstorming
- Pros and Cons
- Making the Recommended Decision
When and how to apply a Structured Approach: Every day an engineer makes decisions and most decisions are made with a straight forward reasoning that the engineer and maybe a peer reviewer agree with. IF the decision is not straight forward, involves multiple disciplines, has multiple competing objectives, has no obvious best solution, AND has significance (dollars, safety, regulatory, schedule, etc.), THEN it is usually a good time to stop and apply more rigor to the decision analysis process.
A small team of stakeholders (four or five is good) should be assembled with someone who knows the decision making process assigned as the facilitator. Depending on the complexity of the decision, the team can complete its work in one meeting (one day) or multiple meetings over days or weeks. Its best to have a written procedure or instruction and to have the facilitator start by training the team if members do not have recent experience using the process.
The team may be given a problem statement or, preferably, they develop it themselves. In either case, the team members need to scrutinize the problem statement and ensure that if they address the problem statement as written, the objectives of the decision will be met.
How much input/information do we need to make the decision? This is often debated within the teams I participate in. Many engineers stress that they can’t make a good decision without more data. Similarly, the team leaders or affected managers stress that time is of the essence and there is no time for a research project. In such situations, the successful teams, whose decisions stand the test of time, are the ones with a good cross-section of experienced team members who can use their experience to make good judgements without all the data they would like.
One caution is that if you don’t have the right experience on the team, you may not even consider the best option because the team is not aware of that technology or technique. Also, significant new information may arise as the selected option is being developed that changes the best path forward. When this happened on one of my teams, the project ended up stopping, factored in the new information, and reconsidered more options by re-assembling the decision making team. This takes courage to admit the decision made is no longer the best choice, but enlightened leaders see it as a sign of a strong culture that faces reality and is not afraid to check and adjust along the way.
Selection Criteria – Determining the decision making criteria (KT calls it the MUSTS and the WANTS) and ranking the solution options against each criteria is what puts the “structure” in the decision analysis process. You almost always have cost and schedule criteria. Other important criteria come from the stakeholders. Stakeholders can be end users, management, designers, etc. These are the people with a vested interest in the outcome. For example, operations people will want something simple to operate; maybe automatically controlled to reduce operator burden. The mechanical design engineer may need a certain factor of safety to meet regulatory commitments.
Brainstorming – Given a problem statement and selection criteria, the fun part is brainstorming all possible solutions. The facilitator needs to allow a free flow of ideas and be careful not to allow any judging of ideas during the brainstorming session. Write everything down on the white board.
Once all the ideas are out, it is usually a good idea to group similar or complementary ideas and then narrow down the field of ideas into a few of the most likely candidate solutions. Most of the time, we end up with five or less solution alternatives, which are often made up of combinations of ideas presented or “solution sets”. Eliminate the solutions that just are not feasible (can’t get material in time, cost prohibitive, etc.)
Pros and Cons – As part of the ranking of different solution alternatives, I usually create a Pros and Cons table. Sometimes this is just a simple three column table with Alternatives listed in the first column, Pros in the second column, and Cons in the third column. I do the more rigorous numerical ranking of selection criteria also, but everybody seems to understand and expect the simple pros and cons table, so that is now a regular part of all my presentations to management.
Occasionally, it helps to organize the pros and cons table by selection criteria to provide a more logical presentation. For example, if cost, schedule, operator burden, and design margin are the selection criteria used to discriminate between different solutions, pros and cons related to each critieria will be presented.
Making the Recommended Decision – The process is intended to assist the team in making good risk informed decisions with a logical basis. However, after you have done your pros and cons and ranked your solutions based on the selection criteria, the numerical winner is not always the best decision. Whenever you have multiple people participating in the decision, there are pitfalls that need to be taken into account. For example, group think is a pitfall, especially when you have one dominant person in the group and others are hesitant to advocate an opposing view. Another pitfall is that once the ranking data is tallied, people may simply accept the answer. The team needs to challenge that result and understand the risks by asking “what can go wrong”? I remember once, a late-identified design change had to be made for an upcoming outage. The team presented four options and recommended the highest ranked solution. During the presentation to station management, the site VP asked, “what option kills this problem”? Meaning which option provided the most certainty that the solution would work. Well, that was the number 2 ranked option, not the one we had recommended. The final decision was to implement the originally ranked number 2 option. This design change was completed on time, and performed flawlessly when tested. While it is likely the original recommended option would have worked, the lesson here is that the team must challenge the first choice by asking questions like “what can go wrong”, “what option best kills the problem”, have we weighted the selection criteria properly, etc. Finally, once the decision is made, monitor progress and be prepared to re-assess if the design is not progressing as planned.