Prove
All outcomes
Skills

Engineering Project Plan

6 weeks · 0 milestones

Produce a complete engineering project plan for a real engineering project (or a documented project scenario), covering scope, schedule, resources, and risk. The plan must include: a Work Breakdown Structure (WBS) decomposing the project to at least 3 levels with clearly defined work packages and deliverables, a project schedule (Gantt chart or network diagram) with dependencies, milestones, and the critical path identified, a resource plan identifying the engineering disciplines and key personnel required with an effort estimate per work package, a risk register with at least 8 technical and programme risks — each with probability, impact, risk score, and mitigation action, and a project communication plan identifying stakeholders, information needs, and reporting frequency. Preferred proof: a project plan for a real engineering project. Accessible alternative: ProjectLibre (free, open-source MS Project equivalent) or a structured spreadsheet WBS and Gantt — a project planning tool is required; a prose document describing a plan is not sufficient. Proof artifacts: the WBS and schedule (design artifact) and the risk register with probability and impact analysis (analysis artifact). Verification: an engineering project manager or engineering manager reviews the critical path — 'your critical path runs through this structural analysis activity; what happens to the project completion date if the geotechnical investigation takes 2 weeks longer than planned?' — requiring specific reasoning from your own schedule and dependencies.

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.

You'll sign in first, then come straight back here.

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.

You'll sign in first, then come straight back here.

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.

You'll sign in first, then come straight back here.

We use analytics to improve Powstik. No ads, ever.