skills/better-plans/references/engineering-depth-context.md

# Better Plans Engineering-Depth Context

## Purpose

Better Plans is a simplified, plain-English application of systems engineering, product development, risk management, validation, and project planning to everyday decisions and projects. This reference calibrates the rigor underneath the framework. It does not define additional Better Plans tools and must not override `tool-library.md` or the orchestration rules in `SKILL.md`.

## Effort translation

Think of a formal engineering organization or full systems-engineering program as roughly 100% effort. A deliberately simplified engineering application to a personal project might still be around 50% effort. Better Plans should usually target roughly 30% effort for normal users:

- enough rigor to avoid major blind spots;
- enough structure to guide real tradeoffs;
- enough practical exhaustiveness to uncover important requirements, stakeholders, constraints, risks, dependencies, and validation needs;
- not so much formality that the user feels they are completing an engineering report.

Increase depth temporarily for unusually complex, expensive, high-stakes, technical, or difficult-to-reverse plans. Compress the process for simple or narrow questions.

## Engineering discipline to preserve

Use the professional foundations to improve the thinking, not to make the output sound technical:

- Start with purpose, scope, and success criteria before committing to solutions.
- Identify stakeholders, users, decision-makers, reviewers, helpers, and people affected later.
- Translate needs into a prioritized set of practical requirements.
- Break the plan into major subareas only when their requirements, constraints, risks, or validation paths differ meaningfully.
- Track how requirements will be checked, demonstrated, reviewed, tested, or otherwise validated.
- Consider usability, reliability, maintainability, availability, long-term burden, and reversibility when they matter.
- Build phases around dependencies, responsibilities, timing, decision gates, and cost assumptions.
- Identify credible failure modes, prioritize them, and define prevention, contingencies, warning triggers, and ownership.
- Use drafts, estimates, diagrams, walkthroughs, reviews, inspections, demonstrations, pilots, and tests before expensive commitment when they can reduce uncertainty.
- Iterate when new information exposes missing requirements, constraints, risks, or design changes.

## Plain-English translation

Translate formal concepts into normal planning language:

- Mission or purpose → What are we trying to accomplish, and why does it matter?
- Requirements → What must or should be true for this plan to work?
- Stakeholder analysis → Who is affected, who decides, who can help, and who could create friction?
- System/context view → What are the major pieces, boundaries, and interactions?
- Requirements traceability → Does the current plan still satisfy what mattered at the start?
- Reliability and maintainability → What could become a recurring problem or long-term burden?
- Integrated plan and schedule → What are the phases, dependencies, owners, milestones, and timing?
- Verification and validation → How can we check, test, inspect, demonstrate, review, or validate this before fully committing?
- Risk register → What could go wrong, which risks deserve attention, and how should they be handled?

## What not to do

Do not turn normal conversations into formal systems-engineering reports unless the user explicitly requests the professional version.

Do not introduce formal artifacts or acronyms such as AV-1, OV-1, OV-2, OV-5, RVTM, MOE, MOP, KPP, TPM, IMP, IMS, RMA, FMEA, RACI, or V&V as additional user-facing Better Plans tools. The professional anchor may guide internal rigor; the framework tool name and plain-English planning move remain user-facing.

Do not assume that a highly detailed worked example is a reusable template for every scenario. Preserve its discipline while adapting scope, depth, language, and outputs to the actual user and decision.