EROM Chapter 3, Part 1: Objectives Hierarchies, Risk Tolerances, and Parity Statements

Book: Enterprise Risk and Opportunity Management: Concepts and Step-by-Step Examples for Pioneering Scientific and Technical Organizations
Author: Allan S. Benjamin
ISBN: 9781119288428

Chapter 2 laid out where EROM sits inside a TRIO organization and how it connects to federal compliance. Chapter 3 gets into the mechanics: how you actually run the analysis. This first installment covers sections 3.1 through 3.3, which are the foundation everything else rests on.

Why objectives hierarchies come first

You cannot rank risks in a vacuum. Benjamin’s whole framework starts with a tree of objectives, built separately for each management unit and then stitched into an enterprise-wide view.

At the executive level, strategic planning produces long-horizon goals (typically 10+ years), top programmatic objectives (5 to 10 years), and top institutional/technical objectives that support both. Program directorates break programmatic objectives into mid-term performance goals (1 to 5 years) and short-term annual goals. Federal agencies call the high-priority ones agency priority goals. Benjamin uses generic labels so the same structure works for NASA, a defense lab, or a contractor.

Technical centers mirror that breakdown. Each center maintains institutional capabilities and takes technical responsibility for programmatic success. The objectives cascade down the same way: top objectives from the executive level, then mid-term, then short-term.

Once every unit has its hierarchy, you combine them into one enterprise picture. The dashed arrows in Benjamin’s diagrams represent interfaces between units. Those interfaces matter because they explain how a slipped milestone in one program can ripple up to a 10-year strategic objective. Tables and templates capture those interactions better than org charts alone.

Populating the hierarchy with risk and opportunity

Here is where EROM earns its keep. For every objective in the hierarchy, the team produces a cumulative risk (likelihood of failure under the current plan) and a cumulative opportunity (likelihood you can improve the plan based on future developments).

The process follows six steps, and the same six steps apply whether you are planning or evaluating performance:

1. Identify individual risks and opportunities affecting each objective.
2. Attach leading indicators to gauge significance and trend status over time.
3. Set trigger values based on stakeholder risk tolerances and opportunity appetites.
4. Determine current indicator status (value plus trend).
5. Roll up indicator statuses to cumulative risk/opportunity ratings per objective.
6. Roll up those ratings across the hierarchy, including cross-objective influences.

During planning, risks come from historical experience because designs are immature. During performance evaluation, you base them on actual architectures and designs.

One detail that caught my attention: opportunity entries can include introduced risks. Pursuing a new technology opportunity might bring first-of-a-kind uncertainties and development costs. EROM tracks both sides of that trade.

Risk tolerances, appetite, and parity

Before you set trigger values, you need the stakeholder posture. That means eliciting risk tolerance and opportunity appetite for each objective. Top-level tolerances often roll up from lower levels, adjusted for response time frames.

Benjamin introduces parity statements to make apples-to-apples comparisons possible. Each parity statement reflects an equal level of pain (for risks) or gain (for opportunities). Five hypothetical examples in the book are treated as equivalent trade-offs:

• Doubling mission failure probability from 10% to 20%
• Slipping a target date by ΔY years
• Increasing total mission cost by 10%
• Decreasing total cost by 20%
• Gaining flexibility to repurpose the system for a different mission

The point is strategic: if boundaries are commensurate in pain and gain, decision makers can weigh a schedule slip against a cost overrun against a new-mission option without talking past each other.

Watch boundaries vs. response boundaries

Stakeholders get two thresholds, not one:

• Response boundary: exceed this and action is imminently needed. Risk is intolerable; opportunity is significant.
• Watch boundary: exceed this but stay below the response line and you are in marginal territory. Trend it and report at reviews, but no immediate response required.
• Below the watch boundary: risk is tolerable, opportunity is insignificant.

This two-tier system prevents every yellow flag from triggering a fire drill while still forcing attention on things that are drifting toward trouble.

What this sets up

Sections 3.4 through 3.6 (covered in the next post) build on this foundation: scenario statements, leading indicators, trigger values, roll-ups, drivers, and response options. Chapter 4 then turns the whole pipeline into fill-in templates using the James Webb Space Telescope as a worked example.

Benjamin also notes that introduced risks travel with opportunities in the roll-up. If a center identifies a technology upgrade path, the planning team should log the first-of-a-kind costs and failure modes that path would add. Skipping that step makes opportunity portfolios look rosier than they are.

The through-line is consistency. Same objectives tree, same tolerance language, same roll-up logic whether you are at a center, a program directorate, or the agency executive suite. That is what makes enterprise risk management more than a pile of program-level risk registers. Chapter 2 described the org wiring; this chapter describes the signal that flows through it.

← Previous: EROM Chapter 2, Federal Compliance and Partnerships · Next: EROM Chapter 3, Scenarios, Indicators, and Responses →