Can I Be A BA With No BA Experience?

Part 1 - 5 Common BA Questions Answered

Transcript below

As I coach business analysts around the globe, there are 5 common Business Analysis career questions I receive consistently from aspiring and existing BAs and they are:

1. How do I move into a BA Role with no BA Experience?

2. What technologies should I know as a BA?

3. What certifications should I pursue as a BA?

4. What is the next logical role after becoming a BA?

5. How do I show my value when no one knows what I do?

So, I decided to answer these questions in a 5-Part series of videos. So, get ready to focus on each of these questions in detail.

My name is Paula Bell, also known as, The BA Martial Artist, as I leverage martial arts concepts to bring forth personal and professional results, and I am here to answer and discuss, some strategies, and tips for the 5 Common BA questions I receive from aspiring, and existing BAs in this 5-Part Series.

But before I get started, if you want more tips and strategies on business analysis, career growth and development, and/or life coaching make sure to click the subscribe button on this video, as well as, on the bell to turn on notifications. Also, I would love to hear from you so be sure to engage with us by leaving comments on this video or participating in the "Community Link" on YouTube.

Okay, now it's time to jump into Part 1 of this 5-Part series of the "5 Common BA Career Questions Answered".

The first question I receive quite a bit, and one of the main reasons my clients reach out to me is:

"How do I move into a Business Analysis(BA) role with no BA experience?"

Now as a martial artist, I have learned you can accomplish ANYTHING you put your mind to whether you have the experience or not. When I started studying the art I had no clue what I was doing, and I started as a way to spend more time with my twins. But as I continued to move up consistently in the belt ranks I began to gain the skills and capabilities needed to effectively protect myself, and I saw the difference it was making in my life holistically. I wanted to continue on, even if my kids didn't.

You see, it is about understanding the capabilities and skills you already have, and then identifying where there may be gaps or deficiencies that require some learning or refinement to achieve the goal you desire.

So though you have not been in a BA role doesn't mean you can't be there. And believe it or not, you are probably using business analysis skills every single day and may not realize it. Here are the 3 main keys I start with when coaching a client interested in the BA role:

1. You have to clearly understand the skills and competencies possessed by a BA. This is the foundation.

2. You have to identify the transferrable skills and competencies you possess to help you move into a BA role, as well as, identify skill gaps

3. You need to know how to effectively market those skills to get noticed.

So let's go a little deeper into these 3 areas:

Let’s start with understanding the skills and competencies needed to effectively be a Business Analyst.

Now the term business analyst is still used quite broadly and differently in the industry. However, here are 15 common skills and competencies you should have as a business analyst, and these will be explained deeper as you continue to watch this video or read this article:

1. The ability to solve problems

2. The ability to analytically and critically think

3. The ability to be detailed-oriented

4. The ability to facilitate meetings

5. Strong communication skills whether verbal or in writing

6. The ability to conduct Enterprise Analysis

7. The ability to plan and organize the business analysis approach

8. The ability to elicit requirements

9. The ability to gather, organize, prioritize, and document those requirements

10. The ability to manage the business requirements

11. The ability to perform solution validation

12. The ability to manage and facilitate change management activities

13. The ability to build and maintain relationships with your stakeholders

14. The ability to manage and resolve conflict

15. The ability to influence, and negotiate with your stakeholders

Now at this point, I have not mentioned the different methodologies, tools, or techniques you can leverage to do all of this. That is because I want to focus on the different buckets of work you do as a BA to open you up to how many of those buckets you already do in your professional and personal life through things such as, volunteer activities.

For example, I am sure at some point you have had to manage conflict with someone you know, or you needed to prioritize tasks to get things done.

So, as you go through this video or read the transcript, think about when you have done these buckets of work, either in your personal or professional life, and write them down. And for any bucket, you have not done, write that down as well and put a star next to it, as this could be a critical skill gap you will need to address.

Now it's time to go deeper into those 15 items I discussed.

ENTERPRISE ANALYSIS

Let's start with Enterprise Analysis.

This is one area of business analysis that tends to get skipped over. And it's not because the BA doesn't want to focus on it, but many times the BA doesn't have the time to by the time they are included in the project. However, this step is a critical step and can really help you as a BA navigate the organization to get the business analysis work completed.

Understanding how the organization is structured to include the stakeholders, processes, customer journeys, systems, data, and more, will arm you with the knowledge to successfully complete the business analysis work. Understanding the organization's objectives and goals is imperative. As well as having an understanding of how to create business cases can help to identify projects needed to drive organizational transformation.

It's also very important to understand the domain you are working in. When I say domain here I mean the business area such as finance, accounting, technology, and human resources, and this can also relate to the industry such as healthcare.

To determine if you have ever done anything like this, think about times when you have started a position in a new company, or department. Did you take time to understand how it was organized, and if you did, what approach did you take? If you did not, what would you do today to gain that understanding?

PLANNING THE BA APPROACH

Moving on to Planning the business analysis approach. This is another critical area to set you up for success to conduct business analysis work. Planning the BA approach is all about defining the approach you will take to perform and execute the BA work. This is an area where newer BAs may struggle. However, the more experience you gain conducting BA work the better you will get at it. But to get you started, here are 6 common approaches or considerations when determining the BA approach:

• First thing is first, understand the problem that needs to be solved. The reason projects exists is to solve some type of organizational problem. If you do not clearly understand the problem to be solved you run the risk of solving nothing at all.

• Second, understand the scope and timeline of the project. Now that you understand the problem make sure you understand the boundaries of the problem to be solved. This helps to keep the project work focused. Yes, there are times the scope may change as you gain understanding through the project work, but there needs to be conditions applied to keep the team focused, and if changes are required a firm WHY and consensus on the reason for those changes.

• Third, understand who your stakeholders are. You can't do this work alone. At some point, you will have to talk to someone. Make sure you know not only who the stakeholders are, but their role in the project.

• Fourth, determine the methodology to be used if not already defined by your organization (e.g., agile, waterfall, iterative). This will help in determining the next step which is identifying the deliverables that will be created throughout the project.

• Fifth, determine the deliverables that will be produced. One thing to consider here is the type of project. The project type can help define deliverables/processes that will be needed. For example,

  • For a Business Process Continuous Improvement Project a common deliverable are business process maps

  • For a Data Migration Project, some common deliverables are data maps, entity relationships diagrams, system context diagams, a glossary, and/or a data dictionary

  • For Technical Projects you may have a business process diagram or model to help understand the current state and pain points.

    • A future state process map to depict what is a desired future state to eliminate those pain points

    • A Business Requirements Document (BRD) (yes some organizations still leverage business requirements documents) to document the functional, non-functional and transition, requirements

    • Use cases/user stories to document the functional requirements

    • Product backlog, or some other mechanism, as a way to prioritize your requirements

    • A formal approval process to gain consensus and approval on the project requirements

    • A traceability matrix to ensure the requirements are being developed and tested throughout the project

    • Technical specification documents to ensure the solution is meeting the business needs and features

    • Test cases and scripts to ensure the requirements are functioning as expected

    • A change management process to track changes to the requirements

There are so many more options and ways to execute technical projects, but I believe this gives you a great idea of the different type of deliverables that could be developed.

• Sixth and final consideration is to determine the communication plan. It's important to set expectations on when you will communicate the status of your work, as well as, an escalation process in case you encounter any roadblocks or challenges. This level sets for everyone when, and for whom, communication will happen.

Now, I know that was a lot of information, let's bring this full circle with an example:

Consider you have been assigned to a process improvement project. A potential 10-Step business analysis approach you could take for this project could be:

1. Document the current state through a process map leveraging Business Process Modeling Notation, known as BPMN

2. Analyze the current state to find areas of opportunities

3. Document the future state by creating a future state BPMN Process Map

4. Identify business needs and features and place them in the Project Charter or potentially another type of document/deliverable based on your organizational standards

5. Elicit requirements through a series of requirement workshops that you would organize and facilitate

6. Out of what you learned in the requirement workshops you would gather and document the requirements in a Business Requirements Document (BRD) or use cases or user stories

7. Validate the requirements through a requirements review session with all the necessary stakeholders

8. Obtain formal approval through your documented approval process

9. Have a defined plan of how to manage the requirements elicited an gathered

10. Create a traceability matrix to ensure the requirements are being developed and meet the needs of the business

Now hearing all of that, think about a time when you had to lead a project. Do you recall doing anything of the things discussed so far. If so, you are doing BA work. If not, then you have identified some skill gaps and you can definitely close those gaps.

Now that you have an idea of how to approach and plan the BA work let's move on to executing the plan in a little more detail.

First up, ELICITING THE REQUIREMENTS.

You will need to determine how you will elicit the requirements from your stakeholders.

Elicitation is the ability to draw out, or draw forth, requirements from your stakeholders, or Subject Matter Experts, also known as, SMEs. This requires the ability to facilitate conversations by asking questions, but more importantly the RIGHT questions.

3 common techniques to elicit requirements are:

1. Requirement workshops as mentioned previously, where you will schedule a meeting, invite all the necessary stakeholders needed, and have a very focused meeting with an agenda and desired outcomes.

2. 1 on 1 interviews where you will schedule an individual meeting with a stakeholder to understand their business needs and requirements.

3. Focus groups, where you invite a smaller set of stakeholders to focus on a particular problem or process (e.g. a problem a specific department or team has). Typically these stakeholders are the department business heads and subject matter experts (SMEs), wtih the end goal to understand their business needs and requirements.

Some additional techniques you can leverage to elicit requirements are brainstorming, user stories, process mapping, and surveys to name a few. But the KEY is knowing your audience, and organizational needs, to help determine the best approach.

I would also like to mention that for each of these techniques, you should create an agenda that sets ground rules for the meeting, outlines the purpose of the meeting, the desired outcomes, required attendees, length of the meeting, what topics will be discussed, as well as, sections to outline action items, parking lot items and decisions agreed upon during the meeting.

REQUIREMENTS GATHERING, DOCUMENTATION, and PRIORITIZATION

Now, once you have elicited the requirements you need to gather, organize, and prioritize them and then document them in a way that will add value to the organization. If you are anything like me you will probably have notes all over the place from the different meetings; therefore, you want to take time to gather up the requirements elicited and organize them in a way that will provide value to the audience consuming them. When I say organize them you can put them in categories of functional, non-functional and/or transitional requirements as some examples.

Now once you have figured out the organization it's time to document the requirements. Now there are many different ways out there to document requirements, so don't let that overwhelm you. My rule of thumb is to use a communication vehicle that will add value, and not just document to document. Some examples of deliverables once again are Business Requirements Document (BRD), Use Case, and/or User Stories.

I do want to take a moment and discuss how to write good requirements because this is really important. Requirements should be clear, complete, consistent, feasible, modifiable, traceable, and testable. Let's go a little deeper on what I mean by these characteristics:

• To be a clear a requirement it should not be ambiguous or leave anything open for interpretation

• To be a complete requirement it should state all that is needed effectively and holistically

• To be a consistent requirement, it should not contradict any other requirements

• To be a feasible requirement, the requirement should be achievable and realistic

• To be a modifiable requirement, the requirement has the flexibility to change based on the environment and needs of the organization

• To be a testable requirement, the requirement should be certified, meaning verified and validated

• To be a traceable requirement, it should effectively trace to any software or test documentation to track that the requirement has been met

Now once you have documented the requirements you want to prioritize them. You want to make sure your criteria for prioritizing requirements are agreed upon by ALL stakeholders. Many default to "high, medium, and low", but I HIGHLY recommend you add more context to what constitutes a high, medium, and low rating if you choose to use such a ranking system. It's too easy to give all requirements a HIGH, especially, when all the different stakeholders may feel that their requirement is the most important one. In addition, you can use a number based or point based ranking system as well.

As I mentioned before, the KEY to documentation is to know your audience and make sure the documentation you create adds value. If you create documentation that no one will read or use, why are you creating it? Requirement documents do not have to be 500 pages to be effective. Only create documentation that adds value and organize it logically so it’s easy to follow. It’s more about the VALUE than the quantity of documentation.

REQUIREMENTS VALIDATION & APPROVAL

Moving along...once you have documented the requirements it’s wise to verify them with your stakeholders and obtain consensus that the requirements are accurate. I said, consensus, not 100% agreement, because you may not always get 100% agreement. Once the requirements have been validated it's time to formally approve them. Once approved, your requirements are now considered baselined. If any of the requirements change after formal approval, they will go through the formal change control process.

REQUIREMENTS MANAGEMENT & TRACEABILITY

Now that the requirements are baselined, it’s important to have a process in place to trace the requirements. Requirement traceability is a process of tracing the requirements to the other documents/deliverables created to ensure the requirements are being met. For example, you will want to trace the technical documents to the requirements and/or the test cases back to the requirements to ensure the baselined requirements are being addressed.

CHANGE MANAGEMENT PROCESS

Let's move on to the change management process that I mentioned prior. There is always the chance of a change in direction, or needs depending on the industry/domain/environment in which you work. You can facilitate these changes through a defined change management which is to:

1. Identify and document the change

2. Idenitfy the reason for the change

3. Identify the impacts of the change, and

4. Provide recommendations on how to move forward with the change

Now, this could be done through a product backlog when leveraging the agile methodology, or a defined change management document for non-agile methodologies. The change management process helps to keep the integrity of the project management process to ensure effective tracking of changes due to decisions made.

SOLUTION VALIDATION

Let's move on to the last functional skill I would like to highlight which is Solution Validation.

As a business analyst, you will want to make sure the solution created is meeting the business' needs. Therefore you will want to validate shortly after the solution is implemented that it is working as intended.

And then you will want to check in maybe every 30, 60, and 90 days, or based on some sort of frequency that the solution is stable and performing as intended.

Now during implementation, the BA is typically engaged and may wear multiple hats whether right, wrong, or indifferent. Just be prepared for this if it should happen.

SOFT SKILLS

Now that we have discussed many of the more technical skills, let's discuss some of the SOFT SKILLS, which I consider the CRITICAL SKILLS of Business Analysis.

I want to be clear this is not an exhaustive list, but some of the common soft skills you want to consistently execute effectively.

1. The first soft skill I want to discuss is LEADERSHIP.

Leadership doesn’t always equate to management. We all lead in some way in our lives and as a BA you are leading others all the time. You are leading individuals from requirements planning to requirements discovery, to requirements implementation, to helop solve organizational problems.

2. The second skill is strong COMMUNICATION.

As a business analyst you must have strong verbal and written communication skills. You have to be organized and detail oriented to articulate the requirements verbally and in writing so that all stakeholders are clear on the requirements.

3. The third skill is INFLUENCE.

When you influence somone you affect or change them in an indirect, but usually important way. As a BA you are constantly influencing stakeholders to either make decisions so the project can move forward, or to gain consensus on certain decisions/direction.

4. The fourth skill is NEGOTIATION.

As a BA there is negotiation that occurs quite often. Again you are facilitating many conversations where you have to gain consensus to move the project forward, gain consensus on decisions, or secure stakeholder buy-in. There are times where you will have to negotiate with stakeholders to find a way through a challenge, or obstacle.

5. The first skill is RELATIONSHIP BUILDING.

Building relationships are critical in business analysis work. You cannot do business analysis in a silo. Or at least when I have watched BAs try they weren't very successful. You have to talk to someone at some point. Yes, even if you are introverted you do need to engage with individuals to get your work done.

6. This sixth skills are COLLABORATION & TEAMWORK.

As a business analyst you will need to collaborate and work with others on teams. The difference between collaboration and teamwork is that with collaboration everyone is working toward the same common goal, while with teamwork you are working on a team, but could be focused on different goals, or a subset of the team is focused on a specific goal. As a BA you will need to effectively work in both environments.

7. The seventh skill is CONFLICT RESOLUTION.

On any project, there is a very good chance there will be conflict. You are working on a project team where you have many different personalities, thoughts, skills, and other layers of diversity. As a business analyst, you have to be comfortable navigating through conflict and not avoid it. Navigating those crucial conversations are criticial to your success as a BA.

So there is your crash course on what are some of the main activities you will encounter as a BA, some technial skills you should possess, and some soft skills that are consistently used. The activities discussed in Part 1 of this question are the fundamental activities and soft skills BAs should possess. If you are missing any of them then take some time to obtain those skills. Also, depending on the industry, or domain you work there may be other skills you will need to possess as far as business acumen or technical knowledge in order to perform the duties.

My question to you is, have you done or executed any of what has been discussed? If so, then you have some, or all, of the common business analysis skills and competencies which demonstrates you are well equipped to pursue a business analysis career, even though you have not been formally trained, or held the formal title. You have transferrable skills that can help you move into a business analysis role so the future is bright.

Now, let’s move to part 2 of the 1st common question which is, "How do I identify the transferrable skills and competencies I possess to help me move into a BA role and identify skill gaps?"

Now when you are pursuing a BA position you must take time to get really clear on what type of business analysis work you want to do, the type of industries or domains you are interested in, and where do you want to go in your career. This will help keep you focused, and not as overwhelmed.

Start to rsearch job postings that relate to those interests. Once you find them take time to dissect them to understand what is being asked as far as skills and competencies for that particular position. You will start to identify patterns of skills, competencies, business domain knowledge, and more when you do this. You will then need to identify the scenarios from your past positions that meet those roles and responsibilities which helps you to identify your transferrable skills. You will also find where you have gaps and you will need to determine if those gaps are critical flaws based on where you want to go in career. If they are critical flaws you will need to devise a plan to close them.

As stated before, you probably have business analysis skills already and may not have realized it. So OWN the skills and competencies you possess, and be confident in what you know. Don’t just focus on the techniques and tools you leverage to do the business analysis work, but also think about those soft skills like verbal and written communication, building relationships, influence, negotiation, collaborations, and teamwork to name a few. You may feel these are just buzzwords, or cliche, but I have found that 80% of the work a BA does is around these soft skills.

Now, let’s move on to the final part, which is part 3, "How to market yourself to effectively get noticed". There are 4 areas you can immediately start working on to effectively market yourself now:

1. The first area is your RESUME.

Your resume is a great starting point. I recommend you look at the different skills and competencies you possess and add them to the skills section of your resume and throughout your resume so Application Tracking Systems (ATS) can capture that information.

In addition, look at the experience section of your resume and update the bullet points to demonstrate the business analysis work, skills, and competencies you bring to the table. When applying for BA positions ensure those items are at the top of each of the applicable positions and your resume is speaking to the responsibilities and desires in the job position. Managers and recruiters are quickly scanning your resume so you want that information to stand out.

2. The second area is all about your LINKEDIN PROFILE.

Once you have completed your resume you can leverage some of that information to create, or update, a LinkedIn Profile. You want to make sure you are really emphasizing your business analysis skills if you are desiring to pursue a BA position. Which means your headline, summary, work experience, certifications, trainings, and recommendations should reflect some aspect of business analysis. You can also turn on the option that you are looking for work and reach out to your network to make you aware of any open job positions.

3. The third area is NETWORKING.

Attending conferences and networking events are great opportunities to market yourself. Make sure you have your 30 seconds elevator pitch so people start to know your name, your personal brand, your value proposition, and your career goals. This is a great way to become more visible and memorable when opportunities open. You may be surprised who may reach out to you for that next opportunity.

4. The 4th and final area is VOLUNTEERING.

This is one area you can start to put your BA skills to work. While you wait for that next opportunity, offer up your BA skills through volunteer organizations. If you volunteer for an organization currently reach out to see if there are any projects you can work on to continue to strengthen your BA skills. These are then examples of work you can now add to your resume, LinkedIn profile, and talk about in your interview.

Well we have come to the end...

This completes Part 1 of, "5 Common BA Career Questions Answered".

I am hopeful you have "more hope" in pursuing a business analysis career based on what you have uncovered in the form of skills and competencies and the current work you have conducted in your career, and potentially personal life. Now go forth with your BA Ninja skills and work on pursuing your BA goals.

Also, stay tuned for Part 2 of the "5 Common BA Career Questions Answered" where I will focus on the next common question: "What technologies should I know as a BA?"

Until next time,

The BA Martial Artist is signing off! 🥋🥷🏽

P.S. If you need additional assistance on updating your resume I offer an online self-paced resume course and resume review services working with me directly.

P.P.S. If you need additional help with interview preparation I offer an online self-paced interview preparation and execution course and interview preparation services working with me directly.