Chapter 5: EROM at Technical Centers and Directorates
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 4 walked through templates on a single project. Chapter 5 zooms out to the institutional layer: the technical center or directorate that owns programs, preserves core competencies, and juggles a web of partners that never quite fits on one org chart.
Two hats, one center
A technical center in a TRIO enterprise wears several hats at once. It may manage assigned programs. It may contribute expertise when another center leads. It maintains mandated core competencies in workforce, facilities, and institutional knowledge. It answers special requests from the federal government or other sponsors.
When the center is in program-manager mode, EROM’s job is integration: pull risk and opportunity inputs from every contributor, handle cross-cutting items consistently, roll them up correctly, and coordinate mitigations. When the center is in institutional mode, EROM shifts to asset stewardship: optimize how human, physical, and instructional resources are acquired, allocated, and retired.
Those are different problems. Benjamin treats both as first-class citizens.
Extended enterprises are not one company
The James Webb Space Telescope is the chapter’s anchor example. Goddard manages the project, but the extended enterprise spans multiple NASA centers, industry primes, universities, and international agencies. Each entity has its own strategic objectives. Success depends on communication protocols that share enough information to integrate work while respecting proprietary boundaries.
Benjamin calls the full set of entities a center interacts with its extended organization. That includes program partners plus TRIO headquarters, mission directorates, institutional oversight, and review boards. A single NASA center sits inside many overlapping extended enterprises at once.
What struck me: EROM at this level is as much diplomacy as analysis. You are not just scoring risks. You are aligning independent enterprises that only partially share incentives.
Governance: working groups and management boards
For multi-partner programs, Benjamin recommends an EROM team per extended enterprise. That team owns the overall risk management plan, finds interface risks that span organizational boundaries, does preliminary likelihood and impact analysis, and assigns ownership. If the owning entity lacks authority, the item escalates.
The organizational pattern is deliberate:
- R-O working groups at each entity identify and analyze risks, recommend controls, and meet with peer working groups on a schedule set by the program.
- R-O management boards prioritize items, choose responses (accept and watch, add controls, mitigate, close-out), assign owners, and meet across entities to adjudicate shared concerns.
The goal is buy-in. Every entity should have technical representation in a working group and/or managerial representation on a board. Informal technical conversations between scheduled meetings are expected, not an afterthought.
Integrated databases, with pragmatic exceptions
Chapter 4 already argued for integrated EROM databases wherever entities must coordinate. At the extended-enterprise level, the database should hold templates, owners, involved entities, working groups, boards, change plans, history, and status.
Reality intrudes. Some partners keep their own process and will not abandon it. Some lack network connectivity and may upload weekly snapshots. Some worry about proprietary data and maintain a private database while still entering program-level risks into the shared system.
Benjamin does not treat these as failures. They are negotiated exceptions. The point is that cross-cutting oversight still needs a common roll-up path, even when local detail stays local.
Right-sizing human, physical, and instructional assets
Institutional EROM asks a blunt question: does the center have the right people, facilities, and governing documents to meet inherited strategic objectives across near term (~1 year), mid term (~5 years), and long term (~10 years)?
Human assets get tracked numerically. Templates count experienced personnel (EPs) by skill area, skill level (1 through 5, from entry-level to expert), and contributing entity. A cryogenics shortage at the prime contractor is not an HR footnote. It can be a schedule driver.
Physical assets (test facilities, IT systems, equipment) are described qualitatively against center needs. Capability and availability only matter relative to objectives. A facility that can test small components is irrelevant if the center only needs full-system testing.
Instructional assets (policies, standards, guidance) are also qualitative and time-phased. Partners’ documents must stay aligned as missions grow more complex or new technology appears.
Asset risks have their own scenario grammar
Program performance risks are one category. Asset risks are another. Funding cuts can drive talent away. Schedule extensions can amplify retirement cliffs. Market competition can poach specialists. A partner’s financial trouble can hollow out a critical skill base. Facilities can shut down after accidents or lose availability when another program gains national priority.
Benjamin extends the standard scenario statement format for assets:
Given current conditions and trends, there is a possibility that [departure event] may occur, affecting the [availability, capability, and/or content of specified assets], resulting in a noteworthy decrease or increase in the center’s likelihood of meeting [specified objectives].
The variants matter. An event might reduce available skilled people, or increase how many skilled people you need, or degrade a facility you own, or reveal you need a facility you do not have. Different mechanisms, same outcome: a gap between assets on hand and assets required.
Leading indicators and the optimization loop
Workforce health indicators draw from NAPA’s NASA recommendations: median age, uncovered FTEs, hire ratios, training participation, turnover, and employee survey results. Physical asset health might track facility age, maintenance history, test scale factors, and cybersecurity gaps.
The powerful move is correlation. Benjamin walks through a JWST cryogenics example: a projected shortage of level 4-5 cryogenic engineers at the prime contractor tightens integration schedule margin, which rolls up to intolerable risk against top objectives like “discover how the universe works” and “maintain a skilled diverse workforce.” The workforce template entry and the schedule leading indicator are explicitly linked.
Optimization becomes iterative:
- Identify objectives, risks, opportunities, and leading indicators (Chapter 4 machinery).
- Propose an asset allocation plan within cost constraints.
- Evaluate effects on leading indicators.
- Roll up to top-level objectives.
- Price the plan.
- Adjust until risk cannot be reduced further within budget, opportunities cannot be captured further within budget, or cost cannot drop without unacceptable risk/opportunity tradeoffs.
The same loop applies, with less iteration, when choosing among candidate prime contractors or suppliers.
What I took away
Chapter 5 is where EROM becomes institutional strategy. Technical centers are integrators sitting inside multiple extended enterprises, each with partially overlapping objectives. The templates from earlier chapters still apply, but the unit of analysis expands to workforce categories, facility capability statements, and policy corpora that age on different clocks.
If you run a research center or defense lab, this chapter answers who owns risks between organizations and how you budget the people and infrastructure that make partnership possible.
← Chapter 4: Templates and Roll-Up Database · Chapter 6: Commercial TRIO Enterprises →