Mission
By the end of this chapter, you can connect an exact hardware-software baseline to supplier evidence, regional deltas, rollout waves, and field-recovery decisions.
- Measurable outcome: Produce an interface-and-rollout plan that connects hardware configuration, software compatibility, vendor evidence, regional readiness, field recovery, and decision rights; score at least 3 of 4.
- Prerequisites: Chapters 8, 11, 14–18, 25, 27, and 30.
- Work product: An Interface and Readiness Ledger plus rollout-wave recommendation.
- Time: 85–110 minutes.
Before you read: Predict → Commit → Connect
Northstar Devices has 40,000 units at a contract manufacturer. A firmware fix passes on the latest board revision, but 12% of manufactured units use an earlier radio module from an approved alternate supplier. Packaging starts tomorrow.
Predict the decision that must precede packaging. Commit to the evidence you need. Connect to Chapter 11: technical maturity is not a property of “the product”; it is evidence tied to a configuration and intended environment.
Physical programs make configuration unavoidable
Software can often be redeployed. Hardware lead times, manufacturing commitments, logistics, certifications, and field access make some decisions slower or irreversible. The system baseline must therefore identify compatible versions of hardware, firmware, mobile app, cloud service, manufacturing test, security keys, documentation, packaging, and regional configuration.
“Firmware 8.4 passed” is incomplete. Passed on which board, component lot, bootloader, radio module, test fixture, cloud API, mobile version, language, power condition, and region? A globally launched device is a family of configured systems, not one object.
Configuration management is not document hygiene. It lets the program answer which evidence applies to which shipped population and what recovery is possible. Without it, incident scope becomes guesswork.
Manage suppliers by interfaces and evidence
A contract does not integrate a supplier. Define the technical and operational interface: specification, tolerances, samples, test method, change notification, defect classification, traceability, capacity, lead time, business continuity, security expectations, escalation, data exchange, and acceptance authority.
Supplier status such as “green” can hide different realities: design complete but production process immature; parts built but not certified; capacity reserved but dependent on one sub-tier supplier. Ask for evidence at the level that determines your next decision.
NIST SP 800-161 Revision 1 treats cybersecurity supply-chain risk as a lifecycle concern involving products, services, and suppliers. A TPM should connect security provenance and vendor change control to the same program baseline used for quality and schedule, rather than operate a separate compliance spreadsheet.
Map sub-tier and single-source dependencies where material. You may not gain full transparency, but uncertainty itself belongs in the risk model. Create options early: alternate part qualification, allocation rules, design substitution, inventory buffer, regional sequence, repair path, or scope reduction. Late “expediting” cannot recover every physical lead time.
Global rollout is not translation plus shipping
Regions differ in regulation, radio certification, privacy, taxes, payments, accessibility, language, support hours, connectivity, power, logistics, returns, data residency, and customer expectations. Use a common global core with explicit local deltas. Avoid assuming that the first region proves every other region.
Rollout waves should balance risk with learning value. Start with a population that is bounded enough to recover yet representative enough to test the system. Define wave entry, hold, expansion, and rollback/recall criteria.
For Northstar, packaging is a commitment because reopening units is costly and may destroy traceability. The program should quarantine the earlier radio-module population until compatibility evidence exists or package configurations separately with an approved remediation plan.
Field recovery is part of architecture
Before shipment, decide how to identify affected serials, revoke credentials, stop activation, update firmware, enter safe mode, support offline devices, replace hardware, notify customers, coordinate regulators, and process returns. Test degraded connectivity and interrupted updates. A remote-update feature that fails during the exact defect it must repair is not recovery evidence.
Keep the ability to segment by hardware lot, supplier, region, firmware, and activation state. Privacy and retention requirements still apply; collect only identifiers needed for justified operational purposes with governed access.
Decision rights: Who owns what?
- Systems/Hardware/Software Engineering owns specifications, design, interfaces, compatibility, and technical evidence.
- Manufacturing/Quality owns production-process controls, lot acceptance, nonconformance, and traceability.
- Supply Chain/Procurement owns commercial supplier management and continuity options with technical input.
- Regional Legal/Compliance/Privacy owns interpretation of local obligations.
- Operations/Support/Logistics owns field processes, spares, returns, and recovery execution.
- Product/Business owns market sequence and customer value trade-offs.
- The TPM integrates baselines, supplier interfaces, regional deltas, long-lead decisions, wave evidence, and field-recovery readiness.
I do
I create a decision row for the alternate radio module:
- affected serial/lot population;
- design and supplier change records;
- firmware compatibility test matrix;
- radio, thermal, power, security, and interrupted-update evidence;
- regional certification impact;
- packaging segregation and field identification;
- decision authority and quarantine release criteria.
I recommend hold that configuration, not the entire launch, while preserving evidence-based separation.
We do
The alternate module passes all functional tests but draws more power during weak-signal retries. The difference appears only in a rural network simulation and may reduce battery life below the marketing claim.
Together decide whether this is a defect, a regional limitation, or an acceptable variation. Name the additional owners needed.
Show the model answer
Model answer
Treat it as a configuration-specific product and compliance decision, not merely a component test. Quantify affected use conditions, battery impact, claim/certification implications, and population. Product, Systems Engineering, Quality, regional Compliance, and Support must decide whether to redesign, limit regions, change the claim, or accept a bounded variation. Preserve lot traceability and a field response. Functional pass does not validate the promised use experience.
Rubric (0–4)
- 0: Ships because functional tests passed or cancels without analysis.
- 1: Requests more battery testing but ignores configuration/region.
- 2: Quantifies impact and options but lacks decision rights or field plan.
- 3: Integrates use condition, claim, region, traceability, authority, and recovery.
- 4: Also considers supplier change control, sub-tier recurrence, and evidence for future lots.
You do
Build an Interface and Readiness Ledger:
| Interface/configuration | Provider | Consumer | Contract/tolerance | Evidence by version/lot | Change-notice rule | Regional delta | Recovery | Decision owner |
|---|---|---|---|---|---|---|---|---|
| Radio module ↔ firmware | Supplier/Firmware | Device system | Timing, power, driver | Test matrix by lot | 90-day notice + requalification | Certification list | Quarantine/update/replace |
Add three rollout waves. Each needs a representative purpose, entry evidence, exposure, observation duration, stop trigger, and field-recovery capacity. Include one supplier failure and one regional hold scenario.
Pause & Recall
Without looking, name six elements of the system baseline. Recall Chapter 15: why can a supplier notification period be on the critical path? Recall Chapter 25: what operational evidence is needed before field exposure? Recall Chapter 27: how would lot traceability change incident containment?
Production lens
Track actual-as-built and actual-as-maintained configurations, not only intended design. Reconcile supplier shipments, manufacturing records, activation, and field updates. Audit emergency substitutions; schedule pressure makes “temporary” components durable. Include vendor access and data in incident, privacy, and offboarding plans.
Workplace artifact: global rollout wave recommendation
Copyable wave recommendation
Release [configurations/lots] to [regions/population] as Wave [N]. Evidence applies to [exact baseline] and demonstrates [claims]. Excluded configurations are [scope/reason]. Observe [signals] for [duration]; hold at [trigger]. Field recovery capacity is [update/quarantine/replace/recall]. Expansion authority: [role/forum/date].
Chapter compression
Hardware-software delivery depends on exact configuration, supplier interfaces, long-lead options, regional deltas, and field recovery. Manage proof by version and lot. Roll out in representative, recoverable waves. A contract or functional test alone does not establish integrated readiness.
Retrieval deck
- Q: Why is configuration a program-control concept? A: It determines which evidence, risks, and recovery paths apply to each shipped system.
- Q: What does a supplier interface include beyond specification? A: Evidence, tolerance, change notice, traceability, capacity, continuity, escalation, acceptance, and security obligations.
- Q: What makes a rollout wave useful? A: It is bounded and recoverable yet representative enough to answer a stated question.
- Q: Why plan field recovery before shipment? A: Physical access, traceability, permissions, spares, and update paths constrain later options.
- Q: What does the TPM own? A: Integration across baselines, suppliers, regions, waves, and recovery, not every specialist decision.
Spaced review
- Now: Name the exact configuration and population supported by current evidence.
- +1 day: Redraw the system baseline from memory.
- +3 days: Add a supplier change-notice and field-recovery path to one interface.
- +7 days: Trace one component from sub-tier source to field population.
- +14 days: Compare intended, as-built, and field-maintained configurations for one batch.