Project Management

Learning Objectives

  • Define project management and distinguish between Traditional and Agile approaches.
  • Describe the five phases of the project life cycle.
  • Explain the importance and structure of a Work Breakdown Structure (WBS).
  • Compare scheduling techniques including Gantt Charts, CPM, and PERT.
  • Understand risk management, resource allocation, and project crashing strategies.
  • Compute and interpret Earned Value Analysis (EVA) metrics.

Project Management Approaches

Project

A temporary endeavor undertaken to create a unique product, service, or result. Unlike ongoing operations, a project has distinct start and end dates, specified resource constraints, and highly specific, measurable objectives.

Project Management Methodologies

  • Predictive or plan-driven approaches: Plan scope, interfaces, and sequence in advance, then manage changes through defined controls. These can suit work with tightly coupled physical or regulatory constraints; they do not make change impossible, and project controls still govern it.
  • Adaptive or iterative approaches: Develop and review increments of work with stakeholders, adjusting as evidence changes. Iterations or sprints may use different lengths and controls. These approaches can suit software, research, or selected design work; project teams can combine them with predictive controls where appropriate.

The Project Life Cycle

The project life cycle provides a predictable framework for managing the complexities of an engineering project. It typically consists of five distinct, yet overlapping phases:

Five Phases of Project Management

  1. Initiation: Defining the high-level project scope, identifying key stakeholders, and obtaining official authorization (usually via a Project Charter) to begin allocating resources.
  2. Planning: Establishing the detailed scope, defining objectives, developing the Work Breakdown Structure (WBS), and creating comprehensive schedules, budgets, and risk management plans.
  3. Execution: The phase where the actual work is performed. Resources are deployed, teams are managed, and the project deliverables are physically created.
  4. Monitoring and Controlling: Simultaneously occurring with execution, this phase involves tracking progress against the baseline plan, reviewing performance metrics, and regulating progress via corrective actions when deviations occur.
  5. Closing: Finalizing all project activities, handing over the deliverables to the client, releasing project resources, and formally closing the project with a "lessons learned" review.
Project Lifecycle and Change Control

Authorize a project, build a controlled plan, execute and monitor work, and route significant changes through the assigned authority.

Project process groups can overlap, and a project may use different phase names. A baseline or scope change is made only through the project's approved authority and documented change process. Continue within the current authorization when a request is declined; hold or escalate when work cannot safely or properly continue under that authorization.

Project Lifecycle and Change ControlAuthorize a project, build a controlled plan, execute and monitor work, and route significant changes through the assigned authority.. Project process groups can overlap, and a project may use different phase names. A baseline or scope change is made only through the project's approved authority and documented change process. Continue within the current authorization when a request is declined; hold or escalate when work cannot safely or properly continue under that authorization.. Start → Initiate: define need, sponsor, scope, and stakeholders; Initiate: define need, sponsor, scope, and stakeholders → Is the project authorized to proceed?; Is the project authorized to proceed? — Yes → Plan scope, schedule, budget, resources, and risks; obtain required approval; Is the project authorized to proceed? — No → Hold or close under the assigned authority; Plan scope, schedule, budget, resources, and risks; obtain required approval → Execute authorized work and manage the team; Execute authorized work and manage the team → Monitor scope, schedule, cost, quality, and risks; Monitor scope, schedule, cost, quality, and risks → Are deliverables complete for acceptance review?; Are deliverables complete for acceptance review? — Yes → Complete acceptance, handover, and closeout; Are deliverables complete for acceptance review? — No → Material variance, risk trigger, or requested change?; Material variance, risk trigger, or requested change? — No → Continue planned work; keep monitoring; Material variance, risk trigger, or requested change? — Yes → Assess impacts and document a change request; Assess impacts and document a change request → Did the assigned authority approve the change?; Did the assigned authority approve the change? — Yes → Update controlled plans and communicate the decision; Did the assigned authority approve the change? — No → Can work proceed under current authorization?; Can work proceed under current authorization? — Yes → Resume authorized work; Can work proceed under current authorization? — No → Hold and escalate under project governance; Resume authorized work → Execute authorized work and manage the team; Update controlled plans and communicate the decision → Execute authorized work and manage the team; Continue planned work; keep monitoring → Execute authorized work and manage the team

Start → Initiate: define need, sponsor, scope, and stakeholders; Initiate: define need, sponsor, scope, and stakeholders → Is the project authorized to proceed?; Is the project authorized to proceed? — Yes → Plan scope, schedule, budget, resources, and risks; obtain required approval; Is the project authorized to proceed? — No → Hold or close under the assigned authority; Plan scope, schedule, budget, resources, and risks; obtain required approval → Execute authorized work and manage the team; Execute authorized work and manage the team → Monitor scope, schedule, cost, quality, and risks; Monitor scope, schedule, cost, quality, and risks → Are deliverables complete for acceptance review?; Are deliverables complete for acceptance review? — Yes → Complete acceptance, handover, and closeout; Are deliverables complete for acceptance review? — No → Material variance, risk trigger, or requested change?; Material variance, risk trigger, or requested change? — No → Continue planned work; keep monitoring; Material variance, risk trigger, or requested change? — Yes → Assess impacts and document a change request; Assess impacts and document a change request → Did the assigned authority approve the change?; Did the assigned authority approve the change? — Yes → Update controlled plans and communicate the decision; Did the assigned authority approve the change? — No → Can work proceed under current authorization?; Can work proceed under current authorization? — Yes → Resume authorized work; Can work proceed under current authorization? — No → Hold and escalate under project governance; Resume authorized work → Execute authorized work and manage the team; Update controlled plans and communicate the decision → Execute authorized work and manage the team; Continue planned work; keep monitoring → Execute authorized work and manage the team

  • Start: terminator
  • Initiate: define need, sponsor, scope, and stakeholders: process
  • Is the project authorized to proceed?: decision
  • Hold or close under the assigned authority: terminator
  • Plan scope, schedule, budget, resources, and risks; obtain required approval: process
  • Execute authorized work and manage the team: process
  • Monitor scope, schedule, cost, quality, and risks: process
  • Are deliverables complete for acceptance review?: decision
  • Material variance, risk trigger, or requested change?: decision
  • Continue planned work; keep monitoring: process
  • Assess impacts and document a change request: process
  • Did the assigned authority approve the change?: decision
  • Update controlled plans and communicate the decision: document
  • Can work proceed under current authorization?: decision
  • Hold and escalate under project governance: terminator
  • Resume authorized work: process
  • Complete acceptance, handover, and closeout: terminator
Decompose Scope into Work Packages

A work breakdown structure organizes the approved project scope hierarchically.

Decompose deliverables into manageable components until each work package can be estimated, assigned, scheduled, and controlled. The WBS describes scope; it is not itself a schedule or an organizational chart.
Project deliverable
Major deliverables or control accounts
Sub-deliverables
Work packages with defined outputs

Work Breakdown Structure (WBS)

A Work Breakdown Structure (WBS) is a foundational project management tool. It is a hierarchical, deliverable-oriented decomposition of the total scope of work to be carried out by the project team. It breaks down a massive, complex project into smaller, highly manageable components called work packages, which can then be easily scheduled, cost-estimated, and assigned.

Scheduling Techniques

Accurate scheduling is the difference between a profitable engineering project and a catastrophic failure. Managers use several tools to visualize and calculate schedules.

Gantt Charts

A visual timeline bar chart that illustrates a project schedule. It clearly shows the start and finish dates of the various elements (work packages) of a project along a horizontal time axis, making it excellent for high-level stakeholder communication.

Critical Path Method (CPM)

A deterministic scheduling method that assumes task durations are known with certainty. It uses fixed time estimates for each activity.

  • Critical Path: The longest continuous sequence of activities through the network diagram; under the network's dependency and duration assumptions, it governs the calculated project completion time.
  • Slack (Float): Time an activity can be delayed without delaying a successor (free float) or the calculated project completion date (total float). Activities on a critical path have zero total float under the current network assumptions; free float is a separate measure.

Program Evaluation and Review Technique (PERT)

A probabilistic scheduling method designed to handle uncertainty in task durations, commonly used in research and development or highly innovative engineering projects. It uses three distinct time estimates for each activity:

  • Optimistic time (tot_o): The minimum possible time to perform the activity, assuming everything goes perfectly and no risks occur.
  • Most likely time (tmt_m): The best, most realistic estimate of the time required to perform the activity under normal conditions.
  • Pessimistic time (tpt_p): The maximum possible time required to perform the activity, assuming almost everything goes wrong (excluding major catastrophes or acts of God).

PERT Expected Time

Calculates the expected time for a PERT activity based on its optimistic, most likely, and pessimistic estimates.

te=to+4tm+tp6t_e = \frac{t_o + 4t_m + t_p}{6}

Variables

SymbolDescriptionUnit
tet_eExpected time-
tot_oOptimistic time-
tmt_mMost likely time-
tpt_pPessimistic time-

PERT Standard Deviation

Determines the uncertainty or variance associated with the activity duration estimate.

σ=tp−to6\sigma = \frac{t_p - t_o}{6}

Variables

SymbolDescriptionUnit
σ\sigmaStandard deviation (uncertainty) of the activity duration-
tot_oOptimistic time-
tpt_pPessimistic time-

Interactive Simulation

Use the simulation below to explore how PERT charts estimate project timelines based on probabilistic duration inputs.

Interactive PERT Chart

4233540
AStart
BDesign
CPermits
DProcure
ESite Prep
FBuild
GFinish

Click on any node in the network diagram above to view detailed scheduling information (ES, EF, LS, LF, and Slack).

Interactive Simulation

Use the simulation below to explore how CPM determines the critical path and available slack in a project schedule network.

CPM Network Diagram

Duration: 12 days

Activity Durations

Adays
Bdays
Cdays
Ddays
Edays

ES: Earliest Start

EF: Earliest Finish

LS: Latest Start

LF: Latest Finish

SL: Slack (Float)

START
ES:0
D:3
EF:3
Activity A
LS:4
SL:4
LF:7
ES:0
D:4
EF:4
Activity B
LS:0
SL:0
LF:4
ES:3
D:2
EF:5
Activity C
LS:7
SL:4
LF:9
ES:4
D:5
EF:9
Activity D
LS:4
SL:0
LF:9
ES:9
D:3
EF:12
Activity E
LS:9
SL:0
LF:12
END

Critical Chain Project Management (CCPM)

Developed by Eliyahu M. Goldratt, CCPM is an alternative to traditional CPM. While CPM focuses strictly on strict task dependencies and rigid deadlines, CCPM emphasizes managing the limited resources required to execute those tasks and the human psychological factors that cause delays.

  • Parkinson's Law: The observation that "work expands so as to fill the time available for its completion." CCPM addresses task-level uncertainty and behavior through its planning and buffer approach; it does not require a universal percentage cut to every estimate.
  • Student Syndrome: The tendency of people to wait until the absolute last possible minute to begin a task.
  • Project Buffers: CCPM places time buffers at the project and feeding-chain level to manage uncertainty and resource constraints. Buffer sizing and monitoring depend on the project method and evidence; the buffer is not a guarantee against delay.

Resource Management

Schedules generated by CPM or PERT often ignore the physical reality of resource availability. A schedule might require 5 cranes on a Tuesday, but the contractor only owns 3.

Resource Scheduling Strategies

  • Resource Leveling: Adjusting the start and finish dates of activities based strictly on resource constraints (e.g., delaying non-critical tasks because the necessary crane is currently occupied). This often results in extending the overall project duration beyond the original critical path.
  • Resource Smoothing: Reallocating resources within the available slack (float) of non-critical activities to create a more even, predictable daily demand for resources, without extending the final project deadline.

Project Risk Management

Engineering projects are inherently risky. A proactive risk management process is required to identify and handle uncertainties before they derail the project.

Four Steps of Risk Management

  1. Risk Identification: Systematically brainstorming potential events (weather delays, supplier bankruptcy, design flaws) that could negatively impact the project.
  2. Risk Assessment: Analyzing both the probability of the risk occurring and the severity of its impact (cost or schedule delay) using a Risk Matrix.
  3. Risk Response Planning: Select a response suited to the cause, exposure, and project authority: Avoid the threat, Transfer or share some financial exposure through an appropriate arrangement, Mitigate probability or impact, or Accept it with a documented contingency or monitoring plan where authorized. A contract or insurance may reallocate some consequences; it does not make the underlying risk disappear.
  4. Risk Monitoring: Continuously tracking identified risks and identifying new ones throughout the project execution phase.
Iterative Project Risk Management

Identify and assess risks against project criteria, assign proportionate responses, and revisit them as evidence or conditions change.

Set probability/impact scales and escalation thresholds in the project risk plan. Response options depend on the risk, authority, and project context. Contractual or insurance transfer may reallocate some exposure but does not make every consequence disappear. This is an iterative management process, not a one-time checklist.

Iterative Project Risk ManagementIdentify and assess risks against project criteria, assign proportionate responses, and revisit them as evidence or conditions change.. Set probability/impact scales and escalation thresholds in the project risk plan. Response options depend on the risk, authority, and project context. Contractual or insurance transfer may reallocate some exposure but does not make every consequence disappear. This is an iterative management process, not a one-time checklist.. Start or scheduled risk review → Set project risk roles, criteria, and review triggers; Set project risk roles, criteria, and review triggers → Identify threats and opportunities with their causes; Identify threats and opportunities with their causes → Assess probability, impact, and uncertainty using project scales; Assess probability, impact, and uncertainty using project scales → Does the risk exceed the project's review threshold?; Does the risk exceed the project's review threshold? — Yes → Choose a proportionate response, owner, trigger, and contingency; Does the risk exceed the project's review threshold? — No → Record owner and watch conditions under the risk plan; Record owner and watch conditions under the risk plan → Monitor triggers, response effectiveness, and new evidence; Choose a proportionate response, owner, trigger, and contingency → Is the response within the team's authority and resources?; Is the response within the team's authority and resources? — Yes → Implement the authorized response and record residual exposure; Is the response within the team's authority and resources? — No → Seek required authority before implementation; Implement the authorized response and record residual exposure → Monitor triggers, response effectiveness, and new evidence; Monitor triggers, response effectiveness, and new evidence → Has the risk changed, occurred, or become obsolete?; Has the risk changed, occurred, or become obsolete? — Yes → Update the risk record and reassess; Has the risk changed, occurred, or become obsolete? — No → Continue scheduled monitoring and review; Update the risk record and reassess → Identify threats and opportunities with their causes

Start or scheduled risk review → Set project risk roles, criteria, and review triggers; Set project risk roles, criteria, and review triggers → Identify threats and opportunities with their causes; Identify threats and opportunities with their causes → Assess probability, impact, and uncertainty using project scales; Assess probability, impact, and uncertainty using project scales → Does the risk exceed the project's review threshold?; Does the risk exceed the project's review threshold? — Yes → Choose a proportionate response, owner, trigger, and contingency; Does the risk exceed the project's review threshold? — No → Record owner and watch conditions under the risk plan; Record owner and watch conditions under the risk plan → Monitor triggers, response effectiveness, and new evidence; Choose a proportionate response, owner, trigger, and contingency → Is the response within the team's authority and resources?; Is the response within the team's authority and resources? — Yes → Implement the authorized response and record residual exposure; Is the response within the team's authority and resources? — No → Seek required authority before implementation; Implement the authorized response and record residual exposure → Monitor triggers, response effectiveness, and new evidence; Monitor triggers, response effectiveness, and new evidence → Has the risk changed, occurred, or become obsolete?; Has the risk changed, occurred, or become obsolete? — Yes → Update the risk record and reassess; Has the risk changed, occurred, or become obsolete? — No → Continue scheduled monitoring and review; Update the risk record and reassess → Identify threats and opportunities with their causes

  • Start or scheduled risk review: terminator
  • Set project risk roles, criteria, and review triggers: process
  • Identify threats and opportunities with their causes: process
  • Assess probability, impact, and uncertainty using project scales: process
  • Does the risk exceed the project's review threshold?: decision
  • Record owner and watch conditions under the risk plan: process
  • Choose a proportionate response, owner, trigger, and contingency: process
  • Is the response within the team's authority and resources?: decision
  • Seek required authority before implementation: terminator
  • Implement the authorized response and record residual exposure: process
  • Monitor triggers, response effectiveness, and new evidence: process
  • Has the risk changed, occurred, or become obsolete?: decision
  • Update the risk record and reassess: process
  • Continue scheduled monitoring and review: terminator
Qualitative Risk Priority Matrix

Compare likelihood and impact using scales defined for the project.

This schematic matrix is a prioritization aid. Agree on rating definitions, distinguish inherent from residual exposure, and use analysis appropriate to the consequences. A color category alone does not decide treatment.
Low likelihood / low impact: record and review
Higher likelihood / low impact: monitor or reduce cause
Low likelihood / high impact: plan contingencies
Higher likelihood / high impact: prioritize response

Project Crashing

When a project falls behind schedule, managers may consider crashing, a schedule compression technique. It adds or changes resources on activities that currently control the calculated completion date, then compares feasible time savings, cost, quality, safety, and resource constraints. Recalculate the network after each change because another path can become critical.

Crash Cost per Unit Time

To determine which critical path activities to crash first, managers calculate the cost to shorten an activity by one unit of time (e.g., one day) and select the cheapest option.

Crash Cost per Time Unit

Calculates the additional cost required to shorten a task's duration by a single unit of time.

Crash Cost per Time Unit=Cc−CnTn−Tc\text{Crash Cost per Time Unit} = \frac{C_c - C_n}{T_n - T_c}

Variables

SymbolDescriptionUnit
CcC_cCrash Cost-
CnC_nNormal Cost-
TnT_nNormal Time-
TcT_cCrash Time-

Earned Value Analysis (EVA)

EVA is an advanced, industry-standard method of measuring project performance and progress. It provides a highly objective view by combining measurements of scope, schedule, and cost into a single integrated quantitative system.

Key EVA Metrics

EVA relies on three core data points taken at a specific moment in time:

  • Planned Value (PV): The authorized budget assigned to the scheduled work that should have been accomplished by this date. (Also called Budgeted Cost of Work Scheduled - BCWS).
  • Earned Value (EV): The measure of work actually performed, expressed in terms of the budget originally authorized for that work. (Also called Budgeted Cost of Work Performed - BCWP).
  • Actual Cost (AC): The total realized cost actually incurred for the work performed to date. (Also called Actual Cost of Work Performed - ACWP).

Schedule Performance Index (SPI)

Measures how efficiently a project is progressing compared to the planned schedule.

SPI=EVPV\text{SPI} = \frac{\text{EV}}{\text{PV}}

Variables

SymbolDescriptionUnit
SPI\text{SPI}Schedule Performance Index-
EV\text{EV}Earned Value-
PV\text{PV}Planned Value-

SPI Interpretation

Interpretation at the data date: If SPI<1\text{SPI} < 1, earned value is below planned value; if SPI>1\text{SPI} > 1, it is above planned value. Interpret the ratio with the schedule network and status data.

Cost Performance Index (CPI)

Measures the financial effectiveness and cost efficiency of a project.

CPI=EVAC\text{CPI} = \frac{\text{EV}}{\text{AC}}

Variables

SymbolDescriptionUnit
CPI\text{CPI}Cost Performance Index-
EV\text{EV}Earned Value-
AC\text{AC}Actual Cost-

CPI Interpretation

Interpretation at the data date: If CPI<1\text{CPI} < 1, earned value is below actual cost; if CPI>1\text{CPI} > 1, it is above actual cost. This is a cost-efficiency ratio to date, not by itself a final-cost forecast.

Read Schedule and Cost Performance Together

SPI and CPI compare earned value with planned value and actual cost.

Values below 1 indicate less earned value than the comparison baseline or cost incurred; values above 1 indicate more earned value per baseline unit. Indices summarize status to a date and do not by themselves forecast completion or explain causes.
SPI < 1 and CPI < 1: behind plan and cost-inefficient
SPI < 1 and CPI > 1: behind plan, cost-efficient to date
SPI > 1 and CPI < 1: ahead of plan, cost-inefficient
SPI > 1 and CPI > 1: ahead of plan and cost-efficient to date

Agile Project Management

While traditional engineering projects (like bridge construction) follow a sequential, "Waterfall" methodology, many modern projects, particularly those involving software or complex systems integration, utilize Agile Project Management.

Core Principles of Agile

Agile is an iterative approach that focuses on continuous releases and incorporating customer feedback with every iteration.

  • Iterative Development: Work is organized into manageable iterations or, in Scrum, timeboxed sprints whose duration is set by the team and its framework.
  • Flexibility and Adaptability: Requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Changes are welcomed, even late in development.
  • Customer Collaboration: The customer or client is continuously involved in the development process, reviewing and providing feedback on each iteration.
  • Working Deliverables: The primary measure of progress is a functional product or deliverable piece of work at the end of each sprint.

Scrum Framework

Scrum is the most widely used Agile framework. It involves specific roles, artifacts, and ceremonies.

  • Roles: Scrum Master (facilitates the process), Product Owner (represents the stakeholders and prioritizes work), and Development Team (the cross-functional team doing the work).
  • Artifacts: Product Backlog (prioritized list of everything needed in the product), Sprint Backlog (the work selected for the current sprint), and Increment (the sum of all completed backlog items).
  • Ceremonies: Sprint Planning (planning the work for the upcoming sprint), Daily Scrum (short daily meeting to discuss progress and blockers), Sprint Review (demonstrating the completed work), and Sprint Retrospective (reflecting on the sprint and identifying improvements).

Waterfall vs. Agile Applicability

Predictive, adaptive, and hybrid approaches can all appear in engineering work. Physical construction has dependencies and authorization requirements that affect how and when changes can be made; that does not make design changes impossible. Select and tailor controls to the work, contract, safety requirements, and decision authority.

Key Takeaways
  • Engineering managers choose between Traditional (Waterfall) methods for physical projects with stable requirements and Agile methods for iterative, software/R&D environments.
  • A project is a temporary endeavor with distinct phases: Initiation, Planning, Execution, Monitoring/Controlling, and Closing.
  • The Work Breakdown Structure (WBS) is a critical tool for hierarchically decomposing project scope into manageable work packages.
  • Scheduling techniques like CPM and PERT determine the Critical Path, while Resource Leveling/Smoothing ensure those schedules are actually achievable with physical constraints.
  • Proactive Risk Management (Identify, Assess, Mitigate/Transfer) and Crashing (compressing the schedule via critical path resource injection) are vital for overcoming unexpected hurdles.
  • Earned Value Analysis (EVA) provides an objective, integrated measure of project health by comparing Planned Value (PV), Earned Value (EV), and Actual Cost (AC) to generate Schedule (SPI) and Cost (CPI) performance indices.

References