Author: Divya Kishore

Business Systems Analyst for a medical device company. Certifications: CSCP CPO

Resources for the Investigative Analyst: Take your pick!

Written by Divya Kishore on January 14, 2021. Posted in Articles. 1 Comment on Resources for the Investigative Analyst: Take your pick!

Being a Business Analyst (BA) is a lot like being an investigative journalist.

You often must dig through lots of seemingly useless information to find the truth that can set you on the right path for your project.

Here are a few frequently overlooked items that you can utilize as resources and analyze to help uncover useful information:

1) Meeting Recordings: What can I gain by listening to a recording? Well, it gives you an opportunity to pause and think through:

What a stakeholder quoted?
What a developer suggested?
What a tester recommended?

These meetings can be analyzed and translated into process flows or current state diagrams. At the very least, by hearing a recording, you are now caught up with what was missed!

2) Presentations: I like to observe how slides are presented and structured during meetings. When slides have an organic progression of a topic, it is easy to follow along. When slides have too much information, I can get lost. Revisiting the slide deck after the meetings can help gain a better understanding of the topic or prompt you to jot down follow up questions. Analyzing the style or format of the slides that the author applied can trigger ideas or suggestions for your next presentation!

3) Email: Checking your inbox is like a daily chore in our professional and personal lives. What kind of analysis could I perform? Watch for those long email chains that includes all the back-and-forth conversations, they could be a potential input for Responsibility/ RACI (Responsible, Accountable, Consulted and Informed) matrix. Yes, it is exhausting to scroll all the way down, but it gives you an understanding of all the stakeholders involved and can provide a fuller perspective.

4) Notes: Missed attending a meeting? Missed recording a meeting? Notes can come to the rescue. Raw or clean notes, they are extremely helpful to get a coworker caught up or can be a memory refresher. In addition, notes can be a powerful input to build decision logs or can feed an action item tracker. Tada, now I know why we did what we did!

5) Chat conversations: I was working on a project one time and there was some confusion about the scope. I recalled I had a casual chat conversation a long time ago relating to the same project with the developer. I searched my chat history and bingo! I was able to pull up what we had chatted about. Fast forward…six months later, this back in the day chat helped the developer and I comprehend what was discussed in the past, what was missed in the previous release and perform a comparative analysis to identify the scope.

6) Artifacts: Grab a document or a diagram that was probably created by a team member or your peer. Study their style and how you can improve your next set of deliverables. Perhaps, it could be an eye opener to how one of the artifacts that you had authored in the past could have been trimmed down by replacing the written content with diagrams instead.

Conclusion:

Next time, when you are wondering, how to make information gathering more productive, I hope the above ideas can lend a helping hand and prove to be beneficial in your next investigation journey. Remember, it is the little things that can make a big difference or rather the little clues that can lead to the ultimate truth!

Minimum Viable Product (MVP) Released: Move on or Resume?

Written by Divya Kishore on October 21, 2020. Posted in Articles.

What’s next? If you are like me, then you are pondering the next item on your to-do list and you can relate to this question.

I end up planning for the next task while my current one is still in progress. Typically, a multi-year project is broken into phases. Prior to the completion of the first phase, discussions are already under way for the next phase. As humans, it is natural to get excited about the new features in an application and want to continually improve on those features. Yet, it is worthwhile to take a pause from “What’s next” or “What’s new”, so that the team can reflect on parking lot items and lessons learned to help define product value.

Here are a few action items that a Business Analyst (BA) or any team member can resume post MVP release:

Revisit the user’s wish list: I have worked on initiatives where we got so focused with the delivery of MVP that the immediate next step was to continue to improve the released MVP. In this process, the wish list of the end users or “nice to have” requirements that were tabled were permanently left off.

How can I help? Record, revisit and re-evaluate wish list items on the backlog once the dust settles down with the MVP release. Follow up discussions relating to these items act as a reminder and help discover new backlog items.

Address edge cases: Recall exceptional scenarios that came up in previous meetings? Often, these exceptions do not transpire on a regular basis and end up on the back burner because the goal initially is to just rollout the MVP.

How can I help? Schedule a discussion, create a project plan and address the one-off scenarios. Risk and prioritize these scenarios to determine which ones will be in the next MVP release and which ones will potentially never need attention.

Reiterate “New functionality vs value”: I was shopping online once, and the website met all the primary needs of an online shopper. However, it was when I had entered all the payment information, I was notified that an item was not in stock. As an online customer, I see more value in receiving live inventory updates for an item instead of the fancy features offered on the website. From the vendor’s perspective, MVP release could be “complete”, but did anyone analyze and evaluate what is truly valuable to an online customer?

How can I help? Perform value analysis. Collaborate with the business partners to define “value”. Value may look very different from the lens of a manager vs the lens of an end user.

Update glossary: I have attended meetings where participants call out terms and abbreviations. When it is a global project, there is an extra layer of chaos since there are a myriad of words and languages thrown all over the place. A lack of standard global terminology is an ongoing problem.

How can I help? Volunteer to author this list and get the definitions reviewed by business partners. Maintain a glossary as a living document in a central repository where everyone can review it after every MVP iteration.

Gather feedback: Are the users inundated with the new application or functionality? Are they forced to adopt the new application? Do they feel it is the same way of doing business but in a new application this time?

How can I help? A survey is a great option to capture the true sentiments of a user. It gives them an opportunity to vote on their likes and helps the team determine value for the next MVP release.

Have you resumed tasks that were placed on hold due to the MVP release? What are the action items you would like to pick up from where you left off? Think about it!! You do not want to keep improving the last MVP endlessly and overlook the features that never made it to the MVP release. The end goal is not to get so absorbed with the MVP that the tasks or action items post MVP release slip through the cracks.

“Strive Not to Be A Success, But Rather to Be of Value” – Albert Einstein

COTS – Challenges or the Solutions?

Written by Divya Kishore on July 9, 2020. Posted in Articles. 1 Comment on COTS – Challenges or the Solutions?

Raise your hand if you have ever been assigned as a business analyst (BA) to a Commercial off the shelf (COTS) application project?

Again, raise your hand if as a business analyst, you have felt like you are neither a subject matter expert on the business side nor on the application/solution side?

COTS applications/solutions are more and more commonly being adopted by global organizations since the belief is that, when there is something readily available in the market, then why recreate the wheel and build a customized solution? Here I don’t want to get into pros and cons of a Custom vs COTS application and rather outline how the COTS pathway has impacted the role of a business analyst in many ways as listed below.

Common Challenges and Potential Solutions for a COTS business analyst:

1. Challenge: Resistance to explaining current/as is business process

2. Challenge: Center of attention is application design/configuration

3. Challenge: High dependency on vendors/implementation partners

4. Challenge: Lack of understanding of a business analyst role by the team

5. Challenge: BA not involved in application/vendor selection

In summary, the goal is not to ensure that the application is designed and set up to accommodate the current processes of an organization but rather to have a closer look at the current processes and see how these can be changed to gain the true business value.

“Don’t make the application work for you but rather see how you can work with the application”.

What is obvious to “You” may not seem obvious to “Me”

Written by Divya Kishore on February 12, 2020. Posted in Articles.

How often do we pause and think about a casual conversation we have had with a friend, coworker or even a family member?

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.

4. Feedback:

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.