Project Engineering: Management Techniques (PEM117V) Notes

Project Engineering: Management Techniques (PEM117V) focuses on how engineering work is planned, executed, monitored, and controlled to deliver scope, quality, time, and cost outcomes. These notes connect classic project management thinking with engineering-specific realities such as technical uncertainty, change control, procurement, safety, commissioning, and compliance. You’ll find practical management techniques, templates of thinking, and exam-style explanations of how to handle trade-offs when constraints clash.

These notes align with how South African universities commonly structure Project Management and Engineering Management learning outcomes—especially the kind of work you see in TUT modules that sit within Project Management course-note collections.

PEM117V at TUT: Project Engineering vs. General Project Management

Project Engineering is not “project management with engineering vocabulary.” It is a discipline where management techniques must be applied to engineering deliverables, technical dependencies, and regulatory constraints. At Tshwane University of Technology (TUT), the PEM117V learning context typically expects students to demonstrate not only knowledge of tools (e.g., Gantt charts, WBS, risk registers) but also judgement: why the tool fits a situation, what outputs are expected, and how control actions should be selected when performance deviates.

What “Project Engineering” Means in Exam Terms

A strong exam response usually distinguishes the project engineering perspective from general PM.

Project Engineering emphasises:

• Technical scope definition: what must be built/design/verified and the engineering acceptance criteria.
• Systems thinking: interfaces between disciplines (civil, mechanical, electrical, instrumentation, software).
• Engineering verification and validation: tests, inspections, commissioning plans.
• Compliance and standards: safety, quality, regulatory, and contractual requirements.
• Change management tied to design and drawings: engineering changes propagate into cost, schedule, procurement, and documentation.

General project management emphasises:

• governance, reporting, stakeholder management
• schedule/cost control as “management performance”
• resource planning and procurement oversight

In PEM117V, the marker typically looks for the ability to merge both: schedule and cost controls must be linked to engineering work packages and technical deliverables.

Typical Engineering Project Life Cycle (A Practical Model)

A coherent life cycle appears repeatedly in exams. While models vary by organisation, you can use a common structure:

1. Initiation & Concept
   • problem definition, feasibility, high-level requirements
   • stakeholder analysis
   • rough cost and time estimates
2. Planning & Design Development
   • define scope boundaries
   • create WBS (work breakdown structure)
   • develop engineering designs and specifications
   • produce procurement strategy and contracting approach
3. Execution
   • implement design outputs
   • manage construction/installation/manufacturing
   • manage suppliers and subcontractors
4. Integration, Testing & Commissioning
   • functional testing, safety checks, performance verification
5. Close-out
   • handover, as-built documentation
   • lessons learned, contract closure

Management techniques appear at each phase. For instance:

• Initiation: feasibility reviews, benefits realisation planning
• Design: risk workshops, configuration management, design reviews
• Execution: earned value, change control boards, look-ahead planning
• Commissioning: test management, snag tracking, readiness reviews
• Close-out: audits, post-project evaluation, knowledge retention

Why Engineering Projects Behave Differently

Engineering projects frequently have characteristics that make them “special” for management:

• High technical interdependency: one design change can affect multiple disciplines and suppliers.
• Long lead items: turbines, transformers, switchgear, control panels often have procurement lead times that can dominate the critical path.
• Uncertainty and discovery: what looks “known” early becomes clearer during design, testing, or site investigation.
• Documentation as a deliverable: drawings, calculations, method statements, and test reports are not optional—they are evidence for acceptance.
• Compliance constraints: safety regulations, quality assurance requirements, and inspection regimes require formal control.

In exam questions where a scenario mentions drawings, specifications, non-conformance, commissioning delays, or supplier lead times, your answer should shift from general PM to engineering PM: focus on technical baselines, configuration control, and verification workflows.

Management Techniques Core to PEM117V: Baselines, WBS, Schedule, Cost Control, and Engineering Governance

This section covers the “core toolkit” that examiners expect: baselines, WBS, scheduling, budgeting, and performance control. However, each technique is framed in engineering terms: how you create baselines for design and deliverables, how you structure technical work packages, and how you detect and correct deviations early.

Establishing the Project Baseline: Scope, Schedule, Cost, Quality, and Technical Baselines

A baseline is a reference point against which performance is measured. In engineering projects, baselines include more than time and cost.

Common baselines:

• Scope baseline: what deliverables are included/excluded
• Schedule baseline: planned start/finish dates for work packages
• Cost baseline: budgets aligned to work packages
• Technical/design baseline: accepted drawings/specifications/calculation approvals
• Quality baseline: acceptance criteria, test requirements, QA/QC plans

In PEM117V exam questions, when a scenario says “the design is approved” or “drawings were issued,” that usually implies a technical baseline. Management techniques should then maintain that baseline unless a formal change occurs.

Baseline Management: Why “Approved” Isn’t Automatically “Controlled”

Engineering projects can suffer from baseline drift:

• a team builds “from the latest drawing” but that drawing wasn’t properly approved
• a supplier interprets a spec differently
• subcontractors follow informal instruction
• design changes are implemented without formal change authorization

Exam-ready control statement:

• Once a technical baseline is approved, management must use configuration management and change control to prevent uncontrolled updates.

Work Breakdown Structure (WBS) for Engineering: From Deliverables to Work Packages

A WBS turns the project scope into manageable elements. In engineering, an effective WBS usually reflects:

• deliverable hierarchy (system → subsystem → components)
• work responsibility (disciplines, trades, subcontractors)
• integration points (interfaces and commissioning activities)
• reporting structure (how costs and progress are measured)

WBS Construction Steps (Exam Answer Format)

A strong exam answer can present WBS construction as a sequence:

1. Define top-level deliverables
   • e.g., “Electrical Distribution System,” “Process Skid,” “Structural Steel Package”
2. Decompose by discipline or system
   • mechanical, electrical, civil, instrumentation, software
3. Decompose to work packages
   • tasks that can be assigned, scheduled, costed, and measured
4. Define reporting accounts
   • what will be used for status reporting and performance measurement
5. Assign responsibility and interfaces
   • identify who owns each work package and which interfaces exist

WBS Example (Consistent, Engineering-Style)

Consider a hypothetical TUT-style engineering project scenario: upgrading a small water treatment plant with new pumping and electrical control.

A simplified WBS could look like:

WBS Level	Element	Example Work Package (Measurement Unit)
1	Plant Upgrade	Commissioning of Pump Control System
2	Electrical & Control	Install PLC cabinet & wiring
3	Controls	I/O mapping verification test
4	Work Package	Perform FAT/SAT and document results

The key exam idea: each work package should have a clear outcome and a way to measure progress (milestones, completed deliverables, inspection pass/fail, tests run).

Scheduling Techniques: From Critical Path to Look-Ahead Planning

In PEM117V, scheduling tools are not just arithmetic; they are decision-making instruments. Engineering schedules must represent technical logic, procurement lead times, and testing/commissioning dependencies.

Critical Path Method (CPM): Scheduling Logic for Engineering Dependencies

CPM helps identify activities that cannot slip without delaying project completion. In engineering, critical path often includes:

• design approvals
• long-lead procurement
• installation completion prerequisites
• commissioning readiness activities

Exam emphasis: if a long-lead item slips, the critical path may change. Therefore:

• updates must be frequent
• schedule logic must remain consistent with technical dependencies

Milestones vs. Activities

Engineering schedules frequently use both:

• Activities: discrete tasks (e.g., “install breaker”)
• Milestones: completion of deliverables (e.g., “approved as-built drawing set”)

Milestones are helpful because progress measurement in engineering is often “deliverable-based,” not “percent work done.”

Look-Ahead Planning (Rolling Wave Planning)

A practical engineering technique:

• plan near-term activities in detail (e.g., next 2–6 weeks)
• keep longer-term activities at higher level until design/procurement becomes clearer

Why it matters in engineering: uncertainty decreases as drawings are released and equipment arrives.

Integration with Procurement and Lead Times

Engineering schedules must explicitly link:

• design release dates → procurement order dates → delivery dates
• delivery dates → installation starts
• installation completion → testing windows → commissioning

Many project delays happen because the schedule looks “optimistic” without realistic lead times. A high-scoring PEM117V answer will mention lead-time risk and schedule logic tied to procurement.

Cost Baseline and Budgeting: Cost Estimation and Control Structures

Engineering projects use cost breakdown structures aligned with WBS.

Cost baseline components:

• direct costs (materials, labour, subcontractors)
• indirect costs (site overhead, supervision, temporary works)
• escalation/contingency (where applicable)
• contingency for technical risk

Cost Estimation Methods (How Exams Expect You to Discuss Them)

Common approaches you may be asked to compare:

• Top-down estimation: from high-level assumptions (useful early)
• Bottom-up estimation: sum of work packages (useful later when WBS is defined)
• Analogous estimation: based on similar past projects
• Parametric estimation: using engineering parameters (e.g., capacity → cost correlations)

An exam marker expects reasoning:

• early stage: top-down/analogous (higher uncertainty)
• later stage: bottom-up/budgeting at work package level

Cost Control: Tracking Variance and Using Indicators

Engineering PM frequently uses variance analysis:

• schedule variance (SV) relates to progress vs plan
• cost variance (CV) relates to cost vs earned value

In scenario questions, you may be given actuals and expected values. A strong response will state:

• what the variance means
• likely causes (labour inefficiency, material price increases, design changes)
• corrective actions (re-baseline request if change is approved, replan sequencing, expedite procurement, revise labour plan)

Engineering Governance: Engineering Reviews, Approvals, and Decision Gates

Governance in PEM117V includes formal reviews that “hold” the engineering baseline.

Design Reviews and Their Management Purpose

Typical review types:

• concept/design validation: can the solution meet requirements?
• detailed design review: do documents meet standards and internal checks?
• design verification: ensure compliance via calculations, test plans, and checks
• design release: authorised issue of drawings/specifications

Each review should produce:

• findings and actions
• approval status (pass/conditional/fail)
• documentation updates
• linkage to schedule impacts (e.g., release delays can push procurement)

Decision Gates

A decision gate is a controlled point where progression is authorised only if criteria are met. In engineering:

• gate may require design approval
• gate may require procurement package readiness
• gate may require safety compliance checks

Exam tip: if a scenario says “approval was withheld” or “gate not passed,” you should interpret it as governance enforcement. Then suggest consequences and required actions.

PEM117V Risk, Change, and Quality Management: Ensuring Engineering Outcomes Under Uncertainty

Many engineering failures are not purely technical—they come from weak management of uncertainty, uncontrolled changes, and insufficient quality controls. PEM117V typically tests how you apply risk and change management systematically, and how quality assurance links to acceptance testing and commissioning.

Risk Management in Engineering Projects: From Identification to Response Planning

Risk management is a structured cycle:

1. Identify risks
2. Analyse risks (likelihood, impact, detectability)
3. Plan responses (avoid, mitigate, transfer, accept)
4. Implement responses
5. Monitor and control (watch triggers, re-assess regularly)

In engineering, risks often fall into technical, procurement, execution, and compliance categories.

Risk Identification Techniques (Exam-Friendly Examples)

Common identification methods:

• checklists (standards, typical failure modes)
• brainstorming workshops with engineers and procurement/safety staff
• lessons learned from similar projects
• site investigation review (geotech, civil constraints)
• supplier consultation for lead-time and design capability risks

A strong exam answer links risk identification to specific engineering artefacts:

• design drawings
• specifications
• test procedures
• procurement packages

Risk Analysis: Qualitative, Semi-Quantitative, Quantitative

Qualitative:

• likelihood: Low/Medium/High
• impact: Low/Medium/High
• risk level derived from a matrix

Semi-quantitative:

• assign numerical scores (e.g., 1–5) to likelihood and impact
• use risk ranking

Quantitative:

• expected monetary value (EMV)
• scenario simulation (less common in basic exams but conceptually valuable)

Engineering Risk Example: Long-Lead Equipment and Drawing Release

Consider this scenario logic:

• a control valve has a lead time of 12–16 weeks
• design drawings required for ordering must be released by a certain date
• if design release slips, procurement slips

This can be turned into a risk statement:

• Risk: design release delay causes procurement delay; installation and commissioning slip.
• Cause: design review backlog or rework due to non-conformance.
• Impact: schedule overrun and potential penalties.
• Response: fast-track design review, allocate engineering capacity for critical sub-packages, place a reservation order, or create an alternative supplier qualification path.

Risk Registers and Monitoring: Turning Plans into Control

A risk register is not documentation for its own sake. It should include:

• risk description
• owner (person responsible)
• triggers (indicators that risk is materialising)
• response type and actions
• due dates and status updates
• contingency plans

In exam responses, a marker often rewards the inclusion of triggers:

• “If drawing approval slips by 2 weeks, trigger supplier escalation”
• “If test failure occurs in FAT, trigger redesign loop and update SAT schedule”

Monitoring and Control: Avoiding “Static” Risk Registers

If risk registers are never updated, they become stale. Engineering teams should:

• review risks at regular intervals (e.g., weekly planning meeting)
• update probability/impact when new information arrives (e.g., test results)
• track whether response actions were completed

Change Management: Controlling Scope Creep and Engineering Rework

In engineering projects, change is inevitable. The task is to manage it transparently, quickly, and contractually.

Types of Change

• scope change: added requirements or removed deliverables
• design change: drawing/spec revision, engineering calculation updates
• contractual change: formal instructions or client changes
• technical standard change: regulatory or client-specific requirement updates
• procurement-related change: substitution due to supplier constraints
• change in site conditions: discovered conditions (geotech, underground services)

Change Control Process (A Standard Exam Sequence)

An exam-ready process usually includes:

1. Change request raised
   • description of change, reason, affected deliverables
2. Impact assessment
   • assess schedule impact, cost impact, quality impacts, and technical feasibility
3. Decision by change control board (CCB)
   • approve, reject, or request modifications
4. Update baselines (if approved)
   • revise scope baseline, schedule baseline, and cost baseline
5. Communicate changes
   • issue revised drawings/specs, update procurement docs
6. Track implementation
   • verify changes implemented correctly and remove issues from open list

Configuration Management: The “Engineering Baseline Protection” Technique

Configuration management manages:

• versions of drawings
• controlled documents
• revisions and release history
• ensuring the “as-built” matches controlled versions

In engineering projects, failures often occur when:

• field teams use outdated drawings
• subcontractors interpret superseded specs as current
• documentation versions differ between departments

A strong PEM117V answer should state that configuration management works together with change control:

• change control decides whether baseline changes are authorised
• configuration management ensures everyone implements the approved version and tracks document control

Case-Style Scenario: Managing a Drawing Revision Loop

A typical exam scenario might describe:

• design review identifies an issue with cable routing
• a new drawing revision is issued
• procurement already ordered certain cable lengths
• installation begins and then stops due to mismatch

A high-quality management technique response should show:

• when the revision was generated (after review vs during execution)
• whether procurement orders were “locked” to an approved revision
• whether the schedule included rework and verification windows
• whether the risk register predicted drawing release and procurement linkage problems

Correct actions could include:

• a formal change request for cable routing modification
• impact assessment: cost for re-order, schedule for replacement, and testing adjustments
• communication to supplier and installation team with correct revision identifiers
• updated configuration control entries

Quality Management: Assurance, Control, and Acceptance Testing

Quality management is not “inspection at the end.” It is planning and assurance throughout.

QA vs QC (Exam Distinction)

• Quality Assurance (QA): system/process that prevents defects (audits, procedures, planning)
• Quality Control (QC): operational techniques to check quality (inspection, testing, measurement)

In engineering:

• QA ensures methods like method statements, calibration control, and design reviews occur.
• QC verifies that installed work meets acceptance criteria.

QA/QC Planning Artifacts

Common QA/QC documents:

• quality plan
• inspection and test plans (ITPs)
• method statements
• check sheets and inspection records
• non-conformance (NCR) procedures
• calibration schedules

Non-Conformance Management: NCR, RCA, Corrective Action

When work fails an inspection or test:

1. Raise NCR
2. Containment: isolate affected work
3. Root Cause Analysis (RCA)
4. Corrective actions: fix the issue and prevent recurrence
5. Verification: re-test or re-inspect
6. Closure with documentation

An exam might provide a scenario where:

• equipment passes initial checks but fails commissioning
• then NCR is raised late

A strong answer argues for earlier verification:

• include factory acceptance testing (FAT) and site acceptance testing (SAT)
• ensure the commissioning plan includes test evidence requirements
• ensure traceability between design specs and test procedures

Engineering Progress Monitoring and Performance Management: Earned Value, Reporting, Compliance, and Stakeholder Control

Engineering projects require monitoring that reflects real progress. The challenge is that percent completion based on time can mislead; progress must align with deliverables, inspections, procurement milestones, and test evidence.

Why Engineering Progress Measurement Is Hard

Engineering work packages often have characteristics:

• work is hidden (e.g., embedded structures, internal wiring)
• verification is required (testing reveals reality)
• deliverables are paperwork-heavy (drawings, calculations, reports)
• dependencies are complex (one package must finish before another starts)

Therefore, progress measurement must be linked to:

• milestone completion
• acceptance pass/fail
• physical evidence (photos, inspection results)
• documentation issuance (controlled revisions)
• commissioning readiness and test completion

Earned Value Management (EVM): Core Concepts for PEM117V

EVM is a widely taught performance technique. Even if exact formulas are not demanded, exam questions often test the interpretation of performance metrics.

Key EVM terms:

• PV (Planned Value): what should have been done by a time
• EV (Earned Value): what budgeted value is earned by actually completed work
• AC (Actual Cost): what it cost to accomplish the EV

From these, performance indicators are derived:

• schedule performance index (SPI): EV/PV
• cost performance index (CPI): EV/AC
• variances (SV = EV − PV, CV = EV − AC)

Engineering Interpretation

• EV < PV: behind schedule—less technical work completed than planned.
• EV < AC: overspending—spent more than the value earned.
• EV > PV: ahead schedule—work completed earlier than planned (watch quality/compliance evidence).
• EV > AC: efficient cost performance—check whether savings are sustainable.

A high-scoring PEM117V response does not only compute; it explains what engineering causes might be:

• design rework
• supplier delays leading to partial work packages
• change-driven extra work
• quality issues leading to re-inspection
• labour productivity changes

Status Reporting Structures: What Should Be Reported and How Often

Engineering progress reporting usually includes:

• schedule status (milestones: on track/at risk/off track)
• cost status (budget vs actual and forecasts)
• technical status (engineering deliverables issued/approved)
• quality status (NCRs, inspections results, open issues)
• risk status (top risks and changes)
• procurement status (orders placed, delivery ETA)
• safety status (TRIFR/near misses if included by the course)

While the exact metric set depends on the course, the exam pattern often includes:

• “top issues” with actions and owners
• “next period plan” with critical tasks

A Practical Weekly Control Cycle (Exam-Style)

A typical engineering project management rhythm:

1. Review last period performance
   • what milestones were completed?
   • what changed since baseline?
2. Review risks and changes
   • did any risk trigger occur?
   • did any change request get approved?
3. Check quality and compliance
   • are inspections completed?
   • are documents and test results updated?
4. Update schedule and cost forecasts
   • incorporate known delays or accelerations
5. Confirm the next period plan
   • align engineering, procurement, and site readiness
6. Communicate status
   • stakeholders receive a consistent narrative

In exam questions, if you propose this cycle, you signal that you understand project engineering as an integrated management system.

Look-Ahead Planning and Constraint Removal

Engineering execution suffers when constraints prevent work:

• materials not delivered
• drawings not approved
• labour not available
• site access not granted
• testing resources not ready

Look-ahead planning solves this:

• plan 2–6 weeks ahead
• identify constraints
• remove constraints (obtain permits, approve drawings, confirm supplier delivery)

In an exam scenario:

• if the question highlights “waiting for drawings” or “site not ready,” your answer should suggest constraint identification and removal.

Stakeholder Management and Communication: Engineering Stakeholder Networks

Project engineering involves stakeholders with different priorities:

• client/owner: value, compliance, delivery outcomes
• engineers: technical correctness and evidence
• procurement: supplier performance and lead time
• contractors: workable instructions, resource availability
• regulators/auditors: safety and compliance proof
• end users/operations: readiness, maintainability, handover documents

Communication Management: Ensuring Single Source of Truth

A key exam point: inconsistent communication causes engineering confusion. Solutions include:

• controlled document distribution
• meeting minutes with action tracking
• formal change notices
• procurement release instructions tied to specific revision numbers

When asked “what would you do,” an ideal response includes:

• identify the misalignment
• correct information flow
• update baselines or documents where necessary
• confirm in writing

Exam Practice Toolkit for PEM117V: Structured Answer Frameworks, Diagrams in Words, and Scenario Solutions

This section provides an exam-focused toolkit: how to structure your responses, how to handle common PEM117V scenario types, and how to demonstrate management technique application rather than just definitions. The aim is to help you score consistently by presenting answers in a logical sequence that mirrors project engineering management practice.

The “PEM117V” Response Framework: Problem → Technique → Evidence → Action

When answering a scenario or short essay question, a marker-friendly structure can be:

1. Restate the scenario problem clearly
   • “There is schedule slippage due to late design release and procurement mismatch.”
2. Name the relevant management technique(s)
   • baseline control, configuration management, change control, risk response.
3. State the expected outputs/evidence
   • updated risk register, NCR logs, revised baseline, updated ITP, revision-controlled drawings.
4. Propose corrective and preventive actions
   • specific actions with owners and timing logic (e.g., “within 48 hours convene CCB; within one week issue revision-controlled package; within next look-ahead plan remove constraints”).
5. Describe monitoring and follow-up
   • schedule update cadence, EVM metrics, and QA verification steps.

This framework prevents vague answers.

Scenario Type 1: “Design Change Approved Late—What Now?”

Common in exams:

• client approves change after procurement orders already placed
• contractors started installation based on previous drawings

Best practice management technique answer:

• initiate a formal change request if not already authorised
• assess impacts:
  • cost impact: rework, materials substitution
  • schedule impact: installation stop/go, procurement lead times
  • quality impact: test plan updates
• decide via change control board
• update technical baseline only when approved
• enforce configuration management:
  • controlled document issuance with revision identifiers
  • ensure procurement and site instructions match the approved revision
• implement corrective actions and update schedule logic

Preventive action:

• improve gate timing and ensure design release is aligned with procurement “order lock” points
• enhance risk response for “drawing approval delay” and supplier dependence

Scenario Type 2: “Quality Fails During Commissioning—Why and What to Do?”

Exam expects:

• contain the problem and avoid repeating it
• show root cause thinking and verification

Correct sequence:

1. Raise NCR and contain affected work.
2. Perform RCA (root cause analysis).
3. Implement corrective action.
4. Update ITP and test procedures if needed.
5. Verify by re-testing (evidence required).
6. Review whether the failure indicates a weakness in QA (e.g., method statement not followed, calibration not current, incorrect spec interpretation).
7. Update lessons learned and adjust future work plans.

High-scoring addition:

• link corrective action to engineering evidence:
  • “as-built documentation,”
  • “test records,”
  • “traceability between drawing revision and test procedure.”

Scenario Type 3: “Schedule Slips but Costs Are Lower—Is That Good?”

A subtle exam trap. If SPI < 1 but CPI > 1, you might be “spending less but not getting progress.” That can happen if:

• work is deferred
• incomplete work is counted as completed
• work packages are not actually earned (progress measurement issue)

A strong answer:

• question the integrity of earned value measurement:
  • are milestones truly earned based on acceptance criteria?
• review whether quality or compliance was compromised.
• forecast completion using updated performance data.
• propose actions:
  • tighten progress measurement rules
  • ensure technical acceptance criteria define “earned” progress
  • remove constraints and accelerate only after quality risks are addressed

Scenario Type 4: “Supplier Lead Time Overrun—Critical Path Impact?”

Your answer should show engineering schedule logic and procurement risk management.

Steps:

1. Identify affected equipment and work packages.
2. Update schedule logic:
   • shift dates where dependencies require it
3. Evaluate alternatives:
   • expedite freight (cost trade-off)
   • find qualified substitute supplier (quality and compliance checks)
   • re-sequence installation and commissioning activities
4. Update risk register and procurement plan.
5. Communicate impacts to stakeholders.
6. Track with revised baseline and EVM metrics.

Key exam point:

• long-lead items often dominate critical path; schedule recovery must be realistic and tied to procurement decisions.

Drawing “In Words”: How to Describe a Baseline-Control Diagram

Examiners sometimes like clear conceptual structure. If asked to “illustrate” a process, you can describe the diagram in words:

• Approved Technical Baseline (drawings/specs with revisions)
  • linked to Change Control Board
    • receives change requests
    • approves/rejects
  • connected to Configuration Management
    • ensures only approved revisions are issued and used
  • linked to Schedule/Cost Baselines
    • updated only after approved changes
  • monitored by Progress and QA Evidence
    • acceptance criteria and test results confirm completion

This narration signals process understanding.

A Mini-Checklist for Exam Answers (What Markers Look For)

Use this while preparing. Good PEM117V answers usually include:

• named baselines (scope/schedule/cost/technical)
• WBS-linked measurement logic (what “progress” means)
• risk identification + response + triggers
• change control steps and configuration management
• quality assurance and QC evidence requirements
• performance monitoring interpretation (EVM-like reasoning)
• clear corrective actions and follow-up monitoring

Consistency and Calculation Notes (If Numbers Appear)

If a question provides quantitative data, maintain internal logic:

• explain which values correspond to PV/EV/AC (if using EVM)
• compute variances and indices correctly
• interpret results against engineering causes and actions

Even if your exam does not require formulas explicitly, the interpretation should be consistent with project engineering outcomes.

Integrated Summary: How PEM117V Management Techniques Work Together

Project Engineering: Management Techniques (PEM117V) is best understood as an integrated management system rather than a set of disconnected tools. The baseline defines the target; the WBS and schedule define what work must occur and in what order; cost budgeting ties engineering work to financial control; risk management prepares the team for uncertainty; change control and configuration management protect the technical baseline; quality management ensures acceptance; and performance monitoring verifies whether the project is actually delivering engineering value, not just spending time or money.

When exams ask “what should be done,” the highest scoring answers typically show the linkages:

• a delay becomes an engineering and procurement problem, not only a schedule problem
• a defect becomes a QA/QC and verification-evidence problem, not only a “fix it” problem
• a change becomes a contractual and technical baseline problem, not only a “update drawing” problem
• progress becomes a deliverables-and-acceptance measurement problem, not a simple percentage completion problem

Finally, PEM117V expects structured judgement. It is not enough to name techniques; you must apply them in the right sequence, with realistic consequences, and with the kind of governance and evidence that engineering delivery requires.