ES-103 — Planning and Work Breakdown¶
You are here¶
ES-102 defined what the system must satisfy. ES-103 determines how the engineering work will be organized so those obligations can be addressed responsibly.
This stage does not design the solution yet. It decomposes obligations into work that can be assigned, sequenced, estimated, reviewed, risk-managed, and tracked. Planning is where vague ambition becomes accountable engineering work.
ES-103 is the engineering bridge between requirements and architecture. ES-104 should not have to guess what work exists, what constraints matter, what risks are known, who owns decisions, or which dependencies shape the architecture effort.
Why this stage exists¶
Teams often move from requirements directly into design or coding. That feels efficient, but it usually hides risk. The missing work eventually reappears as rework, delay, quality failure, unverified AI behavior, or release uncertainty.
Without disciplined planning, teams often discover too late that:
- requirements were too large for the available time;
- dependencies were misunderstood;
- risks were not assigned;
- AI-assisted work lacked verification time;
- review work was not planned;
- evidence work had no owner;
- testing was treated as an afterthought;
- governance review was assumed instead of scheduled;
- release readiness was expected without evidence.
ES-103 prevents those failures by creating a traceable engineering plan.
The engineering question¶
How should the required engineering work be decomposed, sequenced, assigned, estimated, and risk-managed?
What you will produce¶
ES-103 produces project artifacts under:
docs/planning/
Required artifacts:
planning_overview.md
work_breakdown_structure.md
milestones.md
roles_and_responsibilities.md
risk_register.md
dependency_map.md
estimation_record.md
planning_review.md
planning_readiness_summary.md
Templates should be copied from:
template-library/planning/
Completed reference examples, when available, should be reviewed under:
examples/lmu-coicp/planning/
What good looks like¶
A good ES-103 plan is not a fantasy schedule. It is a reviewable engineering plan that shows what work exists, why it exists, where it came from, who owns it, what depends on what, what risks matter, what is deferred, what must be reviewed, and what evidence must be produced.
A work package is strong when a reviewer can trace it to a requirement, constraint, risk, review obligation, or evidence need.
A milestone is strong when it represents an evidence-backed readiness point, not just a calendar date.
An estimate is strong when it expresses uncertainty honestly enough to support decision-making.
Required reading order¶
Relationship to ES-102¶
ES-102 says what the system must satisfy. ES-103 says how the work will be organized to satisfy it.
Do not create work items that cannot be traced to requirements, constraints, risks, review obligations, evidence obligations, or platform responsibilities. Untraceable work may still be valid, but it must be explained.
Relationship to ES-104¶
ES-104 should begin with a realistic understanding of the work architecture must support. The architecture stage needs to know which requirements matter most, which constraints are binding, which dependencies exist, which risks require design attention, and where tradeoffs may be necessary.
Lifecycle chain¶
ES-103 continues the ETIS lifecycle chain:
Question
↓
Evidence
↓
Decision
↓
Repository Artifact
↓
Next Stage
The question is how the required engineering work should be organized. The evidence is the planning package. The decision is whether the work is understood well enough for architecture to begin. The repository artifact is stored under docs/planning/. The next stage is ES-104.
AI may help decompose requirements, identify hidden work, surface dependencies, suggest risks, compare sequencing options, and critique estimates. AI must not create false certainty about effort, ownership, or schedule. Engineers remain responsible for final estimates, commitments, sequencing, risk ownership, and readiness decisions.
Do not confuse a task list with a plan. A task list names activity. A plan explains work, dependencies, risk, ownership, evidence, and readiness.
Planning is where engineering honesty becomes visible. A realistic plan is more valuable than an optimistic plan that cannot survive contact with the work.