How do you think companies feel about returned merchandise or a cancellation?
I worked with PayPal for a period of time to help them decrease churn (their equivalent of a service cancellation). Trust me, it's not something they want to get out of control.
As a business analyst, your version of a return, a cancellation, or churn is end users who don't use the data solution that you and your team just spent months building for them. You go through the process of documenting requirements, translating them into something the developers can build, securing the right infrastructure, building and testing the solution, and then finally deploying it into production. And then when you check your usage statistics, you find they're not using it at all.
That, my friends, is bad news for you.
So, how do we avoid this situation? Well, you can start by making sure you do a good job of collecting and documenting requirements. However, the biggest opportunities are lost in User Acceptance Testing (UAT). Here are my six key strategies for a successful UAT.
- Strategy #1: Allow adequate time for UAT. UAT typically gets squeezed between delayed system testing and hard production deployment windows. Don’t allow this to happen on your project. Allow enough time for three cycles of user testing. That means, users should have two opportunities to re-test bugs that the developers have fixed. This typically translates to at least a dedicated month of UAT.
- Strategy #2: Explain the importance of UAT to your users. Many users feel like it’s your job to test the solution for them and their involvement, if any, is just to “check a few things out.” Not true. Even the best business analysts cannot test a data solution like the actual end users. That’s why it’s so important for them to invest the time to really give it a once-over–and a twice-over.
- Strategy #3: Make sure they understand what they need to do. Schedule time with your end users to explain your testing process. You should have both structured and unstructured testing. Structured testing is what you document in test scenarios and scripts. Unstructured testing is dedicated time for the end users to just play with it and try to break it. Your end users should have no doubts about what you’re asking them to do.
- Strategy #4: Plan your testing to death. Make sure you have a clear plan and schedule for your UAT–don’t try to wing it. Have all your objectives and deliverables clearly defined, all activities that are necessary for accomplishing those deliverables identified, sequence and dependencies worked out, estimated durations for all activities, and a clear schedule that maps out who’s doing what, how long each step will take, and when your end users are expected to participate.
- Strategy #5: Work with your end users' management to secure the priority and time for UAT. The value of Strategy #4 (planning) is realized in this strategy. Review your plan with your end users to ensure they 1) understand their time commitments, 2) identify schedule conflicts, 3) have the support required to clear their priorities with management. Many times, your end users will write checks with their time they can’t cash. Secure commitment from their management to lock in the priority.
- Strategy #6: Pull them away from their day job. Don’t let your users conduct UAT at their desk. It’s too distracting. Instead, provide a testing lab where they can go to focus on the task at hand. And facilitate the testing sessions–even the unstructured ones.
Conclusion
Building data solutions that aren't used is a waste of time and an indirect attack on your value as a business analyst. To prevent this from happening make sure you knock it out of the park with your UAT. I've shown you six key strategies for success–employ all of them. Even if the solution isn't perfect (even though you delivered what they asked for), you'll at least have the opportunity make it useable and collect valuable feedback for the next version. The last thing you need is users who cancel your service–so don't let it happen.
