Chapter 7. Project Management and Where Value Is Earned

Learning objectives

After this chapter you should be able to:

Build a work breakdown structure that satisfies the 100% rule, and find the critical path and float of a small network.
Compute planned value, earned value, actual cost, the variances and indices, and the estimate at completion.
State the load-bearing assumption of earned value, and distinguish rigorous completion criteria, the informal shortcut of crediting at ticket close, and the new conditions that make the shortcut costly.
Distinguish code-complete, merge-ready and integrated work, and explain why the critical path runs through review.
Size work packages, state a project's credit event, and track the review-state gap.
Test the verdict (prediction P5) on your own project data.

Opening case

A composite case, not a real engagement.

Ines is a program manager for three internal software projects. Each month a status agent builds her earned-value report from the team's ticket tracker: a work package counts as complete when its ticket is closed, and a ticket closes when the implementing agent opens a pull request and reports that its tests pass.

The chapter continues from here.

What the chapter covers

7.1 The classical method
- 7.1.1 Project, product and program
- 7.1.2 The work breakdown structure
- 7.1.3 The critical path method
- 7.1.4 Earned value management
- 7.1.5 The agile counterparts
- 7.1.6 What the classical method got right
7.2 The assumption it depends on
7.3 What agents change
- 7.3.1 Generated is not verified
- 7.3.2 What survives: the structure and the critical path
- 7.3.3 Program management returns
7.4 The verdict
7.5 What replaces it: earned value at verified merge
- 7.5.1 The rules
- 7.5.2 The Dispatch plan
- 7.5.3 Nine weeks, two ways
- 7.5.4 The gap as a leading indicator
- 7.5.5 Burndown at merge
7.6 Lab: Two earned-value curves
7.7 What would make this verdict false

Lab and prediction

Lab: Two earned-value curves

Feeds milestone M2 (BAC); M3 (WBS, tracking). How the labs fit the project

The lab tests this prediction from the working paper the book grows from (Smith 2026a):

P5 Earned value at code-complete and at verified merge diverge, most in weeks of highest agent output

A result that contradicts a prediction, honestly reported, is a result. You are graded on accurate records and reasoned interpretation, not on agreeing with the book.

Summary

Load-bearing assumption: progress is measured by work completed. Rigorous EVM credits against objective criteria set in advance; crediting at ticket close was a shortcut, tolerable only while φ was small and the reporter was the worker.
Verdict: recalibrate. The equations survive. Each project states its credit event, packages are sized to one agent session and one review sitting, and the critical path runs through the reviewer's calendar.
Replacement: for Dispatch, credit at verified merge, all or nothing, with a named acceptance check, three tracked states and the review-state gap as a leading indicator.
Worked result: on Dispatch (BAC 105 hours), the week-4 generation view forecasts 76 hours and the merge view 126; the project finished at 118. No study yet computes earned value both ways (prediction P5).
Earned value is budgeted work accepted, not demonstrated customer value, and a project-management agent must read the repository, never other agents' claims.

Key terms

Credit event: the stated event at which a work package earns its budget.Also used in 2
Verified merge: arrival of the integrated state; the credit event used for Dispatch.Also used in 2, 16
Code-complete, merge-ready, integrated: an agent reports done; reviewed and acceptance check passed; merged and main line green. (Hassan's third rung is "integration-ready": Hassan 2026, §6.4.4, p. 192.)Also used in 1, 2, 3, 18
Review-state gap: packages generated but not yet integrated.
φ (phi): the share of a package's budgeted effort that remains after the point where it is credited.Also used in 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
Demonstrated customer value: value shown in use after release, as distinct from budgeted value earned.Also used in 2
WBS, work package, 100% rule: a decomposition of scope; its lowest element; child elements account for exactly 100% of their parent (Haugan 2002).Also used in 2, 5, 9, 14
BAC, PV, EV, AC, SPI, CPI, EAC: the quantities and indices of Section 7.1.4.

Connections

Where this chapter and another point to each other most often.

Chapter 1: The Coordination Problem, 1968 to Now
From Chapter 1: In Chapter 7 he asks why a project with plentiful labor, time, and technology failed anyway.
Chapter 2: The Assumption Audit: A Method That Outlasts the Tools
The productivity studies of Section 2.6 point the same way.
Chapter 3: Life-Cycle Models When Iteration Is Cheap
With both engineers (20 hours a week, Chapter 3) the 75 hours of agent packages would clear in under four weeks.
Chapter 6: Cost and Schedule Estimation After COCOMO
Table 7.3 gives the first level for Dispatch, the dashboard from Chapter 6. ### 7.1.3 The critical path method Kelley and Walker (1959) presented the critical path method (CPM) for scheduling activities with durations and precedence relations. 1.
Chapter 16: Roles and the Four Conditions for Assurance
That is a program-level job: one named owner (condition 4, Chapter 16) for what projects share, and one view of the load their agents place on the same reviewers.
Chapter 18: Running the Whole Life Cycle: The Engineer as Manager of an Agent Team
From Chapter 18: Eight activities fill the manager's week: specify (Chapter 4), decompose (Chapters 7 and 11), assign (Chapters 8 and 16), review evidence packages (Chapter 12), verify (Chapters 13 and 15), decide (Chapters 7 and 14), escalate (Chapters 16 and 17) and record.

See it on the map

07 Project Management and Where Value Is Earned