Risk Management Software Deployment Your Guidebook to Success
24 Aon eSolutions share this guide
Third: Address the issue of time
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. Or, they'll 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. We also like to test
the less likely scenarios that are outside the norm of everyday operations.
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, we believe the RMIS provider 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.
