To achieve results from a good plan, you need to execute the plan well. As explained earlier, you might have to do multiple rounds of UAT testing with the same group in order to ensure that business users are comfortable with the new system, and that any issue found during the testing is addressed. To do so, you have to ensure progress of the UAT execution and that the identified issues are tracked. During the execution of UAT, consider the following points:

• Track the testing progress along with the test cases that passed/failed. Publish reports on progress, bugs reported, and resolved bugs (for retesting).
• Actively manage blocking issues. You need to stay on top of the issues that are blocking the testing of certain areas; try to be creative in finding workarounds to continue testing.
• Issue a triage and managing issue list. Have multiple reviews with the team every day for issue statuses and resolutions. Set daily meetings with the business leaders to discuss issues and provide updates on the progress made. You need to hear their first-hand feedback on the issues that are being experienced.
• Ensure that the formal release process is defined and validations are performed to verify that the release has not broken the environment. This will ensure that precious testing time is not lost due to a broken UAT environment.
• Track dependencies between test cases. You may have a dependency between test cases that will need coordination among the different business groups for testing. For example, when a sales order is created, you need to verify with the warehouse for it to be shipped, and then the AR can see the invoice and collect against it.
• On larger projects with a multilocation roll out, it is a good idea to execute testing at a central location. However, you should also perform some testing locally, especially features that require local resources, such as local printing.

• Poor analysis and design for complex areas will get exposed in UAT and will cause a lot of rework/continuous break-fixing. Identify such critical areas and allocate dedicated resources in order to get extra focus on such critical path items.
• In one of our implementation experiences, a focus team was defined for testing and fixing the revenue recognition and deferral scenarios. It was one of the most complex parts of the project, and was dependent on many other processes, such as correct product and customer setup, order entry with different combinations of products and the way in which the billing frequency was chosen by the customer, order entry and CRM integrations, and invoice distribution and rounding of totals. Every time a scenario was fixed, another was broken in deferrals; issues in the upstream processes, such as order entry, impacted the testing of the deferrals' functionality. The focus group helped to track this subproject with additional visibility, which helped to fix the issues faster.