User Acceptance Testing (UAT) and The Path to a Successful Cloud ERP Implementation (Part 4 of 5)

Are you down with UAT (yeah, you know me)?

So far, we’ve covered addressing personnel bandwidth restrictions, avoiding scope creep, and how to sufficiently train the user base. In Part 4 of our The Path to a Successful Cloud ERP Implementation series we are focusing on the consequences of the Lack of User Acceptance Testing and how to avoid them.

User Acceptance Testing (UAT) represents a pivotal moment in ERP implementations. It provides an opportunity for client management to not only see their system design in action, but to receive feedback from employees and get a clear idea of how the new system will help their business.

During a conventionally structured project, UAT will begin only after all system requirements have been gathered by implementers, a complete system design has been agreed to by client leadership, the implementation team has configured the system, and the end-users have been trained to use the system.

UAT is the start of the end-users using the new ERP system and figuring out how the system will assist them in completing their work. The importance of active client participation in this project phase cannot be overstated – implementers will have performed system testing of their own, but not with the comprehensive understanding of specific day-to-day operations that end-users bring.

Due to its position in the project timeline, as well as the involvement of more resources, there are some inherent risks to UAT. These are the most common risks that can compromise a successful UAT phase.

1. The Extension of Previous Project Phases – Other phases of the project may be extended for many reasons. Some may look to shrink other phases of the project in order to compensate for previous phases running long.  It’s important to not compromise UAT due to the extension of other phases of the project.  UAT is critical to prove the system will work as expected and the organization will be able to perform its critical tasks and get its reports.
2. Lack of Available Resources – UAT means additional responsibilities for end-users, as they will be tasked with system testing as well as the regular requirements of their position. UAT can be seen as a secondary responsibility, and therefore may receive lesser attention than more immediate matters.
3. Lack of Structure and Accountability – UAT requires participation and preparation from both implementers and clients. Implementers must establish what is required of end-users and provide support and documentation to allow end-users to effectively participate. On the client side, the project leaders must plan ahead to ensure end-users will have enough availability to participate in UAT and effectively carry out their normal tasks. Finally, end-users must actively participate and provide feedback to implementers on what is (or isn’t) working. Failure in any of these areas can severely compromise the success of the UAT phase and the ultimate success of the project.

It is also important to note that the risks described do not occur in silos, and are frequently compounded by each other—an extended design phase can delay UAT until a time when resources are not as available.  It is crucial that the pieces for a successful UAT are in place beforehand. This will require the project management team to meet well before UAT begins to schedule testing time in order to avoid the risks described above. In addition to making resources available and providing enough time to complete UAT, there are other essential items that must be complete for UAT to be successful:

1. Implementers must provide quality test scripts for end-users. Generally, test scripts will provide the scope of what processes must be tested in the system. Quality test scripts will detail: the task, the steps users must follow to complete the task, the expected results of the task, and how to verify that the task was performed successfully.  This will provide useful practice and experience performing tasks in the new system.
2. Implementers must be sure that there is a mechanism in place for end-users to report issues. This mechanism can be as formal as providing an external system to log and report issues (such as JIRA or ZenDesk) or as informal as emailing issues and information to implementers. The correct solution will vary widely depending on the size and scope of the project, but without feedback on testing, implementers will be unable to troubleshoot errors and provide additional guidance before the system goes live. This mechanism will also allow client management to know the progress of testing, as well as keeping them aware of potential large project issues that must be discussed.
3. Client leadership must prioritize and encourage their team to test the system. Without the support and advocacy from leadership, users are inclined to focus on their normal duties and not provide the extra effort needed to properly test the system.  The support and advocacy from client leadership goes a long way in ensuring a successful UAT.

Ultimately, a well-executed UAT phase will provide enormous benefits. By having other users test their processes as if it was a live environment, implementers can make design tweaks and troubleshoot system issues well before the system goes live. Client management will be able to get feedback from their own employees on how they feel the system works, as well as observing new business processes in action. Finally, client end-users can get an advance look at the system, as well as the opportunity to gain experience using it in a consequence-free environment.

Now What?

• Part 5: Data Reconciliation