P6 Reflections and What-If
Last reviewed 16 September 20268 min read
Testing a recovery without wrecking the live schedule — the sandbox that remembers where it came from
🟩 In one line: A Reflection is a linked copy of a project that you can edit freely and then either discard or merge back selectively; it is the place every TIA fragnet, recovery option, Global Change and logic clean-up is built and proven before anything touches the live schedule — one Reflection per event, named for it, archived as XER with its Schedule Comparison, and never itself submitted as a baseline.
👤 Who this is for: J/M. Prerequisites: p6-schedule-comparison, time-impact-analysis, building-a-recovery-plan.
First, let's be honest about why this page exists
Half the conventions in this hub end with "in a Reflection." This page is where that instruction becomes a menu path. The tool is simple — right-click, Create Reflection — and the discipline around it is what matters: what to name it, what to do inside it, what to archive, and what to merge back.
The failure it prevents is the one every planner has done once: a what-if edit made directly in the live project "just to see," then the phone rings, then the monthly update goes out with the what-if inside it.
🟨 The standard — what "good" looks like
| Source | What it asks for (paraphrased) | Consequence |
|---|---|---|
| AACE RP 52R-06 | TIA performed on a copy of the current update; unimpacted and impacted versions retained | One Reflection per fragnet; both versions archived |
| SCL Protocol 2nd ed., Core Principle 4 and Guidance Part B | Contemporaneous analysis; records kept | Reflection XER + comparison per event |
| GAO Schedule Assessment Guide, BP 9 and 10 | Updates and baseline changes controlled and documented | Nothing reaches the live project without a proven change |
| PMI Practice Standard for Scheduling, 2nd ed. | What-if analysis as part of schedule maintenance; changes controlled | Same |
| Convention (change-control-in-a-live-schedule; building-a-recovery-plan; p6-global-change) | Reflection first, one change at a time, Schedule Comparison after, archive, then incorporate | This page's procedure |
🟢 Rule: nothing exploratory is ever done in the live project — Reflection per event, named for the event and its source data date, one change at a time with a comparison after each, archived as XER with its reports, merged selectively or re-entered by hand, then deleted.
How it actually works
1. Creating one
| Step | Action | Note |
|---|---|---|
| 1 | Enterprise → Projects; select the source project | Source = the last accepted update for TIA and recovery; the live working project for a Global Change or clean-up test |
| 2 | Right-click → Create Reflection | Creates a copy with status What-If, linked to the source |
| 3 | Rename immediately | "VO-014 Impact — Reflection of Upd 08 DD 01Sep25"; "Recovery R1 — Reflection of Upd 08 DD 01Sep25"; "GC test — Level codes — Reflection of Upd 08" |
| 4 | Move under a "Reflections / What-If" EPS node | Keeps them out of the production list and out of summaries |
| 5 | Open it; check scheduling options and data date match the source | They copy across, but check |
Baselines: the number of baselines copied with the Reflection is governed by Admin → Admin Preferences → Data Limits ("maximum baselines copied with project" — verify label). For date comparison inside the Reflection, assign the source's Project Baseline in the Reflection's Assign Baselines.
Reflection vs Copy/Paste project: a pasted copy is independent, with no merge link — fine for a permanent archive, useless for merging. Reflection is for anything that may go back.
2. What is done inside — and the one-at-a-time rule
| Purpose | Inside the Reflection | Then |
|---|---|---|
| TIA fragnet | New WBS node per event; activities from SBM rates; one FS in, one FS out; hard logic; F9 | Schedule Comparison vs source: completion movement = the impact; archive XER + report per change ref |
| Recovery option | Apply lever 1; F9; comparison; re-run near-critical filter; apply lever 2 … | Options table row per lever; archive; forecast vs target reported |
| Global Change test | Spec applied; report read; F9 | Comparison proves footprint; same spec then run on live |
| Logic clean-up | Redundant links removed; F9 | Comparison: dates section empty; archive proof |
| Client "what if we …" | Whatever is asked, labelled as hypothetical | Report from the Reflection; never merged; deleted after |
One change per comparison. Three changes then one comparison tells you the total; it cannot tell you which change did what, and the options table needs each.
3. Getting the result back — three routes
| Route | When | How |
|---|---|---|
| Merge Reflection into Source | The change is discrete and the source has not moved since the Reflection was created | Right-click Reflection → Merge Reflection into Source Project → tick only the items to merge (activities, relationships, codes, etc., listed individually) → option to create a baseline of the source before merge (tick it) → option to delete the Reflection after merge (untick until archived) |
| Manual re-entry | The source has been updated since (a month passed); or the change is small (a fragnet of six activities); or the merge list is long and hard to read | Re-enter the fragnet under its WBS node in the live project at the incorporation step; comparison afterwards confirms it matches the Reflection |
| Nothing | What-if for a client; rejected recovery option; failed test | Archive the XER and report; delete the Reflection |
The merge matches on Activity ID and overwrites source values with Reflection values for every ticked item. If the source has been statused since the Reflection was made, a merge that ticks dates or durations will overwrite the new actuals with old ones. That is why change-control-in-a-live-schedule uses manual re-entry at step 10 when a month has passed.
4. Archiving — what the folder holds per event
| Item | Name |
|---|---|
| Reflection XER (impacted) | VO-014_Impacted_ReflUpd08_DD01Sep25.xer |
| Source XER (unimpacted) | Already in the Upd 08 archive; referenced, not duplicated |
| Schedule Comparison report | VO-014_Comparison_vs_Upd08.html / .csv |
| One-page note | Source, data date, what was changed, result, who ran it, date |
Then the Reflection is deleted from the database (Enterprise → Projects → Delete) or set Inactive under the What-If node if the database owner prefers to keep it a month. Twenty live Reflections in the project list is how a merge goes to the wrong one.
5. Reflection is not a baseline and not a recovery
| Object | Purpose | Ever submitted? |
|---|---|---|
| Reflection | Sandbox to build and prove a change | The archived XER may be submitted as the impacted schedule for a TIA or as the recovery-plan file — labelled as such |
| Recovery plan (copy) | The recovery document of record | Yes, as Recovery Rn |
| Baseline | Yardstick from the register | Yes, per acceptance |
A Reflection XER submitted with a recovery narrative is fine. A Reflection assigned as the Project Baseline is the error revised-baseline-vs-recovery-schedule exists to stop.
🟥 Where people go wrong
- "Just testing" in the live project. The what-if goes out in the update. Reflection takes fifteen seconds; the alternative takes a retraction letter.
- Three changes, one comparison. The options table needs days saved per measure. One lever, F9, comparison, next lever.
- Merging after the source moved. A month's actuals overwritten by the Reflection's older dates. Manual re-entry once the source has been statused; merge only into a frozen source.
- Merge with everything ticked. Scheduling-option or calendar differences ride along with the six fragnet activities. Tick the listed items you mean; read the list.
- Default name kept. "Upd 08 – Reflection" ×7 in the project list, and the wrong one gets merged. Event name plus source data date, immediately.
- Never deleted, never archived. The database fills with sandboxes; the evidence folder is empty. XER + comparison + note into the archive, then delete.
- Reflection submitted as the baseline. The slippage vanishes and the register points at a sandbox. Reflections build; baselines measure.
⚖️ When you're challenged
"Can you just try moving the façade start earlier so we can see the date?" Yes — in a Reflection. Two minutes to create, the change, F9, and the comparison shows what moves. The live programme doesn't change until we've decided and recorded it.
"Why is there a project called 'Recovery R1 — Reflection' in the database? Is that the new programme?" It's the sandbox the recovery options were built in, one lever at a time. The recovery plan of record is the R1 file in the submission; the baseline is unchanged. The Reflection gets archived and deleted this week.
"Merge the whole Reflection back — it's the same project." It was the same project on 1 September. The live project has October's actuals now; merging dates and durations would overwrite them with September's. The six VO-014 activities are re-entered by hand under their node and the comparison confirms they match — twenty minutes, no damage.
📄 Related pages
- P6 Schedule Comparison — the proof after every step
- P6 Global Change — the commonest thing tested here
- Time Impact Analysis — the fragnet built here
- Building a Recovery Plan — the options built here
- Change Control in a Live Schedule — when to merge and when to re-enter
- P6 Baselines: Assign and Maintain — why a Reflection is never a baseline
- P6 EPS, OBS and Enterprise Data — the What-If EPS node
✏️ Worked example
Recovery options on a 22-storey Dubai tower (building-a-recovery-plan), built in "Recovery R1 — Reflection of Upd 08 DD 01Sep25":
| Sequence | Action in Reflection | Comparison vs previous step | Archived as |
|---|---|---|---|
| 0 | Reflection created from Upd 08 (frozen, accepted); Project Baseline assigned | — | — |
| 1 | R1-01: façade L3 constraint removed; F9 | Completion −4 days; 1 constraint change | R1-01_cmp.csv |
| 2 | R1-02: façade predecessor L18 → L12, FS+5d; F9; near-critical re-run | Completion −12 days; 2 relationship changes; lift path now driving | R1-02_cmp.csv |
| 3 | R1-03: MEP first fix SS links re-pointed; F9 | −6 days; 22 relationship changes | R1-03_cmp.csv |
| 4 | R1-04: L16–L22 cycle RDs 9 → 7 with basis notes; F9 | −10 days; 7 RD changes, 7 Notebook entries | R1-04_cmp.csv |
| 5 | R1-05 and R1-06 | −7; −3 | R1-05/06_cmp.csv |
| 6 | Final comparison Reflection vs Upd 08 | −42 days net; every difference traceable to a row above | R1_final_cmp.html |
| 7 | Export "Recovery_R1_ReflUpd08_DD01Sep25.xer"; note written | — | Archive folder Recovery R1 |
| 8 | Reflection not merged — measures enter the live project only as they are instructed and evidenced (R1-01, R1-02 and R1-03 in Upd 09 by manual re-entry; R1-04 in Upd 10 after mobilisation) | Upd 09 comparison shows exactly the R1-01/02/03 changes | Upd 09 archive |
| 9 | Reflection deleted after Upd 09 issued | — | — |
One Reflection, six comparisons, one archive folder, zero edits to the live project before each measure was real.
📖 References
- AACE International RP 52R-06, Time Impact Analysis – As Applied in Construction
- SCL Delay and Disruption Protocol, 2nd ed. (2017), Core Principle 4; Guidance Part B
- GAO Schedule Assessment Guide (GAO-16-89G), Best Practices 9, 10
- PMI Practice Standard for Scheduling, 2nd ed.
- Oracle Primavera P6 Professional User Guide — Reflections (Create Reflection; Merge Reflection into Source Project); Admin Preferences → Data Limits (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.