As we continue this series of blog posts focusing on the attributes of a successful risk management software implementation, we turn our attention now to user-acceptance testing, or UAT.
Throughout this series, we've emphasized the importance of 
the client and RMIS provider working together. This is especially important during UAT, which is, at it's core, a process meant to determine if the software complies with the requirements and success criteria defined for the risk management information software being deployed.
Why is user-acceptance testing so important? Well, at the end of the day, a RMIS isn't much use if the ultimate users don't accept it. UAT sets the stage for users to embrace a new system in three key ways:
- At the most basic level, UAT let's the end users get their hands on the system, before it goes live, and get comfortable with the real-life scenarios they'll encounter once they're using the system on a daily basis.
- UAT gives end users the opportunity to ensure that the system will support their business processes, which, after all, is why any organization adopts a RMIS.
- And finally, UAT allows end users to be sure that the RMIS is functional and useful from their perspective (as opposed to how their IT manager expects it to work or how the RMIS vendor believes it will perform).
So, how do we coach clients to build UAT into their process? Here's what I've found.
First: Engage users from the very beginning
The actual users should be involved early in the process to make sure the RMIS vendor understands their business requirements and that test cases and test scripts align with those requirements (more on test scripts in a moment). In fact, we encourage users to help define the actual test steps for the business testing, and that happens at the very beginning of the project.
Clients often ask us who should be involved in testing. We recommend having end users from various parts of the organization. You would have users both from the risk management team as well as the finance team, for example. You would want to make sure that user community from both groups is represented to get a full picture of performance.
When my team starts an implementation, we begin talking about testing as early as the requirements-gathering, or discovery, stage. We make sure it's included in the project plan.
Second: Test each deliverable as its delivered
Testing deliverables as theyre delivered means that user input should be solicited throughout the deployment not just at the end of the implementation or at a critical juncture. By doing so, the client and RMIS provider are more likely to uncover issues that will be most effectively addressed before the next deliverable is delivered
Third: Address the issue of time
My experience has shown that for virtually every client, time is the biggest obstacle. End users have their day jobs. Sometimes they have their own day job and then some! Whereas the client's IT staff may have set aside time for the project, the end users usually have a full workload they have to carry.
In these cases, we caution the client: When users don't have the time to invest in doing the testing, or they want to rely on the provider or their IT staff to do it, the client runs the risk that some top-level requirements won't be met. Clients also run the risk that we will have to spend more time at the end of the deployment resolving unexpected issues.
What to test? Test scripts that consider actual scenarios
For the actual tests, we have clients provide us with sample scenarios they'll encounter both typical and problem scenarios. For example, we can see how this claim for John Doe went through a certain type of payment schedule, which is not normal for us, and so we want to make sure that when we're testing, we're testing that claim because its not a normal claim.
I also like to test the less likely scenarios that are outside the norm of everyday operations. For example, if a claim came in showing a loss date after the report date, how would the RMIS handle that scenario? Early testing allows you to think about how you want the system to respond when something like that occurs. We perform a trial of how we want the system to respond to the user.
If users come across an issue, often it's not really an issue; it may have been the way the data was entered or the workflow that was used. The testing will help determine if it's something that can be addressed in training, or if we want to actually incorporate a change into the project.
In developing the test scripts, I believe the RMIS company should support the client. The provider can bring experience in the areas that make the most sense to test. They'll know how to develop the test plans and scripts. They'll know the functional elements to look for. And if they do find something, they'll know what it means and if it aligns with or is outside of the original business objectives. This is an example of the consultative value a RMIS provider can and should bring during testing.
Leslie Sargent, PMP, is a senior member of the Professional Services team with Aon eSolutions. Please email Leslie at leslie.sargent@aon.com.
