A deeper look · Change and earned value

Deliverable Change Management

When a change is approved, its budget has to go somewhere. There are two ways to do it: modify an existing deliverable, or add a new item. Most teams modify because it is quick. Adding is the more disciplined approach, and for gated deliverables it is the better one.

Two ways to budget a change

Modify the existing deliverable

Increase the hours on Del_0142 from 100 to 120 and note the change number in a comment.

One field to edit, with no new IDs or mapping
The register stays the same length
The budget is spread through gates the change never touched
Progress or earned value already reported moves after the fact
The change disappears into the base scope

Add a new change item

Leave Del_0142 alone. Add “Chg2 · Extra review cycle to IFR for Del_0142” with 20 hours.

The original hours, gates and progress stay exactly as they were
The budget sits on the gate the change actually affects
Every change can be seen, reported and audited as its own line
Standard gatesets stay standard
Needs a naming convention and a link back to the parent

Gates are why modifying goes wrong

A gated deliverable's budget is not one number. It is split across the gates by their weightings, and progress is earned as each gate is reached. The gateset is usually standard for each deliverable type, which is what makes progress comparable across hundreds of drawings.

Changes rarely affect the whole route to 100%. An extra client review, a re-issue or an added tie-in affects one gate. Changing the deliverable's total hours forces a choice: spread the change across gates it never touched, or recalculate the gate weights for that one deliverable. Both damage the record. Step through the example below.

Del_0142 is at IFD and working towards IFR

A 100-hour drawing with the standard drawing gateset. IFD has been reached, so 30 hours are earned. The client now asks for an extra review cycle before IFR, estimated at 20 hours (Chg2).

Del_0142 · Piping GA, Area 200

100 h

IFD30 h

IFR30 h

IFA30 h

IFC10 h

Gate	Cumulative	Hours	Change	Status
IFD	30%	30	—	Earned
IFR	60%	30	—	Open
IFA	90%	30	—	Open
IFC	100%	10	—	Open

Budget: 100 h
Earned: 30 h
% complete: 30%

Starting point

The gateset is the standard one for drawings, shared by every similar deliverable.
Earned value at IFD has already been reported in previous periods.
The change affects one gate only: the work between IFD and IFR.

Illustrative example. Hours, gates and weightings are teaching values, not a recommended gateset.

What a change item looks like in the register

A change item is a deliverable line like any other: it has an ID, hours, a gateset and a schedule mapping. What sets it apart is a change reference and, where it reworks existing scope, a parent deliverable. A change can also create genuinely new deliverables, such as an added isometric drawing.

Example deliverable register with change items
Item	Description	Parent	Change	Hours	Gateset	L3 activity	Progress
Del_0142	Piping GA, Area 200	—	Baseline	100	Drawing · IFD / IFR / IFA / IFC	ENG-200-IFR · ENG-200-IFC	30%
Chg2-0142	Chg2 · Extra review cycle to IFR for Del_0142	Del_0142	Chg2	20	Review cycle · Comments in / Re-issue	ENG-200-IFR	0%
Chg5-0142	Chg5 · Add tie-in TP-07 to IFC for Del_0142	Del_0142	Chg5	14	Revision · Mark-up / Check / Re-issue	ENG-200-IFC	Pending approval
Chg5-0188	Chg5 · New isometric for tie-in TP-07	—	Chg5	24	Drawing · IFD / IFR / IFA / IFC	ENG-200-IFC	Pending approval

Name it for what changed

Chg<n> · <what> to <gate> for <deliverable>. Anyone reading the register can tell the scope, the gate and the parent without opening the change form.

Give it a simple gateset

A review cycle or revision rarely needs four gates. Two or three objective steps, such as comments received, revised and re-issued, are enough to measure it honestly.

Map it to the gate it affects

Tie the item to the schedule activity for the affected gate, such as the IFR interim activity. Its hours then time-phase where the work actually happens.

How it rolls up

Original + approved changes = current budget

Because change items are separate lines, the control account shows its original budget, its approved changes and its current budget without reconstructing history.

Productivity stays readable

If Del_0142 burns 140 hours, you can see that 100 were base scope and 20 were Chg2. That leaves 20 hours of real overrun, rather than one 140-hour line that looks like a 40% overrun.

Change cost becomes reportable

Filter the register by change reference to see what each change cost, what has been earned and what remains. That supports trend reporting and client recovery.

Time-phasing follows the schedule

Each change item takes the dates of the activity it maps to, so the change budget spreads where the work occurs rather than across the parent's whole duration.

For how approved changes get a custom spread inside control accounts, see Chapter 09 · Time-Phased Budgets & Change Management.

When modifying is still reasonable

Adding is the default, not an absolute rule. Modifying the original line is defensible when nothing has been earned and the change really does affect every gate.

Before any progress. The deliverable hasn't started, so no earned value moves, and the change scales the whole route evenly (for example, a drawing that doubles in size).
Correcting the baseline itself. Errors in the original estimate are handled through baseline correction, not dressed up as a client change.
Deleting scope. Removing a deliverable or gate that hasn't started is often cleaner as a negative change item against the parent, so the record still shows why the budget went down.

Keep the original deliverable as it was baselined. Record the change as a new item.

Standards and further reading

None of these prescribe the “add an item” method specifically. They set the principles it satisfies. Reference numbers should be checked against the current editions.

EIA-748

Earned Value Management Systems (Guidelines 28–32)

Authorised changes are incorporated promptly and traceably, and retroactive changes to earned value already reported are controlled. Scaling an in-progress deliverable runs straight into this.

PMI EVM

Practice Standard for Earned Value Management

The performance measurement baseline changes only through approved change control, and the method for measuring earned value is fixed when the work package is planned.

AACE 10S-90

Cost Engineering Terminology

Separates original budget, approved changes and current budget. Keeping change items as separate lines keeps these figures visible.

AACE 86R-14

Variance Analysis and Reporting

Variances need a traceable cause. A separate change item keeps scope growth from looking like poor productivity.

CII RT-43

Project Change Management

Research on recognising, evaluating and tracking change early, before it is absorbed into the base scope.

Deliverable Management Time-Phased Budgets