Category: BA Skills

Presales Job Responsibilities for a BA

Posted on November 27, 2020 Last updated on July 1, 2025 by admin | 4 min read | 41 views

Ideally a BA works in project or operation. Sometimes due to lack of dedicated resources, our organizations tend to involve BAs in presales activities. Ideally an IT organization should have a dedicated team for presales consultants. But in reality, we see that along with the project work, BAs are involved in presales activities. So the million dollar question is can a Business Analyst get into a Presales job dedicatedly? The answer is yes they can provided they have gained enough experience in certain areas. You may start your job as a fresh BA but not as a fresh Presales Consultant. 

Let us understand what we mean by Presales job. There are various definitions depending upon the organization and the business process. For example, some organizations consider “cold calling as pre sales“. I am not referring to that profile. Here we are concerned about IT presales (mainly software). As it happens in IT organization, you have an Account Manager who is purely into Sales and his key performance indicator is sales target attainment but when it comes to presales guy, he will not have any sales target but he will have to create technical proposal, coordinate with an architect to get an estimate and high-level project plan. So the presales person will mainly work closely with the Account Manager to build the proposal including solution and cost estimate. Now the overall responsibility of the presales consultant varies from company to company; e.g. in some organizations the presales person is also involved in customer demonstration of the solution, presales clarification (questionnaire session). Remember we are talking about all these activities when there is a sales lead in the presales state. So the process looks like below –  

RFI / RFP / RFQ Process – 

  • A potential customer is interested >
  • Account Manager gets in touch to understand what the customer needs >
  • The customer wants to understand your company’s capability on a ERP/CRM >
  • AM gets in touch with Presales Consultant to get Capability document on ERP/CRM >
  • Customer is interested for a proposal >
  • AM will bring in the Presales guy in the picture to discuss the requirements with customer >
  • After that Presales person will prepare a proposal, consult with Architect on the solution, risk, assumptions, estimate >
  • The proposal is shared with AM who will schedule another appointment for solution Demo >
  • Presales person will join the demo to showcase the solution and handle customer queries >
  • AM will close the deal >>>>> After the order is received the BA will be involved to gather project requirements; so here the project work will start as per SDLC >>>

What a BA has to know about Presales?  

As a BA you must understand that in Presales we do not get into the functional or technical requirements but only on high-level business requirements. Based on this we have to provide a high-level solution and estimate our efforts, and provide a timeline. So a lot of assumptions, dependencies, risks need to be considered. You should be clear on the in scope and out of scope work items. You should also have good knowledge about your organization’s solutions, accelerators, frameworks etc. so that you can plug them in as part of your solution. Presales consultants must be able to articulate the Value Additions for the potential clients and show the Unique Selling Propositions. 

Once you start working on some of the RFPs on Implementation, Consulting, Upgrade, Support & Maintenance and build solution documents (Proposal) you will understand the basic expectations and over a period of time you will continue to improve. 

How does it differ from BA Job? 

Well, every day or week you will see new requirements, new solutions, new industry. So you have to be very dynamic to adapt. Also knowledge on various industries, technology trends (AI, Machine Learning, Big Data, DevOps, Cloud, Digital Platform like AWS, Azure), software integration (SOA Architecture, Service Bus, ETL, Batch Jobs, Real Time, API) etc. will definitely add value towards your contribution. 

Strategy for offshore Business Analysts

Posted on October 3, 2020 Last updated on July 1, 2025 by admin | 3 min read | 325 views

Business Analysis is a job that makes more sense when you work closely with customers at onsite locations but it doesn’t always happen that way. Many a times Business Analysts work from offshore and help the technical team clarify key questions. The offshore BA sends questions through email, schedules virtual meetings with business stakeholders and tries to get clarity on requirements. Now, all of a sudden, an onsite person from your team starts to interact with the customer and takes the lead on requirement clarification but you know it will not work as you have been through the questions and you only know the background of them. Hence the onsite person needs a knowledge transfer from you so that he understands the intention of the questions. You seem to feel bad that why you are sitting in offshore and not at the client side. You may have your personal reasons to stay back in offshore but it’s painful sometimes.

What should be your strategy when as a BA you are stuck in offshore:

  1. You cannot be a generic BA in offshore, rather you need to know the technology to become Functional Consultant so that you can discuss key techno-functional aspects with developers and suggest a solution to your client.
  2. You cannot be in a 9 to 6 job, rather make yourself flexible to overlap the office schedule to spent some hours with customer schedule either early morning or late night.
  3. Define a clear responsibility for the onsite person of your team. Both of you should not do the same set of work, rather ask him to take handover from where you leave it day before.
  4. Make sure you are not left out from some critical meetings that happen in onsite. If the schedule doesn’t match with you, ask someone to record the meeting and share with you.
  5. Always take email or chat approvals from your stakeholders for any decision you make. Do not assume. Keep all approval mails in a single folder.
  6. Don’t take up unimportant and unnecessary works just because you are in offshore. Avoid saying YES. Learn to understand your role in the project and focus on the specific outcomes only.
  7. Don’t get too much involved in outside project work to impress your boss. If you manage some time, learn something, document it, align it to your current engagement and share it with others to show your Knowledge.

BAs in offshore may face a lot of issues for not being available in the client site. I have tried to highlight some points so that you can enjoy your place and still be key player in the team.

Will you be a Business Analyst for ever?

Posted on August 11, 2020 Last updated on July 1, 2025 by admin | 2 min read | 28 views

Well many people argue that Business Analysis is a lifelong profession but I have a different take on this topic.

The Career Architecture for a BA mainly depends on his or her learning abilities and applications on the same. If you start your career as a Junior BA, you work under the guidance of a Senior BA and your responsibilities are scheduling meeting with stakeholders, taking meeting notes, preparing BRD.

Have you ever noticed what the Senior BA is upto?

Well, he is probably working with more complex requirements and explaining the problem to the technical team. He is also giving input for Technical Design.

If you observe one ladder up, you will probably see the there are BA Managers, Functional Architect, Solution Architect who are working on more complex assignments.

So my point is never consider yourself a BA for lifetime. We all know requirements are key in any project and as a BA we have to be on top of it but you also need to see what next. Get involved in Design discussions, don’t hold yourself back because you are a BA. With more experience you will probably be able to guide the tech team in Design.

But….. before you go there maintain the flow of your understanding as below –

Business Requirements Clarity > Functional Architecture and Process Clarity > High-level Design Approach > Low-level Design Approach

Make yourself comfortable but don’t be too proud to restrict yourself to chop the onion. You will end up learning more, you will end up creating value.

Career Options for Business Analysts:

Continue as Business Analyst:

Product Manager:

Product Owner:

Domain Expert:

Functional Expert:

Process Consultant:

Pre-sales Consultant:

Business Architect:

Iteration Manager:

5 Crucial Factors for Agile Business Analyst

Posted on April 10, 2020 Last updated on July 1, 2025 by admin | 3 min read | 53 views

Most of the Business Analysts are now working in Agile engagements. We all know that a Business Analyst in Agile project will work as a Product Owner and he should be responsible for the product backlog (requirements). In this article I’m going to highlight crucial factors that an Agile Business Analyst should take into consideration.

  1. Business Priorities – You may know all the requirements that are listed in product backlog but that doesn’t mean you know the business priorities. With each and every requirements you must have a priority ranking which will be provided by Business Stakeholders. Do not assume the priority and add the stories in sprint. Also take help from Business team or sponsor to know which epic or story should be part of which sprint.
  2. Requirements Mapping – Whenever you add a user story in the sprint, you should also validate the related user stories and map them logically. Suppose you have added a user story for customer’s dashboard design, then you should also look for what data are required on the dashboard and which system should provide the data. In this scenario you should create two user stories, one for UI and another for Data. Finally map them in Jira.
  3. Team Structure – Don’t always depend on the scrum master to take the call on team’s capabilities. You must know the capacity and capabilities of your team members in terms of technical Knowledge and delivery assurance. Blindly don’t pick up any story that will be too complex for the team to deliver, rather based on their capabilities you may split the complex story in small ones.
  4. Testing Team – As a Business Analyst you are supposed to clarify all the requirements not only to the development team but also to testing team. Sometimes you will have to handle conflicts between development and testing teams when they argue on a defect.
  5. Agile Learning Curve – However it’s scrum master’s responsibility but still you should also measure if the team’s learning curve is inclined or declined. All the members should improve their productivity as they progress in the sprint. E.g. a functionality took 5 days to develop in sprint 1, should take much less time to develop in sprint 5 if the requirements are similar. Also it should require less discussion for clarification.

Agile is vast area for project management prospective but a Business Analyst one must ensure there is a common understanding across the team members on the requirements and functionality. Hence the 5 Crucial Factors are undeniably the responsibility of Business Analyst during Agile engagement.

How to Analyze Requirements?

Posted on March 28, 2020 Last updated on July 1, 2025 by admin | 1 min read | 44 views

Requirement Analysis is a sequential process in which we try to unfold the deep secrets. As a Business Analyst, your analytical skill is going to be your goodwill. Ideally a BA has to perform the requirement analysis, however the other team members can also support and contribute.

Before we start requirement analysis we must have the requirements handy either as BRD or any other template.

The sequence that I follow –

  1. Functional Architecture Design
  2. Integration Requirements
  3. Functional Requirements
  4. User Requirements
  5. Report / Statement Requirements
  6. Nonfunctional Requirements

Sometimes functional requirements are analyzed before integration requirements. Both ways are fine as long as we can keep a balance between the 6 areas of requirement analysis.

I will post seperate post on each areas.

The deliverables of Requirements Analysis is Functional Specification Document (FSD) or Functional Requirement Document (FRD). In addition we also produce –

  • Use Case,
  • Data Dictionary,
  • Data Mapping,
  • Activity Diagram,
  • Sequence Diagram,
  • Class Diagram etc.

We will later learn about Unified Modeling Language (UML) to understand more about the diagrams.

I will also suggest to go through http://mybatrainer.com/what-is-functional-knowledge-for-a-business-analyst/

How to Gather Requirements?

Posted on February 19, 2020 Last updated on July 1, 2025 by admin | 2 min read | 35 views

Many formal techniques are used to gather requirements from stakeholders. Before we go into the formal techniques, I would advise the BA to be prepared and disciplined.

  • You must know your stakeholders and their roles in the project
  • You must know what requirements you are going to gather
  • You should write your questions before
  • You should know the key business terminology of your stakeholders
  • You should conduct some web research on the topic or business process before meeting the stakeholders

If above points are taken care of, let’s now go and elicit the requirements.

  1. The meeting is scheduled and you introduce yourself to the stakeholders and they also do the same
  2. You should first discuss and decide on requirement gathering approach. You start the topic and let the conversation begin. You need to provide your input on various approaches and their pros and cons. You can suggest a mixed approach also, e.g. interview, document analysis, questionnaire techniques etc.
  3. Now you start gathering the requirements step by step
  4. Let’s know the vision, objective and reason for the project
  5. What are the challenges they are facing in the current situation
  6. What should change
  7. Why the change is required now
  8. How will the new software or system will help
  9. Where does the software fit in within the enterprise landscape
  10. What are the risks they foresee
  11. What are the dependencies and assumptions
  12. What is the expected and ideal future landscape

Now we have to get into the current and future landscape.

After that we will discuss on users, teams, security aspects.

Let’s get functional.

Let’s understand non functional.

Will update this post.

What is domain Knowledge for a Business Analyst?

Posted on November 12, 2019 Last updated on July 1, 2025 by admin | 3 min read | 26 views

As a Business Analyst if you have domain knowledge, it will definitely help you in BA career. In this article, I will explain what we mean by domain knowledge for a business analyst and how to acquire domain knowledge.

Domain is the industry, which our customer organization belongs to. Banking, Insurance, Healthcare, Retail, Hospitality, Aviation, Real estate, Manufacturing etc. are the examples of various industries. All the industries differ based on –

  • Business process (Sales, Production)
  • Product or Service offerings
  • Customer types, Market, Target audience, Competitors, Alliances  
  • Statutory compliance and government regulation

Based on the above-mentioned factors, all the business organizations have segregated themselves as a domain.

A Business Analyst is expected to know at least one domain so that he can communicate well with the customer to understand the business issues, process, requirements and business goals. If the business analyst is planning to acquire the knowledge on a domain, he should focus on the points, mentioned above and try to gain as much information he can gain.

If someone wants to gain Healthcare domain knowledge, he should first follow the instruction as below –

  • Learn the Business process that is followed in Healthcare domain. It follows various sales processes. If you work in healthcare business, you may ask the sales person to explain you how the sales happens, what are the sale types, how much time does it take, how do customer make payment, how does a customer cancel a sale etc.
  • Learn how many different Products or Services offered by the healthcare company. What are the major category of healthcare products e.g. Medical, Dental, Medicare, Medicaid etc. How do the products differ, what are the major value the product or services provide to customers?  
  • Learn about Customer types, Market, Target audience, Competitors, Alliances the healthcare organization has. The customers are segmented based on various factors, the competitors are in the market with additional benefits, the partners, distributors, providers, health organizations, pharmacists all have key role to play for a healthcare organization. Try to understand why they exist and what they do.
  • All healthcare organizations have to maintain some statutory compliance and government regulations, e.g. HIPAA. Try to know about the major statutory compliance for healthcare organizations and the rules.

How to gain domain knowledge?

  1. If you are a fresher, you can learn about a domain from internet by searching on the topics as discussed above
  2. If you are working in an organization, you can speak to the end user in your company and gain the required knowledge you are seeking for
  3. You can also subscribe to the specific industry portal’s newsletter and business updates
  4. Follow some organizations that you aspire for (follow it on Facebook, LinkedIn, organization’s official website)

I believe this will help you in the first step in understanding a domain. Remember, domain knowledge acquisition, is a continuous process and there is no end of it. So keep learning and maintain a journal to keep recording what you have learnt today.

Do I need technical Knowledge to become a Business Analyst?

Posted on November 12, 2019 Last updated on July 1, 2025 by admin | 3 min read | 24 views

Many people have asked me if a Business Analyst need to understand the technical side of the project or not. 

My answer to it – “No and Yes”..

Let me explain. 

This is when Business Analyst does not need technical knowledge:

As a beginner when you join the BA group, it is not expected that you will be able to guide someone or your team technically. Your job is mainly focused onto – 

  • Identifying the stakeholders
  • Preparing questionnaire for the stakeholders 
  • Understanding the business requirements 
  • Documenting the requirements 
  • Asking questions if anything is not clear 
  • Coordinating with the team members to ensure they understand the requirements and deliver accordingly 

Gradually you gain experience of the project, the domain or industry, the customer’s business processes and also the technical solution that you are working with. 

Over a period of time, with number of years experience, you become a guide to the team. Because I have seen that the technical team is more happy if they work on code and design work while they will need someone to approve and provide them confidence that what they are developing will meet customer’s requirements. Here comes the Business Analyst because he knows the requirements best. 

This is when Business Analyst should gain some Technical Knowledge:
When it comes to technical knowledge, I will advise a Business Analyst to grab the fundamental knowledge on the following – 

  • Structured Query Language (SQL)
  • Database Structure 
  • Data Integration (DI)
  • Extract Transform Load (ETL)
  • Enterprise Resource Planning (ERP)
  • Customer Relationship Management (CRM)
  • Business Process Management (BPM)
  • Master Data Management (MDM)
  • Big Data
  • Artificial Intelligence (AI)
  • Ecommerce 
  • Cloud 

Don’t try to gain these technical knowledge in one day. It takes time to gain knowledge. Take your time. Go to Youtube or Google, search and learn it. It will polish you to become a Senior Business Analyst. 

Apart from these, a Business Analyst should have Functional knowledge on the specific solution that is being developed in the current project. Suppose, I am working in a project to implement Microsoft CRM solution, I will research about the CRM solution offered by Microsoft. I will try to understand the features, functionalities, limitation, customization, deployment details of the tool. I may not be able to code or configure but I should know how the CRM works and what is the ideal process that my customer should follow. All these information are available if you google it.  

I am not sure if you will agree; but I have seen many business analysts who have sound technical knowledge and can challenge a technical architect also. However, you don’t have to become an Architect but the Fundamental or Functional knowledge that you gain will make you more relevant and valuable resource in the team. It’s a continuous process; to learn and help your team. I do it and it helps me build great impact on your clients because they see me as a consultant who can guide rather than a BA who always says “I will get back to you after discussing with my technical team“. 

What are the deliverables of a Business Analyst?

Posted on November 12, 2019 Last updated on December 26, 2019 by admin | 2 min read | 538 views

The deliverable of a Business Analyst vary depending upon the role, project methodology, and industry. In this article, I will explain about different deliverable that a Business Analyst produces. Based on the nature of the project Business Analyst may merge some of the deliverable in a single document; e.g., a Functional Specification Document can include Use Cases, Data Dictionary.

  • Strategic and Business Deliverable
    • Scope Document
    • Mission and Vision Document
    • Problem Analysis Document
    • Root Cause Analysis Document
    • ASIS and TOBE Landscape
    • RACI Matrix
    • Business Case
    • Business Road-map
    • Different Analysis (Decision Analysis, SWOT Analysis)
    • Risk and Mitigation Plan
    • Case Study
    • ROI Analysis
    • Industry Analysis
    • Trend Analysis
  • Project Deliverable
    • User Stories
    • Business Requirement Document
    • Functional Specification Document
    • Traceability Matrix
    • Use Case
    • Various Diagram and Process Flows (Using UML)

Business Analyst can also come up with various other documents and deliverable that are unique for the project or customer. Above-mentioned ones are standard deliverable. The BA may work in Operation or Project. If he works in operation, he will mainly focus on the business and strategic deliverable; however if the BA works in IT project, he will come up with the project deliverable as outlined. BA can also use the business deliverable within a project. Later we will understand how to create all these deliverable.

**

If you are looking for the template of all these deliverable, please mail me at mybatrainer@gmail.com

What does a Business Analyst do?

Posted on November 12, 2019 Last updated on July 5, 2020 by admin | 3 min read | 49 views

From my personal experience and observation during my career as a Business Analyst, I can say that a Business Analyst will go through number of roles and responsibilities during his career. Now, in the initial days as a fresher when a BA start the job, his role will vary from a senior business analyst who has spent more than 10 years. I will explain it from IT standpoint where a System Integrator (IT Company) is working on a project for a client organization. The other scenario could be a Business Analyst who is working within the customer organization (we are not taking about the business analyst role).

Phase 1

This is the time when a fresher joins as a business analyst. The BA has probably done a business analyst training (not certification). His job role will be –

  1. Understand the client requirements from reading a number of documents (RFP, Scope, SOW etc.)
  2. He will have regular meetings with the Senior BA to understand the project requirements and also to validate himself
  3. He will undergo some technical training to understand the tool that is being used in the current project
  4. He will prepare questionnaire to gather requirements and send it to his senior
  5. He will document high level requirements in BRD based on his understanding
  6. He will co-ordinate with development and testing team members

Phase 2

This is when the junior business analyst has gained some experience and can work independently. His role will be –

  1. To work closely with the client on the requirements
  2. To work with the technical team and guide them
  3. Ensure the documentations are done properly (BRD, FRD, RTM)
  4. Ensure the testing team understands what functionalities need to be tested and how to go about it
  5. Build confidence with the customer so that the project continues and they are satisfied

Phase 3

This is when the business analyst has more than a decade experience and he implemented various solutions. He is BABOK certified. Here the BA role will be vast –

  1. Bring domain knowledge on the table (Insurance, Banking, Healthcare, Telecom, Real-estate etc.)
  2. Help the customer to define the requirements
  3. Consult and recommend the customer to benchmark the solution with peers
  4. Bring in best practices during the project and also in the solution
  5. Help junior business analysts to gear up
  6. Help the sales team to close deals (pre-sales) or be the business consultant for new customer acquisition

The role of business analyst will change based on the location, industry, his capability also.

How Capability of the Business Analyst matter?

I have seen many business analyst who can also design the solution. So they are technically aligned with the team.

Similarly there will be business analysts who can also work as a Project Manager or Program Manager. However this will add too much of job load on a single person and either of the role may be impacted

Back to top ⇧