The “Green Program” That Wasn’t
Three months before formal verification, the program review looked exactly as leadership would hope. Every major workstream was green. Milestones were holding. No critical issues were open. The dashboard signaled control.
The first full round of testing told a different story.
Multiple failures traced back to a sealing design assumed to perform under thermal cycling but never tested under representative conditions. The assumption had been embedded for months in design decisions, supplier discussions, and downstream dependencies. It was never framed or tracked as a risk.
The dashboard did not miss the signal. The signal was never part of the system.
Most executive dashboards fail for the same reason. They track evidence of progress. Real risk lives in uncertainty.
Dashboards Track Progress, Not Truth
Executive dashboards are built to answer familiar questions. Are we on schedule? Are we within budget? Are issues being resolved?
The underlying metrics reflect completed work, milestones achieved, tasks closed, issues logged and cleared. These indicate activity and coordination, but not whether the product will perform as expected.
Because dashboards emphasize completed work, they miss the conditions that exist before failure is observed. The structure favors what is known and resolved, not what remains uncertain.
How Risk Actually Develops
Risk does not arrive as a discrete event. It develops through a predictable pattern.
An assumption is made, often implicitly. Work progresses as if it is true. Other teams build on it. Dependencies form. Validation is deferred due to schedule pressure or immature test methods. Eventually, the assumption is challenged. When it fails, it is no longer isolated. It is embedded.
The highest-impact risks are created early, remain invisible midstream, and surface late.
Dashboards typically engage at the point of failure. By then, the program is reacting rather than managing.
The Risk Register Is Underused
Most organizations already have a mechanism to capture uncertainty: the risk register. The issue is not the absence of a tool. It is how the tool is used.
Risk registers are often filled with known issues, compliance-driven entries, or broad statements that are difficult to act on. What is frequently missing are the assumptions driving the program forward.
A more effective approach is to capture assumptions as risks before they are validated:
- Frame risks as conditions that must be proven
- Define paths to validation, not just mitigation
- Identify dependencies that rely on the assumption
Examples are straightforward. A supplier must hold a ±0.02 mm tolerance at production volume. A control algorithm must remain stable across edge conditions. An adhesive bond must maintain strength after accelerated aging and humidity exposure.
These are often understood but not formally tracked.
When assumption-based risks are included and actively managed, the risk register becomes forward-looking. It reflects where the program is uncertain, not just where it has already encountered difficulty.
Confidence Must Be Tied to Evidence
Most dashboards compress complex reality into simple signals. A workstream is labeled green because it is believed to be on track. That belief is not always grounded in proof.
A more reliable approach is to express confidence in terms of evidence:
- High confidence supported by representative testing or production data
- Moderate confidence based on partial validation
- Low confidence based on analysis or expectation
Each level must be tied to specific evidence. If the evidence does not exist, the confidence should reflect that reality.
This shifts the conversation from status to proof. The question becomes what evidence supports the belief.
Programs that make this shift begin to separate assumption from demonstration. That separation is where risk becomes visible.
Executive Engagement Shapes What Gets Reported
Dashboards reflect behavior as much as data. If reviews focus on status, teams optimize for status. If leaders probe for evidence and uncertainty, teams surface both.
Effective questions include:
- What must be true for this plan to hold?
- Which assumptions have not been tested?
- Where are we relying on analysis instead of evidence?
- What failed in early testing?
- Where is confidence lowest?
These questions create space for uncertainty to surface early.
This is a shared responsibility. Executives must ask better questions. Program leaders must connect technical reality to decisions. Teams must expose assumptions rather than protect status.
When these behaviors are consistent, dashboards begin to reflect reality rather than progress alone.
Evolving the Dashboard Without Replacing It
Most organizations do not need new dashboards. They need to elevate the right inputs.
Useful adjustments include:
- Highlighting assumption-based risks from the risk register
- Expressing confidence levels tied to evidence
- Making incomplete validation visible
- Tracking how long critical risks remain unresolved
- Tracking time-to-resolution
At the same time, aggregated status indicators and percent complete metrics provide limited insight without context.
The goal is not more reporting. It is more relevant reporting.
Make Risk Visible Early or Pay for It Late
Risk does not appear suddenly in testing or at launch. It accumulates through untested assumptions and deferred validation. Dashboards that do not reflect this dynamic will continue to signal progress while risk grows beneath the surface.
The shift is structural and behavioral. It requires using existing tools effectively, grounding confidence in evidence, and engaging directly with what is not yet known.
If programs elevate assumption-based risks within their existing risk registers, tie confidence to evidence, and actively engage uncertainty across all levels, then risk becomes visible earlier, decisions improve, and costly late-stage surprises are significantly reduced.
Free Risk Visibility Assessment
If your program dashboards consistently show progress but issues continue to surface late, the problem may not be execution. It may be how risk is defined, surfaced, and connected to decision-making.
A65 works with leadership teams to improve risk visibility by aligning program governance and tying confidence to evidence across Engineering, Manufacturing, and Quality.
If you would like an objective review of how risk is currently managed in your programs, we welcome the conversation.
Email: sdonnigan@a65consulting.com
Or schedule your review online
References
Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.
International Organization for Standardization. (2019). ISO 14971: Medical devices — Application of risk management to medical devices.
International Council on Systems Engineering (INCOSE). (2015). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (4th ed.).
Ulrich, K. T., & Eppinger, S. D. (2015). Product Design and Development (6th ed.). McGraw-Hill Education.
Leveson, N. (2011). Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press.