P6 Global Change
Last reviewed 16 September 20268 min read
The most dangerous button, used safely — one rule, one report, one comparison, then commit
🟩 In one line: Global Change applies an If/Then/Else rule to every activity, assignment or expense in the project in one pass, cannot be undone, and is the right tool for exactly four jobs — assigning codes, correcting settings, populating UDFs and clearing fields by rule — provided it is run on a Reflection first, its report is read, and a Schedule Comparison proves it changed only what it was meant to.
👤 Who this is for: J/M. Prerequisites: p6-reflections-and-what-if, p6-schedule-comparison, activity-coding-structure.
First, let's be honest about why this page exists
Global Change saves hours: 3,000 Area codes assigned from the WBS in ten seconds, 400 calendars corrected in one pass, every Expected Finish cleared where an Actual Finish exists. It also destroys schedules: an Else clause nobody noticed sets remaining duration to zero on everything that didn't match the If, and there is no Undo.
The second danger is quieter. Global Change is how the proportional remaining-duration cut gets done — "RD = OD × 0.8" on the critical path — and that is the fiction forecasting-honestly and building-a-recovery-plan exist to prevent. The tool is not the problem; the arithmetic is.
🟨 The standard — what "good" looks like
| Source | What it asks for (paraphrased) | Consequence |
|---|---|---|
| AACE RP 38R-06 | Every duration has a documented basis | No Global Change ever writes a duration by formula on production work |
| GAO Schedule Assessment Guide, BP 9 and 10 | Changes documented; baseline traceability | Specification saved, report archived, comparison archived |
| PMI Practice Standard for Scheduling, 2nd ed. | Schedule changes controlled and recorded | Every bulk edit appears in the change table |
| SCL Protocol 2nd ed., Guidance Part B | Contemporaneous record of programme changes | Report + comparison = the record |
| Convention (redundant-relationships, logic-density-and-quality) | Clean-ups proven neutral with Schedule Comparison | Same sequence here |
🟢 Rule: Global Change touches codes, settings, UDFs and cleared fields — never durations, dates or logic on production work; it is run on a Reflection, its report is read line by line, Schedule Comparison proves the footprint, and only then is it run on the live project with the specification and both reports archived.
How it actually works
1. The dialog
| Element | Path / content | Note |
|---|---|---|
| Open | Tools → Global Change → New (or select a saved spec) | Specs saved per user; "Available To" User / All Users / Another User |
| Subject Area | Activities / Activity Resource Assignments / Project Expenses | Choose before writing conditions — fields differ |
| If | One or more conditions, ANDed; "Any of the following" for OR | Use codes, WBS path, activity type, status, names |
| Then | Field = value, or field = field ± / × value | The action |
| Else | Applies to everything that fails the If | Leave empty unless you mean it — the single most destructive line in P6 |
| Apply Change | Produces a report of every proposed change | Read before Commit |
| Commit Changes / Cancel | Writes or discards | No Undo after Commit |
Filters: the change applies to the activities currently visible under the active filter/layout — a stacked filter narrows the footprint, which is useful and also a trap. Show All Activities before a project-wide change; apply a deliberate filter when the change is meant to be local.
2. The four legitimate jobs
| Job | Example spec | Why it's safe |
|---|---|---|
| Assign codes from structure | If WBS code contains ".L05." Then Level = L05 | No date effect; provable by comparison (codes section) |
| Correct settings by type | If Activity Type = Task Dependent Then Duration Type = Fixed Duration & Units; % Complete Type = Physical | Setting change; run in a baseline draft, prove zero date change |
| Populate UDFs | If Discipline = BLK Then Unit = m² | Data only |
| Clear fields by rule | If Actual Finish is not null Then Expected Finish = (blank) | Removes stale overrides; date effect is intended and visible |
Also acceptable, with the same discipline: calendar assignment by rule (If name contains "cure" Then Calendar = 7d 24h), where the resulting date changes are expected, listed and explained in the change table.
3. What it never does
| Never | Why |
|---|---|
| Remaining Duration = Original × factor | Fiction with a formula; every RD comes from quantity ÷ achieved rate |
| Original Duration ± days on production work | Durations have a basis per activity, not per rule |
| Actual Start / Actual Finish by formula | Actuals come from records |
| Physical % by formula | Progress comes from the quantity sheet |
| Constraint = value across a set | Constraints are per document reference, one at a time |
| Delete or add relationships | Logic is reasoned, not batched |
| Anything with an Else you didn't write deliberately | See above |
The exception for durations: copying Original Duration to Remaining Duration on not-started activities in a baseline draft after a duration correction is a settings tidy, not a forecast, and is acceptable with the proof.
4. The procedure
| Step | Action |
|---|---|
| 1 | Create Reflection of the live project (p6-reflections-and-what-if) |
| 2 | View → Filters → All Activities (or the deliberate filter, named in the record) |
| 3 | Write the spec; Else empty; save as user spec with a descriptive name ("Assign Level from WBS – JED-H") |
| 4 | Apply Change → read the report: count of activities, every field written; look for rows you did not expect |
| 5 | Commit on the Reflection; F9 |
| 6 | Schedule Comparison Reflection vs live: only the intended section shows differences (codes / UDFs / settings); dates empty unless expected |
| 7 | Run the same saved spec on the live project; Apply → report → Commit |
| 8 | Archive: spec name, both reports, comparison, one line in the change table |
| 9 | Delete the Reflection or keep it until the update is issued |
For a spec that will repeat every month (clear Expected Finish on completed activities), steps 1–6 happen once; afterwards step 4's report is read every time and step 6 runs quarterly.
5. Reading the Apply Change report
It lists every activity the change will touch and the old and new value of each field. Read the count first: 412 when you expected 26 means the If is too loose or a filter is off. Then scan for a field you did not name — that is the Else, or a Then line left from a previous spec. Cancel costs nothing; Commit costs the afternoon.
🟥 Where people go wrong
- An Else clause left from the template. "Else Remaining Duration = 0" on everything that didn't match. Committed on the live project, no Undo. Else empty unless written on purpose, and the report read.
- Straight onto the live project. No Reflection, no comparison, and the first sign of trouble is the client's review. Reflection first, every time — it costs three minutes.
- RD × 0.8 to hit a date. The recovery reaches the date in P6 and nowhere else. Durations are never written by Global Change on production work.
- A filter left on. Half the project changed, the other half didn't, and the two halves now have different code values. All Activities before a project-wide change.
- Report not read. Apply Change shows 3,000 rows; Commit clicked. The one field you didn't mean was on every row.
- Spec not saved, nothing archived. Next month the same change is rebuilt from scratch and slightly differently; in month 14 nobody can say what ran. Saved spec, two reports, comparison, change-table line.
⚖️ When you're challenged
"You changed 3,100 activities at once. How do I know the dates are the same?" The change wrote the Level code only. Schedule Comparison of the Reflection against the live project shows 3,100 rows in the activity-codes section and nothing in dates, durations, constraints or relationships. Both reports are in the archive folder.
"Just run a Global Change to cut the remaining durations by 20% on the critical path. It's a recovery." That reaches the date on screen and nothing on site changes, so the first weekly update is behind it. Recovery durations come from the measures — second crew, re-sequence, longer day — each with a basis note. That's a day's work in a Reflection, not a formula.
📄 Related pages
- P6 Reflections and What-If — the sandbox the change runs in first
- P6 Schedule Comparison — the proof
- Activity Coding Structure — the commonest legitimate job
- Forecasting honestly — why durations are never written by rule
- Building a Recovery Plan — what replaces the ×0.8
- P6 Keyboard and Speed — Fill Down for the small cases
✏️ Worked example
Baseline draft for a hospital in Jeddah, 3,410 activities, template inherited with Duration % and Fixed Units/Time on 1,900 of them:
| Step | Spec | Report count | Comparison result |
|---|---|---|---|
| Reflection created | "JED-H BL Draft – GC test" | — | — |
| GC 1 | If Activity Type = Task Dependent Then % Complete Type = Physical | 3,102 | Settings only; dates empty |
| GC 2 | If Activity Type = Task Dependent Then Duration Type = Fixed Duration & Units | 3,102 | Settings only; dates empty (no resources loaded yet) |
| GC 3 | If Activity Type = Level of Effort Then % Complete Type = Duration; Duration Type = Fixed Duration & Units/Time | 61 | Settings only |
| GC 4 | If WBS code contains "TWR" Then Area = TWR (and 4 siblings for POD, EXT, INF, MIL) | 3,410 across five runs | Codes only |
| GC 5 | If name contains "cure" Then Calendar = "JED-H Cure 7d 24h" | 84 | 84 calendar changes; 84 finish dates earlier by 1–2 days; 6 downstream date changes — listed in the change table as intended |
| GC 6 (rejected in review) | If TF ≤ 0 Then Remaining Duration = Remaining Duration × 0.85 | — | Not run. Recorded as requested and declined |
Live project: specs 1–5 re-run, reports and comparisons archived, five lines in the SBM change log. Elapsed: 50 minutes including the Reflection and comparisons.
📖 References
- AACE International RP 38R-06, Documenting the Schedule Basis
- GAO Schedule Assessment Guide (GAO-16-89G), Best Practices 9, 10
- PMI Practice Standard for Scheduling, 2nd ed.
- SCL Delay and Disruption Protocol, 2nd ed. (2017), Guidance Part B
- Oracle Primavera P6 Professional User Guide — Global Change (field labels as in P6 Professional v20; earlier versions differ)
From the field
Notes, corrections and additions from people who've done this on a real job. Everything is checked before it appears here.
Loading notes…
Checked before it appears. No client, project or employer names. Your name is shown; your email never is. Terms.