Objects Impacted and Modular Architecture

It's critical to capture the objects impacted by a risk in order to understand risk exposure, as well as take a modular approach to architecture to enable faster product evolution.

Why make the effort to identify the objects impacted by a risk?

In Risk Analysis, we accomplish two important things: first we work to understand the severity of a risk; and then, set ourselves up to mitigate it. So why make the effort to identify the objects impacted by a risk during this process? Because identifying objects impacted helps us achieve both of these goals.

What does objects impacted mean?

I define objects impacted as simply -- parts, subsystems, documents, and deliverables which might need to change as the risk driver questions are answered. Objects impacted is most easily applied to technical, design, and manufacturability risks - those that impact any component’s design or production process.

In the last post we used the example of a hand-held device. We identified risk drivers such as, "How hot does it get?" and "How hot is too hot?" In evaluating objects impacted, we ask and answer (as best we can) the question, "What would we change it if it is too hot?" We’d probably change the housing to dissipate the heat, and maybe the circuit board or another internal component that is generating the heat, if we can.

Generally, the directly impacted objects have ripple effects on other objects. Take this arthroscopic camera for example:

Screen_Shot_2016-08-01_at_1.39.32_PM.png

If drastic changes are needed to the housing to dissipate heat, we may also need to change how the cable connects to the back, or how the accessories (black parts) connect in the front. It is important to recognize when we may need to change these additional parts as well, and it is important to recognize it early.

Documenting the objects impacted looks like this:

Objects Impacted:

Body (6 weeks)
PCBA (4 weeks)
Cable (12 weeks)
Accessories Mounts (6 weeks)

Why capture objects impacted?

When asking, “Is this risk a high, medium, or low?,” it is generally easy for people come up with a gut-feel answer. But the question is why? e.g., What makes a high risk high? Ultimately, a high risk is one where many objects are likely to be impacted or the objects impacted have long lead times.

Rather than doing this analysis in the back of our minds, we recommend making it clearly visible. It only takes a minute or two, but communication and documentation can shine a light on two important things.

First, communicating and documenting the objects impacted provides a standard, objective and reasonably accurate way to quantitatively assess the impact of the risk. Second, modularizing architecture can significantly accelerate product development.

Reason #1: What is the impact of the risk?

The risk’s impact is the amount of cost (usually in schedule delay and associated cost of delay), that we would realize if we did not mitigate the risk. In our example, it is the delay we’d incur if we do nothing and realize in some later test that the product is too hot, and we have to reduce that heat before we can launch.

If our solution to a heat issue is to change the design, and thereby impact the housing and circuit board, then the delay we incur, the impact of the risk, will be the time it takes to: define the design change, update the drawings, order and receive new parts, build them into units, and, test again that the solution has worked.

In other words, it is the time it takes to procure the longest lead time part, plus a few weeks for the design/document update, build, and test steps. The length of these steps can often be standardized – 3 weeks, for example. Then the impact of the risk is the maximum lead time of the impacted objects + 3 weeks.

Granted, when we need to buy another round of parts anyway because we found the heat issue in mid-project testing instead of late-project testing, the actual impact is the time required for the additional mid-project design/discuss/decide work to solve that issue PLUS the residual risk. The residual risk is usually the big part.

The residual risk is the impact (times the likelihood) of needing to do it again (and again) if we didn’t really solve it right the next time, PLUS the impact (times the likelihood) that we created other problems we’d have to solve before launch. Because the residual risks are substantial, and can be several iterations long an objective, happy medium is to just consider a single design-order-build-test iteration in evaluating the impact of a design risk.

This impacted object maximum lead-time approach corresponds well to our gut-feel high/medium/low approach, but has added benefits, in that it can drive risk mitigations that can be executed right away. Sometimes at very little time and cost.

Reason #2: Modularizing architecture speeds up development

Don Reinertsen does an excellent job of describing how modularity in our product architectures can help speed development, especially if we modularize in the ’high risk areas’. Please see his book, "Managing the Design Factory," for his overview.

I’ll summarize here by first defining modularity. There are a couple primary connotations to it. One is the ability to interchange, mix and match, and share ’modules’ across several different applications.

The second, and the one most pertinent to risk management, is that it reflects the ability to change one part of the design without any ripple effects across the rest of the design. The opposite of a modular design is a tightly integrated design, where changes are very likely to impact many other areas of the design.

Modular architectures, as opposed to tightly integrated architectures, enable faster iterations. We can change one area and procure a few parts, without needing to change lots of other areas and procure lots of other parts, too.

In our risky areas, more iterations are needed in order to learn everything and work out the kinks. If we want to deliver quickly, each iteration must be faster. Therefore, we want to modularize in risky areas.

When we capture the objects impacted by a risk, modularizing in the risky areas amounts to finding ways to get some of the impacted objects off the list, especially the longest-lead objects.

In our arthroscopic camera example, the cable in the back is a very long lead item, 12 weeks compared to the next longest item, the housing, which takes 6 weeks. If we have to change the cable design late, we will suffer a 6 week longer delay than if we don’t need to change the cable.

To get the cable off of the impacted objects list, and eliminate up to 6 weeks worth of the risk right away, we might be able to design that interface with enough design margin that the housing can change without needing to change the cable.

Or, perhaps the change we foresee on the circuit board that generates the heat would require an additional conductor in the cable. We could get the long-lead cable off the impact chain by adding an extra conductor or three, just in case we need them later, for this risk or any others.

Modularization results in much faster projects

Modularizing in risky areas is often a natural part of design, in those really obvious areas where modularization is relatively easy. However, it is easy to miss opportunities to modularize in the non-obvious areas. Capturing objects impacted as part of the risk management process, and dedicating a little time (and sometimes money) to getting some of them off the list, makes these powerful mitigations-via-modularization a visible and standard part of the risk-management process, which results in much faster projects.

There is a lot more I could go into about how and where to modularize, and the downsides of modularity (increased unit cost, usually), but I’ll refer you to Don’s book.

Are impacted objects always components?

The example above describes the natural ways we can capture objects impacted and leverage that information in analyzing and mitigating design-impacting risks. However, sometimes the ’objects’ aren’t necessarily components in our design.

Note, in my definition of objects impacted that I recommend including documents and other deliverables. These documents/deliverables include test protocols, instructions for use, regulatory approvals, requirements documents, and more.

There isn’t any need to list the documents directly related to producing the physical parts and subsystems. These impacts are implied by naming the part or subsystem impacted. For example, if eliminating the heat risk might be too difficult to do through design changes, perhaps the instructions for use, requirements, and regulatory submission documents will need to be changed to reduce the continuous operating time and allow time for it to cool off.

Surfacing impacted documents and deliverables can help drive discussions about whether those impacts are acceptable. It can help determine the exposure of the risk when the cost may be in the form of reduced sales volumes. These considerations help establish the exposure of the risk and how much we should be willing to spend on mitigation. This is one of the goals of risk analysis.

In the next post, we’ll take the next step in risk analysis – evaluating risk exposure (the high/medium/low-ness of the risk). Stay tuned...

Download a free risk management template to get you and your team started.