Earlier in this series, we introduced the change champion as one of the most effective tools for managing UAT risk on large retail technology programmes. This article is the third in our UAT series and looks at what the model actually involves, how to set it up, and what it delivers in practice.
There is a moment that programme teams dread: the first day of UAT.
Business users walk in and sit down, and within the first hour it's clear something's wrong. There might not be anything wrong with the system, but something's up with the atmosphere in room.
Users are disengaged and asking questions that suggest they have no idea what they are being asked to do. Someone senior has already decided, before they have tested a single journey, that the system is not fit for purpose.
That moment is almost always the result of the same failure: business users have been brought into the programme too late, they've been told too little, and left to form their own impressions on day one.
Change champions can overcome all of this but they need to be set up properly.
A change champion is a role within the programme, typically played by someone who is already credible within their business function, who is embedded in the programme well before UAT begins, and who acts as the informed bridge between the technology team and the business users in their area.
They are there to be honest, informed advocates, people who understand what's working and what's not, who can help their colleagues understand what to focus on, and who can bring genuine business concerns back into the programme in a way that gets heard.
A change champion who is just seen as a mouthpiece for the technology team loses credibility with the business users they are supposed to be helping. A change champion who is genuinely across the programme, knows the known issues, and is trusted by their colleagues changes the quality of acceptance activity significantly.
The most common mistake with change champions is appointing them too late. If someone is brought into the programme two weeks before UAT starts, there's not enough time for them to build the understanding or the credibility that makes the role work.
Our work on the ASOS Oracle Retail implementation involved thousands of merchandisers across a major programme. It succeeded in part because change champions were embedded throughout the programme, not just parachuted in at the end.
The practical steps:
Identify the right people early.
Change champions need to be credible within their own function. Seniority is less important than trust and credibility.
The practical impact of a well-prepared change champion shows up immediately in UAT sessions.
Users arrive with context. They know what the system does and broadly how it works. They are not encountering it for the first time. Questions that would otherwise consume session time have already been answered either individually or in pre-UAT briefings run by the change champion in their own function.
Defects get better quality triage. A change champion who understands the system well enough to distinguish between a genuine defect and user error, or between a known issue and a new finding, saves significant programme time. Without that filter, the defect log fills up with duplicates, misattributed issues, and things that were already known. Managing that log cleanly is one of the things that separates a UAT phase that completes on time from one that runs indefinitely.
Perception is managed in both directions. When something goes wrong (and in a complex implementation, it will) the change champion can contextualise it for their colleagues: this is a known issue, it is being fixed by this date, here is the workaround in the meantime.
That kind of informed, credible communication is the difference between a defect that gets logged and resolved, and a defect that becomes a reason for a business function to refuse sign-off.
Escalations go to the right place. Change champions give the technology team a direct line into business concerns. When there is a genuine problem that needs to be heard at programme level, it comes through someone who understands both the business context and the technical constraint, rather than arriving as an escalation from a frustrated user who has not been given enough information to understand what they are seeing.
Change champions are not a substitute for everything else. They cannot compensate for a system that is genuinely not ready for acceptance. They cannot replace proper training. And they are not responsible for delivering UAT. That remains with the programme.
What they can do is change the quality of the human experience of UAT, for the business users in the room and for the programme team running the sessions. On a large implementation, that human dimension is often where the real risk sits.
Change champions are a UAT risk management tool. Used properly, they are one of the most cost-effective investments a programme can make.
Next in the series: How automation supports UAT preparation: data, environments, scheduling.