It is hour four of a design review. After a tense discussion, a slightly defensive member of company leadership says, "It's never too late to do the right thing". The venerable reviewer across the table sighs at this and mutters, "Would that that were true..."

What we do in the space industry is inherently risky. Most startups fail¹. Most space startups fail years before they run out of money due to defects that are baked into the way that they operate, many before they launch a single vehicle. Though launch is by no means a guarantee of mission success². Exposing the defects a program is carrying before they cause problems is a core feature of an effective risk management capability.

By necessity, we develop systems in a completely different environment from where they are deployed and operated. Risk management allows us to systematically and consistently deploy resources so that the only things left to chance are those truly outside our control. This article lays out a simple, immediately deployable risk management framework that doesn't require a giant binder or a full Class A NASA process.

We are so used to consumer electronics "just working" in our daily lives so it's easy to forget the amount of effort that goes into development and failure recovery. That engineering and failure recovery effort is amortized over 10,000-10,000,000 units³; costs that virtually no space program can distribute in the same way. In space, the lowest band of that production range is on the horizon, but I'd wager the median quantity produced across all unique space hardware configurations operating today is in the low single digits⁴.

The long development cycles on these systems⁵ and vast and varied engineering knowledge bases required to develop them make managing space-system development difficult. Engineers that are proficient in their respective disciplines are both useful in the development of these systems and at identifying the likelihood of specific problems arising in the context of that program. A lightweight risk process channels that intuition into a structure the whole program can act on.

Risk management is baked into the canon of space mission development⁶, but is often applied poorly and as an afterthought. Many programs throw together some risks for a risk slide as a design review deliverable that won't get updated until a few days before the next design review. That makes it feel like busy work for whoever is putting it together because, for the person stuck with putting risks together only to check a box in the review, it is. Risk management done once per quarter is not risk management; it's theater.

Like other abstract and preventative engineering endeavors (systems, quality, etc.), risk management is nearly invisible when it's working well. But for it to work at all, it must be tailored to the mission, team, and company culture that's deploying it.

A well-run Risk Management effort eliminates fear, uncertainty, and doubt (FUD) by aligning the team to the risk approach that should have been explicitly set at the beginning of the program.

NASA defines risk as “the potential for shortfalls with respect to achieving explicitly established and stated objectives.”⁷ Less generically, a risk is a future, uncertain event that could negatively impact the project if it comes to pass and is within your organization's ability to mitigate. Mitigation isn't prevention, but is some action undertaken to lessen the likelihood and/or impact of an identified risk. Likelihood is exactly what you'd expect, a percentage chance of the risk taking place. Impact is the quantifiable negative consequence that will be experienced.

Of all of the different types of risk, the two I'm going to focus on are Programmatic Risks and Technical Risks. Programmatic risks cover items that will prevent you from ever getting to launch. Technical risks are, once the spacecraft is launched, how will its performance (and thus capacity to provide a return on investment) be affected. The impact values associated with programmatic risks are schedule and cost. The impact values associated with technical risks are on the spacecraft's return. Degraded pointing knowledge of a vehicle will result in lower data throughput, which directly reduces mission return.

The typical "stoplight chart" heat map of risks that you see are populated by normalizing the likelihood and impact on scales of 1-5 (5 being most likely/mission ending). The values that correspond to each likelihood and impact need to be agreed upon at the start of your risk management effort. Strictly speaking, you don't need to use a 5x5 representation of your risks in order to manage them. The 5x5 grid is simply a common shorthand to avoid parsing dozens of long-form likelihood-impact descriptions.

Collecting risks from your team, assigning impact and likelihood values, and being able to look at them objectively is the first and hardest step. This is especially true if the program or company culture to date hasn't explicitly championed risk identification. From there, it's as simple as determining the threshold for unacceptable risks and triaging above that threshold.

Other useful risk metadata to capture:

Developing a culture of risk management can take time, especially for a new team. It takes trust, effort, and understanding. On the leadership side, it takes setting aside some time for your team to look at risks together (30 minutes, once a week).

In space missions, second chances are rare. Don't willfully ignore that nagging feeling. Give yourself and your team somewhere to openly discuss mission/program killers in an explicit and constructive way. Identify which potential issues your team has the power to mitigate, and apply your finite resources to burning those risks down systematically. If your team openly surfaces and burns down risks every week, design reviews stop being surprises and start being confirmations.

Further reading: