Milestone map
Milestone map
3 milestones
Frame the Engineering Management Problem
3–4 weeks (3–4 hrs/week)
Identify a real engineering management challenge — cost overrun, schedule delay, team scaling failure, or process breakdown — and frame it with quantified evidence. Produce a problem statement that names the system, the failure mode, the measurable impact, and the investigation scope. A clearly-framed problem prevents scope creep and ensures later analysis is anchored to evidence rather than opinion.
Proof required
Submit your problem statement document (≥600 words): the engineering management challenge, evidence of its impact (cost, schedule, quality, or team metrics), system description, and a structured investigation plan listing the data sources and methods you will use.
What gets checked
- Problem statement names a specific, measurable failure — not a general process concern
- Impact is quantified with real figures (cost variance, schedule slippage, defect count, or team metric)
- Investigation plan lists specific data sources and methods — not generic 'research the problem'
Common mistakes
- Framing a problem you cannot get data on — without evidence, the case study becomes speculative
- Framing too broadly (e.g. 'our engineering culture is poor') — narrow to a specific, measurable failure with a defined time window
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm the problem statement names a specific engineering management failure, not a generic process concern.
- Confirm quantified evidence is cited — cost variance, schedule slippage, headcount, defect rate, or equivalent — not opinions.
- Confirm the investigation plan lists real data sources the submitter has access to.
Analyse Root Causes and Solution Options
4–5 weeks (3–4 hrs/week)
Conduct root cause analysis using fishbone diagram or 5 Whys applied to the framed problem. Evaluate ≥2 solution options using a weighted decision matrix that scores each option on cost, schedule impact, feasibility, and risk. Quantifying trade-offs transforms opinion into defensible recommendation — the matrix is what prevents a case study from being just a narrative.
Proof required
Submit your analysis document: completed root cause analysis (fishbone or 5 Whys), weighted decision matrix (≥2 options, ≥3 criteria, scored with weightings), and a preliminary recommendation with rationale.
What gets checked
- Root cause analysis reaches controllable root causes — not surface symptoms like 'team was slow'
- Decision matrix weightings are stated before scoring (not derived retrospectively to favour the preferred option)
- ≥2 genuine options are compared — not one real option and an obvious straw-man
Common mistakes
- Building a decision matrix that reverse-engineers your preferred answer — assign weights before scoring
- Root cause analysis that stays at symptom level (e.g. 'team was too slow') — keep asking Why until you reach a controllable root cause
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm the root cause analysis reaches controllable root causes — not surface-level symptoms.
- Confirm decision matrix weightings are stated before scoring, not derived after.
- Confirm ≥2 genuine options are compared — not one real option and one obviously inferior straw-man.
Write, Present, and Defend the Case Study
3–4 weeks (2–3 hrs/week)
Write a complete engineering management case study (2,000–3,000 words) covering the problem, root cause analysis, options evaluation, recommendation, and lessons learned. Present findings to a reviewer with engineering management or project management experience and respond to challenger questions. The presentation and Q&A are what make the case study non-fabricatable — reasoning under challenge is the core test.
Proof required
Submit your case study document (2,000–3,000 words) and a review record documenting the reviewer's name, role, challenge questions asked, and your responses.
What gets checked
- Case study references its own analysis artefacts (root cause analysis, decision matrix) — not a narrative describing conclusions without evidence
- Review record names the reviewer, their role, and documents ≥3 specific challenge questions with the submitter's responses
- Lessons learned section names at least one thing the submitter would do differently — not generic reflection
Common mistakes
- Requesting review from someone without engineering management experience — reviewer must be able to challenge the root cause logic and the options trade-offs
- Writing a narrative that omits the decision matrix and root cause analysis — the case study must reference these artefacts, not just describe conclusions
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Engineering Design Triad check: M1–M3 together produce an analysis artifact (root cause analysis + decision matrix), and a documentation artifact (2,000–3,000-word case study + review record) — confirm both types are present.
- The case study must reference its own analysis artefacts (root cause analysis, decision matrix) — a narrative-only submission without attached artefacts does not meet the standard.
- Review record must document ≥3 specific challenge questions and the submitter's responses — generic praise is not a review record.
- Reviewer must have engineering management or project management experience — peer review from a co-worker without management experience does not count.
- The Proof Accessibility Rule applies — ASQ tools, MIT OCW, PMI summaries, and open-source documents are free; no proprietary software required.
Part of