The P-Diagram before the design is finished
What changes when we stop asking only what could go wrong and start asking what we can still change?
ENGINEERING METHODS
Engineering methods are wonderful things. They help us organize complicated problems, avoid repeating old mistakes, and occasionally make us look as though we knew what we were doing all along.
But sometimes we use a perfectly good method and discover that the question it helps us answer is not quite the question we wanted to ask.
I have been thinking about this in relation to the P-Diagram, a familiar tool in robust design and Design for Six Sigma (DfSS).
A P-Diagram describes a function or process in terms of its inputs, control factors, noise factors, and responses. It is a compact and useful way of examining how a system behaves, including what might prevent it from delivering the intended result.
This is already useful. We can investigate undesirable outcomes and identify disturbances that might prevent the process from behaving as intended.
But now imagine that we haven't decided how we're going to cook the tortilla.
We're still designing the solution.
What if the design is still open?
Suppose we're trying to determine which pan diameter is most suitable. Or which potato variety gives us the texture we want. Or whether cooking temperature and timing should change depending on the ingredients.
Perhaps we haven't even agreed on what constitutes a properly cooked tortilla. But at this point, I am interested in something other than listing everything that could go wrong.
I want to identify the factors I can deliberately change to improve the intended performance.
So let's modify the emphasis of our P-Diagram: instead of expanding the disturbances, we leave them summarized for the moment. We then expand the factors that might influence the quality of the desired output. And instead of concentrating on a distinction between expected and unwanted outcomes, we focus on the performance of the intended result.
Nothing controversial here, but I want to explore a slightly different use of the same idea.
And for that, we're going to cook a Spanish tortilla.
Engineering a tortilla de patatas
Suppose we want to prepare a proper tortilla de patatas, the Spanish potato omelet. We'll need potatoes, eggs, olive oil, salt, and perhaps onions, depending on which football team you happen to support. Those will be our inputs.
Our process is straightforward: prepare and cook the tortilla.
We also have controls. A frying pan, a stove, cooking ware, ventilation, and the choices we make while preparing the ingredients. And, naturally, we have disturbances: poor-quality potatoes. Old eggs. An incompetent cook. An unreliable stove. Excessive heat. Perhaps somebody opening the kitchen door at the wrong moment.
The desired output is a great tortilla.
The undesirable outputs could include burnt fingers, spilled oil, a ruined frying pan, an activated smoke alarm, or something resembling a geological sample rather than breakfast.
We can represent all this in a conventional P-Diagram.
The difference may appear modest., but the question has changed.
In the first diagram, we were investigating what can interfere with the intended process, and which undesirable results might follow. In this second, we're investigating which design choices and operating characteristics influence how well the intended function performs.
We have moved our attention from protecting a chosen solution toward investigating the solution itself.
Are all these factors really controls?
Not necessarily, and that is an important point!
Potato variety might be a controllable choice if we select the ingredients. It might instead become an uncontrolled input characteristic if someone else supplies the potatoes.
Oil age could be controlled through a preparation rule or treated as a source of variation.
A smoke-alarm setting is clearly more relevant to a safety response than to the quality of the tortilla.
So, our exploratory list is not yet a carefully classified architecture. That's fine for us, for now.
At this stage, the list is helping us discover which relationships deserve attention. We can then classify them, define what they influence, and determine which are genuinely under our control. A good engineering representation should help us ask better questions, not merely arrange everything into boxes.
And what about that performance indicator?
You'll notice that the second diagram includes an indicator representing the percentage of the intended tortilla specification achieved. This is an illustrative example only. Before treating it as a real engineering response, we would need to define what performance actually means. Texture? Flavor? Cooking uniformity? Appearance? Food safety?
We would also need to determine how to measure those characteristics and whether combining them into a single score makes sense. Only then could we investigate the relationship between our design choices, disturbances, and the resulting performance. For a genuine design exercise, that's where things become particularly interesting.
We can begin asking which parameters matter most, how they interact, and which alternatives are likely to be robust. These are precisely the kinds of questions that become valuable during the Design and Optimize stages of DIDOV.
Two views, two useful questions
I'm not suggesting here that the conventional P-Diagram is wrong or that designers should abandon its familiar structure. The same function can benefit from multiple perspectives, and we are here trying to cater to a design stage a structure that is known to work well during risk analysis and decision-making activities.
One helps us investigate disturbances, undesirable behavior, and robustness: the current P-Diagram as we all know it. Another helps us explore the choices that determine intended performance while those choices are still open.
Neither perspective eliminates the need for the other.
To conclude, there is a broader architectural question hiding here: should we begin by defining the types of relationships we expect, or by identifying concrete factors and then classifying their relationships?
Both approaches can teach us something. For now, my proposal is simpler:
When you're still designing, make sure your engineering tools help you explore what could be designed, not only what could go wrong with what you've already chosen.
Otherwise, you might end up with an exceptionally well-documented process for producing a mediocre tortilla, and nobody wants that.
What do you think?
Look again at the second diagram. Is the classification of the influencing factors correctly laid out? Would you arrange them differently? Would you retain the unwanted outputs in the same view?
I'd be particularly interested in how other engineers adapt P-Diagrams during early design work.
After all, a useful engineering method should survive being questioned.
