Project Management for Engineers (PERT/CPM/EVM/Agile) — Engineering Reference

Project Management for Engineers — Engineering Reference

1. At a glance

Project management for engineers is the discipline of planning, scheduling, costing, risking, and stakeholder-coordinating a finite effort (a project, with a definite start, end, and deliverable) as distinct from steady-state operations. The PMBOK Guide (PMI 2021, 7th ed) defines a project as “a temporary endeavour undertaken to create a unique product, service, or result”; ISO 21500:2021 and ISO 21502:2020 give the international-standard equivalent definitions. Engineering projects span aerospace + defence programmes (DoD 5000.02), construction (CMAA, AACE International), product development (NPD stage-gate), IT infrastructure rollouts, and R&D — and routinely overrun on cost and schedule, which is why the discipline exists.

The toolkit splits into three overlapping families that coexist in 2026:

1. Predictive / “waterfall” — PMBOK-style, plan-driven. WBS → activity network → CPM/PERT schedule → EVM cost control. Right when scope is well-defined up front (large infrastructure, regulated aerospace, capital plant).
2. Adaptive / agile — Scrum (Sutherland-Schwaber 1995), Kanban (Anderson 2010), SAFe (Leffingwell 2011), LeSS, DAD. Right when scope evolves under learning (software, R&D, product-market fit).
3. Hybrid — agile development phases nested inside stage-gate or systems-engineering V-models. Now the modal approach in aerospace + defence + medical-device + automotive electronics where regulatory frameworks (DO-178C, IEC 62304, ISO 26262, ARP4754A) demand traceable verification but execution benefits from iteration.

Systems engineering (INCOSE Handbook 5th ed 2023, NASA NPR 7120.5F, ARP4754A, MIL-STD-499C) overlays the technical content on whichever lifecycle: V-model, requirements management, trade studies, TRL/MRL gates, MBSE. Engineering project managers are typically responsible for both the management-system (cost/schedule/risk) and the technical baseline; large programmes split the role between a Programme Manager and a Chief Engineer / Chief Systems Engineer.

Where it sits in the engineering stack: above lean-manufacturing and six-sigma (which improve recurring operations), adjacent to reliability-engineering (which manages the technical content of RAMS), and below corporate strategy (portfolio management). The PMI competency triangle — Ways of Working, Power Skills, Business Acumen — captures the modern view that engineering PMs need technical depth + leadership + strategic alignment, not just Gantt-chart literacy.

2. Why it matters

Engineering project performance is poor on average and catastrophic in the tail. Flyvbjerg’s “How Big Things Get Done” (2023) compiles a 16 000-project database (infrastructure, IT, defence, energy) and reports: average cost overrun ≈ 38 %, average schedule slip ≈ 60 %, with a fat-tailed distribution — IT megaprojects exhibit ~18 % probability of >50 % cost overrun and ~7 % probability of cancellation. Classic case studies: Boston Big Dig (1991-2007, originally $2.6B\to final$14.8 B), Berlin Brandenburg airport (planned 2007 → opened 2020), Sydney Opera House (1959 estimate AUD 7 M → 1973 final AUD 102 M), F-35 Lightning II (2001 estimate $233B\to 2025lifecycleestimate$1.7 T), Boeing 787 Dreamliner (3 years late, ~$30 B above plan).

Aerospace + defence programmes above ~$100 M routinely mandate quantitative project controls: ANSI EIA-748-D (32 EVM system criteria), DoD DI-MGMT-81861/81466/81467 data items, PARS II (Project Analysis & Reporting System) at DOE, and NASA’s NPR 7120.5F (programme management) + NPR 7123.1C (systems engineering). NASA estimates that programmes meeting EVM compliance criteria experience ~30 % lower cost growth (NASA Cost Symposium aggregated data). EVM is not magic — it surfaces overruns 6-12 months earlier than monthly accruals do, but it does not prevent them.

The economic value of competent PM is not just the avoided overrun. Schedule compression has direct revenue value: shipping a product 6 months earlier captures market share; bringing a refinery online 3 months earlier on a 25-year asset is ~1 % of NPV. Reinertsen (“The Principles of Product Development Flow”, 2009) makes the case in detail with cost-of-delay (CoD) quantified in $/week — a metric that anchors prioritisation decisions in dollar terms rather than political ones.

3. First principles

3.1 The iron triangle (and its modern critique)

The classical triple constraint: scope, schedule, cost. “Pick two.” Quality is sometimes drawn as a fourth corner; in modern thinking quality is emergent from the other three. Modern variants:

• PMBOK 7th ed (2021) dropped the iron triangle in favour of eight performance domains (stakeholders, team, life cycle, planning, project work, delivery, measurement, uncertainty). Recognises that the triangle is necessary but not sufficient.
• Atkinson’s “square route” (1999) — scope/cost/schedule + benefits (organisational + stakeholder). Pushes PM toward outcome, not output.
• Agile inversion — fix schedule + cost (sprint cadence, team size), flex scope.

3.2 Work Breakdown Structure (WBS)

The WBS is the deliverable-oriented hierarchical decomposition of the total project scope. Governing rule: the 100 % rule — children of a parent must sum to the parent’s full scope, no more no less. MIL-STD-881F (2022) is the canonical defence WBS standard, prescribing standard top-level breakdowns for aircraft, missile, ship, ground-vehicle, space, ordnance, electronics, surface-vehicle, automated information systems, and unmanned-air-vehicle systems.

• Levels: typically 3-5 levels (Level 1 = project total; Level 5 = work package, 80-hr rule recommended — no single work package > ~80 person-hours).
• WBS Dictionary — each WBS element gets a narrative description, deliverables, exit criteria, charging account.
• Control Account (CA) — the management-control point where scope + schedule + budget meet; the EVM “unit” — typically a Level 3 or Level 4 element.

3.3 Activity network

Once WBS is decomposed to work packages, decompose further to activities — discrete schedulable tasks. Each activity has duration, predecessors, and (in resource-loaded schedules) resource requirements.

Precedence relationships (per PMBOK + Primavera P6 conventions):

Relation	Symbol	Meaning
Finish-to-Start	FS	B starts after A finishes (most common)
Start-to-Start	SS	B starts after A starts
Finish-to-Finish	FF	B finishes after A finishes
Start-to-Finish	SF	B finishes after A starts (rare)

Lags + leads are integer offsets on relations (FS+5d = B starts 5 d after A finishes).

3.4 Critical path + float

The critical path is the longest sequence of dependent activities, defining the minimum project duration. Activities on the critical path have zero float; delaying any of them delays the project. Float (slack) comes in two flavours:

• Total float (TF) = LF − EF = LS − ES. The amount an activity can slip without delaying the project end.
• Free float (FF) = ES of next activity − EF of this. The amount an activity can slip without delaying any successor.

3.5 Resource leveling and the RCPSP

Resource-Constrained Project Scheduling Problem (RCPSP) is NP-hard in the general case (Blazewicz et al. 1983). Real schedulers (Primavera P6, MS Project) use heuristics — typically priority-rule-based (most total float first, longest path first, latest finish first) with optional genetic-algorithm or constraint-programming back-ends in newer tools (e.g. Smartsheet’s CP-SAT integration).

3.6 Risk register

A structured table of identified risks with probability, impact, response strategy, owner, trigger, residual risk. Standards: ISO 31000:2018 (risk management principles), ISO 31010:2019 (techniques), PMI Practice Standard for Project Risk Management 2009.

Response	When
Avoid	Eliminate the risk by changing scope/plan (probability → 0)
Transfer	Insurance, fixed-price contract, warranty — shift to a third party
Mitigate	Reduce probability or impact (engineering action)
Accept	Active (contingency reserve) or passive (deal with it if it happens)

3.7 Stakeholder map

Power × interest grid (Mendelow 1991): High-Power + High-Interest = manage closely; High-Power + Low-Interest = keep satisfied; Low-Power + High-Interest = keep informed; Low-Power + Low-Interest = monitor. The two-axis grid hides nuance (regulator vs end-user are both “high power high interest” but require very different engagement); modern variants add salience, urgency, attitude dimensions.

4. Scheduling methods

4.1 Gantt chart — Henry Gantt 1910s

Visual horizontal-bar chart of activities vs time. Predates CPM/PERT by ~40 years. Foundational visualisation, still in every modern tool. Not a scheduling method — a display method.

4.2 CPM — Critical Path Method (Kelley + Walker, DuPont/Remington Rand 1957)

Deterministic activity durations. Forward pass computes ES (Early Start) + EF (Early Finish); backward pass computes LS (Late Start) + LF (Late Finish). Float = LF − EF. Critical path = activities with zero float. Standard since DuPont’s 1957 chemical-plant maintenance scheduling.

4.3 PERT — Program Evaluation and Review Technique (USN Special Projects Office 1958 Polaris)

3-point activity estimates: optimistic (a), most likely (m), pessimistic (b). Assumes β distribution (originally; sometimes triangular).

• Expected duration: t_e = (a + 4m + b) / 6
• Standard deviation: σ = (b − a) / 6
• Variance: σ² = ((b − a)/6)²

Project duration = sum of t_e along critical path. Project variance = sum of σ² along critical path (assuming activities are independent — a known approximation; correlated activities require Monte Carlo). Project duration distribution treated as normal (Central Limit Theorem) for ≥ 4-5 activities.

4.4 GERT, MPM, ADM/AON

• GERT (Graphical Evaluation and Review Technique, Pritsker 1966) — extends PERT with probabilistic branching and feedback loops. Used for R&D with rework.
• MPM (Metra Potential Method) — French, ~1958, uses activity-on-node (AON) and finish-to-start dependencies. Now subsumed into PDM.
• PDM (Precedence Diagramming Method) — AON network with all four FS/SS/FF/SF relations. Dominant since ~1980.
• ADM (Arrow Diagramming Method) — activity-on-arrow (AOA), older, still used in some legacy contexts.

4.5 Critical Chain Method (CCM, Goldratt 1997)

Theory-of-Constraints application to scheduling. Key claims: (i) per-activity safety inflates project duration; (ii) Parkinson’s law + student syndrome waste that safety; (iii) strip safety from activity estimates and aggregate it into project + feeder buffers. The longest path through the resource-constrained network is the critical chain (vs CPM’s critical path which ignores resource conflicts).

Buffer types: Project Buffer (end of critical chain), Feeder Buffer (where a non-critical-chain path joins), Resource Buffer (warns when a critical-chain resource is needed). Buffer sizing rules: typically 50 % of critical-chain duration (the “cut-and-paste” method) or root-mean-square of stripped safety (more rigorous).

CCM adoption is uneven — strong evidence from focused pilot studies; mixed evidence at programme scale. Notable users: Boeing (in segments), Mazda, US Air Force depot maintenance, ProChain consultancy clients.

4.6 Last Planner System (Ballard 1994, LCI 2000)

Pull-based construction-industry scheduling. Master schedule → look-ahead schedule (6-week rolling) → weekly work plan with Percent Plan Complete (PPC) = (committed tasks completed) / (committed tasks planned). PPC < 70 % = chronic planning failure. Used widely in commercial construction (Skanska, Turner, DPR, Mortenson). See lean-manufacturing §8.5.

4.7 Scheduling-method comparison

Method	Duration model	Best for	Tooling	Origin
Gantt	Bars	Display only	Universal	Gantt 1910s
CPM	Deterministic	Construction, capital plant	Primavera P6, MS Project	DuPont 1957
PERT	3-point β	R&D, defence development	Primavera, custom MC	USN 1958
Critical Chain	Stripped + buffers	Multi-project resource bottleneck	ProChain, Concerto	Goldratt 1997
Last Planner	Weekly pull	Construction	LeanKit, vPlanner	Ballard 1994
Monte Carlo	Distributions	Risk-aware large programmes	@RISK, Acumen Risk	1950s

5. Earned Value Management (EVM)

EVM is the canonical integrated cost/schedule control method. Originated as DoD’s C/SCSC (Cost/Schedule Control Systems Criteria, 1967); commercialised as ANSI/EIA-748 in 1998, current revision ANSI EIA-748-D (2019) with 32 system criteria across 5 process groups (Organisation, Planning/Scheduling/Budgeting, Accounting, Analysis/Management Reporting, Revisions/Data Maintenance).

5.1 Core measurements

At any status date for any control account:

Symbol	Name	Definition
PV	Planned Value (BCWS)	Budgeted Cost of Work Scheduled — time-phased budget
EV	Earned Value (BCWP)	Budgeted Cost of Work Performed — % complete × budget
AC	Actual Cost (ACWP)	Actual Cost of Work Performed — what we spent
BAC	Budget at Completion	Total approved budget
EAC	Estimate at Completion	Forecast final cost
ETC	Estimate to Complete	EAC − AC
VAC	Variance at Completion	BAC − EAC

5.2 Variances and indices

Metric	Formula	Interpretation
Cost Variance	CV = EV − AC	+ = under budget
Schedule Variance	SV = EV − PV	+ = ahead of schedule
Cost Performance Index	CPI = EV / AC	1.0 = on; <1 = over
Schedule Performance Index	SPI = EV / PV	1.0 = on; <1 = behind
To-Complete Performance Index (BAC)	TCPI = (BAC − EV)/(BAC − AC)	Future CPI needed to meet BAC
To-Complete Performance Index (EAC)	TCPI = (BAC − EV)/(EAC − AC)	Future CPI needed to meet EAC

5.3 EAC forecasting methods

Method	Formula	When
Optimistic	EAC = AC + (BAC − EV)	Past variance was one-off
Typical (CPI-based)	EAC = BAC / CPI	Past cost performance will continue
Pessimistic (cost + schedule)	EAC = AC + (BAC − EV)/(CPI · SPI)	Schedule slip drives cost too
Bottoms-up	EAC = AC + ETC_resestimated	Major rebaseline; team re-plans remaining work

DoD EVMSEC guidance for high-confidence forecasts: use the CPI·SPI form when CPI < 0.95 and project is < 30 % complete; use a bottoms-up rebaseline when CPI < 0.90 or > 70 % complete.

5.4 Earned Schedule (ES)

SV in dollars converges to zero at project completion even on a late project — a known EVM defect. Earned Schedule (Lipke 2003) redefines SV in time units: ES = the date on the PV curve at which the current EV would have been planned. SV(t) = ES − AT (actual time). SPI(t) = ES / AT. Continues to give meaningful schedule signal late in the project. Now standard in NASA, ESA, DoD programmes; PMI Practice Standard for Earned Value Management 3rd ed (2019) covers it.

5.5 EVM + CPM integration

Best practice: monitor critical-path tasks (CPM) and aggregated EVM together. CPM tells you which activities are late; EVM tells you how much late and how much over. A schedule slip on a non-critical-path activity may show SV < 0 but the project end date is unaffected.

6. Agile + iterative methods

6.1 Scrum (Sutherland + Schwaber 1995; Scrum Guide v2020)

Time-boxed iterative framework.

Element	Definition
Sprint	2-4 week fixed-duration iteration
Product Owner	Owns product backlog + priorities
Scrum Master	Process steward, removes impediments
Development Team	Cross-functional, 3-9 people
Product Backlog	Ordered list of all desired work
Sprint Backlog	Items committed for this sprint
Sprint Planning	Start-of-sprint commitment meeting
Daily Scrum	15-min standup
Sprint Review	End-of-sprint demo to stakeholders
Sprint Retrospective	End-of-sprint improvement meeting
Increment	Potentially shippable product at sprint end

Velocity = sum of story points completed per sprint. Used for capacity planning, not as a productivity metric (Goodhart’s law applies). Burndown / burnup charts visualise progress.

6.2 Kanban (Anderson 2010, based on Toyota Kanban)

Continuous flow, no time-boxed sprints. Core practices:

• Visualise the workflow — board with columns for each stage
• Limit WIP (Work-in-Process) — explicit numeric cap per column
• Manage flow — measure cycle time + throughput
• Make policies explicit — written rules for moving items
• Implement feedback loops — replenishment, cadence, ops review
• Improve collaboratively, evolve experimentally — kaizen

WIP-limit math: per Little’s Law (see lean-manufacturing §6 Example B), Cycle Time = WIP / Throughput. Lowering WIP shortens cycle time at constant throughput.

6.3 SAFe — Scaled Agile Framework (Leffingwell 2011, v6.0 2023)

Enterprise-scale agile. Agile Release Train (ART) = 50-125 people across 5-12 Scrum teams aligned to a single value stream. Program Increment (PI) = 8-12 weeks. PI Planning = 2-day event where the entire ART aligns on objectives. Heavy on ceremonies and roles (RTE, Product Manager, System Architect, Business Owner, Solution Train Engineer at portfolio level). Mixed reputation — adopted widely in large enterprises (Lockheed, Cisco, BMW), criticised by purists (“agile waterfall”).

6.4 LeSS — Large-Scale Scrum (Larman + Vodde 2008)

Multi-team Scrum (up to ~8 teams = 50 people) sharing one Product Owner + one backlog. LeSS Huge for >8 teams adds Area Product Owners. Lighter framework than SAFe, fewer roles.

6.5 DAD — Disciplined Agile Delivery (Ambler 2009, acquired by PMI 2019)

Process-tailoring toolkit; not a prescriptive framework. PMI now publishes the Disciplined Agile (DA) Tool Kit.

6.6 DevOps + SRE

• DevOps (Allspaw + Hammond 2009 Velocity talk; Kim, Humble, Debois, Willis “The DevOps Handbook” 2016) — culture + practices + tooling that integrate development and operations. Pillars: CI/CD, infrastructure-as-code, automated testing, monitoring/observability, blameless postmortems. DORA (DevOps Research & Assessment) metrics: deployment frequency, lead time for changes, change failure rate, mean time to restore.
• SRE — Site Reliability Engineering (Treynor / Google 2003; Beyer et al. “Site Reliability Engineering” 2016). SLI/SLO/SLA framework; error budgets; toil reduction; blameless postmortems.

6.7 Hybrid: Stage-Gate + Agile

Cooper’s Stage-Gate (1986; current Stage-Gate Next-Gen) for new-product development with agile inside Develop + Test phases. Common in consumer goods (P&G), automotive (FCA-Stellantis), medical devices.

6.8 Agile framework comparison

Framework	Scale	Cadence	Roles	Best for
Scrum	1 team (3-9)	2-4 wk sprint	PO, SM, Dev Team	Single-team software
Kanban	1 team or flow	Continuous	None mandated	Ops, support, mixed work
SAFe	50-1000+	8-12 wk PI	RTE, PM, BO, STE	Large enterprise
LeSS	2-8 teams	2-4 wk sprint	1 PO, SMs	Mid-size, Scrum-loyal
DAD/DA	Configurable	Configurable	Goal-driven	Tailored, hybrid
Nexus	3-9 teams	2-4 wk sprint	Nexus Integration Team	Scrum.org-aligned scale

7. Systems engineering

Systems engineering (SE) is the technical-content counterpart to PM. INCOSE Systems Engineering Handbook 5th ed (2023) is the canonical reference; NASA NPR 7123.1C and DoD MIL-STD-499C (2018) are the government equivalents.

7.1 V-model

The classic SE lifecycle visualisation:

   Stakeholder needs ─── Acceptance test
            ↓                ↑
   System requirements ── System integration test
            ↓                ↑
   System architecture ── Subsystem integration test
            ↓                ↑
   Detailed design ─── Unit test
            ↓                ↑
            └─── Implementation ─┘

Left side = decomposition + definition; right side = integration + verification + validation; horizontal arrows = traceability (every test traces back to a requirement). Used in safety-critical industries (avionics ARP4754A, automotive ISO 26262, medical IEC 62304, rail EN 50128).

7.2 MBSE — Model-Based Systems Engineering

Replaces document-centric SE (Word + Excel + Visio) with a unified executable model. Languages: SysML v1.x (2007 onward, OMG), SysML v2 (released 2024-2025 as a major redesign — no longer a UML profile, native textual + graphical syntax). Architecture frameworks: DoDAF 2.02, MODAF, NAF, UAF (Unified Architecture Framework, OMG 2017).

7.3 Requirements engineering

Standard: ISO/IEC/IEEE 29148:2018 (requirements engineering processes). Key practices:

• Shall-statements — atomic, testable, unambiguous: “The system shall maintain cabin altitude ≤ 8 000 ft when flying at ≤ FL410.”
• Traceability — every requirement traces upward to a need and downward to design, code, and tests. Tools: IBM DOORS, Jama Connect, Polarion, Codebeamer.
• Verification methods — Test, Analysis, Inspection, Demonstration (TAID). MIL-STD-961E + DO-178C use these four; ARP4754A adds Similarity.
• Validation vs Verification — Verification = “did we build it right?” (meets spec); Validation = “did we build the right thing?” (meets need).

7.4 CONOPS

Concept of Operations (per IEEE Std 1362-1998 or ANSI/AIAA G-043A) — narrative description of how the system will be used, by whom, in what scenarios, with what interfaces. Anchors stakeholder agreement before requirements.

7.5 Trade studies

Multi-attribute decision analysis. Methods: weighted sum (simple, transparent, susceptible to scaling games), AHP (Analytic Hierarchy Process, Saaty 1980, supports pairwise judgement), Pugh matrix (concept selection, Pugh 1991), TOPSIS, ELECTRE. Engineering practice favours weighted sum or Pugh for transparency; AHP for high-stakes contested decisions.

7.6 TPM — Technical Performance Measure

A quantitative metric tracked across the lifecycle (mass, range, power consumption, latency, accuracy). Plotted vs time with target, threshold, and tolerance band. Margin = current − target. Drives technical reserve decisions.

7.7 TRL + MRL

Technology Readiness Level (Mankins/NASA 1995, standardised in NASA NPR 7123.1 and ISO 16290:2013):

TRL	Meaning
1	Basic principles observed
2	Technology concept formulated
3	Experimental proof of concept
4	Tech validated in lab
5	Tech validated in relevant env
6	Tech demonstrated in relevant env
7	System prototype in operational env
8	System complete + qualified
9	System proven in operational env

Manufacturing Readiness Level (MRL) is the production-process parallel (MRL 1-10, DoD Manufacturing Readiness Deskbook). TRL/MRL gating is mandatory on DoD acquisition programmes and standard practice on NASA, ESA, JAXA, and large commercial space.

8. Worked examples

8.1 Example A — CPM critical path on 6 activities

Project: subsystem prototype, 6 activities with precedences.

Activity	Duration (d)	Predecessors
A	3	—
B	5	—
C	4	A
D	6	A, B
E	2	B
F	3	C, D, E

Forward pass (ES = max EF of preds; EF = ES + duration):

Act	ES	EF
A	0	3
B	0	5
C	3	7
D	5	11
E	5	7
F	11	14

Project duration = 14 d. Wait — recheck D: pred A (EF=3), B (EF=5) → ES_D = 5, EF_D = 11. F preds: C (7), D (11), E (7) → ES_F = 11, EF_F = 14.

Backward pass (LF = min LS of successors; LS = LF − duration; project end LF = 14):

Act	LS	LF
F	11	14
E	9	11
D	5	11
C	7	11
B	0	5
A	2	5

Wait — A’s successors are C and D. LS_C = 7, LS_D = 5. So LF_A = min(7, 5) = 5; LS_A = 2.

Float TF = LF − EF (or LS − ES):

Act	TF (d)	Critical?
A	2	No
B	0	Yes
C	4	No
D	0	Yes
E	4	No
F	0	Yes

Critical path = B → D → F (5 + 6 + 3 = 14 d). Activity A has 2 d of float despite preceding the critical-path D — because B is longer and drives D’s ES.

8.2 Example B — PERT probability of meeting target date

Critical-path with 5 activities, each given 3-point estimates (days):

Act	a	m	b	t_e	σ	σ²
1	4	6	14	7.0	1.67	2.78
2	3	5	9	5.33	1.00	1.00
3	5	8	13	8.33	1.33	1.78
4	6	9	18	10.0	2.00	4.00
5	2	4	6	4.0	0.67	0.44

t_e = (a + 4m + b)/6, σ = (b − a)/6.

Project expected duration = sum t_e = 7.0 + 5.33 + 8.33 + 10.0 + 4.0 = 34.67 d.

Project variance (independence assumption) = sum σ² = 2.78 + 1.00 + 1.78 + 4.00 + 0.44 = 10.0, σ_proj = √10 = 3.16 d.

Probability of finishing in 40 d (target):

z = (40 − 34.67) / 3.16 = 5.33 / 3.16 = 1.687

P(Z ≤ 1.687) ≈ 0.954, so ~95 % chance of finishing within 40 d.

Probability of finishing in 35 d:

z = (35 − 34.67) / 3.16 = 0.104; P ≈ 0.541 — barely better than coin flip.

Caveat: PERT systematically underestimates project duration because (i) it only considers the deterministic critical path, ignoring that non-critical paths can become critical under variability (the merge bias); (ii) it assumes activity independence; (iii) the β-fit to 3-point estimates is empirical. Modern practice: run Monte Carlo with realistic correlation structure (Crystal Ball, @RISK, Acumen Risk) instead of analytic PERT.

8.3 Example C — EVM monthly status

Project: 12-month, BAC = $1.2M,linearPVplan($100K/month).

Status at end of month 6:

• PV = 6 × $100K=\ast \ast$600K**
• AC = $720K (actual spend to date)
• EV = **$540K\ast \ast (45$1.2M, per project management’s % complete assessment)

Variances:

• CV = EV − AC = 540 − 720 = −$180K (over budget)
• SV = EV − PV = 540 − 600 = −$60K (behind schedule)

Indices:

• CPI = 540/720 = 0.75 (getting $0.75ofworkper$1 spent)
• SPI = 540/600 = 0.90 (90 % of planned schedule progress)

EAC forecasts:

• Optimistic: AC + (BAC − EV) = 720 + (1200 − 540) = $1.38M (+15 % overrun)
• Typical (CPI): BAC / CPI = 1200 / 0.75 = $1.60M (+33 % overrun)
• Pessimistic (CPI·SPI): AC + (BAC − EV)/(CPI·SPI) = 720 + 660/(0.75·0.90) = 720 + 660/0.675 = 720 + 977 = $1.697M (+41 % overrun)

TCPI (to recover to BAC): (BAC − EV)/(BAC − AC) = (1200 − 540)/(1200 − 720) = 660/480 = 1.375.

A TCPI of 1.375 means the remaining 55 % of work must be executed at 37.5 % better than budgeted to land at the original BAC. CPI to date is 0.75; the required step-change from 0.75 to 1.375 is an 83 % productivity improvement with no plan change. Almost never achievable. Action options:

1. Rebaseline the budget (sponsor approval required).
2. Descope the remaining work to reduce ETC.
3. Add resources if labour is the constraint (often makes it worse — Brooks’ Law).
4. Cancel if VAC > project NPV.

EVM’s value here is that the data is visible in month 6 of a 12-month project, leaving 6 months to act. Without EVM, the same overrun typically surfaces at month 10-11 when there is no time left to recover.

9. Risk + uncertainty

9.1 Quantitative risk methods

• Monte Carlo simulation — every activity given a duration distribution (often PERT/β, triangular, lognormal, or uniform); run 1 000-10 000 iterations. Outputs: project completion-date distribution, criticality index per activity (% of iterations in which it was on the critical path), sensitivity tornado chart. Tools: Oracle Crystal Ball, Palisade @RISK (now part of Lumivero), Deltek Acumen Risk, Safran Risk, ModelRisk, GoldSim.
• Decision tree — discrete branches with probabilities; expected monetary value (EMV) = Σ pᵢ · valueᵢ. Used for go/no-go decisions, R&D portfolio.
• Reference-class forecasting (Kahneman 1979; Flyvbjerg 2006) — estimate from the distribution of outcomes of completed similar projects, not from inside-view expert opinion alone. Empirically reduces optimism bias.
• Quantitative Schedule Risk Analysis (QSRA) — formal Monte Carlo on a CPM schedule. Required on UK Treasury Green Book projects > £100M; common on US DoD ACAT I.

9.2 Contingency funding

Industry rules of thumb (highly project-type-specific):

Phase	Engineering contingency	Cost contingency
Concept (AACE Class 5)	30-50 %	30-50 %
Feasibility (AACE Class 4)	20-30 %	20-30 %
Definition (AACE Class 3)	10-20 %	10-20 %
Detailed (AACE Class 2)	5-15 %	5-15 %
Construction (AACE Class 1)	3-10 %	3-10 %

AACE International Recommended Practice 18R-97 codifies the Class 1-5 cost-estimate categorisation. Defence + nuclear typically carry higher contingency through later phases.

9.3 Black swans and tail risk

Standard probability-impact matrices do not handle low-probability high-impact events (Taleb 2007). Mitigation: scenario planning, resilience engineering, distributed redundancy, optionality (Reinertsen). Examples: 2011 Tōhoku earthquake disrupting Renesas chip supply (auto industry); 2020-2022 COVID-19; 2021 Suez Ever Given grounding; 2022 Russian invasion of Ukraine on neon/palladium supply.

10. Edge cases + gotchas

Pitfall	What goes wrong	Mitigation
Mythical man-month (Brooks 1975)	Adding people to a late project makes it later (communication overhead n(n−1)/2)	Plan adequate headcount up front; partition work cleanly
Parkinson’s law	Work expands to fill available time	Critical-chain buffer-pooling; small-batch agile
Student syndrome	Operators procrastinate, burn buffer at end	Daily standups, near-term commitments
Goodhart’s law	When a measure becomes a target, it ceases to be a good measure	Multiple competing metrics; story-point velocity not a productivity KPI
Optimism bias	Planners systematically over-confident on duration + cost	Reference-class forecasting; pre-mortems
Strategic misrepresentation (Flyvbjerg)	Sponsors deliberately underestimate to get approval	Independent estimate; staged commitment
Scope creep	Requirements added without rebaselining cost/schedule	Change control board; documented baselines
Single critical path with no slack	Any activity variance hits project end	QSRA Monte Carlo; insert feeder buffers
Watermelon reporting	Status green outside, red inside; culture of fear	Anonymous risk reporting; psychological safety
SV → 0 at completion	EVM SV in $ is meaningless on a late project	Use Earned Schedule (ES) in time units
Crashing nonlinearity	Doubling resources doesn’t halve duration (coordination cost)	Use crash-cost curves; verify min-time/max-cost limits
Agile in safety-critical	Misperception that DO-178C/IEC 62304 prohibit agile	They don’t — but verification artefacts must be traceable; “Scrum + V-model” hybrid is standard
Outsourcing + offshoring	Communication overhead, IP risk, timezone latency	Liaison engineer onshore; shared chat ops; “follow-the-sun” only with mature handoff
Political requirements	Missing requirements are political not technical	Stakeholder map + RACI; explicit power/interest analysis
Critical chain vs critical path confusion	Mistaking longest-resource-constrained for longest-duration	Use both views; critical chain is resource-aware
EVM gaming	”Level of Effort” tasks earn value by passage of time; over-allocation to LOE inflates EV	Limit LOE to ≤ 15 % of budget; rebaseline if ratio drifts
Velocity inflation	Teams inflate story-point estimates to look productive	Velocity is internal capacity-planning only, never cross-team or cross-time-period KPI
Sunk-cost fallacy	Continuing failing project because of investment to date	EAC vs go-forward NPV decision — bygones are bygones

11. Tools / software

Category	Tools
Traditional scheduling	Oracle Primavera P6 (dominant aerospace + construction), Microsoft Project, Smartsheet, Asta Powerproject (Elecosoft), Deltek Open Plan, GanttPRO, ProjectLibre (FOSS), TILOS (linear scheduling for rail/pipeline)
EVM	Deltek Cobra (DoD standard), Deltek MPM, Empower (DOE/NASA), Encore Analytics, ARES PRISM, Microsoft Project EVM module, wInsight Analytics
Schedule risk (Monte Carlo)	Oracle Crystal Ball, Palisade @RISK (Lumivero), Deltek Acumen Risk, Safran Risk, ModelRisk, RiskyProject (Intaver), Polaris (Booz Allen)
Agile + Kanban	Atlassian Jira (dominant), Atlassian Trello, Asana, ClickUp, Monday.com, Linear, Shortcut, GitHub Projects, GitLab Issues, Notion, Azure DevOps Boards, Kanbanize, LeanKit (Planview)
SAFe-scaled	Jira with Advanced Roadmaps (formerly Portfolio for Jira), Targetprocess (Apptio), Planview AgilePlace + Portfolios, ServiceNow Strategic Portfolio Management, Atlassian Jira Align, Digital.ai Agility
MBSE + SE	IBM Engineering Systems Design Rhapsody, Cameo Systems Modeler / Magic Systems of Systems Architect (Dassault 3DEXPERIENCE), Capella (Eclipse, free, Thales + Airbus + naval), Sparx Enterprise Architect, Vitech CORE / GENESYS, IBM DOORS Next + IBM ELM, Innoslate, Ansys SCADE Architect
Requirements + ALM	IBM DOORS + DOORS Next, PTC Polarion, Jama Connect, Visure Requirements, Codebeamer (Intland/PTC), Helix RM (Perforce), ReqView
Cost estimating	ACEIT (Air Force Cost Analysis Improvement Group), SEER-H/SEM (Galorath), TruePlanning (PRICE Systems / Unison), Cleopatra Enterprise (Cost Engineering Consultancy), AACE methods, RIB CostX (construction), Sage Estimating
PMO + portfolio	Planview Portfolios (Daptiv), Adobe Workfront, Smartsheet, ServiceNow PPM (now SPM), Oracle Primavera Cloud, Microsoft Project for the Web + Planner, Clarizen (Planview), Sciforma
BIM + construction	Procore (dominant US construction), Autodesk Construction Cloud (Build, BIM 360), Bentley SYNCHRO 4D, Trimble Tekla PowerFab + Trimble Connect, Oracle Aconex, RIB iTWO 4.0
Knowledge / collaboration	Atlassian Confluence, Notion, Microsoft Loop, Slab, GitBook, SharePoint
FOSS / OSS	ProjectLibre, GanttProject, Taiga (agile), OpenProject, Redmine, OrangeScrum

12. Cross-references

• lean-manufacturing — Kanban + value stream mapping + Last Planner System; lean foundations underpinning agile and pull-based scheduling
• six-sigma — DMAIC project framework; common Lean Six Sigma marriage inside operations improvement programmes
• reliability-engineering — RAMS programme management; reliability allocation flow-down; HALT/RDT test planning
• supply-chain-management — supplier integration into project schedules; DDMRP; logistics critical paths
• ergonomics-human-factors — organisational ergonomics; team-of-teams effectiveness
• realtime-embedded — DO-178C, IEC 62304, agile-in-safety-critical
• system-identification — V&V verification loop on identified models
• fpga-design — DO-254 and agile hardware development
• fatigue-analysis — TRL gates on fatigue qualification
• additive-manufacturing — TRL/MRL gating for production introduction
• safety-standards — ISO 10218 + ISO 13849 safety-case management
• notation-spec — SysML for MBSE
• retail-supplychain — EDI for supplier scheduling integration

13. Citations

Canonical PM textbooks + handbooks

• PMI. A Guide to the Project Management Body of Knowledge (PMBOK Guide), 7th ed. PMI, 2021.
• PMI. The Standard for Earned Value Management, 3rd ed. PMI, 2019.
• PMI. Practice Standard for Project Risk Management. PMI, 2009.
• PMI. Practice Standard for Scheduling, 3rd ed. PMI, 2019.
• PMI. Practice Standard for Work Breakdown Structures, 3rd ed. PMI, 2019.
• AXELOS. Managing Successful Projects with PRINCE2, 7th ed. TSO, 2023.
• IPMA. Individual Competence Baseline (ICB), version 4.0. IPMA, 2015.
• INCOSE. Systems Engineering Handbook, 5th ed. Wiley, 2023.
• Kerzner, H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 13th ed. Wiley, 2022.
• Cleland, D. I. & Ireland, L. R. Project Management: Strategic Design and Implementation, 5th ed. McGraw-Hill, 2006.

Foundational works + papers

• Brooks, F. P. The Mythical Man-Month: Essays on Software Engineering, 20th anniversary ed. Addison-Wesley, 1995. (Orig. 1975.)
• Goldratt, E. Critical Chain. North River Press, 1997.
• DeMarco, T. The Deadline: A Novel About Project Management. Dorset House, 1997.
• Reinertsen, D. The Principles of Product Development Flow. Celeritas, 2009.
• Flyvbjerg, B. & Gardner, D. How Big Things Get Done. Crown, 2023.
• Flyvbjerg, B., Bruzelius, N. & Rothengatter, W. Megaprojects and Risk. Cambridge UP, 2003.
• Kelley, J. E. & Walker, M. R. (1959). “Critical-path planning and scheduling.” Proc Eastern Joint Computer Conf, IRE/ACM, 160-173. (Original DuPont/UNIVAC 1957 work.)
• Malcolm, D. G., Roseboom, J. H., Clark, C. E. & Fazar, W. (1959). “Application of a technique for research and development program evaluation.” Operations Research 7 (5), 646-669. (Original PERT paper, USN Polaris.)
• Lipke, W. (2003). “Schedule is different.” The Measurable News, Summer/Fall 2003. (Earned Schedule.)
• Cooper, R. G. (1986). “Stage-Gate systems: a new tool for managing new products.” Business Horizons 33 (3), 44-54.
• Atkinson, R. (1999). “Project management: cost, time and quality, two best guesses and a phenomenon, it’s time to accept other success criteria.” Int J Project Management 17 (6), 337-342.
• Saaty, T. L. (1980). The Analytic Hierarchy Process. McGraw-Hill.

Agile foundations

• Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J. & Thomas, D. (2001). Manifesto for Agile Software Development. https://agilemanifesto.org
• Sutherland, J. Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business, 2014.
• Schwaber, K. & Sutherland, J. The Scrum Guide, v2020. https://scrumguides.org
• Anderson, D. J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
• Leffingwell, D. SAFe 6.0 Distilled: Achieving Business Agility with the Scaled Agile Framework. Addison-Wesley, 2023.
• Larman, C. & Vodde, B. Large-Scale Scrum: More with LeSS. Addison-Wesley, 2017.
• Poppendieck, M. & Poppendieck, T. Lean Software Development: An Agile Toolkit. Addison-Wesley, 2003.
• Kniberg, H. Lean from the Trenches: Managing Large-Scale Projects with Kanban. Pragmatic Bookshelf, 2011.
• Kim, G., Humble, J., Debois, P. & Willis, J. The DevOps Handbook, 2nd ed. IT Revolution, 2021.
• Beyer, B., Jones, C., Petoff, J. & Murphy, N. R. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly, 2016.

Standards

• ISO 21500:2021 — Project, programme and portfolio management — Context and concepts.
• ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management.
• ISO 21503:2022 — Programme management.
• ISO 21504:2022 — Portfolio management.
• ISO 31000:2018 — Risk management — Guidelines.
• ISO 31010:2019 — Risk assessment techniques.
• ANSI/EIA-748-D (2019) — Earned Value Management Systems.
• MIL-STD-881F (2022) — Work Breakdown Structures for Defense Materiel Items.
• MIL-STD-499C (2018) — Systems Engineering (DoD).
• DoD 5000.02 — Operation of the Adaptive Acquisition Framework.
• DI-MGMT-81861/81466/81467 — DoD EVM data items.
• NASA NPR 7120.5F — NASA Space Flight Program and Project Management Requirements.
• NASA NPR 7123.1C — NASA Systems Engineering Processes and Requirements.
• ARP4754A:2010 — Guidelines for Development of Civil Aircraft and Systems.
• ARP4761A:2023 — Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment.
• DO-178C:2011 / DO-254:2000 — Software / Hardware considerations in airborne systems.
• ISO 26262:2018 — Road vehicles — Functional safety.
• IEC 62304:2006 + Amd 1:2015 — Medical device software lifecycle.
• IEEE Std 1362-1998 (R2007) — Concept of Operations document.
• ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Requirements engineering.
• ISO 16290:2013 — Space systems — Definition of TRLs and their criteria of assessment.
• AACE International RP 18R-97 — Cost Estimate Classification System.
• SAE JA1011:2009 — Evaluation Criteria for Reliability-Centered Maintenance (RCM) Processes.

Online + institutional

• PMI: https://www.pmi.org
• INCOSE: https://www.incose.org
• IPMA: https://www.ipma.world
• AXELOS (PRINCE2): https://www.axelos.com
• AACE International: https://web.aacei.org
• Scaled Agile (SAFe): https://scaledagileframework.com
• LeSS: https://less.works
• Scrum Alliance: https://www.scrumalliance.org
• Scrum.org: https://www.scrum.org
• NASA Office of the Chief Engineer (NPR documents): https://nodis3.gsfc.nasa.gov
• Defense Acquisition University (DAU): https://www.dau.edu
• College of Performance Management (EVM community): https://www.mycpm.org
• Lean Construction Institute: https://www.leanconstruction.org

---

node ~/.claude/bin/obsidian-research.mjs log "Built Engineering/project-management-engineering.md Tier 2 deep note"