How often do we think that a quick text/email/phone call could have resolved a problem instantly?
Recently, I had a conversation with a staff member from my children’s school to check if I could view the accounts details for both my kids on their website via a single login ID. Apparently, it was a possibility and I was informed that the school had linked both the kids accounts on their end, so I was good to go. After multiple attempts, I was still not able to see my second child’s account on their website and was reassured by the school that everything was set up as expected.
So, did my problem ever get resolved? Yes! There was a link on the website – “Change Student” that was not at all obvious and perhaps the reason why my attention was not driven there. I selected the link and bingo, there was my second child’s account and finally I can now view all the details via a single login ID.
How is this related to the Business Analysis world we live in?
1. Communicate, communicate and communicate:
Many times, as a business analyst we tend to make assumptions about the knowledge level of our end users. What may seem “obvious” to us may not necessarily translate as “obvious” to them. In the example above, had I been informed there is a link I am supposed to click to toggle between the two accounts, there would not have been so many follow ups. As a business analyst, communication is a key skill and we should always look for ways to ensure that everyone receives the same message and is exiting from meetings with the same understanding.
2. Keep the customer in mind always:
While designing an application, the end user’s lens should be the top priority, ultimately the system is designed to aid them. Going back to my scenario, had the option to “Change Student” been displayed in a more prominent spot on the website, it would have been an easy find. While designing an application, it is significant to step in the shoes of an end user and as a business analyst, it is our job to ensure there are no gaps between what is required vs what is delivered to the end user.
3. Track “trivial” details:
As a business analyst, during requirements elicitation, if an end user has expressed his/her desire “not” have a specific option displayed at a certain spot in the application, then we should try to understand the reasoning behind it and note them down. Another key thing to keep in mind is, to document all the acronyms or abbreviations, especially the ones that are commonly referenced within the organization.
Ensure to receive periodic feedback from the end users – what works vs what does not work? This would make them feel that their needs are being heard and their input is appreciated. Implement their feedback in the next release of the application or at least at a minimum, let them know as to why their suggestion was not rolled out.
In conclusion, always keep the customer in mind and never “assume” we all have the same level of knowledge and understanding. Doing everything in your power and capability to get everyone on the same page is one of the key mantras for the successful implementation of a project.