Risks, Assumptions, Issues, Actions, Changes, and Configuration

Mission

By the end of this chapter, you can classify program-control items correctly and trace them from uncertainty through decision, change, configuration, and verified closure.

• Measurable outcome: Classify program-control items correctly, state risk in decision-useful form, and operate an integrated lifecycle for risks, assumptions, issues, actions, decisions, changes, and configuration.
• Prerequisites: Chapters 13–17; one active program plan.
• Work product: A linked control record and change assessment for Northstar Devices.
• Time: 80–100 minutes.

Before you read: Predict → Commit → Connect

Predict: “The supplier may miss the sample date” and “the samples did not arrive” require different responses. Name them.

Commit: Write one assumption your current plan depends on and the date by which it must be validated.

Connect: Recall an action that stayed open for weeks. Was it a real action with an owner and due date, or a vague concern stored in the wrong list?

Use one control language

Programs lose information when every uncertain statement becomes a “risk” and every request becomes an “action item.” Use distinct types:

• Risk: an uncertain future event or condition that could affect objectives.
• Assumption: a proposition treated as true for planning despite incomplete evidence.
• Issue: a condition that has occurred and needs resolution.
• Action: a concrete next step with one owner and due or trigger date.
• Decision: an authorized choice that constrains future action.
• Change: a proposed or approved modification to a controlled baseline, commitment, scope, interface, or plan.
• Configuration item: an artifact or product element whose identity, version, and approved state must be controlled.

These items should link rather than live in isolated registers. An assumption can be tested and closed, disproved and converted into an issue, or remain uncertain and produce a risk. A realized risk becomes an issue. An issue creates actions and may require a decision or change. An approved change updates relevant configuration and baselines.

The diagram is a reasoning pattern, not a mandatory workflow. Some actions do not require changes, and some changes originate from opportunity rather than failure. The key is preserving traceability from signal to response and verified state.

State risk so somebody can act

A useful risk statement uses cause → uncertain event → impact:

Because the battery supplier's new cell has not passed the production thermal profile, samples may fail qualification, which could delay regulatory submissions or require a reduced regional launch.

Record probability and impact using locally defined scales, but do not let a score replace judgment. Include proximity, detectability, affected objective, owner, response, trigger, residual exposure, and the person authorized to accept it. Numeric multiplication can create false precision when inputs are subjective. Use ranking to focus discussion, then examine the underlying scenario.

Responses include avoiding the exposure, reducing likelihood, reducing impact, transferring or sharing some consequence, accepting within authority, or exploiting an opportunity. A mitigation must alter the risk: “monitor weekly” provides awareness but usually does not reduce probability or impact. “Qualify a second cell and reserve lab time by July 8” might.

Assumptions need owners too. An assumption log should say why the plan relies on the proposition, how it will be tested, by when, and what changes if false. The validation deadline is often earlier than the date the assumption would cause visible failure.

Control change without freezing learning

Change control is not bureaucracy for stopping change. It ensures that people understand and authorize consequences before a controlled commitment moves. Define what is controlled: outcome, guardrails, launch regions, architecture interfaces, approved budget, certification design, production configuration, or customer commitment.

Assess a proposed change across:

• intended benefit and urgency;
• outcome, scope, schedule, cost, and staffing;
• safety, privacy, security, compliance, quality, and reliability;
• interfaces, test evidence, documentation, support, and rollback;
• downstream commitments and configuration versions;
• options, including defer or run an experiment.

Match approval altitude to consequence and delegated thresholds. Low-impact reversible changes should move quickly. A material control or customer-impacting change needs the authorized owner.

Configuration management answers: What exact version is approved, deployed, tested, and recoverable? A program can approve a change yet fail in production because the build, model, firmware, policy, supplier part, runbook, or feature flag does not match the reviewed state.

Recurring case: Northstar Devices

Northstar assumed its new battery cell would behave like the engineering sample. The assumption had no validation date. When production samples failed a thermal profile, leaders called it a “new risk” even though the condition already existed.

The TPM converts it to an issue, links the original assumption, and records actions: failure analysis, alternate-cell qualification, regional certification impact, inventory exposure, and customer-date review. Engineering proposes a firmware power-limit change. That change may reduce heat but affect device performance and certification evidence.

The program assesses options: firmware limit, alternate cell, mechanical revision, or reduced launch region. Quality and Engineering own technical acceptance; Product owns experience trade-offs; Regulatory owns certification interpretation; the sponsor owns the material cost/scope/date choice. Approved firmware and hardware combinations receive explicit configuration identifiers, and the pilot gate checks that deployed combinations match the evidence.

Decision rights: Who owns what?

• Risk owner: owns response and monitoring; may accept only within delegated tolerance.
• Assumption owner: owns validation and consequence planning.
• Issue owner: drives resolution across linked actions.
• Action owner: delivers one concrete result by the agreed time.
• Change authority: approves, rejects, or defers a change within a defined class.
• Configuration owner: maintains identity, approved state, and reconciliation.
• TPM: maintains the integrated control system, challenges misclassification, connects impacts, and routes exceptions. The TPM does not personally accept another domain's risk or approve unowned technical changes.

I do

I audit the register and rewrite vague entries. “Supplier concern” becomes a cause-event-impact risk. “Samples late” becomes an issue. “Assume certification unchanged” becomes a dated assumption owned by Regulatory. “Discuss battery” becomes an action to present comparative thermal evidence by Thursday.

For the proposed firmware limit, I collect impact from Product, Engineering, Quality, Regulatory, Support, and Supply. I identify the decision owner and ensure the approved configuration, test plan, roadmap, and external promise change together.

We do

Together, classify this sentence: “We expect the privacy review to finish by August 1, and launch is planned for August 15.”

It is an assumption if the plan treats August 1 as true without confirmation. It creates a risk if review duration is uncertain and could prevent launch. If August 1 passes without approval, it becomes an issue. “Ask Privacy for status” is weak; “Privacy lead provides review disposition or missing-evidence list by July 25” is an action. Changing launch scope to exclude the affected data path is a proposed change.

You do

Take ten entries from a status report or invent a case set. Classify each as risk, assumption, issue, action, decision, change, or configuration. Rewrite three risks using cause-event-impact. Choose one assumption and define a validation test, deadline, false-case response, and owner. Complete a cross-domain assessment for one proposed change.

Pause & Recall

Without looking, define all seven item types. Turn “vendor delay” into a cause-event-impact statement. Connect to Chapter 17: which assumption, if false, moves your reference scenario into the adverse scenario?

Production lens

Review control items by exception and transition, not by reading every row aloud. Look for assumptions past validation date, issues mislabeled as risks, actions with group owners, mitigations that only monitor, accepted risks without authority, approved changes not reflected in tests, and deployed configurations that differ from evidence. Preserve history; do not overwrite the original forecast or decision rationale.

Workplace artifact: Integrated program-control record

ID / type:
Statement and affected objective:
Owner / acceptance authority:
Evidence and source:
Probability, impact, proximity, or severity:
Response / action / due date:
Trigger or validation deadline:
Linked decision and change:
Configuration / baseline affected:
Residual exposure and approver:
Status / closure evidence:

Chapter compression

Distinct control items demand distinct responses. Link assumptions, risks, issues, actions, decisions, changes, and configurations into one traceable system. State risk as cause-event-impact, validate assumptions before they become failures, and reconcile approved change with the exact implemented state.

Retrieval deck

• Q: When does a risk become an issue? A: When the uncertain event or condition occurs.
• Q: What must an assumption record include? A: Owner, why the plan relies on it, validation method and deadline, and consequence if false.
• Q: Why is “monitor” usually not mitigation? A: It may improve detection but does not necessarily reduce likelihood or impact.
• Q: What does configuration management add to change control? A: Proof of the exact approved, tested, deployed, and recoverable state.
• Q: Who accepts residual risk? A: A person with explicit authority for that domain and level of exposure.

Spaced review

• Now: Define all seven control-item types without looking.
• +1 day: Classify seven fresh program statements.
• +3 days: Rewrite two risks as cause, uncertain event, and impact.
• +7 days: Audit assumptions past their validation deadline.
• +14 days: Reconcile one approved configuration with test evidence and deployed state.

Sources and further study

• NIST: Guide for Conducting Risk Assessments, SP 800-30 Rev. 1
• NASA: Crosscutting Technical Management
• PMI: PMBOK Guide
• GAO: Technology Readiness Assessment Guide