Presenting Solutions

Introduction: An old Scottish saying says to “Leave things better than you find them.” Much of my career, especially my early career, was about finding and solving problems. I like to learn, I like sharing what I learned, and I want people and projects to succeed. So, I have a clear bias, and when a senior DP personage recommended not providing solutions in an online DP discussion, I was concerned. Of course, he was partially right (completely right in the right context), and there have been times when I haven’t provided solutions. Let’s have a look at some reasons not to provide solutions.

Stealing Victory: An old and effective approach to education poses a question for the student to ponder and find the solution to. If the student succeeds, it is his victory and something he is more likely to remember, value, and apply. Providing the solution steals that victory, and we want other people to succeed and grow. Clearly defining the problem, how it is a problem, and why it is a problem can aid in that. There is a danger to this. This isn’t a teacher/student relationship, with similar power dynamics, but an interaction of equals. The person with the knowledge needs to be careful to not manipulate the other party into his preferred solution, and must recognize that the other person may have better information and resources. For example, I often aim at small scale, simple fixes, but sometimes people are willing to pay for a more comprehensive and complete solution. Someone else’s path to a good solution is valuable and might be better than your own.

Incomplete Information: Sometimes, there is insufficient information to define the problem, let alone a solution. For example, there might be a master thruster control system, whose previous iterations all had single point failures in design, and a couple concerning test results have been seen in the current design. Is it a problem, or isn’t it? What is the solution? If I had my druthers, I’d have an independent expert perform IMCA M259 testing to find out. But is that justified? There is cause for concern, but not evidence of concern. The concern needs registered, so it can be monitored, but whether it is actionable is another thing. This would be a lot easier if we better tracked DP anomalies, so we could see patterns.

Danger: Sometimes the people who are informed of the problem and solution are incapable of understanding and implementing the solution, or likely to take dangerous shortcuts. I’m thinking of vendors who sold a pig in a poke, don’t understand the problem, can’t implement the solution, and will take dangerous short cuts. Do not give them the rope to hang themselves and their client. Complex technical solutions aren’t great recommendations. This is a grave temptation for engineers, and a route to unclear kludges. I once carefully explained how to solve a difficult problem and lightened the situation with a humorous tale of something ridiculous to avoid. They implemented the thing to avoid and everything needed torn out. Communicate clearly and avoid suggesting solutions that are liable to fail or not be maintained.

Hype: A good salesmen sells his clients what they really need, rather than what they think they want. Unfortunately, some successful salesman and companies sell dreams. Sure, simple procedure, configuration, or component improvements, or a piece of wood, might do the job, but a hydrogen-powered, quantum computing, AI controlled, networked, remote access, closed-bus, backscratcher is so much cooler and futuristic. It’s amazing how often the “hydrogen, quantum, AI, IoT, closed bus, backscratcher” is a source of problems. Or maybe it isn’t surprising (KISS – Keep It Simple, Murphy is watching). Providing atomic backscratcher improvements is counterproductive, and will be dropped when you are gone (software update) or used to con the next guy. Define the problems, but don’t make them worse. For example, I just list the technical problems with a well-known, closed bus, protection system that doesn’t work on first principles and that I don’t know anyone who can’t black it out.

Quantity has a Quality of its Own: Sometimes, there are so many problems that solutions cannot be presented for all of them. This is especially true early in a project when the design is still flexible. They have non-DP problems of their own, and any solutions need to be harmonized as the design is still being iterated. In that case, you are better providing initial technical queries asking how various problems will be solved. This recognizes that they are skilled professionals that are still working on it, but provides a warning of potential problems to be considered. In that context, making the engineers dig through potential solutions to get to the problems is counterproductive bloat. Atomic backscratchers can produce similar long lists of risks, but the chances of solution are much smaller.

Bureaucracy: These are project success concerns, but there are more bureaucratic reasons, such as liability, cost, time, and scope. When I started doing class review and survey, I had to learn to not solve problems. Instead, when people were stuck, I told them how other people had solved similar problems and gave examples of options. That wasn’t advice, it was description - often, badly needed and wanted description. Sometimes, a project has enough budget to find problems, but runs out before their solution. In the end, solving problems is often other peoples’ responsibility, and that needs to be respected. At one point, we had a problem with people doing annual DP trials and making main class “A” findings. That wasn’t what we were hired for, and disguised the DP findings. We needed to stay within bounds of contract and competency.

When to Supply Solutions: I’m not interested in being a professional complainer, and prefer to provide solution options to each problem, but there are criteria that need to be met. Solutions need to be wanted by the client, needed, respectful, clear, easily implemented, and effective. The problems need to be clearly understood, and the solutions actionable.

Conclusion: While I still prefer to provide problems with solutions, the other guy was right and there are times when you should not provide solutions. Sometimes, it is counterproductive, dangerous, or outside the scope or budget, but when solution options are welcome, safe, effective, and within contract, they should be provided to help the work get done.

P.S. The advance program for the 2024 MTS DP Conference is now available.