Beating Risk in Product Development

Is R&D a Financial Black Hole from which no results escape? If this has been your experience before, well, have I got great news for you. There is a way to produce results while simultaneously limiting financial exposure.

Engineering Research and Development takes many forms - novel technology development, product change/improvement, investigating solutions to emerging problems, seeking higher value or efficiency in stable products - but the one thing they all have is Risk.

Broadly, Risk in this context means, "What if it doesn't work? Now all our time & money is gone, and we have nothing to show for it!"

There is always a chance that it won't work; otherwise it wouldn't be an R&D project, and you could have just gone out and purchased the thing that does exactly what you want. The fact is, a) R&D is sometimes inescapable, b) R&D equals Risk, Embracing this reality is the first step towards not leaving it up to chance, and not gambling your entire budget and window of opportunity on one roll of the dice. Once you've decided NOT to do that, what do you do instead?

Every engineered product requires hundreds or thousands of individual design decisions to be made. Most, hopefully, have an established basis for the decision - ie the design choice is "established" by prior art as the right one for the context and for the requirements. But if there is anything at all novel about the product under development, and there ought to be, many key design decisions won't have a basis in prior art. How do you make a decision when there is no establishing art or other information telling you how to achieve the required outcome?

The sort of engineering I trained in focuses on doing exactly that. It included analysis, modelling, simulation, and experimentation on design scenarios presumed never before attempted. And that leads to new technology. This is the practice of Engineering as an Applied Science.

But sometimes it doesn't work. Sometimes the best laid plans go awry, and the Applied Science of human-made systems, materials and objects throws a surprise at you that no one could anticipate. Yes, there is occasionally new physics that emerges within non-naturally-occurring systems that no one ever studied before, within the boundaries of the laws of natural physics, of course. But quite often, it's more the case that despite our best efforts, training, and diligence, our predictions are just off and things don't quite work how we'd like them to.

This is a fact of engineering that must be accommodated when planning and undertaking product development initiatives. This is where we acknowledge the existence of risk, embrace the possibility of failure, and take deliberate steps to steer the project away from that real possibility. Here are those steps.

1. Identify and list your Assumptions. This requires a knowledgeable and self-aware engineer with broad experience to know what elements in the design are established by prior art, and which ones are perhaps going a bit out on a limb. Just because you assume it should work, doesn't mean it will. Until demonstrated under real conditions, it is "just a theory" (actually, a Hypothesis). Note that "element" in this context means some identifiable single or composite aspect of a design: a dimension, a size, a position, a material selection, a fastener, a geometric configuration; a line of code, an algorithm, a component (sensor, actuator, etc), or a process step. Elements "influence" the "outcomes," i.e. they contribute to determining what the technology does and how well it does it. The engineer, knowing each element's influence, chooses elements and combinations of elements to produce a technology that meets the performance specifications. But if that influence is not known or is in any doubt, then we're making assumptions.
2. Rate the risk level of each assumption. Low: the element occurs elsewhere, but is used under slightly different conditions that might affect the way it influences the outcome. Medium: the element occurs under meaningfully different conditions likely to change its influence; or under a meaningfully more restrictive set of constraints that probably limits or alters its influence. High: the element occurs in other designs, but these do not now perform at the level required by a key metric in the specifications; i.e. that magnitude of influence has not been established. Extreme Risk: the element is seen elsewhere, but the kind of behaviour it is known to produce is qualitatively different to what is now required; i.e. that quality of influence has not been established. Ridiculous/Ludicrous Risk: The design element has never been used before and is entirely novel; no empirical information exists about the quality or quantity of its influence over any technology behaviour.
3. Invent a time-machine, go back in time and re-start the entire development initiative to first focus solely and to the exclusion of all other activity on the one highest risk level item of all design questions or elements. Alternatively, if you don't have access to a time machine, be an experienced R&D engineer able to anticipate upcoming design risks and accurately rank them. Do not spend any time or money on any lower risk-level items until the highest risk has been completely set aside. This is the entire fulcrum and substance and essence of successful R&D: isolate the highest risk, and gamble only the smallest possible fraction of the project's time and budget on eliminating that risk. If it can't be eliminated, cancel the project quickly and cheaply. If it can, document everything, then proceed to the next highest risk item.
4. Note that the highest risk levels have the potential to kill a project, since there might not be a solution to getting the outcomes and performance levels required in the specification, in the way proposed by the overarching design direction chosen for your project. The lower risk levels, on the other hand, almost always admit a work-around or alternative designs. This is what is meant by Fail Fast: if one key assumption has, if wrong, the power to kill a project, work on nothing else but that until the possibility of it being wrong has been eliminated.

How to do all that? This is the domain of Research Engineering and Applied Science: get qualified people on the team, then read, study, do analysis, and conduct controlled experiments. These experiments should have unambiguous yes-or-no outcomes. These are experiments that definitively show whether a design element possesses the necessary influence to produce the specified behaviour at the specified level of performance, or not.

There are no shortcuts; the only way through that doesn't take extraordinary, unwarranted and unaffordable risks is to follow the process. This is what experience has taught those who are masters of product development.