Why is it that we as engineers always seem to think we never have enough of us in product development? Or that we never have enough time? I believe it starts with insufficient use of a systems engineering approach. We don’t spend enough time in determining our unknowns in the problem space or in the solution space. We also don’t take time to tailor our engineering efforts for the development of our project. In doing this, we fail to realize what engineering is needed and where best to apply it.
If we look at jigsaw puzzles as an analogy to product development, we can start with how we look at them from the outside: the box. We can examine the picture, the shape of the puzzle, and the number of pieces to estimate how difficult the puzzle will be to solve. This is the problem space. Here are some examples of different problem spaces in the jigsaw world.
Consider the problem space
Typical jigsaw puzzle pictures range in detail from very distinctive shapes/patterns/contrast to more abstract renderings that deliberately obscure shapes/pattern/contrast. The puzzles typically are rectangular and can vary in the number of pieces. The picture boundary is fairly straight-forward, so the problem space is well defined.
Another type of puzzle called the Scramble Square®, has a picture of one piece on the box. It is square and is made up of nine square pieces. The lack of an entire picture deprives the puzzler the complete view of the problem space, but the picture of the single piece provides insight into how difficult the pieces will be to connect.
A third example puzzle is called Wet Paint. The picture outline looks like someone just poured paint on a flat surface, the color is one uniform solid color, and it is 350 pieces. The well-defined puzzle space is similar to the more common jigsaw puzzles, but the implications of the shape and singular color present a very different problem.
It is clear that each puzzle presents a different problem. Relating this back to our development, we should be looking at the problem in front of us and asking whether we have done an analysis of how this problem compares to other problems we have solved. This first step offers a good idea of what engineering we are going to need.
Consider the solution space
Continuing our jigsaw puzzle analogy, let’s examine the pieces and the picture on each piece. In our case, each puzzle presents us with a very different set of pieces to work with. This set is our solution space.
The typical jigsaw puzzle pieces are fairly well understood. The outline of the puzzle is easy to define and with the pictorial reference, we know that there are going to be areas of the puzzles that go together easily and those that will take more time. The relationships in the solution set vary, but for the most part are easily established.
The scramble puzzle assembles easily, but getting the right pictures to line up is more difficult. While there are multiple sets of pieces that can create the same singular relationship, only one enables the whole puzzle to be put together completely. The solution set provides a different set of challenges in correctly assembling the puzzle.
In the case of the Wet Paint puzzle, the outline is hard to identify. The shape makes it hard to distinguish where you are on the outline and makes for difficulty in differentiating the border from the interior pieces. There also is no reference from a picture standpoint as all the pieces are the same color. This solution set is difficult to work with because you must rely completely on the shape of the pieces. It presents a greater challenge in establishing the relationships required to assemble it.
The solution space in a jigsaw puzzle is a little different than in product development. The solution space has been deliberately chosen along with the problem space to create unique challenges in assembly. This is the inherent purpose of the jigsaw puzzle. But, it does give us reason to look at the solution space and ask the question: Are the pieces similar to what we have seen in previous development, or are they new, unique, or different? This same question can be asked of every one of the applicable engineering disciplines in product development. Does the problem space drive us to unknown solution spaces, or are they within the knowledge and capabilities we already have?
Consider the engineering process
The final area of our jigsaw puzzle analogy pertains to the approach a puzzler takes to assemble the puzzle. One might take an approach similar to the following:
- Separate border pieces from interior pieces
- Place all border pieces on the table upright
- Iterate until complete:
- Group pieces by similar picture/color
- Assemble groups of pieces
- Locate groups relative to one another based on box picture
- Assemble border
- Place all interior pieces on the table upright
- Iterate until complete:
- Group pieces by similar picture/color
- Assemble group of pieces
- Locate groups relative to one another based on box picture
- Assemble the interior
While this approach may work well for a typical jigsaw puzzle, it may not work as well for the other types of puzzles.
In development, we try to use a standard approach as well. It is composed of our engineering processes. While these processes may work with some or most problems, they may not work for all problems. In each case, we must be aware of the development processes we are using. We need to make sure that we are using them to enable the right effort in the right ways. Spending a lot of time on things we already know and have done provides less value. Expending effort on what we do not know and what we have not done aids in eliminating the things that might throw a project off course, causing delays, missed milestones, or other undesired outcomes.
I offer this personal experience as an example of where additional systems engineering may have improved the outcome of a project.
I was working for Motorola in their automotive electronics division. I was instated as a project design team lead for a Transmission Electro-Hydraulic Control Module. I had not been involved in the project quote, and was handed a detailed design to run through requirements analysis and develop a verification and validation effort to complete the project.
In the problem space there were some unique aspects of this project that we had never done at Motorola before, or at least in my group. Three things made this unique to us. First, the operating environment was 140° C. Second, that environment was internal to the transmission where the solution was immersed in hydraulic fluid. Third, we had never done the hydraulic side of the system. As a problem space, it was very much outside the norm.
The 140° C environment was accounted for in the electronics design and the material properties of all components. All material was also reviewed for compatibility with the hydraulic fluid. We brought on expertise in hydraulics and used a supplier to fill out our hydraulics capability. So, while these were known differences and we attempted to fill in all the unknowns, there were two that we tripped over. I will expand on the one that cost us the most.
This unknown was a little thing called adhesion. While the material properties had been analyzed, we had failed to look at the adhesion used in our sealing techniques. These techniques had been used in all kinds of Electronic Control Units (ECUs), but none of the designs had been employed in this type of environment. The seals relied specifically on mechanical adhesion. What we had failed to realize was that the forces created by the extreme temperature swings combined with the forces created by the hydraulic pumping action from the thermal expansion of the hydraulic fluid were extremely large. Once a breach started on the seal, the fluid seeped in and amplified the decay.
However, we were able to launch, although with an expensive design addition, to protect the electronics from the hydraulic fluid. We were able to redesign the sealing solution and remove the design addition the following model year.
In hindsight, I believe that had we spent more time analyzing the impacts of our unknowns on our solution space, we might have been able to identify the seal as a risk and put in place the engineering efforts to provide a solution that would have worked before we began working on a solution.
Suggestions for how to proceed in the problem space
I conclude with the following recommendations for setting up projects for success.
In the problem space:
- Spend time analyzing your problem space. Make sure you identify what you know and what you don’t know (knowns and known unknowns).
- Spend additional time examining your system boundary, trying to identify those things you may not know that you don’t know (unknown unknowns).
In the solution space:
- Take a deep dive into every aspect of the design with respect to your problem space unknowns.
- Analyze the solution space for new and unique items in the solution space. Inherently, these bring with them a certain number of unknowns.
- Spend time trying to find the unknown unknowns in the solution space.
In your process:
- Examine where in the process you will address your unknowns.
- Identify any need for new processes.
- Tailor your process to the problem you are trying to solve.
- Address your unknowns as early as possible.
If we do not fully explore our unknowns, we can be certain that we haven’t identified all of the engineering efforts and must continue to ask questions about having enough resources and time. As systems engineers, it is our goal to make sure that proposed solutions can achieve predictable outcomes with a reasonable amount of certainty. Let us be as certain as we can by eliminating as many unknowns as we can.
To learn more about GENESYS, we encourage you to visit What’s New in GENESYS 2020 R2.
