Author: Jai Manral

Being a Business Analyst, carrying burden of expectations

Written by Jai Manral on May 10, 2018. Posted in Articles.

Business Analysts work across different teams. We expect a lot from them. They are the face of a company when traveling to the client’s site.

Account Managers expect them to leave a long-lasting positive impact on clients, after all, account managers are always looking to get more business from existing clients. Project Managers are often worried that Business Analyst may overpromise on anything which they may not fulfill. Developers and testers have their concerns regarding requirements. They want requirements which are detailed, clear and easy to understand. And as for clients, they want you to be more than a “Note Taker”, someone who can add value to the project. And yes, they don’t want to repeat things which have already been conveyed to you or your team.

So how can you fulfill everyone’s expectation? Below are starting points to help you in this regard.

Know about your customer and their industry. You should be thorough with the products, services and the market your customer has focused on. This will help you during the requirement and solution designing phase to clearly visualize the need of an application. If you know the business of your client, you will be able to make a more informed decision and can contribute more towards your clients’ goal.
Make sure you know the boundary of your work and structure of deliverables. The best way is to go through Request of Proposals or Statement of Work to extract the information regarding a project. You may also want to interact with your sales team to get firsthand information on your client. If this is an existing account where you are joining late, be sure to know about the processes, templates for documentation and system in scope.
Engage with your internal team from the beginning until very last. It’s imperative that you know your internal team, their expectations and any concerns they may have. Discuss on the expectations from the documents you will be preparing. Regular interaction with the team will make sure that all that is needed (i.e., the requirements) has been conveyed and understood by them.
If working with different vendors in a project, make sure you know what their role will be in the project, what is expected from them and any dependencies to you (or vice-versa). Ask for these information upfront and plan your work accordingly.
In summary, the key here is to know the customer and their industry well. Understand the need and objective of the project, know about the key success criteria, avoid asking everything about everything and start contributing.

Being a Business Analyst is just not documenting requirements from customers, it involves business analysis which is fundamental to any project. You should be able to convey your thoughts and understanding to the clients, help them to understand the implications of insignificant requirements, and make them aware or contribute in understanding their competition. After all, in this era of constant change and stiff competition, no one needs a note taker. Be a contributor!

How to get started with Business Analysis?

Written by Jai Manral on April 11, 2018. Posted in Articles.

As a business analyst you might have worked across different projects either from the inception or you might have joined the project in between, or it may have been a maintenance project.

The one question which we always have is – where to get started?

You might have read the arduous guides to figure it out, but it’s not only time consuming but pretty difficult to follow when you are looking for project specific skill sets. Well there are no specific rules to follow but a quick guide to check on some of the most important aspects of business analysis skills are below:

Know your stakeholders – it doesn’t matter what sort of project you are working on, you should always know about your stakeholders. Well there can be many stakeholders in a project and to identify them you can create a stakeholder analysis document. This is a simple excel sheet where you can list down the name, business title/position, department, project role and any other relevant details as specific to your project. This will come in handy throughout the project lifecycle and beyond.
Just knowing your stakeholder is not enough- Ok so now you have the list of all your stakeholder’s, you ask what’s next? Well not all stakeholders are important or influential in a project. The key here is to identify whom to listen to? For this you can create a stakeholder matrix mapping RASCI elements defined below against the names of stakeholders from stakeholder analysis document. Here RASCI acronym stand for
- Responsible – The one who owns the project/problem. Highly influential.
- Accountable – The one who acts as an approver. Usually signoff the work.
- Supportive – The one who is your friend. Can provide resources or help but may not be influential in a project. Kind of a helping hand.
- Consulted – The one who knows his stuff and you may require to seek his/her help often.
- Informed – The silent one, just keep him/her informed about the project.
Deciding on elicitation techniques – There are numerous techniques for electing requirements such as brainstorming, interviews, workshops etc. Well this is the time you can visits your stakeholder matrix to know about the stakeholder and his/her influence on the project. For example, a VP operations guy can be an influential person for a specific project but may not be the one to give you detailed process knowledge for your TO BE application. You may want to interview him for his point of view, concerns and thought process but might not invite him for a brainstorming or workshops sessions which may consume lot of his time from his already busy schedule. You must check the availability, influence level, position, interest level before making the choice of elicitation techniques.
Doing your homework – Not all projects start with calling stakeholders for meetings, sending them surveys, or organizing workshops. Most of the them, if not all, improvement (aka digital transformation) projects do not start from the scratch in a way that, the business processes are already defined and followed, these are AS IS processes. For these projects, client may have the loads of documents depicting the process/ applications designed and other artifacts of the current application(s). Analyzing these set of documents, process flows, business rules is cumulatively referred to as document analysis. As a business analyst, you should have keen eye on details, and should note down any information which is ambiguous as any assumptions here may cause dearly in the future. So be prepared before getting out with stakeholders as this will save everyone’s time and you can decide better which stakeholder is required and what elicitation technique to use.
Are you sure of the requirements? – Well chances are that you may have heard this statement before from your team members. Now assuming that you have gathered the requirements, one of the most essential part of requirement management is to analyze them. Like document analysis in previous step, which may or may not be part of a project, this is a mandatory exercise every business analyst should follow no matter what kind of project he/she is associated with. Analyzing requirements means finding any anomalies, highlighting assumptions and constrains, decomposing requirements into functionalities, classifying the requirements and figuring out what is important and what’s not. The higher the concentration and time spend on this stage lesser will be the surprises at the end. So keep a hawks eye on it.
It’s time to prioritize the requirements – So you have analyzed and documented the requirements, now depending on the kind of project and SDLC you follow, you may have to choose between requirements. This is mostly part of AGILE methodology where we deliver functionalities of a product/ application in an incremental fashion. Though you will have sponsors/ product owners but as a business analyst you should be aware of each requirements, its implications and need to the business. A well thought out plan on requirements delivery in phases is as crucial as the whole project. For example, considering e-commerce website example, what will be the point of delivering a functionality where users can add products to shopping basket but can’t proceed to buy, rather giving user an option to create wish list in one phase and delivery shopping cart and buy functionality in another makes more sense.
Finally can you trace the requirements back– This is required during the testing phase as well when there are difference in the said requirements and finished product. As a business analyst you should be able to trace the requirement to its origin when required. The IT is ever-changing space and there might come a time when someone else will access your work to define a new change. So a well-documented and traceable requirements will save both time and energy and of course the frustration which we usually witness ourselves when going through missing/unambiguous requirements from others.

How to get started with Business Analysis?

Written by Jai Manral on March 29, 2018. Posted in Articles. 1 Comment on How to get started with Business Analysis?

As a business analyst, you might have worked on different projects either from the inception, or you might have joined the project in between, or it may have been a maintenance project.

The one question which we always have is – where to get started?

You might have read the arduous guides to figure it out, but it’s not only time consuming but pretty difficult to follow when you are looking for project specific skill sets. Well there are no specific rules to follow, but a quick guide to check on some of the most important aspects of business analysis skills are below:

Know your stakeholders – it doesn’t matter what sort of project you are working on, you should always know about your stakeholders. Well, there can be many stakeholders in a project and to identify them you can create a stakeholder analysis document. This is a simple excel sheet where you can list down the name, business title/position, department, project role and any other relevant details as specific to your project. This will come in handy throughout the project lifecycle and beyond.
Just knowing your stakeholder is not enough- Ok so now you have the list of all your stakeholder’s, you ask what’s next? Well, not all stakeholders are important or influential in a project. The key here is to identify whom to listen to? For this, you can create a stakeholder matrix mapping RASCI elements defined below against the names of stakeholders from stakeholder analysis document. Here RASCI acronym stands for
- Responsible – The one who owns the project/problem. Highly influential.
- Accountable – The one who acts as an approver. Usually signoff the work.
- Supportive – The one who is your friend. Can provide resources or help but may not be influential in a project. Kind of a helping hand.
- Consulted – The one who knows his stuff and you may require seeking his/her help often.
- Informed – The silent one, just keep him/her informed about the project.
Deciding on elicitation techniques – There are numerous techniques for electing requirements such as brainstorming, interviews, workshops, etc. Well, this is the time you can visit your stakeholder matrix to know about the stakeholder and his/her influence on the project. For example, a VP operations guy can be an influential person for a specific project but may not be the one to give you detailed process knowledge for your TO BE application. You may want to interview him for his point of view, concerns and thought process but might not invite him for a brainstorming or workshops sessions which may consume a lot of his time from his already busy schedule. You must check the availability, influence level, position, interest level before choosing elicitation techniques.
Doing your homework – Not all projects start with calling stakeholders for meetings, sending them surveys, or organizing workshops. Most of them, if not all, improvement (aka digital transformation) projects do not start from the scratch in a way that, the business processes are already defined and followed, these are AS IS processes. For these projects, the client may have the loads of documents depicting the process/ applications designed and other artifacts of the current application(s). Analyzing these set of documents, process flows, business rules are cumulatively referred to as document analysis. As a business analyst, you should have a keen eye for details and should note down any information which is ambiguous as any assumptions here may cause dearly in the future. So be prepared before getting out with stakeholders as this will save everyone’s time, and you can decide better which stakeholder is required and what elicitation technique to use.
Are you sure of the requirements? – Well, the chances are that you may have heard this statement before from your team members. Now assuming that you have gathered the requirements, one of the essential parts of requirement management is to analyze them. Like document analysis in the previous step, which may or may not be part of a project, this is a mandatory exercise every business analyst should follow no matter what kind of project he/she is associated with. Analyzing requirements means finding any anomalies, highlighting assumptions and constrains, decomposing requirements into functionalities, classifying the requirements and figuring out what is important and what’s not. The higher the concentration and time spend on this stage lesser will be the surprises at the end. So keep a hawks eye on it.
It’s time to prioritize the requirements – So you have analyzed and documented the requirements, now depending on the kind of project and SDLC you follow, you may have to choose between requirements. This is mostly part of AGILE methodology where we deliver functionalities of a product/ application in an incremental fashion. Though you will have sponsors/ product owners as a business analyst, you should be aware of each requirement, its implications and need to the business. A well thought out plan on requirements delivery in phases is as crucial as the whole project. For example, considering e-commerce website example, what will be the point of delivering a functionality where users can add products to shopping basket but can’t proceed to buy, rather giving the user an option to create a wish list in one phase and delivery shopping cart and buy functionality in another makes more sense.
Finally, can you trace the requirements back– This is required during the testing phase as well when there are differences in the said requirements and finished product. As a business analyst, you should be able to trace the requirement to its origin when required. The IT is ever-changing space, and there might come a time when someone else will access your work to define a new change. So a well-documented and traceable requirements will save both time and energy and of course the frustration which we usually witness ourselves when going through missing/unambiguous requirements from others.