#005B - Don’t Test on Moving Targets pt. B
The Thinking Path Behind the Decision
Part A deliberately stopped before giving you answers. That wasn’t accidental.
In real projects, PMs rarely fail because they don’t know options. They fail because they decide too early, under emotional pressure, without understanding the real problem.
This part walks through the reasoning that separates reactive PM behavior from senior-level decision-making.
First: What This Scenario Is Really About
This is not an infrastructure problem. It’s not even a testing problem.
It’s a decision-making problem under noise and time pressure.
The core tension is simple:
Everyone around you wants movement
Very few people care whether the movement is correct
The fastest way to look incompetent as a PM is not to be slow. It’s to be fast…..and terribly wrong.
Step 1: Separate Facts from Noise
Before touching the UAT plan, senior PM does one thing: Freezes hasty decisions to allow real progress.
At the moment the vendor message arrives, here is what you actually know:
Facts
Vendor plans an upgrade during the UAT window
SLA and stability are not guaranteed
UAT is a hard gate before go-live
Go-live is tied to cost and datacenter exit
Unknowns
Why the upgrade is happening
Whether it’s mandatory or optional
Whether it can be moved
Whether PROD is affected
Who approved it
What exactly changes technically
Every option proposed by others assumes answers to these unknowns. That alone should stop you from deciding!
Step 2: Identify the Real First Decision
Most people think the first decision is: “What should we do with UAT?”
It isn’t. Take a step back, detach from the tunnel vision focused purely on your precious deliverables.
The real first decision is: “Is this upgrade fixed in time, or flexible?”
Until you answer that, all the "what do we do with our UAT" discussions are premature.
This is where junior and senior PM behavior diverges:
Junior PMs optimize within assumed constraints
Senior PMs challenge whether the constraints are real
Step 3: Why the “Obvious” Options Are Dangerous
Let’s walk through the four options calmly — without panic.
Option A — “Test before the upgrade”
This fails a basic principle of why the UAT is performed: UAT must validate the production configuration.
If the environment changes after UAT:
the upgrade itself becomes untested
new defects can appear post-UAT
UAT results lose credibility
auditors will challenge sign-off
This option gives speed at the cost of test validity and introduces significant secondary risks.
That’s not a trade-off you want to make, as it will backfire later.
Option B — “Spin up a temporary UAT environment”
This is the most seductive option — and one of the most dangerous.
You introduce:
different infrastructure
different performance characteristics
different security posture
different patch levels
different failure modes
UAT passes here mean nothing about PROD behavior.
You didn’t reduce risk. You displaced it to go-live night. Good luck with that!
Option C — “Run UAT during the upgrade and hope”
Hope is not a mitigation.
Running UAT during instability creates:
non-reproducible failures
false positives
false negatives
endless defect debates
This option maximizes chaos with no upside. And you don't want to introduce even more chaos, do you?
Option D — “Postpone UAT”
This is the only option that preserves test integrity, but it is emotionally hard:
it looks like failure
it impacts dates
it triggers escalation
Because of that, people resist it — even when out of these 4 options it's the most correct one.
Step 4: The Correct Decision Path (Before Choosing Any Option)
Before selecting any of the above, a senior PM does three things:
1) Escalate for visibility, not permission
This is not about panic. It’s about ensuring stakeholders know:
a critical dependency has changed
a key milestone is at risk
decisions may be required
Silence is not professionalism here.
It’s negligence. It's hiding.
2) Start an immediate vendor fact-finding call
Your first concrete action is not rescheduling UAT. It’s asking the vendor:
Why is the upgrade scheduled now?
Was UAT communicated?
Is the upgrade mandatory?
Can it be postponed?
Is PROD affected?
What are the contractual implications?
You do not negotiate yet. You focus on collecting facts. Validating real vs. perceived constraints.
3) Reframe the problem correctly
The problem is not: “How do we squeeze UAT into the schedule?” Even though this question is very tempting.
The problem is: “How do we ensure UAT validates the final production state?”
Once framed correctly, most “clever” workarounds collapse on their own.
It is vital to understand that completing tasks does not equal delivering value. A PM does not add value by mindlessly pushing activities to “Complete” on a plan.
The real question must always be: why does this task exist?
UAT exists to validate the production configuration — and once that purpose is compromised, running UAT creates noise, not progress. Zero value delivered.
Step 5: Why Moving UAT After the Upgrade Is the Only Valid Option
If the upgrade cannot be moved, the decision becomes clear.
UAT must run:
on the final environment
after all changes
under stable conditions
Yes, this may delay UAT. But delaying UAT is not the same as delaying go-live irresponsibly.
It is a controlled protection of system integrity.
This choice:
preserves test credibility
reduces unknowns
protects PROD
avoids emergency fixes
reduces post-go-live incidents
protects your professional reputation
Speed without validity is not progress.
Step 6: How You Communicate This Upwards
This is where many PMs fail — not technically, but politically.
You don’t say: “We’re delayed.”
You say: “Running UAT before or outside the final configuration invalidates test results. To ensure system integrity and protect go-live, UAT must run after the vendor upgrade.”
This is both factual & calm. Leaders trust clarity more than optimism.
The Real Lesson of This Case Study
This scenario highlights one thing above all: The most dangerous moment in a project is when everyone demands a fast decision — before understanding the problem.
Pressure creates motion.
Detachment creates correct motion.
Senior PMs don’t slow projects down. They prevent them from running fast in the wrong direction.
Final Thought - Next time pressure hits, remember: Pause. Understand. Decide.
Slow is smooth.
Smooth is fast.
What's one project where this could have changed the outcome for you? Share in the comments!