Mission Engineering: Steps Done ≠ Mission Accomplished — A Coffee Lesson

Mission Engineering (ME), as defined in the U.S. Department of Defense's Mission Engineering Guide 2.0 (2023), analyzes what needs, capabilities, and coordination are required to achieve an intended outcome. The article illustrates this with a simple pour-over coffee scenario: you follow every tutorial step, but the family member finds the coffee bitter and has no time to drink it. Completing steps (grinding, pouring) is not the same as accomplishing the mission (delivering a tasty cup on time).

"Mission" Scaled Down

The DoD guide defines a mission as tasks and actions around a specific objective. Mission Engineering then asks: what needs must be satisfied, what capabilities are required, and how do they fit together? In the coffee example, this means first clarifying who drinks it, when, and what "good" tastes like, then checking whether current equipment and skill can meet that under the time constraint.

Two distinct questions are separated:

What must be accomplished (overall mission goal): serve a cup the family likes, by the agreed time.

What must be investigated first: can the current method achieve it? If not, should you prepare earlier, practice more, or change equipment?

The guide requires distinguishing the mission itself from the purpose of the engineering analysis (DoD Guide, p.9). This separation gives the investigation a concrete direction.

Equipment Works, So Where Is the Problem?

Assume kettle, grinder, and scale are fine. The delay comes from hunting for filter paper and dripper after water boils. Steps are all done, but sequencing wastes time. Bitterness is a separate issue involving beans, recipe, and technique.

Compare two approaches: (1) current habit, (2) pre-staging everything. Record each step's duration and finish time. Use identical beans and recipe; note any other changes. One trial isn't enough — repeat to see if differences persist and whether skill improves.

Arrows show sequence, not actual duration. Boiling includes waiting; fetching filter paper requires hands-on time. Whether heating can overlap with prep depends on whether the kettle needs watching and if you have other tasks. Episode 04 will separate sequential vs. parallel steps.

Mission Engineering asks: when one step improves, does the whole mission improve? It analyzes interdependencies and compares adjustments like redistributing work, practicing, or changing methods — not just buying new gear (DoD Guide, p.3).

In business systems: database and services respond fast, but a ticket stalls at approval because no owner is assigned. Interface latency won't reveal this. Complex deliveries often involve multiple independently managed systems (order, warehouse, logistics) forming a System of Systems (SoS). SEBoK warns that improving one constituent system doesn't guarantee better overall effect (SEBoK, Architecting Approaches for Systems of Systems ). The coffee example treats person, tools, and materials as one system without independent management, so it doesn't cover SoS coordination challenges.

Interactions produce emergent behaviors — sometimes beneficial, sometimes not (SEBoK, Emergence and Complexity ). Here, it's enough to see where steps help or hinder each other without labeling every confusion as emergence.

Don't Draw Flowcharts Yet — Ask Three Questions First

Start with the stakeholder's own words. Suppose the family member only says: "Make it tastier, don't keep me waiting."

"Who judges tasty?" Record their exact preferences — what flavors they like, what they dislike. Don't translate "bitter" into a temperature or dose yet.

"When and how will they drink?" Grabbing the cup while leaving vs. sitting down changes the time budget. Agree on a ready time; if unclear, note it — don't arbitrarily set "4 minutes."

"What will I change after learning this?" Agree not to buy new gear. Measure each step's time, listen to feedback, then decide whether to reorder prep or adjust technique. The better option is unknown until tested.

Also capture the need for a repeatable recipe — this is a separate requirement. One good cup doesn't guarantee the next.

Writing these answers creates the first Mission Description Card . Keep it in one living document; later add scenarios, tasks, and models — building a "Pour-Over Coffee Business Analysis and Model Archive" instead of starting fresh each time.

What is this called? Make a tasty pour-over with existing gear before the family leaves, and record the method.

Who needs it, who confirms? Family drinks and judges taste/timeliness; you want a reusable record.

What is the goal? Ready by agreed time, family likes it, method recorded clearly.

Known conditions & assumptions: beginner, one person, existing gear; detailed inventory later.

Start and end boundaries: from prep start to serving, hearing feedback, and organizing records; exclude bean buying/roasting.

What to investigate this round? Where time goes, whether pre-staging helps, impact on taste and record-keeping.

Who decides next steps? You, based on records and feedback; no new gear this round.

Evidence of success: prep-to-serve duration, step-by-step log, family's evaluation; repeatability tested next time.

Open questions, who to ask, when: agree on ready time and taste preferences with family; list what to record. Unanswered items can wait — don't conclude early.

Fill what's clear now; leave the rest for later. The card's "evidence of success" will expand in Episode 03 into Mission Success, Measures of Effectiveness (MOE), and Measures of Performance (MOP).

Premature solution: "Use a professional pour-over kettle, follow standard process, improve coffee quality."

Equipment fixed, "quality" undefined.

Next actionable step: "Use existing gear, ask what they want and when. Record current step times, then test if pre-staging helps."

The second version tells how to investigate and experiment; the card explains why, for whom, and to what level.

From Card to Model

Next: define scenarios and success criteria, break down tasks, set requirements, assign people and tools. Early steps need only paper or spreadsheets — no modeling tool rush.

The diagram's top half shows four reading phases; bottom half shows revision loops when issues appear. Episode 11's "experiment results" come from actual trials; the article provides the experiment plan.

Episode 04 covers task sequencing (Mission Thread, MT); Episode 06 maps tasks to people and tools (Mission Engineering Thread, MET). Terms are introduced in their respective episodes.

Later, when changing pour timing forces updates to equipment occupancy and logging across multiple tables, OPM (Object-Process Methodology) can unify who does what, with what, and what changes in one model. Then separate recipe, this brew, the log, and the coffee into reusable ontology definitions. This series chooses that path, but ME doesn't mandate OPM or any specific ontology language.

The path also loops back. Example: "Will detailed recording slow down the pour?" examined three times:

Episode 07: compare methods — how long does extra logging take, does it clash with pouring?

Episode 09: model check — which two actions collide, are they truly sequential? If overloaded, reschedule and update model.

Episode 11: design the trial — what to observe and record to verify the concern and whether the fix helps.

If trials still show overload, go back and adjust; if the time target itself is unrealistic, renegotiate. The guide's methods allow iterative adjustment as information grows (DoD Guide, p.4).

How is this different from a pour-over tutorial? A tutorial gives steps; ME asks: does this method fit this person under these constraints? Would another be better, and how would we know? Existing process, project, and systems engineering methods already study this — use what works, no need to rename everything.

If a simple checklist solves it, stop there. When interactions become unclear, deepen the analysis.

Try It on Your Work

Pick a familiar task with a 1–3 day feedback loop: issuing a spare part, deploying a hotfix needing manual approval. Human-to-human or human-to-tool handoffs reveal issues quickly. Software tasks work too — don't start with "full ERP rollout."

Below is a blank card matching the coffee example's fields:

1. 这件事叫什么：
2. 谁需要、谁来确认：
3. 想做到什么：
4. 已知条件与假设：
5. 从哪开始、到哪结束：
6. 这次想弄清什么：
7. 谁来决定下一步怎么做：
8. 凭什么判断做到了：
9. 还有什么没问清、找谁、何时问：

Ask: who in your work is the waiting family member, who is the brewer? Have a colleague read the card without explanation — can they state: for whom, to what level, what to investigate next, what to change, and how to verify success? If they only say "make a coffee" or "run a process," go back and ask. A clear card tells you where to start; whether the fix works comes later.

Summary

Back to the bitter, rushed coffee. Clarify how the family wants to drink it, then diagnose your own scramble — that finds the next improvement faster than buying a new kettle or re-memorizing steps.

Same pour-over, weekend vs. rushed morning — which conditions must be separated? Next episode defines scenarios and boundaries.

References

U.S. Department of Defense, Mission Engineering Guide , Version 2.0, 2023-10-01. Primary references: pp.3-4 (definition & iterative method), pp.9-10 (mission vs. analysis purpose). Coffee case, card, and teaching path are original.

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

SEBoK, Architecting Approaches for Systems of Systems . Used to explain constituent system independence and local vs. global goals.

https://sebokwiki.org/wiki/Architecting_Approaches_for_Systems_of_Systems

SEBoK, Emergence and Complexity . Used to explain interactions and collective behavior, avoiding simplistic "emergence means better" interpretation.

https://sebokwiki.org/wiki/Emergence_and_Complexity