Hi all,
Our organisation complete UAT on many delivered projects by external vendors and some smaller internal developed solutions.
More and more, our delivered solutions aren’t specific to one business.
E.g. a Content Management System for our primary customer site.
UAT is now taking more cross organisation involvement.
I manage test across several projects and a UAT lead would support (I support them on initial kickoff of Project and throughout) business users on day to day testing such as “is this a bug?”, “can you show me how to log a bug again please?”, etc.
The issues are:
No one business will dedicate a resource to full time UAT lead.
The use of a UAT lead not working in the related businesses gives the SME knowledge disadvantage to their role as they may not have been involved in the design and brought in just before UAT start to support the business users.
Staff in those business areas aren’t very technical. When I get the UAT Lead up to speed, I have a tendency to try and “hold” onto them for future projects.
From your experiences,
how do you manage UAT where multiple businesses are involved?
Do I need to ensure that from Project Kickoff, a UAT lead from each business unit is identified as a dedicated resource on the project?
That there is a team/group of UAT Leads working closely together and as “backups” to each other in the event of time off?
The nomination of an external user to those business units (contractor even) to lead UAT and have no conflict of interest to get the project UAT completed.
I understand your troubles. It’s quite a challenge to influence someone outside the delivery focus to assist in the project activities and to commit full-time staff to coordinate things. I have been in that situation many times
One thing that has helped for me is to realize they are volunteering to help you besides their “real work”. You cannot command&control them as easily - it often backfires if you try. Yet you need their know-how to run the UAT. So we need to involve them with a different narrative. Perhaps tap into their passions in the business domain - their quest for quality solutions for their customers
It’s all about expectation management and alignment from the start of the thing. Right when you estimate and consider the tasks of the UAT activity. Perhaps you can frame the activity in a way where it helps the business unit? That the people participating in the UAT planning will get early insights into the releases and can help implement and train the business staff later on.
Also, consider what you can do to make it easy for them to attend. Minimum of test tooling, cake, or focussing only on the tricky parts (not the tedious parts).
Do we work in the same company? We certainly have identical challenges. Some of our projects do not require a dedicated UAT Lead, perhaps due to budget constraints or due to its size/nature. Whatever the situation though, our team still needs some involvement before new applications (or major enhancements) are rolled out.
I have positioned some members of our team at Consultancy level. Whenever we have a new project engagement, they give an overview of our framework (way of working), practices and RACI to the stakeholders. When the project has resource constraints, the RACI will be a particular focus as there are key areas/events that must be done vs considered - the message being someone must do it.
Having done this for a few years, it helps to have references and lessons learned from previous projects. Some could be comparable to a new initiative which the project members may identify with.
When there is simply no fund for a dedicated UAT lead, we end up with two likely scenarios:
The Project Manager coordinating and managing the entire event & processes., including defect management We give them our guidelines, templates, tools training, etc. to get them started.
A functional tester/test lead continues on the project to manage the UAT processes such as defect triage, artefacts management, reporting, etc. But the discussions with the business users may be limited as mainly handled by the Project Manager.
Many thanks all for the feedback. Some really good points.
PM managing UAT is definitely an option as some projects are small and wouldn’t take much co-ordination. In some ways our PM’s are Product Owners due to their overall knowledge of the system
The RACI at Project Kickoff is something that isn’t occurring. I get dragged into all sorts of workstreams and I don’t want a UAT “Functional” Lead working on Content Validation or ORT items when their focus should be on just that, “Functional Test”. Are the Requirements met?
Jesper, will most definitely review your MoT Pro talk. thanks for this.
If there was a big project, then there was a test manager coordinating the test coordinators or test leads.
the most test UAT leads were internal employees. There were also contractors for a buffer.
in the department there was a broad experience with testing. A lot of technical issues were prevented in an early stage of the project.
there was always a backup available for UAT leads.
UAT was performed in a similar way all over the company.
for the users there were workplaces for testing on a different floor. This reduced the number of questions from colleagues.
a test department could also offer test services like performance tests, security tests, and usability tests. This reduced a lot of paperwork for the project leads.
Cons:
Users were the most cheapest option for the UAT. It was difficult to find users with a feeling for testing. After a few UATs they were not available anymore.
the key users were in high demand for the business and UAT. This was due to conflicting targets: your department has to sell X things this month and your department must support the project.
the cost management for test leads was difficult for project managers. They had not enough budget for testing, So, on a corporate level a significant amount of budget for testing was required. Then the project managers said that it was still too expensive. So, service providers were trying to take over the test lead of UAT.
the test leads had less focus on domain knowledge than the users. This had impact on the communication.
We certainly have identical challenges. Some of our projects do not require a dedicated UAT Lead, perhaps due to budget constraints or due to its size/nature. Whatever the situation though, our team still needs some involvement before new applications (or major enhancements) are rolled out.