Mission Engineering 12: Scaling from One Cup to Ten — What Carries Over to Complex Delivery?

Scaling from One Cup to Ten: Reconfirm Goals Before Multiplying

The article opens with a family request: "Can you make coffee for ten friends this weekend?" The author notes that simply copying the single-cup plan ten times fails because the same kettle, scale, and operator cannot be in ten places at once. The core lesson: before scaling, you must reconfirm who needs what , what counts as on-time (sequential vs. simultaneous service), actual resource capacity (shared kettle, scale, counter space), what can change (adding equipment, altering sequence), and what records to keep for this run and for future comparison.

Who needs what: Each person's requirements and confirmation status; cannot assume ten people have same preferences.

What counts as on-time: Sequential or simultaneous service, each person's acceptable wait and serving conditions.

Actual resources: Personnel, equipment, capacity, counter space, and available time slots; identify what must be shared.

What can change: Whether to add equipment, change method, or adjust serving sequence, and who authorizes changes.

Records to keep: Information that prevents errors this run and data for later comparison.

A new scenario card is created for the gathering (CF-GROUP v1), distinct from the weekday single-cup scenario (CF-WD). The original 7:28 target and CF-T01 definition ("start of first prep to serve") are preserved, not silently redefined as "ten cups completed." New timing conventions must be agreed: when total time starts, when each person's wait starts. If each person's acceptable wait is defined, verify per person — average wait may hide an individual's excessive wait.

Image: Ten cups do not mean existing equipment can handle ten cups; first ask whether serving is sequential or simultaneous, then verify personnel and capacity.

Reuse Definitions, Re-verify Arrangements

Drawing on the framework from article 10 (recipe version, execution plan, actual brew, record, artifact, evaluation), the author walks through a reuse/check table:

Recipe & version: Keep specification/execution separation and version history; re-check if original recipe suits new volume, equipment, preferences.

Brew, record, traceability: Keep per-brew numbering and traceable records; re-check that interleaved brews don't cause reading/record cross-contamination.

Resources: Keep same kettle instance, units, identifiers; re-check quantity, capacity, occupancy, release, wait, and log new personnel.

Tasks & dependencies: Keep pre-brew condition checks; re-check if batching, portioning, handoff, cleanup, re-use steps need insertion.

Metrics & requirements: Keep taste confirmed by actual drinker with source; re-check how each of ten people evaluates, when completion counts, allowed exceptions.

Model & test cases: Keep single-cup cases for regression; re-check coverage of new division of labor, relationships, resource waits.

Some changes only adjust parameters (e.g., new time target with versioned history); others add new actions (e.g., "portion and match cup to person") requiring explicit who/what/how — not just a headcount change. Unchanged definitions stay; old model's checked items and conditions are retained; feasibility for this gathering must be re-verified under new conditions.

Image: Concepts and sources can continue, but time limits, resource capacities, handoffs, and serving methods must be reconfirmed for the new scenario.

Adding a Person Does Not Automatically Add Resources

Assuming a friend helps record while the author brews, the single-operator contention (pouring vs. logging, article 09) may ease, but feasibility isn't automatic. The friend needs access to readings: if the phone timer is used by the brewer, can the friend see the next step's data? If both watch the same scale, which batch does a reading belong to? The article 06 exclusive-use assumption for one person cannot be blindly applied to all people and equipment.

Shared use doesn't necessarily mean contention. Two people can watch one display, but whether one scale can weigh two batches simultaneously depends on the operation. Handoffs must be explicit: "second brew, first segment done" must map to the correct record; clarification time counts in the schedule. Using OPM, keep processes (pour, read, log), reassign friend's actions to him, add information-handoff links. The diagram shows added person but feasibility depends on each one's timeline and shared equipment. If everything queues on one kettle, compare alternatives: resequence, reduce on-the-spot logging, add resources, or renegotiate staggered service — each has a cost; buying new gear isn't presupposed as best.

One Brew, One Batch, One Cup — Trace Separately

Previous single-cup discussion didn't need portioning. Now one brew may fill several cups, or several brews may be served separately. "Batch" means one brew's output, distinct from bean lot. Portioning records must capture: this brew → which cups → which person. The cup is the container; evaluation targets the coffee in that cup. If multiple brews are mixed, provenance needs separate tracking (not expanded here).

Thus a friend's "this cup is good" traces to that portion, that brew, that recipe version. One person's approval cannot be copied to all cups; "ten cups served" ≠ "ten people satisfied." Original single-cup records stay at original detail; absence of portioning fields doesn't prove no portioning occurred, nor can historical operations be invented. New scenario records these relations from actual ops; any historical backfill requires evidence and source annotation.

Image: Partial illustration of one brew and three portions; one person's feedback belongs only to the portion they drank. Kettle markings are equipment appearance, not this run's measured amounts.

Switch to Order Fulfillment: Check Cross-Team Handoffs

Replacing coffee with a committed delivery order, the same questions apply but nouns cannot be merely swapped. Start with a representative order: confirm customer's real need (correct goods in agreed window with agreed acceptance), not just ERP "shipped" status. Trace actual artifacts: how order enters, what pick instruction warehouse uses, when carrier takes over, who confirms receipt and acceptance. At each handoff ask both "what was handed over" and "what authorizes the next step."

"When do they drink?" → Customer's required window, location, goods, acceptance criteria, change authority.

"Next step's inputs ready?" → Pick basis, pick result, dispatch plan, receipt conditions all referencing same delivery.

"What are multiple tasks waiting for?" → Warehouse slots, vehicles, dock windows occupied by other orders; capacity and priority decisions.

"Which record belongs to which cup?" → Order lines, packages, batches, transport & receipt records; after split-order, can we still trace?

"Served = satisfied?" → Evidence for picked, dispatched, signed, accepted — each with its own proof.

Order processing, warehousing, carrier logistics — each with own people, equipment, governance — together participate in delivery. They retain operational and managerial independence (SEBoK SoS characteristics), so the ensemble may exhibit System-of-Systems traits. Managerial independence doesn't preclude shared goals, coordination lead, or agreed scheduling. Whether it's an SoS depends on actual boundaries, not just org chart or three software systems. Adding kitchen gadgets or scaling to ten cups doesn't automatically create an SoS.

Local targets can all be met while customer misses the window: warehouse meets internal pick deadline but misses carrier's pickup cutoff. The fix isn't just "push warehouse faster"; compare options: early staging, shift adjustment — each with cost and feasibility. This mirrors article 01's "emergence": whole behavior arises from part interactions, not from one part alone. In this order, analyze how pick schedule and pickup window interact rather than labeling "negative emergence."

MEG 2.0 calls for mission-goal-centered analysis of cross-element collaboration with iterative alternative comparison. Article 03's Mission Success Indicators (MOS) map here: delivered correct goods in agreed window with agreed acceptance, each with its own judgment basis — not substituted by pick speed or truck utilization.

If current conditions can't meet the promise, the authorized person renegotiates with customer, preserving original agreement and change record. Changing a date in the model ≠ customer agreement. The ontology clarifies what "picked" and "dispatched" mean and their evidence; actual warehouse work stays in warehouse logs, carrier moves in carrier systems, acceptance by authorized staff. Naming things clearly doesn't transfer responsibilities to the model.

Image: Picking, dispatch, receipt, and acceptance each have evidence and responsibility; diagram shows collaboration boundaries, not that this order is complete, and cannot judge SoS solely by departmental division.

Start Small: One Traceable Scenario in 1–3 Days

First practice: pick a small thing with visible result in 1–3 days, involving people + tools or physical handoffs, so you can observe and ask. Even one order must note if other orders consume the same vehicle or clerk. Extend existing analysis files with these fields (filled from real documents, observation, owner confirmation — no tool selection yet):

1. Decision this run supports
2. Who needs what result, who confirms success
3. Scenario, scope, timebox, immutable constraints
4. Known facts & sources; unverified key assumptions
5. Critical tasks, required inputs, handoff confirmations
6. Actual people, shared resources, capacities, governing bodies
7. Current way; proposed changes & their costs
8. Reusable definitions; content needing fresh analysis
9. How this round checks model, gathers facts, confirms business outcome
10. On finding issues: what to change, who approves, which old cases to re-run
11. When evidence is thin: pause which judgments, what to gather next

After filling, have the actual next-step owner read it: can they state what they wait for, what they need to proceed, who to ask when something's missing? Test with one normal completion and one delayed/rework case — does the file explain the difference? If you can only write "improve collaboration," return to concrete handoffs. If you can pinpoint a verifiable change, know who approves, and how to observe result, start small-scale comparison — don't wait for a company-wide model.

Tools need not be complete upfront. A few cards can clarify the flow; use cards first. When process changes keep missing material/equipment/record impacts, bring in OPM to check those relations together. When several apps interpret the same term differently, add definitions and mappings. When queuing and scheduling exceed mental capacity, then consider scheduling or simulation tools — validated against reality. For high-risk domains, professional validation per relevant standards is required; the coffee example only illustrates the method.

Image: Four segments are this series' reading and analysis path; evidence can feed back to revise earlier agreements, arrangements, or definitions, not just one-directional progression.

Summary

Across twelve articles, mission engineering helps us clarify what we're trying to achieve and compare ways to get there; OPM puts people, equipment, materials, and processes in one view for checking; ontology separates recipe, plan, actual brew, and record meanings. Moving to a new scenario, we can reuse the questioning patterns and confirmed definitions, but the concrete arrangement must be re-verified. This is the series' chosen learning path, not the only tool combination mandated by mission engineering.

Returning to article 01's frustration: "I followed all steps, why isn't it right?" The tutorial steps were done, yet the family found the coffee bitter and had no time to enjoy it. The gap lies between "I completed the steps" and "Did the thing actually succeed?" From one cup to one order, we must keep verifying: who got what result, does it match the prior agreement, where's the evidence; if it didn't succeed, what to change first next time. A model earns its keep only if it helps answer those questions.

References

SEBoK, Systems of Systems (SoS), "Characteristics and Definition of Systems of Systems" and "Types of SoS". Used to illustrate constituent systems' operational independence, managerial independence, and coordination modes; coffee and order scenarios are teaching designs, actual enterprise SoS determination requires real boundaries. URL: https://sebokwiki.org/wiki/Systems_of_Systems_(SoS) U.S. Department of Defense, Mission Engineering Guide 2.0, October 2023, sections 2.1–2.2 and 4.2, pp. 3–5, 14–17. Used to illustrate mission-goal-centered cross-element analysis, alternative evaluation and iteration, and link between mission success indicators and lower-level indicators; order indicators are teaching analogies, guide does not prescribe this article's ME, OPM, ontology integration. URL:

https://ac.cto.mil/wp-content/uploads/2023/11/MEG_2_Oct2023.pdf

SEBoK, Emergence and Complexity. Used to illustrate system-level properties and behaviors arising from interactions, and possible beneficial/harmful outcomes; order case used to analyze handoff mismatch, not as validated emergence mechanism research. URL:

https://sebokwiki.org/wiki/Emergence_and_Complexity