Milestone map
Milestone map
3 milestones
Define Project Scope and Stakeholder Requirements
2–3 weeks (3–4 hrs/week)
Select a real or realistic engineering project to plan — a product development, infrastructure upgrade, system implementation, or similar. Define the project scope through a Work Breakdown Structure (WBS) that decomposes the project into ≥15 work packages. Identify all stakeholders and their requirements. A clear WBS and stakeholder map prevent scope creep — the leading cause of engineering project failure.
Proof required
Submit your scope document: WBS with ≥15 work packages (at least 3 levels of decomposition), stakeholder register (name, role, requirement, influence level), and project objectives statement (specific, measurable, achievable, relevant, time-bound).
What gets checked
- WBS has at least 3 decomposition levels and ≥15 work packages — not just a high-level task list
- Stakeholder register identifies ≥5 stakeholders with their specific requirements and influence level
- Project objectives are SMART — specific with quantitative targets, not generic descriptions
Common mistakes
- WBS with only one or two levels — a shallow WBS cannot drive a realistic schedule or resource plan
- Stakeholder register listing only the project team — identify both internal and external stakeholders including regulators, end users, and suppliers
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm WBS has ≥3 levels of decomposition and ≥15 work packages — count the lowest-level packages.
- Confirm stakeholder register identifies both internal and external stakeholders with their specific requirements.
- Confirm project objectives are SMART — check each objective against the SMART criteria.
Build the Schedule, Resource Plan, and Risk Register
3–4 weeks (4–5 hrs/week)
Using the WBS from M1, build a project schedule: estimate durations for each work package, establish task dependencies, and produce a Gantt chart identifying the critical path. Build a resource plan: assign people, equipment, or materials to each task with hours and costs. Build a risk register: identify ≥8 project risks, assess likelihood and impact (1–5 scale), and define a mitigation action for each risk above a threshold score. These three documents together constitute a project baseline that can be managed against.
Proof required
Submit your project schedule (Gantt chart with critical path highlighted), resource plan (resource histogram or hours/cost table per task), and risk register (≥8 risks with likelihood, impact, score, and mitigation).
What gets checked
- Gantt chart identifies the critical path — the longest sequence of dependent tasks that determines the project end date
- Resource plan assigns specific resources to tasks with hours or cost estimates — not just role names without time estimates
- Risk register has ≥8 entries with likelihood × impact scores and mitigation actions — not generic risks like 'scope creep'
Common mistakes
- Gantt chart without task dependencies — a schedule with no dependencies cannot have a critical path
- Risk register with generic risks (communication failures, scope creep) — risks must be specific to the project being planned
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm critical path is identified on the Gantt chart — the longest sequence of dependent tasks.
- Confirm resource plan assigns hours or cost to specific tasks — not just role assignments without time estimates.
- Confirm risk register has ≥8 project-specific risks with likelihood × impact scoring and specific mitigation actions.
Write the Project Plan Document and Present for Review
2–3 weeks (2–3 hrs/week)
Compile all three documents (WBS/scope, schedule/resource plan, risk register) into a single integrated project plan document (2,000–3,000 words plus appendices). Add sections for: quality plan (how deliverables will be checked), communication plan (who gets what information, how often), and change control process (how scope changes will be managed). Present the plan to a reviewer with project management or engineering management experience. A plan that cannot survive a review challenge is not yet a plan.
Proof required
Submit your project plan document (2,000–3,000 words plus appendices) and review record: reviewer name, role, ≥3 challenge questions asked, and your responses.
What gets checked
- Project plan integrates all five sections: scope/WBS, schedule/Gantt, resource plan, risk register, and quality/communication/change control
- Review record names the reviewer, their role, and documents ≥3 specific challenge questions with substantive responses
- Change control section defines the process for approving and recording scope changes — not just noting that changes are possible
Common mistakes
- Omitting quality, communication, and change control sections — a project plan without these three sections is incomplete per any project management standard
- Reviewer without project management or engineering management experience — challenge questions must probe the schedule realism and risk mitigation validity
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Engineering Design Triad check: M1–M3 together produce a design artifact (WBS + Gantt chart + resource plan), an analysis artifact (risk register with scored risks and mitigations), and a documentation artifact (integrated project plan document + review record) — confirm all three types are present.
- Confirm project plan includes quality, communication, and change control sections — flag any that are missing.
- Confirm change control section defines an actual process, not just acknowledgement that changes happen.
- Confirm reviewer has project management or engineering management experience — challenge questions must probe schedule realism and risk mitigation validity.
- The Proof Accessibility Rule applies — ProjectLibre (free), GanttProject (free), APM free resources, and AXELOS free overview are all accessible without commercial licence.
Part of