They may not have the business analyst job title, and they may not even be aware they are doing business analysis work, but someone is ensuring the right problem is being solved, that everyone understands the problem and solution in detail and is on the same page about what the software is going to do, and how that achieves the business objectives.

So what is a business analyst? And what does a business analyst do?

There are many variations of the business analyst role, and the business analyst job title is used inconsistently. Here at Bridging the Gap, we focus on how the practice of business analysis unfolds specifically on software projects, where the business analyst is responsible for ensuring the team is solving the right business problem and guiding the team in analysis and communication activities that get all business and technical stakeholders on the same page about the project scope, including the business and technical aspects of the solution.

Whether your team is leveraging agile software development practices or more traditional ones, effective business analysis is essential to success. If you are interested in starting, succeeding, or excelling in a business analyst role, this article is your guide to the role, responsibilities, job description, and mindset of a business analyst.

Defining The Business Analyst Role and Mindset

Out of chaos, we create order.

Out of disagreement, we create alignment.

Out of ambiguity, we create clarity.

But most of all, we create positive change for the organizations we serve.

Business analysts lead teams from the inside out. We create positive change for our organizations. We inspire others to follow us on our path toward positive change. We help everyone understand exactly what that change is and how they can contribute to it. We help teams discover what the change should be.

Source: Bridging the Gap’s Business Analyst Manifesto.

In essence, if you’ve helped teams focus on alignment, clarity, and positive change, you are filling the essentials of a business analyst role and have the mindset of a business analyst. It’s not uncommon for an aspiring business analyst to discover they’ve been doing BA work intuitively for years. They are able to uncover many transferable business analyst skills and position themselves for mid-level and, depending on their experience, even senior business analyst roles.

A Dedicated Business Analyst Role Sets Projects Up for Success

Having a dedicated business analyst role on your project has a tremendous ROI (Return on Investment). As high-performing business analysts, we need to be aware of the value we create, and how we contribute to the ROI of a project. The role is still misunderstood by many, and we’ll often find ourselves needing to educate our leadership and stakeholders about how we can make a contribution.

Business analysts add value by:

• Reducing rework that’s caused by overlooking requirements until late in the development process.
• Reducing requirements churn, or the time investment from stakeholders in getting clear on what they want out of a software solution.
• Finding more cost-effective solutions, whether that’s simplifying the requirements or finding non-technical solutions to business problems.
• Discovering new business benefits that increase the ROI on the planned project investment.
• Prioritizing requirements, so the development team has a clear idea of what to implement first.
• Facilitating communication with the business community, so the delivered solution is used as intended.
• Providing a framework for IT to scale, particularly as an organization grows beyond the boundaries of informal communication where everyone knows everything about the business.

Here’s a video walking you through the value proposition of business analysis:

>>Plan Your Next Step with a Free Workshop

While this is a lot of information, you might be wondering exactly what steps you can take. We offer a free Quick Start to Success workshop  that will help you figure out your next step.

Click here to learn more about how to start your BA career

The Key Responsibilities of a Business Analyst

To contribute this level of value, you need to bring a structured framework or approach to the business analyst role. This role includes taking the requirements aspect of the project from initial problem or idea to a fully implemented solution. The following business analysis process supports the business analyst in navigating a project effectively and successfully.

This is the 8-step business analysis process framework we teach at Bridging the Gap, and it’s helped thousands of business analysts be more effective in their role. Let’s take a quick look at the business analyst responsibilities involved in each step.

1. Get Oriented – Start actively contributing as quickly as possible by managing expectations and conducting preliminary stakeholder analysis.
2. Discover the Primary Business Objectives– Ensure the right business need or problem is solved, and that all stakeholders are aligned on the expected outcome.
3. Define Solution Scope– After exploring multiple possible solutions, gain agreement from stakeholders on the scope of the solution to be developed, and ensure it fits within the constraints of the project.
4. Formulate Your Business Analysis Plan– Identify what types of documentation or deliverables to create, and what needs to be done when. Ensure stakeholders understand what contributions they need to make as part of the project, as business analysis never happens in a vaccum.
5. Define the Detailed Requirements– Gain alignment and clarity at a detailed level, so that both business and technical stakeholders can successfully implement the solution. This involves developing a consistent method of communication so that all stakeholders know and understand the requirements.
6. Support the Technical Implementation– Be a partner with the tech team and ensure they have everything they need to be successful, and explore opportunities to generate even more business value from the software aspect of the solution.
7. Help the Business Implement the Solution– Support business stakeholders during implementation, user acceptance testing, and roll out so that they ultimately get what they need and are able to incorporate the delivered solution into their day-to-day work.
8. Assess the Value Created by the Solution– Assess the Return on Investment (ROI) of the solution, celebrate the project successes, and identify new opportunities to improve the business.

You can learn more about the 8-step business analysis process framework in this video:

And, yes, this process framework applies in agile too! Here’s a guide to how to leverage this framework to be a successful agile business analyst.

Key Skills for Success in a Business Analyst Role

The business analyst role requires both hard and soft skills. Business analysts need to be able to gain alignment from diverse sets of stakeholders on both the big picture and the granular details of the project.

First, there are core, underlying skills that set you up to be a great business analyst, such as:

• Communication skills – Verbal and written communication skills are extremely important, as is the ability to facilitate meetings with diverse sets of stakeholders.
• Problem-solving skills – The ability to understand what problem is being solved and why, as well as navigate new challenges and problems throughout the project, is essential.
• Critical thinking skills – Business analysts evaluate multiple solution options and provide critical thinking to back-up or probe into stakeholder assumptions.

Then there are specific business analysis skills in analysis and communication.  To be successful as a business analyst, you need a toolbox and a framework.

• A TOOLBOX of techniques that you can pick and choose from, based on the needs of your project and team.
• A FRAMEWORK that guides you step-by-step what to when.

At Bridging the Gap, we provide an organized, streamlined, and practical toolbox and framework in the form of The Business Analyst Blueprint® – it’s both a framework for approaching business analysis skill development and the name of our flagship, online, practical training program.

And it looks like this:

While we already talked about the end-to-end framework. :et’s take a deeper look at the toolbox of techniques a business analyst needs to succeed in their role.

• The Business-Level, or how the business work flows operationally, often completed by analyzing the business process (a textual model) and creating business process flow diagrams (a visual model).
• The Software-Level, or how the software system supports the business workflows, often completed through functional requirements models like use cases and wireframes.
• The Information-Level, or how data and information are stored and maintained by an organization, completed by data modeling techniques including an entity relationship diagram (ERD), data dictionary, data map, and system context diagram.

When you use multiple techniques, particularly powerful analytical and visual models, you will find that you naturally see gaps that others gloss over and identify the downstream impact of a change or new solution.

Here’s a video that walks you through the key business analyst skills.

The Typical Day of a Business Analyst – Or, What Does a Business Analyst Actually Do?

The role is so varied that there really is no typical day for a business analyst. And that’s one of the things many business analysts love about the role, as there is a lot of variety in the work.

I have an entire video on this topic, but here are a few things I’ll share here about the role:

• There tends to be a split between independent and stakeholder-facing work. It can vary from 50/50 to 70/30 in either direction. You want to be sure that you’ll enjoy interacting with people as well as doing independent analysis and critical thinking work.
• Business analysis is a self-managing role. You need to be proactively thinking ahead and planning out your process to ensure nothing slips through the cracks.
• The days tend to be different depending on what type of project(s) you are on and what phase they are in. Early on, you’ll be doing a lot more discovery. Then you’ll be in the details and analysis process. Then you may be supporting the business and technology teams during development and implementation.
• It’s quite possible you’ll be working on more than one project at once! So be ready to be in all the phases at any given time.

And here’s the video with a lot more detail on what to expect day-to-day:

Business Analyst Roles Can Vary Widely

While these are the essential skills and responsibilities of a business analyst role on a software project, roles and titles vary widely. Depending on the role, the BA professional may also take on more senior-level business analysis responsibilities, such as such as strategic analysis, learning new domains, and project portfolio management.

The definition of business analysis allows for many different approaches to the role.

• It brings in professionals who work on software projects, business process changes, logistics, or ensuring compliance with regulations.
• It brings in professionals who work on projects focused on integrating multiple software systems, building new software systems, and modifying existing software systems, or migrating from one software system to another.
• Sometimes specific industry expertise or expertise in a specific business application is required to be successful. Pick any attribute of a project, organization, or stakeholder group — oftentimes the business analyst role in that context is shaped around multiple attributes.

When reviewing business analyst job descriptions, pay attention to both the generalized aspects of the role that are common across many roles and the specialized skill sets that pop up in a specific roles.

Hybrid Business Analyst Roles Are Incredibly Common

What’s more, it’s common for a specific business analyst role to be a hybrid business analyst role, meaning that you will have responsibilities beyond the core of business analysis.

Common hybrid roles include:

• Business Analyst / Software Tester
• Business Analyst / Project Manager
• Business Analyst / Product Manager
• Business Analyst / Software Developer

Because business analyst job titles are used inconsistently, it’s not uncommon for these hybrid roles to be under the title of “Business Analyst”. It’s also not uncommon for a role like Project Manager or Software Developer to simply include business analyst responsibilities.

In fact, there are dozens of different business analyst job titles. You can learn more about the difference between the BA job title and the BA role here:

The Difference Between Business Analysis and Related Roles

What’s more, there are many roles that are closely related to business analysis, or leverage business analysis skills to be successful. Here are articles in which we dive into the difference business analysis and other, similar, roles:

• The Difference Between a Systems Analyst and a Business Analyst
• The Difference Between a Product Manager and a Business Analyst
• The Difference Between a Subject Matter Expert and a Business Analyst
• The Interplay of Project Management and Business Analysis
• The Difference Between Business Intelligence and Business Analysis Roles

How to Become a Business Analyst

Business analyst roles generally favor on-the-job work experience. And it is definitely possible for a mid-career professional with work experience to start a business analyst career.

1. First, learn about the business analysis career and confirm your career choice. Exploring the resources in this article is a great place to start!
2. Second, identify your transferable business analyst skills – these will enable you to skip right past entry-level BA positions.
3. Third, invest in your foundational business analysis skill set. Here at Bridging the Gap, we provide online business analysis training opportunities that help professionals start, succeed, and excel in their business analyst careers.
4. Fourth, build on-the-job business analysis work experience by approaching your current work with a BA mindset. For example, no matter your role, you can always improve a business process.
5. Fifth, focus your efforts to find your first BA opportunity. Leverage your areas of expertise and experience in related roles to focus on the opportunities that will be easiest to qualify for. Then you can expand your skill set and experience, opening up even more opportunities.

In short – if you truly want to become a business analyst, it’s certainly possible! And the career opportunities within business analysis make this an exciting time to pursue a business analyst role.

>>How to Learn the Foundational Business Analyst Skills

When you join The Business Analyst Blueprint® training program, you’ll gain real world experience in the industry-standard techniques and business analysis processes so you can upgrade your skills, bring a fresh perspective to your business analysis approach, and know exactly what to do on your software projects.

In this video, I’ll cover how to avoid the most common business analyst mistakes, so you can make smart project decisions that earn the appreciation of your stakeholders and open up more opportunities in your business analyst career.

One of the mistakes I mention in the video is not engaging stakeholders early enough. We’ve created a FREE guide full of practical tips, real-world advice, so you can discover how to work more effectively with stakeholders to achieve better project outcomes.

In this free download, you will:

• Save time and effort by clarifying the requirements more quickly.
• Build stronger relationships that elevate your reputation and career.
• Increase your impact by communicating more effectively and improving project outcomes.

 >> Download 10 Tips to Improve Stakeholder Engagement <<

As a business analyst, you want to create the best requirements documentation and models possible. But what if I told you that focusing too much on perfecting those documents is actually a big mistake. Not only does it waste your time when you do that perfection too early in the process, it can also damage your credibility and delay the business analyst timeline.

In this video, we’re going to cover this mistake and four others that every business analyst should avoid. Stick around to learn how to add more value to your projects and avoid these common pitfalls.

Hi, I’m Laura Brandenburg with Bridging the Gap where we help you start, succeed, and excel in your business analyst career.

Business Analyst Mistake #1 – Making Assumptions About Your Role

The number one mistake I see business analysts make on a new project is to make assumptions about the business analyst role that lead to overlooked responsibilities or areas of requirements. And I can point the finger at myself here more times than I would like to admit.

• I have unknowingly trampled on other team members’ roles because I just thought that’s what a BA was supposed to do.
• I’ve failed to deliver what was actually expected of me while working with incredible diligence towards deliverables that no one actually wanted me to create, and therefore went undervalued and underappreciated.
• I have followed the job description I was given to a T only to the learn that my team really needed something additional from me that wasn’t explicitly asked for.

There is so much dialogue out there about what the business analyst role is and what it’s supposed to be, and these jobs vary widely among different companies. Even within the same company, they can vary depending on what project team you’re on or what stakeholders you’re working with or what that team makeup looks like.

Correcting this mistake is really simple. Take time to clarify your role. Confirm your understanding and ask questions whenever anything is not clear. A lot of business analysts feel like they need to make assumptions because they shouldn’t be asking and asking for clarity about their expectations, that they should just know. But just knowing often leads us to deliver the wrong thing to the wrong people.

Let your manager and team know what you’re planning to do. Ask for their feedback to make sure you’re on the right track, and then deliver on your promise. Do this not just once, but again and again throughout the project as new information surfaces, or as new stakeholders get involved, or as you start to see an expanded view of how you can contribute. Re-clarify over and over again.

Wanting to learn more about the business analyst role? This video on the typical day of a business analyst is a great place to start!

Business Analyst Mistake #2 – Not Engaging Stakeholders Early Enough

Now, mistake number two is not engaging stakeholders early enough. When we start to move forward without getting all of the stakeholders on board. And sometimes the stakeholder is like lurking in the corner, not like literally in the meeting room, but they’re lurking somewhere, but they’re not really engaged. Sometimes they’re just too busy to meet with us. Other times there are reasons that we don’t want to meet with them, so we try to work around them. But it’s really important to get all the stakeholders invested upfront.

• On a project with new stakeholders, it’s your role as the business analyst to really invest extra time in getting to know who they are, what they care about and how they work best. It’s also a great time to clarify your role.
• If you are working with stakeholders that you already know and trust, a new project is a great time to deepen that relationship establishing ground rules to correct for past problem areas and really reengage since you’re working on something new together.

Even when you are facing that pressure to just move forward and get the requirements done already, you absolutely must ensure there is engagement each step of the way. Otherwise, you are simply setting yourself up to have to rework the requirements later, which is going to damage your credibility as a business analyst.

If engaging stakeholders makes you a bit nervous or you just want to get better at it, it’s one of those areas we can always get better at as a business analyst. I’ve got an absolutely free guide that’s called 10 Tips to Improve your Stakeholder Relationships.

> Download 10 Tips to Improve Stakeholder Engagement <<

And here’s a video with lots of great tips on engaging stakeholders too!

Business Analyst Mistake  #3 – Perfecting Documents Too Early

Now, the third mistake that I see is business analysts spending too much time perfecting documents and models too early. This is often related to not engaging stakeholders and it’s a great procrastination tactic. We can feel incredibly productive. We’re working really hard to get all our lines lined up and everything looking really beautiful, but it’s not actually capturing what the stakeholders want. You’re not in a collaborative information sharing type role where you’re learning more about the actual project or the domain.

While it feels really productive to sit behind your computer and tweak the language in your requirements or get all of your lines straight on a visual model, like an entity relationship diagram, you’re not going to really create real value from that documentation until you bring them to stakeholders and work towards creating a shared understanding.

If you happen not to be familiar with an entity relationship diagram, or ERD, I did do a full video tutorial on that model that you can check out after this video by clicking on the video below. If that’s something you want to learn more about, we’ve got all kinds of content on that.

My challenge to you is to put your together rough drafts of documentation and use those to guide productive working meetings with your stakeholders. You’re going to learn so much more from the discussion and the project is going to move forward more quickly.

Business Analyst Mistake #4- Focusing Too Much On the What and Not the Why

That brings us to mistake number four, which is focusing too much on the what and not the why, or really like focusing too much on the what too early and not using time early of the project to really focus on the why. This can lead to misunderstandings and misaligned expectations between stakeholders.

This is especially common, again, when we’re faced with those aggressive requirements deadlines and people just want us to get the requirements done so that the implementation can start, or when our stakeholders just seem so clear about the solution and they really just want us to help get the details down on paper.

Handling tight deadlines is more art than science, and here’s a video with some strategic approaches to navigating expectations without losing credibility.

As a business analyst, it’s really important to understand the underlying business goal and the objectives that drive that project, and to ensure that all stakeholders are on the same page regarding why the project is being funded in the first place and what the benefits are that it’s expected to deliver. This involves not just documenting the project requirements or all the things that the software needs to do, or even what the future business process is going to be, but also getting that understanding of the why.

What’s the problem that we’re trying to solve here? What is the end result we want to create for the business? What are those business objectives? By getting clear on those, you’re going to help keep your project on track and avoid unexpected delays, increased costs, and ultimately deliver a solution that does not deliver the expected benefits.

Business Analyst Mistake #5 – Allowing Scope Creep (and Straying from Focused Business Outcomes)

That really leads us to the fifth mistake I see, which is somewhat related to the previous mistake, but there’s a nuance that’s really important that I wanted you to grasp, and that’s really allowing scope creep or straying from these focused business outcomes. This means that the solution sort of gets bigger and bigger and bigger the longer the requirements process goes on. It strays from that original focus of the project. This will often happen when the business analyst is what is considered too business oriented.

And yes, that is a real thing. A business analyst can be too oriented or focused on the business in the sense that they don’t hold boundaries or constraints or keep things in check for the business. In fact, I did a video on this concept a while back that you can check out after this video.

It can also happen because as we build trust with stakeholders, we start to become really empathetic and they really start to open up about the problems that they have and we want to solve those problems and help them. We’re a helper kind of profession. Again, the scope just grows and grows. We can include that little thing and that little thing and that little thing. And, no, it’s really not what we’re supposed to be here for, but I can see how much value that it’s going to add for you.

This really damages our credibility with the project team because we build a reputation as somebody who comes in and takes maybe a small project or a medium-sized project and makes it way bigger than intended, and then people in other roles, like the project manager, are forced to arbitrarily cut scope to get the project done on time and on budget.

The solution to this is to always keep the desired outcomes of the project or the why, the problem that we’re solving, top of mind in ourselves, in our stakeholders, and for our sponsors. And as you get into the details of those requirements, make sure that each requirement is absolutely necessary to solve that business problem or achieve the business objectives of the project.

As an aside, if this means you’re smacked dab in the middle of a project and you haven’t done that work that we talked about before of understanding the business outcomes, the most important work you have to do is to bring that kind of clarity to the project, and to do it sooner rather than later.

Move Forward, And Do Your Best in Business Analysis

We’ve covered quite a few mistakes here that I see business analysts make. The last thing I want you to do is leave this video feeling more afraid of making mistakes than of moving your project forward. Any action you take in the direction of creating alignment and clarity and positive change for your organization will move you forward, will move your organization forward, will move your project forward.

You will make mistakes, and that’s okay. Just keep learning from them. How do you think I could put this video together? Because I’ve made the mistakes and I’ve learned from them, and I’m trying to share them with you so that you hopefully don’t have to make the same mistakes I did.

But maybe you’ve made one of these mistakes. Maybe you found something else, or you’ve learned from these and you make something new. That’s great. It’s a great learning opportunity. Keep moving forward instead of worrying about the mistakes. I’ve published tons of content here at Bridging the Gap about how to become a better business analyst and excel in your career, mostly leverage for all the mistakes that I’ve made in my career.

One great insurance policy against making mistakes is having really strong stakeholder relationships. The more your stakeholders respect and trust you, the easier it’s going to be to cover up when you eventually do slip up here and there.

We’ve created a new free guide, relatively recently, that gives you 10 tips to improve your stakeholder relationships. You can claim that free download right now by clicking below.

>> Download 10 Tips to Improve Stakeholder Engagement <<

Engagement is key in any role, but it’s especially important for you as a business analyst where you are constantly communicating with stakeholders and making important decisions.

I’d love to see you at another video that I’ve recorded specifically on how to build more confidence in your role, and I’ll see you over there next.

If you’re looking for a career that’s high in demand, has immense growth potential, and will ride the wave of data revolution, an opportunity in the business intelligence space might be for you.

In this video, you’ll learn:

• The typical responsibilities one might expect with a business intelligence role
• How a BI role differs from a traditional business analyst role
• The difference between data analysis and data modeling
• The technical skills required in business analytics and business intelligence

Whether you are just starting out or looking to make a career change, this video is a must-watch.

If you are interested in enhancing your data modeling skills, download our free data modeling training! This resource will teach you:

• What data models you can use to clarify the data requirements
• How to use data models on a variety of projects
• How to understand new domains quickly
• How to excel on system integration and data migration projects

 >> Download the Free Data Modeling Training <<

It is all about the data these days, and if you are looking for a career that’s in high demand, has immense growth potential and will ride the wave of this data revolution, we find ourselves on an opportunity in the business intelligence or BI space might be for you.

In this video, we are going to look at business analysis roles in business intelligence and analytics, including the key skills that you will need for success and how it differs from a more traditional business analyst role. Whether you’re just starting out or looking to make a career change, this video is a must watch.

Hi, I’m Laura Brandenburg with Bridging the Gap where we help you start, succeed, and excel in your business analyst career with weekly videos on business analysis, tips and techniques.

Two Main Ways the “Business Analyst” Job Title is Used

When it comes to job titles in the business analysis space, they can be confusing and deceiving. In particular, there are two primary ways that the business analyst job title is used.

The first is the role that literally bridges the gap between business and technology by ensuring that software solutions do what the business needs them to do and solves a real business problem. Often this role is seen as a technology or IT role. Sometimes it’s located within the business and is the role that collaborates with the technology team.

The second way that the business analyst job title is used is often for more of a business intelligence or analytics role that involves using data analysis and business intelligent tools to gain insights and make decisions. Often this role sits on the financial team, but it may be in marketing some aspect of business, or it might even be on an IT team, or you might have a company that has an entire business intelligence department within one of those larger umbrellas. And of course, as a business analyst, you could be filling both roles. This video is really going to be about the typical responsibilities in both of these roles; the skill sets you need to succeed, and how the rules differ and overlap.

Typical Responsibilities in Business Intelligence

The typical responsibilities in a business intelligence role involve collecting and analyzing data to identify trends and patterns. You’d be developing models that show patterns in the data. You might be identifying opportunities for growth and improvement or how to solve a specific business problem. You could be creating reports that summarize insights and inform business decisions and presenting those reports to leadership within your company, a project team, or a set of sponsors that are trying to make decisions about how to invest money in the company.

Clearly you could be in both roles. You could be using business analytic tools and techniques to identify problems and opportunities, and then you could be using business analysis tools and techniques to clarify and solve them.

One interesting project that I worked on was after the implementation of a major business intelligence platform. It turned out that the data wasn’t actually giving them the information they needed and so I worked with stakeholders to update their business processes and their proprietary software systems to capture the data that they needed for reporting. I think this example shows how these two roles flow together and how essential both can be.

Now to understand the difference between business intelligence roles and the more traditional business analyst roles you really need to understand the difference between data analysis and data modeling.

The Difference Between Data Analysis and Data Modeling

I have an entire video on the difference between data analysis and data modeling, so make sure to check that video out after you finish this one. Nevertheless, I want to speak to it briefly here because it’s just so relevant to this discussion.

Data analysis is the work that you do to analyze the data. It involves generating reports, analyzing those reports, mapping trends, like looking at huge quantities of data sets of things that have been happening in terms of business activity and customer activity, and analyzing and creating meaning from that data, the raw data, that’s been created.

Data modeling is the work you do to decide how information will be modeled and stored in an information system. You would answer questions like, what information do we need to store about our customer behavior or about this transaction, o about how the business completes this workflow? What field are we going to capture this information in?

In the context of setting up a business intelligence reporting system, you’ll determine what data sources are being fed into that centralized repository and how the information in those systems relate together. And again, there’s an overlap because without the data being stored and managed, you really can’t report on it to use it to make better business decisions.

That’s the scenario that my team had run into. They had this great business intelligence system, but it didn’t have the data that they needed, so we had to backtrack and figure out how to re-engineer their business process and their software to ensure we were capturing that data so they could use it to analyze it and make better business decisions.

It’s important to develop skills in both areas if you want to succeed in business intelligence.

If you are interested in enhancing your data modeling skills, we have a great resource for you. It’s our free data modeling training, and it’s going to teach you what data models you can use to clarify data requirements and how to use these on all kinds of projects, even system integration projects and data migration projects, which is really a business intelligence rollout.

A rollout of a business intelligence system often is both your migrating or integrating data into that system. The set of techniques that we cover in that free training would be relevant to you.

In a business intelligence rollout as well, even if you don’t know how to code, I like to stress that about data modeling. You don’t have to know how to code to know how to model data. You can claim this free training by clicking the link below.

 >> Download the Free Data Modeling Training <<

Technical Skills Required in Business Analytics and Business Intelligence

Let’s talk about the technical skills that are required in business analytics and business intelligence. If you want to take your career in that direction, you will need to have a more advanced technical skill set for a functional or process focused business analyst role.

At a minimum, you’re going to need very advanced skills in Excel to be able to create sophisticated reports and pivot tables and really leverage all the functionality available to you in Excel to take that data and make it consumable by other stakeholders in your organization. Often you will need to know how to use SQL so that you can generate reports directly against data sources and run those queries against the database.

It’s also likely that you are going to need to know the business intelligence tool in place in your organization. Common examples include Power BI and Tableau. You might see those coming up on job descriptions for a business analyst role that might be titled Business Analyst. That’s often a great indicator that it’s really a business intelligence analyst type of role. Those sorts of tools like Power BI and Tableau centralize data from multiple sources and help you generate those sophisticated reports that you can use as part of exploring business problems.

Business Acumen is Also Required

Now, business acumen is often also required. This is not just a technical role. You need that business acumen to know what questions to ask. How do I interpret this data to answer those questions? How do I present this data in a meaningful way to executives and other stakeholders to drive better decision making? It’s a technical role with still a business acumen focus.

Where Do You Want to Go With Your Career?

My question for you is, where do you want to go with your career? Business analytics, business intelligence, and more general business analyst rules all represent great career opportunities. Where you ultimately decide to go in your career will depend on the skills that you want to develop. Do you want to be more data focused and technical? Do you want to be part of ongoing decision making and prioritizing improvements? A career in business analytics or business intelligence could be a really good fit for you.

Do you want to be more process and functional focused, perhaps less technical, more collaborative than a career in business analysis doing process development and functional software requirements as well as modeling the data could be a great fit for you. Both are an option. These roles flow really well together, and no matter what you choose, you could find yourself doing work from the other role on a particular project or just at a particular time in your career. Either way, data modeling skills are going to be essential to your success as you can’t analyze data if you don’t understand how it’s structured. That’s why our free data modeling training is so valuable.

Expand Your Data Modeling Skills

You can sign up for that free training right now and discover the essential data modeling techniques that you can use to add more value, even if you don’t know how to code, by clicking the link below.

 >> Download the Free Data Modeling Training <<

It means more authority, more responsibility, and more impact.

If you’re curious whether or not you are prepared for a Lead Business Analyst role, this video is for you because I share 5 tips to help you excel as a Lead Business Analyst.

In this video, you’ll discover:

• What a Lead Business Analyst is
• My 5 tips for success as a Lead Business Analyst
• Career growth opportunities beyond becoming a Lead Business Analyst

If you’re looking to start a career as a business analyst, I have a complete free workshop called Quick Start to Success as a Business Analyst. You’ll discover:

• What a business analyst does
• How to be effective in your role
• The key skills you need to be more successful in today’s competitive job environment

>> Sign up for the FREE workshop <<

Becoming a lead business analyst is a significant step forward in your business analyst career. It means more authority, more responsibility, and also a lot more impact. But are you actually ready? What will it require and how can you prepare yourself?

In this video, I’ll be sharing five tips on how to be successful as a lead business. This is a role I have filled during my business analysis career, and leading teams is still one of my favorite aspects of my role as CEO of Bridging the Gap. So stay with me and let’s dive into the five tips that will help you prepare for this exciting opportunity.

Hi, I’m Laura Brandenburg with Bridging the Gap where we help you start, succeed, and excel in your business analyst career with weekly videos on business analysis tips and techniques.

Lead Business Analyst – Defined

Typically, a lead business analyst is responsible for overseeing and coordinating the efforts of multiple business analysts on a project. The lead might be a business analyst manager by title, or they might be the lead on a project without managerial authority over a group of BAs working on the project. For this video, we’re going to talk about the leadership role, not the management role.

For context, when we talk about business analysis here at Bridging the Gap, we’re talking about the role that literally bridges the gap between business and technology stakeholders. This means they help ensure software solutions actually do what the business needs them to do and solve real business problems.

Leading the BA effort on a project, it could involve planning the business analysis effort, it could involve determining how the requirements will be managed. It could involve reviewing deliverables created by all of the business analysts on the team for quality inconsistency. That might start to sound a lot like a project manager, but there is a key difference.

While the project manager coordinates the efforts of the entire project team to deliver the solution, the role of the BA Lead is to coordinate the efforts of several business analysts to discover the problem and determine the requirements of that solution. So let’s just take a look at these five tips on how to be more successful.

Lead Business Analyst Success Tip #1 – Put A Business Analysis Framework In Place

Tip number one is to put a business analysis framework in place. When you are leading a team on a project, you need to have a framework for how you perform business analysis. Where does your work start? Where does it end? What are the templates a business analysts is supposed to use and when are they used? What is expected from each business analyst on that project? You need to have clear expectations in place so that your business analysts know what’s expected of them and how they can contribute.

A great starting point for getting a supportive framework in place is by learning about our eight step business analysis process framework that we teach here at Bridging the Gap. I did a whole separate video outlining those eight steps, so if you haven’t watched that, I’d encourage you to do so after this video.

Now, if you have a team of junior or entry level business analysts, this is where you may need to explore investing in business analysis training to ensure that they have the foundational skills that they need to be successful. It can be overwhelming to try to train business analysts and do all the other leadership responsibilities at the same. If you’re in that situation, please reach out about the training we offer here at Bridging the Gap.

Lead Business Analyst Success Tip #2 – Divide Up the Work

Tip number two is to divide up the work. With a framework in place, you’ll want to start to look at who is going to do what. As the lead business analyst, you’ll often be responsible for the higher level or the strategic business analysis activities, like collaborating with high level stakeholders, defining the business needs, providing the overall scope of the project. Then your business analyst team will step in to discover, analyze, and define the detailed requirements.

This requires you to create a business analysis plan that is step four in that business analysis process framework we talked about. But that plan needs to segment your project in a meaningful way. This could be by software system or by stakeholder group, or by a category of features. And then your individual business analysts are responsible for analyzing the business processes, defining the functional requirements, and analyzing the data requirements within their assigned area of work.

Alternatively, if you have BAs that are skilled in, say, business process and others skilled more in data, you could look at sequencing the project to leverage their skillsets and their areas of expertise across all parts of the project. Depending on the size of your team and the work that’s required, you may also need to reassign yourself requirements deliverables as well. You may be doing the leadership of capabilities as well as doing the detailed requirements work for a part of the project.

Lead Business Analyst Success Tip #3 – Implement Knowledge Sharing

Okay, so let’s talk about tip number three, implementing knowledge sharing. If you are new to the business analyst lead role, I’m guessing your head was buzzing a little bit as I was talking about dividing up the work because how does each business analyst actually be effective without seeing the whole big picture? When you are the sole BA on a project, you are responsible for the big picture and all the details. When a requirement in one area impacts another, you just tend to see the impact and make the adjustment. How will this work with business analysts all working in their own silos? Well, you need to break down the silos.

One practice I implemented in my very first business analyst team was doing use case reviews. We met every other week to review one of our peers use cases. We were a small team and we were working on independent projects, so this was more for building best practices and learning from each other and improving our skills than it was for looking at project impacts. Although often we would realize that what one of us was doing that was seemingly unrelated to the other did have a cross impact and we would be able to bring that up to the project management team to handle.

It would work the same way for a team working on a larger project together. You just probably need to allocate a little bit more time. It might be a weekly meeting. It might even be more frequently than that to ensure that everyone is reviewing or having some knowledge flow about what the others are working on so that they can determine the impacts and bring kind of a bigger picture view to each of their individual requirements work.

Lead Business Analyst Success Tip #4 – Maintain a Strategic Level View

Tip number four is for you to maintain that strategic level. I think one of the hardest aspects of moving into any sort of leadership role as a business analyst I still struggle with 14 years into running Bridging the Gap and being CEO of this company, one of the hardest aspects is maintaining the strategic level view. It’s so natural for us to want to be in all the details, and that’s likely what made you successful as a business analyst in the first place. But if you do so, if you’re in all the details of all the requirements, you risk alienating your team in micromanaging their work and quite frankly, burning yourself out. You can’t possibly be in every meeting and you probably are not going to be able to review every document in detail.

You need to stay focused on activities like maintaining the business analysis plan. You need to be supporting your team in navigating roadblocks and challenges. You need to be ensuring everyone is staying focused on delivering those requirements that support the business objectives. You need to be providing leadership within the overall project team, particularly to ensure your business analysts are involved in necessary discussions and informed of any project impacts. You need to be looking at change requests and navigating the impacts between the different aspects of the solution and maintaining communication with your project sponsor or other organizational leaders about the project and opportunity.

You have all the strategic level work to do, and so your work is to focus your energy there and get just enough in the details to make sure that you can do your strategic work effectively. It’s a really tough balance. But by shifting your energy towards the strategic level work and seeing that as important, it will help you let go of the details that your team can handle. Tip number five is really going to help you with this.

Lead Business Analyst Success Tip #5 – Coach Your Business Analysts

Tip number five is to coach your business analyst. This could be, and for me, it’s always been one of the most enjoyable aspects of the job especially if you’re working with a team of more junior level business analysts, they’re going to need your support in finessing their documentation, navigating the tricky stakeholder issues that for you have become just part of the job will be earth shattering for them, and they’ll need your help in figuring out how to navigate these things and learning how to grow and expand in their career. They might need assistance working through the plan you set out for them.

If you happen to be working with more mid-level or even other senior level business analysts, your more role might be more of a mentor for them professionally and an ability to provide some support for their ongoing career advancement. Either way, the most important thing I found when coaching is to meet each person where they are individually. What are their strengths and capabilities? How can I support them in building on those capabilities and adding more value to the organization?

How can I help them appreciate the value that they contribute so that they can see a bigger set of possibilities for themselves? This is when you start to move into a true champion for business analyst and you start leaving a long lasting legacy of impact, not just through whatever project you happen to be working on, but also on the people who thrive under your leadership and take their skills and capabilities with them as they grow their careers.

I have to say, as somebody who trains business analysts and who has led business analyst teams, there is nothing more gratifying than seeing somebody that you have helped somewhere along their journey, thrive and succeed and go beyond where they were when you first interacted with them and do amazing things in their business analyst career. It’s really fun.

Find More Success as a Business Analyst Lead

If you are a lead business analyst and you are looking to support your team’s growth, or if you’re someone who’s aspiring to become a lead BA, at Bridging the Gap, we offer a wide range of resources that can help you. In fact, we find many BA leads share our resources with their team, sharing our YouTube channel, sharing our blog, sharing our LinkedIn page, all of the resources that we offer, and that will help them get up to speed on what’s expected and navigate this complex career path.

One of the most popular resources is our quick start to success workshop. This workshop provides both career advice and guidance on being effective on a project, making it a valuable resource for both beginners and experienced professionals. By exploring this workshop with a beginner’s mind, you’re also going to find a lot of value. You can put yourself in the shoes of the business analyst on your team and gain a better understanding of their needs and challenges.

It’s a completely free workshop that you can both join and share with your business analysts.

>> Sign up for the FREE workshop <<

Also, I want you to know that a lead business analyst role is just one of the many opportunities for growth as you become more senior as a business analyst.

Be sure to check out our video below on six different potential areas of responsibility for a senior business analyst role if you’re interested in growing in this career.

Wondering how a Functional Analyst role can fit into your career path?

There is a lot of confusion in the industry about what business analysts are and what they actually do.

The reality is that the skill set of a business analyst is so incredibly valuable that the responsibilities make its way into a wide variety of different roles.

In this video, we’ll explore the ins and outs of a Functional Analyst, including the key skills needed for success and how it differs from a traditional Business Analyst role.

If you’re looking to start a career as a business analyst, I have a completely free workshop called Quick Start to Success as a Business Analyst. You’ll discover:

• What a business analyst does
• How to be effective in your role
• The key skills you need to be more successful in today’s competitive job environment

>> Sign up for the FREE workshop <<

Are you looking to take your career as a business analyst to the next level? Are you wondering how a functional analyst role can fit into your career path? In this video, we’re going to explore the ins and outs of a functional analyst, including the key skills needed for success and how it differs from a so-called traditional business analyst role. Whether you’re just starting out or looking to make a career change, this video is a must watch.

Hi, I’m Laura Brandenburg from Bridging The Gap where we help you start, succeed, and excel in your business analyst’s career with weekly videos on business analysis, tips and techniques.

Job Titles Like Functional Analyst Can Be Deceiving

First thing I want to say as we dive into the functional analyst role is job titles like functional analyst can be deceiving. I’m always the first to say that with job titles within the entire business analysis profession are deceiving. They are used inconsistently across organizations and that makes it really difficult when you’re looking for a job and trying to figure out what that job is supposed to be just by kind of scanning through maybe the results that come up.

When determining the qualifications for a particular role, it’s really important to look at the responsibilities and the expectations and how those are listed more than just the title of the role. This being said, very often that functional analyst job title is used to describe a type of business analyst role with some very specific variations. So let’s get into what that looks like.

How the Functional Analyst Job Title is Typically Used

A functional analyst is typically a role that focuses on the functions of the software in a specific business application. It is generally more tactical than other business analysts role. The responsibilities of this role could include responsibilities like specializing in a specific business domain such as insurance, real estate, or healthcare. Again, being very specific in a domain.

Often you will focus more on the functional software requirements as opposed to say, the larger business process. This rule is going to typically focus on what the software needs to do to meet the business need. If you’re not familiar with what functional software requirements are, click below to watch my video on that topic.

In addition to focusing on what the software needs to do, a functional analyst might have light technical or systems design responsibilities. These require more in-depth technical skills than a so-called traditional business analyst role. They could even conclude configuring, updating, or even installing the software system.

In a functional analyst role, you are more likely to seek qualifications requiring data analysis or data analytics skill sets. Those often require capabilities such as advanced Excel skills and even SQL. A functional analyst may have ongoing duties outside of projects where they are using their expertise in that software system to do operational work for the business. This could include reporting, data updates, or even business user or customer support.

How is a Functional Analyst Different From a Business Analyst?

How is a functional analyst different from a business analyst? Industry-wide, there’s a lot of confusion about what business analysts are and what they actually do, and honestly, it’s not a problem that’s going to be solved anytime soon. So I say, let’s just lean into it.

The reality is that the set of skills that a business analyst brings is so incredibly valuable that the responsibilities make its way into a wide variety of roles, including this functional analyst role that we’re talking about today. At Bridging the Gap, we help business analysts who literally bridge the gap between business and technology and stakeholders by offering business analyst training. This means that they help ensure that software solutions actually do what the business needs them to do and solve real business problems.

In addition to the functional software requirements that a functional analyst might focus on, a fuller view or a larger scope of a business analyst role could also include business process analysis to understand the business workflow and the problem to be solved that might not be required of a functional analyst.

They often start by defining the business needs and outcomes and take that project through scope defining the detailed requirements and collaborating with the business and technology teams along the way to ensure a successful implementation of the requirements.

On some projects, you might have a business process analyst and a functional analyst working together to fulfill all of the responsibilities of what we’re calling a business analyst role at Bridging the Gap, successfully in a project. There are just a lot of ways that this can play out.

Now where the question really is, where do you want to go with your career?

Where Do You Want To Go with Your Career?

A functional analyst is a great career opportunity and one that can easily expand into other areas within business analysis. As you broaden your skillset to focus on both the business and the technology, it can also create opportunities within the technical realm if you want to become a software developer or a software designer, or software architect because you’re building a specialty in a deeper understanding of the functions in the software and even the configuration of a software system.

• If you would like to be more on the business side and you want to be more in connection with business users and solving business problems, you might want to take that functional analyst role and start to gravitate towards a more business focused role.
• If you like the technology and even if you don’t want to code anymore, but you have that deep technology background and you want to leverage that technical understanding without having to write code, functional analysts can provide a great career path for you. And if you do want to write code, it can also provide a great career path into roles that require even deeper technology expertise.

Take The Next Step in Your Functional Analyst Career

How do you take the next step in your business analyst or functional analyst career?

Ultimately, you are in charge of your career and you get to decide. There are many, many options and you have many different ways to succeed in this profession.

If you’d like to learn more about starting your career as a business analyst, I do have a completely free workshop called The Quick Start to Success as a Business Analyst. This includes additional resources about what a business analyst does, how to be effective, and the key skills you need to be successful in today’s competitive job market. You can sign up for that workshop completely for free by clicking the link below.

>> Sign up for the FREE workshop <<

Now that you know what a functional analyst role is, another role that’s really closely related to this is called a systems analyst role. If you’d like to learn more about that role, watch the video below next.

Are you unsure if your skills qualify you as a subject matter expert or a business analyst?

If you have proven yourself as a subject matter expert, a career as a business analyst could be a great next step for you and allow you to break into more interesting project work to steward lasting changes in your organization.

In this video, I’m sharing the difference between a business analyst and a subject matter expert and how you can potentially move from one to the other.

If you are interested in learning more about what it looks like to be a business analyst, you can sign up for our completely free workshop, Quick Start to Success, where you will:

• Get specific action steps to advance your career.
• Receive immediate access to the self-paced online workshop.
• Discover how to be more effective on any project.

>> Sign up for our FREE Quick Start to Success Workshop today! <<

Are you exploring job roles and wondering about the difference between being a business analyst and being a subject matter expert? Are you possibly a subject matter expert and wondering if you could actually be a business analyst or vice versa? A career as a business analyst can provide opportunities to somebody who has proven themselves in a subject matter expert role and can help you break into more interesting project work and have the opportunity to steward lasting changes in your organization. So keep watching to learn the differences between these two roles and how you can potentially move from one to the other.

Hi, I’m Laura Brandenburg with Bridging the Gap, where we help you start, succeed, and excel in your business analyst career with weekly videos on business analysis tips and techniques.

The Subject Matter Expert Role

The subject matter expert. Those are individuals who possess in depth knowledge and expertise in a specific industry or field. They are often considered the go-to person for information and advice on a particular topic. On a typical project, the business analyst will engage with many subject matter experts to understand the current business process and how the software solution that exists today is supporting that business process.

The SME, or subject matter expert, may also provide input into the challenges that they’re facing with their current processes and the solutions that are in place, and they may advocate for specific changes that they want to have put in place to support them in their department. The SME may also take on a leadership role with their department throughout the project training other department members on the new processes and technology and being the facilitator of change within their team.

Now what is the business analyst role? And we’ll talk about the business analyst role and then we’ll talk about the differences between the two and how to move back and forth.

The Business Analyst Role

Business analysts, on the other hand, are professionals who help organizations identify and solve problems. They analyze data and use various tools and methodologies to identify areas for improvement and to make recommendations for changes. At Bridging the Gap, we help business analysts who literally “bridge the gap” between business and technology stakeholders. This means they help ensure that the software solutions actually do what the business needs them to do and solve real business problems.

A business analyst doing this kind of work would use a technique like business process analysis to understand that business workflow and the problem to be solved. They would use use cases, wireframes, and user stories to analyze and define the software or functional requirements.

They would also use a variety of data modeling techniques to define how information is stored and flows through all the various software systems. This type of business analyst starts out a project by defining the needs or outcomes, takes it through to scope, defining the detailed requirements and collaborating with the business and technology teams to ensure a successful implementation of the requirements.

How Business Analysts and Subject Matter Experts Work Together

Now, how do these two roles work together? As a business analyst, you are going to work really closely with your subject matter experts across multiple departments to discover, analyze, and validate those requirements.

• The business analyst is typically responsible for leading the entire business analysis process for preparing requirements documentation, and managing change.
• The subject matter expert would review those requirements and may have a role in validating and approving the requirements documentation. They also provide a lot of input into the early stages of when the business analyst is gathering information about how processes work and how the systems work today.

It’s not uncommon, as a business analyst, to include a subject matter expert or many of them in your weekly meetings so that they are current on where the project is, and then maybe meet with them through one-on-one sessions to validate documentation and answer any questions that they might have about what’s coming.

SMEs provide incredible value to business analysts. I can’t emphasize this enough. Because they can provide in-depth information about how a department or a process works and can often bring up subtle nuances that a business analyst might not be aware of if they were not also a subject matter expert in that particular domain.

Many Business Analysts Get Their Start as Subject Matter Experts

As you grow in your business analyst career, you might start by being that expert in that domain. But as you grow, it’s important to grow into new areas. You need to be able to work with SMEs to kind of gain on the project expertise, so to speak. This is why many business analysts get their start as subject matter experts. Because you have a detailed understanding of the current business processes and systems, and it’s common as an SME to move into a more formal business analyst role.

In fact, many business analysts report falling in to a business analyst role after being assigned as a subject matter expert to a major IT project. Usually these are those big system migration projects, like moving from one accounting system or one customer management system to another, and you have a big role that takes up a significant amount of time and kind of co-ops your responsibilities for a while. In these cases, the role of SME and business analysts can get a little bit blurred, especially if you’re in an organization that does not have a formal business analyst practice, which is still common today.

Over time, the SME may become like the go-to person for the tech team when they have questions about the process or requirements. They might take on leadership and change management roles within their department and kind of be more of a liaison to the tech team than the doer within their department that got them into that role in the first place.

Also many business analyst job roles require specialized expertise in a business process and solution area. And that further creates confusion between these two roles. But there are some really key differences between a business analyst and a subject matter expert.

Key Differences Between a Business Analyst and Subject Matter Expert

While SMEs tend to focus on their field of expertise, their domain, the work that they do within the company, or have historically done within the company, a business analyst will focus on the organization or project as a whole and the role of the business analyst, as we’ve discussed. SMEs are often contributors to projects and might be brought in for their input, for reviews, for problem solving on a temporary basis during a project. The business analysts own that requirements process for the entire project, which may impact multiple different departments and have multiple different subject matter experts, and then typically fulfill that business analyst’s role. That is their full-time role or their contribution to the company.

Another difference is that once the project is done, the SME would typically go back to their “regular job” using the systems or executing the processes that have been defined. The business analyst will go on to work on a different project or initiative as a business analyst.

Moving From SME to Business Analyst

If you are an SME, or subject matter expert, and you’re looking to move into the business analyst role, here are a few quick tips that can help you get started. And these come right from my book, How to Start a Business Analyst Career. There’s a whole section in here on how to move from a business focused role into more of a business analyst role. And for those of you who might be techies, there’s also a whole section on how to move from a more technical focused role to a business analyst role because we see people come from both of those backgrounds.

So just a few of the things that I share in the book are to share your career intentions with the business analyst you work with, and offer to support them in business analysis activities, like capturing meeting notes, documenting requirements, or updating their requirements or engaging with your department. Just, “Anything I can do to help, just let me know. I’d be happy to support you.”

Also we’ll be looking at starting to analyze your department’s processes, even if this is not needed for an active project. Look for opportunities to analyze, document, and then improve the business processes. You could often do business process work outside of a project with no software improvement aspect.

Often significant improvements do come through software, but you could take ownership of what can we do just within our department in terms of how we work with other departments and how we are efficient with the tools that we have. So you don’t need to “get IT involved” to start doing business analysis.

A third opportunity is to lead a project in your department from beginning to end. And one other thing I want to add here is to look for opportunities to be outside your department because your ability to be successful as a business analyst is going to come from your subject matter expertise at first, but also your ability to understand the bigger picture of what’s happening in your organization and be able to represent other departments that you aren’t necessarily an expert in and at least understanding how your work within your department affects other departments and how that flow works is a first step. But really gaining any exposure outside your area of the company will be a great step just to having that more global perspective that will make you a great business analyst.

Start YOUR Path to Success

If business analysis is a career that you want to pursue, the absolute best next thing to do is to join my free Quick Start to Success Workshop. In that workshop, you will learn more about the business analyst career path as well as details about the business analysis process framework that will give you the structure that you need to manage your day and your projects appropriately.

>> Click here to join the Quick Start to Success workshop <<

In this video, you’ll discover:

• The difference between business architecture and business analysis
• The foundational skill sets needed as a business architect
• How to become a business architect

If you’re interested in learning more about business architecture, be sure to check out Whynde Kuehn’s new book Strategy to Reality: Making the Impossible Possible for Business Architects, Change Makers and Strategy Execution Leaders by visiting https://strategyintoreality.com/.

LAURA BRANDENBURG: Hello, I’m Laura Brandenburg from Bridging The Gap here today with Whynde Kuehn to talk about all things business architecture. Whynde, why don’t you just start to tell us a little bit about what business architecture is and maybe why it’s important to us and why you are so passionate about this topic.

Business Architecture Defined

WHYNDE KUEHN: Absolutely. Very simply said, business architecture is a macro level view of an organization, of everything the organization does from end to end, very high level of elevation. And specifically, business architecture includes or can include 10 domains. It represents the capabilities of an organization, what it does. It represents the value streams. Very high level flows of the organization delivers value. It includes the vocabulary. What’s a customer, what’s a partner, what’s an asset, those words that we use. And then other focal points, including organization, stakeholders, products, policies, strategies, metrics and initiatives.

And so that’s the what, but why I’m so passionate is the why. It’s the how we can use business architecture, and it’s kind of a Swiss army knife, which can make it confusing to people. But I like to say there are three sort of value propositions of business architecture. The first is that business architecture plays a role. You appreciate the Bridging the Gap to bridge the gap between strategy and execution. It is a discipline that can help inform strategic decisions. For example, understanding impacts, it can help us to translate strategies. For example, to catalog the changes that need to be made by value streams and capabilities across business units and products and geographies. Then it helps to shape initiatives and the scope at a very high level. That’s the first thing is translating strategy.

The second is helping organizations to design or redesign. Again, macro level blueprint. For example, to streamline our systems, or to build reusable solutions around what we do. And then the third is just making better business decisions and bringing this sort of holistic perspective to, you name it, risks or cost or compliance, sustainability, investments, and many more things.

LAURA BRANDENBURG: It sounds like an organization that has their business architecture in place is going to be a really well run competitive, forward thinking, innovative, evolving organization. Is that really what you’ve seen in practice?

WHYNDE KUEHN: I’m just smiling because you couldn’t have said it better. Competitive, or if they’re a government or non-profit, they’re going to better deliver on the mission. They’re competitive because they can get ideas into action, and more effective because of the way they design and can streamline. So you could not have said it better, exactly.

LAURA BRANDENBURG: Well, thank you so much for that. Our audience here at Bridging the Gap is mostly business analysts. Our core teachings are around process analysis, like in process analysis, use cases, data modeling, which goes to that glossary of terms that you were talking about, and how to manage a whole project or really an initiative. It would be part of that translating strategy to reality, but maybe not so much the strategy piece. I know you work with a lot of people who were business analysts and have expanded into business architecture roles. Could you talk about the difference between those two roles and the difference in what they need to bring from a skill set perspective?

The Difference Between Business Architecture and Business Analysis

WHYNDE KUEHN: Oh, you bet. Because these are mutually beneficial, like tight, tight, tight partnership roles. We are better together.

Just some ways to think about. So business architecture is more of like the macro scale. If we think the scope we look at, it’s often going to be either full enterprise wide or maybe we’re looking at a capability of the organization from an enterprise perspective, so the scope is broader.

Second, we’re going to get involved, as you’re saying, earlier upstream as we’re translating ideas, we’re going to shape and describe the change at a very macro level. In other words, we want to do something to the payment management capability. And here’s a really high level people process, technology changes, but we’re not going to go into the detail.

This also means that we have different deliverables, different scenarios that we’re involved in as well. That’s a little bit of the how we might describe the disciplines, but we would actually, literally, tie things together in that you could tie a requirement, I’m speaking generally; however you define those. You could tie a requirement back to the capability that it is improving. Now we have traceability back to the strategies and the objectives and the other things going on in the enterprise. And as you mentioned, business architecture can bring the common vocabulary for everyone to use as well.

LAURA BRANDENBURG: Across the organization.

WHYNDE KUEHN: Exactly.

LAURA BRANDENBURG: And I feel like one of the challenges that BAs get stuck in, we might create a glossary for our project and then it gets lost. So much of what we create that could be holistic kind of gets lost in the documentation for our project. How does a business architect transcend that, so to speak.

WHYNDE KUEHN: That is an extremely important question because this is baked into the approach. Business architecture, in its spirit and intent, is meant to be an enterprise discipline. For us to transcend that, we actually bring together a cross-functional group of business people, business sponsorship, business people in a room to build the business architecture to define the terms at a high level, the capabilities, the value streams, and then they continue to own and steward that going forward. It has to be business owned and driven to transcend and to be able to do these cool things that we’re talking about.

LAURA BRANDENBURG: Yeah, and I can imagine your projects just run so much more effectively once you have that organizational understanding in place.

WHYNDE KUEHN: Exactly. It’s like put in the time up front to speed up later. Exactly.

Business Architecture: Foundational Skill Sets

LAURA BRANDENBURG: So what are some of the key skills and mindsets that are really essential to be successful in business architecture?

WHYNDE KUEHN: Yeah, I like to think of six of them. The first is just being very business minded. I know that sounds obvious and that’s pretty natural, but, it’s really thinking business first. Even if we’re doing digital transformation or building solutions, it’s really saying, “What does the business need?” This is really about the business.

The second is a focus on value and a focus on value in the bigger picture. Not just what’s the value of maybe delivering something to the internal person, but how does this fit in the bigger picture with our customers and stakeholders. So, value.

The third is related to big picture thinking and just being an enterprise advocate because that’s how I think about it. There are lots of people that maybe work in silos, but someone’s got to be an advocate for the enterprise and what’s best for the bigger picture.

The fourth skill or sort of mindset that I like to think about is around information abstraction in synthesis. The ability to see patterns, the ability to see similarities. “Hey, you’re doing this over here, but so are you. I know it seems different, but is there a way to build a solution or collaborate?”

Then I would also say bridge builders and dot connectors. That is just naturally part of what we do.

And then lastly would be just visualizers and storytellers, helping people to take complex ideas and boil them down into simple concepts and pictures and influence people towards change.

LAURA BRANDENBURG: The picture that you’ve just given, sometimes I think I had this vision of business architecture being in this kind of almost up in this marble tower of we’re going to go figure all the things out. But that’s really relationship driven. It does not happen outside of everything else. It’s within. There are a lot of relationships and cultivating relationships within that.

WHYNDE KUEHN: I love that because the business architecture teams around the world that are successful again and again, they do two things. They focus on delivering value with business architecture and they focus on building partnerships.

Business architecture, itself, is a bit of a scaffolding. And it does have a unique role, as I was saying, to inform and translate strategy, but it’s a partner; it’s another perspective that we can add to so many disciplines and decisions. We’ve got to be out there building relationships. We can’t be in the corner. It’s not about the models, it’s about the value we deliver.

LAURA BRANDENBURG: Yeah. And I know from one of our conversations, historically, one of the things we share as a mindset is really a very practical orientation, and that’s definitely coming out of what you’re sharing here. And it can feel, the scaffolding can feel a bit abstract around business architecture. Do you have an example of how somebody has really used it to deliver value for the business? Or how do you coach people to really ensure it’s really best? Really practical and valuable for the organization.

WHYNDE KUEHN: It’s all in the approach of leading with value, not leading with model. Honestly, I say there’s a secret of business architecture, and the secret is it’s not about business architecture. I know that sounds silly coming from me, but it’s about what we do with it. The way to make it work is we literally lead with “why.”

When we start business architecture in an organization, and by the way, this is if it’s organic, bottoms up or top down from the CEO, we pick one thing that we’re going to do. Maybe we say we’re going to help translate strategy, or maybe we’re going to help with investment decision making. Maybe we’re going to help with application portfolio management.

We’re going to decide how are we going to deliver value first. Then we build the baseline, which is capabilities and value streams and information concepts, minimally, the least we need to do. And then we’re going to use it. In my example, let’s say we’re using it for application portfolio management. We might tie some capabilities to applications. We start creating views. We might start to see some heat maps of where we have system redundancy or some changes we want to make, and then we’re going to help people sort of see the story, see the value, and then we’re going to come around and do it again. And we’re going to find another scenario. And if we don’t have the business architecture knowledge base where it needs to be, we’re going to build out a little bit more.

We’re going to use it. That’s absolutely the key. It’s essentially building the plane while you’re flying it. But that’s how we make it real. That’s also how we help organizations find their way. Because how organizations use business architecture is a little bit different. It’s also about the mindset and helping people to think about things at the enterprise perspective and crossing business units at macro level. It’s often some organizational change there, so it’s bit by bit one step at a time.

LAURA BRANDENBURG: Yeah. I love that because I feel like when we’re embedding business analysis in the organization, it often needs to be the same way. Like you start with that first project that just maybe is a little different than what the organization has done before and you need to use the tools effectively to help that project versus bringing the whole kit and caboodle, so to speak, and demanding that.

How to Become a Business Architect

LAURA BRANDENBURG: What I really like about business architecture, I feel like it’s a career path for somebody to rise up who is a great business analyst, who doesn’t want to be a project manager, maybe doesn’t want to be a product manager, doesn’t necessarily want to go into management itself, but really wants to analyze at a higher level. And I could imagine people in our community are listening to this and are like, “This is the role that I’ve been thinking about for a while.” What would you suggest to them as a path if they’re in a business analyst role and this is where they want to go next in their career?

WHYNDE KUEHN: Absolutely. Well, this is not self-serving, but I wrote a book called Strategy to Reality, and I wrote it with all my heart for current and aspiring business architecture practitioners. It breaks down all of business architecture and helps us kind of understand the what and why. That is actually a good place to start because there’s a lot of information out there and it helps you sort it out, so that’s a place to start.

Then there’s an organization called the Business Architecture Guild. That is the industry not-for-profit organization around business architecture. There’s a body of knowledge called the Biz Box. There’s also a certification called the CBA, or the Certified Business Architect.

A next nice step is to join the Guild. Start learning about the resources. If you want to take it to the next level, get your CBA and the business architecture discipline is such that this juncture, having a CBA and getting into this field is very, very doable. You’ll be still very distinguished. The demand is growing and getting the CBA is just the first level of understanding the body of knowledge. But that prepares you enough, then, to start looking for a job or engaging in the community. I even see people that really want to be in this field, they’ll just go volunteer. They’ll find a nonprofit or a small business and they start using business architecture for them to start sort of getting their footing and trying it, and then the opportunities really come from there.

LAURA BRANDENBURG: We see the same thing with business analysts. I have to say go and start doing business analysis somewhere, whether it’s in a non-profit, on a project, a new company, just like taking that first step.

Is there a way that somebody who is a senior business analyst today could apply a model or a piece in their project just to experiment with a tool and kind of build some of that experience in the work that they’re already doing?

WHYNDE KUEHN: That is an excellent question. Absolutely. That’s so good I should have mentioned that. For sure. Start bringing those approaches to what you do. The key when you do that is you still have to think enterprise. Think global, think enterprise, but bring it local, bring it to your project. For example, on an effort, maybe you’re writing some requirements and you’re tying them back to the overall capabilities so that you can sort of create an overall view of change and how that’s touching stakeholders that are involved in those capabilities. But just make sure the capabilities are from the enterprise perspective, not getting too detailed. That is a brilliant idea and that is also how business analysts can be change agents for business architecture in an organization.

LAURA BRANDENBURG: I love that kind of on the job career growth is one of our, definitely our pieces of advice.

You talk a little bit about this, but I do want to give you a chance. This is a relatively new book. I know that it’ll be out a month or two by the time we launch this video, but Strategy to Reality. Congratulations. I love this cover and the colors. All of it is just beautiful.

Do you want to tell us a little bit more about the book? You told us who it is for, but what somebody might really take away from reading it?

WHYNDE KUEHN: You bet. So the book casts a vision around strategy, execution as an enterprise muscle with end to end teams working together, accountability, business ownership, a function that is as important as other functions. We don’t always think about it that way.

And then it’s focus. The book is really unpacking the “What is business architecture?” :Why does it matter?” There’s an entire chapter on just different usage scenarios for it.

And then how does an organization, kind of a playbook, how does an organization go about establishing business architecture in their organization successfully and give it the ability to scale. And then also how do you relate business architecture to disciplines, like business analysis or customer experience design or strategies?

I wrote the book. It’s oriented a little bit nontraditionally. It’s oriented around questions, but those are the questions that I hear and I wanted people to have sort of a bite size way to consume this book. Whether it was cover to cover or like a reference guide they can go back to and consult from. I wrote it for them and because of them. Just really excited to help people out on their journey.

LAURA BRANDENBURG: Yeah. And I could just tell from your energy around the book this is coming from a total place of service and a give back to the community and you are just so excited to have it out there.

Learn More: With Strategy to Reality

LAURA BRANDENBURG: Where do they go to find a copy of the book if they would like one?

WHYNDE KUEHN: Yeah. You can go to StrategyIntoReality.com. If you go to the book, there’s a place where you can see book orders, you can find it in your region. However, just simply said, you can go on Barnes and Noble or Amazon or Book Depository, pretty much whatever book seller is in your region, you should be able to find the book there.

LAURA BRANDENBURG: That’s awesome. And we’ll leave a link to that below in the video notes and in the blog post as well.

Well thank you. Whynde, is there anything else that you would like to share before we close off?

WHYNDE KUEHN: I just want to thank you for your time today. Thank you so much. I really appreciate our just alignment on these ideas, the practical, the delivering value, the service. Just all the best to you and thank you for all you do for the discipline and just wishing everyone the best of luck.

LAURA BRANDENBURG: All right. Thank you so much.

More About Whynde Kuehn

Whynde Kuehn is the Founder of S2E Transformation, helping clients bridge the gap between strategy and execution, and achieve their greatest visions for business and digital transformation in a practical, business-focused way. She is recognized globally as a highly sought-after pioneer and thought leader in business architecture, with a distinguished track record of creating successful strategic business architecture teams worldwide. Whynde has worked with an extensive array of organizations to build their capacity for end-to-end strategy execution, including Fortune 500 and global enterprises, governmental and non-profit organizations, social enterprises, startups, and cross-sector initiatives. Whynde is the creator of Biz Arch Mastery, a dedicated online platform and community that helps professionals master the art and science of business architecture. She is also a co-founder of the Business Architecture Guild, a Fellow with the Institute for Digital Transformation, and a member of the Fast Company Executive Board. Whynde is author of the book Strategy to Reality.

What’s the difference between the two roles? And how do you transition from one role to another?

That’s the question we address in today’s video.

For those who like to read instead of watch, here’s the full text of the video:

Hey there, this is Laura Brandenburg from Bridging the Gap, and we help business analysts get started in their careers.

We’ve been receiving a lot of questions about the difference between product manager roles and business analyst roles, how they work together, and how you can move between these different roles as you plan out your career, so I decided to chat about that today.

Before we jump into how they work together, let’s talk about what each role is.

Product Manager Role

A product manager, you could think of as the CEO of the product. They just own the product. The own the strategy. They own the roadmap. They own the future definition of what is that product going to do. Sometimes they’re also in charge of the marketing, coordinating with the sales team, maybe forecasting, and have overall profit and loss (or P&L), responsibilities for their product, or for an entire product line with an organization.

Business Analyst Role

The definition of business analysis from the International Institute of Business Analysis (IIBA^®), is that it’s

“the practice of enabling change in the organization by defining needs and recommending solutions.”

Often, when that change involves software, then the business analyst is collaborating and facilitating a discussion and requirements between business and the technology team. So, it’s the business team that is desiring the software or business change, and the software team that is enabling that by delivering a software solution.

And they’re in the middle of collaborating and making sure everybody is on the same page about the requirements and what that updated business process will be. That could include business process definition, a functional requirements definition, and data requirements definition.

How Product Managers and Business Analysts Work Together

When that change or that software involves a new product, then, often, that business owner is actually the product manager. And, so, the business analyst is coordinating and collaborating with the product manager and making sure the requirements are understood and defined so that the software team can build against those requirements.

I actually got my start as a business analyst in the product space, or the product world, so, I want to share a couple of examples from my career.

Product Management + Business Analysis on an eBook Platform

My very first project, or company that I worked for, they were an online publishing company. The first product I got to work on was an eBook platform. I was the business analyst. We were mostly focused on the software changes – the software features and functions, the functional requirements for that eBook platform. I worked with a product manager who owned that platform.

Just like we talked about, she had the profit and loss responsibilities. It was coordinating with the sales team for the rollout, coordinating with marketing for the marketing plan, and she owned what that software needed to do in order for it to achieve its financial objectives for the company.

An interesting part of my role though that developed  ̶  she was in charge of the customer-facing features, but there were a lot of features that we had to put in place to successfully serve our customers and fulfill our customers.

I ended up, as the business analyst, taking more of a leadership role in the internal part of the product, working with somebody from customer service and fulfillment to define what their needs would be and make sure that those requirements were covered as well, so that we could serve not only our customers, and not have just those customer-facing features, but make sure our business processes are and our internal products were in place to make sure that the product could be a success.

(Want to learn more about business processes? Go here to download my free business process template.)

Quite a few of my experiences throughout my early days as a business analyst were very similar. I was working on a lot of online content, a lot of online publishing companies, and we were doing similar kinds of products in that my role was very similar in all of those.

Product Management + Business Analysis to Build a Website for Customer-Facing Processes

Then I started working as a contractor for another organization that was taking their internally focused business process and getting that online. It was, essentially, another way of creating a product.

They were enabling, through a website, to have their customers interact with them through a website where it was, previously, they were faxing in information and calling. I don’t even think they used a lot of email  ̶  a lot of phone and a lot of fax, some email. We were putting that business process onto a website and enabling the end user, the customer, to collaborate with the company through the website.

In a way, that was another product. I wasn’t really a product manager in that one, interestingly. There was a project manager who was a business subject matter expert. They filled the role, essentially, of product manager, as well.

The Product Manager Role Has More Decision-Making Power

The biggest difference, if you look at some of these examples, is that the product manager has more decision-making power.

• They’re deciding what the software should do.
• They’re often collaborating up with executive teams to make sure that the product is aligned with the bigger picture organizational objectives.
• They might have some true financial responsibilities for the company as well.

The business analyst is more of the facilitator role discovering the requirements from the product manager who might be collaborating with end users, hopefully, figuring out what the customer wants, and bringing that information into the business analyst.

Sometimes the business analyst and product manager will do that together. As a business analyst on a product, I would get to sit into some of those end-user sessions, or the discovery sessions that the product manager was doing with actual representative customers as well. I was hearing firsthand what those needs were from the customers.

My role was taking that information, making sure that I understood what the product owners’ priorities were based on that information, and then defining, and detailing out the requirements and collaborating with technology to make sure that those requirements could get implemented.

Product Management and Business Analysis Career Paths

Because of this, many business analysts see product management as a logical step forward in their careers. It does. It involves more authority, more decision-making power, probably advanced salaries as well. You could look at it as a promotion. But if you are a product manager, you’re probably going to be working with business analysts. It’s worthwhile to know a little bit about business analysis as well. Here’s a list of key business analysis skills to get you started.

If your ultimate goal is to be a product manager, I think there can be, unless you have a lot of prior professional experience, it can be a pretty rough role to just jump right into right away. You could be looking at business analysis as an interim career path on your way to product management.

Because business analysis is going to be a great way to build a lot of those communication skills, to understand what a product is, to work with a project team, and to start building those leadership skills, as well, that you’re going to need at even more advanced levels as a product manager.

Again, I’m Laura Brandenburg at Bridging the Gap. At Bridging the Gap, we help business analysts start their careers. We’ve got lots of great resources for you if you do want to pursue a career in business analysis. Be sure to check out our website.

Until next time, great to be here, and I’ll chat soon. Thank you.

Learn More About Business Analysis

In How to Start a Business Analyst Career, you’ll learn how to assess and expand your business analysis skills and experience.

This book will help you find your best path forward into a business analyst career. More than that, you will know exactly what to do next to expand your business analysis opportunities.

Click here to learn more about How to Start a Business Analyst Career

There is a Lack of Awareness of How to Do Business Analysis

Let me just say that I know what it is like to feel that you constantly have to be paving a path for how to do business analysis, and guiding your stakeholders through the business analysis steps.

I also get the pressure you feel to just get “things” done without the proper time and analysis. I’ve succumbed to it many times in my career – and always to my ultimate regret. 

It’s incredibly difficult to always be the one pushing back, and it can be wicked hard to keep asking questions when it feels like everyone else has things figured out.  

(Spoiler alert: They don’t.) 

But you and I – we also know, deep in our souls, that we’re doing our projects, our teams, and our companies a disservice if we don’t do the right analysis and keep asking questions. 

When self-doubt creeps in, you need a structure to fall back on. A business analysis process framework to guide you forward and re-affirm that you are on the right track. 

And that’s what the 8-step business analysis process framework that we teach at Bridging the Gap is all about. 

By the way,  I cover these 8 steps in more detail in our free Quick Start to Success Workshop.

Now let’s look at each of the 8 business analysis steps in more detail.

Business Analysis Process Framework Step 1 – Get Oriented

Often as business analysts, we are expected to dive into a project and start contributing as quickly as possible to make a positive impact. Sometimes the project is already underway. Other times there are vague notions about what the project is or why it exists. We face a lot of ambiguity as business analysts and it’s our job to clarify the scope, requirements, and business objectives as quickly as possible.

But that doesn’t mean that it makes sense to get ourselves knee-deep into the detailed requirements right away. Doing so very likely means a quick start in the wrong direction.

Taking some time, whether that’s a few hours, few days, or at the very most a few weeks, to get oriented will ensure you are not only moving quickly but also able to be an effective and confident contributor on the project.

Your key responsibilities in this step include:

• Clarifying your role as the business analyst so that you are sure to create deliverables that meet stakeholder needs. (To better understand the BA role, be sure to check out our free workshop – Quick Start to Success as a Business Analyst.)
• Determining the primary stakeholders to engage in defining the project’s business objectives and scope, as well as any subject matter experts, to be consulted early in the project.
• Understanding the project history so that you don’t inadvertently repeat work that’s already been done or rehash previously made decisions.
• Understanding the existing systems and business processes so you have a reasonably clear picture of the current state business process that needs to change.

This is where you learn how to learn what you don’t know you don’t know, so to speak. This step gets you the information you need to be successful and effective in the context of this particular project.

Business Analysis Process Framework Step 2 – Discover the Primary Business Objectives

It’s very common for business analysts and project managers to jump right in to defining the scope of the project. However, this can lead to unnecessary headaches. Uncovering and getting agreement on the business needs early in a project and before scope is defined is the quickest path forward to a successful project.

Your key responsibilities in this step include:

• Discovering expectations from your primary stakeholders – essentially discovering the “why” behind the project. (Our BA Essentials Master Class covers 7 different business analysis techniques that can be used as part of this discovery.)
• Reconciling conflicting expectations so that the business community begins the project with a shared understanding of the business objectives and are not unique to one person’s perspective.
• Ensuring the business objectives are clear and actionable to provide the project team with momentum and context while defining scope and, later on, the detailed requirements.

Discovering the primary business objectives sets the stage for defining scope, ensuring that you don’t end up with a solution that solves the wrong problem or, even worse, with a solution that no one can even determine is successful or not.

Business Analysis Process Framework Step 3 – Define Scope

A clear and complete statement of scope provides your project team the go-forward concept to realize the business needs. Scope makes the business needs tangible in such a way that multiple project team participants can envision their contribution to the project and the implementation. 

Your key responsibilities in this step include:

• Defining a solution approach to determine the nature and extent of technology and business process changes to be made as part of implementing the solution to the primary business objectives.
• Drafting a scope statement and reviewing it with your key business and technology stakeholders until they are prepared to sign-off or buy-in to the document.
• Confirming the business case to ensure that it still makes sense for your organization to invest in the project.

Scope is not an implementation plan, but it is a touchstone guiding all of the subsequent steps of the business analysis process and tasks by other project participants.

Business Analysis Process Framework Step 4 – Formulate Your Business Analysis Plan

Your business analysis plan will bring clarity to the business analysis process that will be used to successfully define the detailed requirements for this project. Your business analysis plan is going to answer many questions for you and your project team.

Your key responsibilities in this step include:

• Choosing the most appropriate types of business analysis deliverables, given the project scope, project methodology, and other key aspects of the project context.
• Defining the specific list of business analysis deliverables that will completely cover the scope of the project and identifying the stakeholders who will be part of the creation and validation of each deliverable.
• Identifying the timelines for completing the business analysis deliverables.

In the absence of defining a credible and realistic plan, a set of expectations may be defined for you, and often those expectations are unrealistic as they do not fully appreciate everything that goes into defining detailed requirements.

If you are facing unrealistic requirements deadlines – here’s a video with more detail on exactly how to respond.

Business Analysis Process Framework Step 5 – Define the Detailed Requirements

Detailed requirements provide your implementation team with the information they need to implement the solution. They make scope implementable.

Without clear, concise, and actionable detailed requirements, implementation teams often flounder and fail to connect the dots in such a way that delivers on the original business case for the project.  

Your key responsibilities in this step include:

• Eliciting the information necessary to understand what the business community wants from a specific feature or process change.
• Analyzing the information you’ve discovered and using it to create a first draft of one or more business analysis deliverables containing the detailed requirements for the project.
• Reviewing and validating each deliverable with appropriate business and technology stakeholders and asking questions to fill in any gaps.

Effective business analysts consciously sequence your deliverables to be as effective as possible in driving the momentum of the project forward. Paying attention to the project’s critical path, reducing ambiguity and complexity, and generating quick wins are all factors to consider when sequencing your deliverables.

Defining the detailed requirements requires a broader toolset of business analysis techniques and business analysis skills. You can learn more about the skills required to be a business analyst here:

Business Analysis Process Framework Step 6 – Support the Technical Implementation

On a typical project employing a business analyst, a significant part of the solution involves a technical implementation team building, customizing, and/or deploying software. During the technical implementation, there are many worthwhile support tasks for you to engage in that will help drive the success of the project and ensure the business objectives are met.

Your key responsibilities in this step include:

• Reviewing the solution design to ensure it fulfills all of the requirements and looking for opportunities to meet additional business needs without increasing the technical scope of the project.
• Updating and/or repackaging requirements documentation to make it useful for the technology design and implementation process.
• Engaging with quality assurance professionals to ensure they understand the business context for the technical requirements. This responsibility may include reviewing test plans and/or test cases to ensure they represent a clear understanding of the functional requirements.
• Making yourself available to answer questions and help resolve any issues that surface during the technical design, technical implementation, or testing phases of the project.
• Managing requirements changes to ensure that everyone is working from up-to-date documentation and that appropriate stakeholders are involved in all decisions about change.
• When appropriate, leading user acceptance testing efforts completed by the business community to ensure that the software implementation meets the needs of business end users.

All of these efforts help the implementation team fulfill the intended benefits of the project and ensure the investment made realizes a positive return.

Business Analysis Process Framework Step 7 – Help the Business Implement the Solution

Your technology team can deliver a beautiful shiny new solution that theoretically meets the business objectives, but if your business users don’t use it as intended and go back to business-as-usual, your project won’t have delivered on the original objectives. Business analysts are increasingly getting involved in this final phase of the project to support the business.

Your key responsibilities in this step may include:

• Analyzing and developing interim and future state business process documentation that articulates exactly what changes need to be made to the business process.
• Training end users to ensure they understand all process and procedural changes or collaborating with training staff so they can create appropriate training materials and deliver the training.
• Collaborating with business users to update other organizational assets impacted by the business process and technology changes.

This step is all about ensuring all members of the business community are prepared to embrace the changes that have been specified as part of the project.

Business Analysis Process Framework Step 8 – Assess Value Created by the Solution

A lot happens throughout the course of a project. Business outcomes are discussed. Details are worked through. Problems, big and small, are solved. Relationships are built. Change is managed. Technology is implemented. Business users are trained to change the way they work.

In this flurry of activity and a focus on delivery, it’s easy to lose track of the big picture. Why are we making all these changes and what value do they deliver for the organization? And even more importantly, are we still on track? Meaning, is the solution we’re delivering actually delivering the value we originally anticipated?

Nothing creates more positive momentum within an organization than a track record of successful projects. But if we don’t stop and assess the value created by the solution, how do we know if we are actually operating from a track record of success?

Your key responsibilities in this step may include:

• Evaluating the actual progress made against the business objectives for the project to show the extent to which the original objectives have been fulfilled.
• Communicating the results to the project sponsor, and if appropriate, to the project team and all members of the organization.
• Suggesting follow-up projects and initiatives to fully realize the intended business objectives of the project or to solve new problems that are discovered while evaluating the impact of this project.

Business analysis creates tremendous value – and you can learn all about how to position your value in this video!

Knowing the Business Analysis Steps Cultivates Confidence and Credibility

As you leverage this process framework, you’ll gain increased recognition for the value of business analysis, and you’ll start to get pulled into more interesting projects, earlier in the process. 

I see BAs resist having a process because it seems like every project is different but without a process, you really feel like you have to make things up as you go along. While there are nuances of each project that are different, this is a framework you can fall back on to guide you. 

It’s both structured AND flexible. 

I invite you to start applying this process. 

If you want to learn more, join my Quick Start to Success workshop, where I teach you the ins and outs. We also do a deeper dive into each step of the process in our online business analyst training programs.

And, again, this is about you increasing your effectiveness, and finding the confidence to do what’s right for your project and your team, even when there can be pressures to “just get things done.” 

We build our profession one business analyst at a time, and success starts with you. 

Let’s Get Started!

Now that you understand the business analysis process framework, the very first step to get started on just about any project involves analyzing the business process. Here’s a great video to help you explore this essential business analysis skill set in more depth!

For those who like to read instead of watch, here’s the full text of the video:

Hello, my name is Laura Brandenburg from Bridging the Gap. Today, I want to talk to you about the difference between business analyst roles and systems analyst roles because we get a lot of questions about this at Bridging the Gap about whether they’re really the same, or are they different, or how those titles in those job roles are used within the profession. I want to empower you to understand the nuances within the profession and the path that you might, personally, want to take as you form your career plan for your business analysis career.

Job Titles

First, just a note about business analyst job titles. They are used extremely inconsistently within our profession.

What I’m going to share with you in this video is about the roles and the standard definition of those roles. How you see a specific job title in your local market and the job postings on your job board, even within your company, might be different from what I share with you today. You always want to look at the responsibilities below the job titles to make sure that you’re understanding the role that a specific organization or employer is looking for you to fill.

What Does a Business Analyst Do?

First, let’s just talk about what a business analyst does, somebody in a business analyst role. Typically, that role is defined as someone who is enabling change, who is responsible for the requirements, the development of the understanding of the business needs to help create a solution, envision a solution to solve a business problem, or to add more value to the business.

Most typically, a business analyst will analyze the process and also analyze the software that’s going to help us improve or implement that process.

In the software, we look at both functional requirements and data requirements. What does the software do, how does the software store information? It involves the heavy relationship with the business and the technology teams, and it’s what Bridging the Gap between business and IT to make sure all those stakeholders have a common shared understanding of what the software solution will be to address a specific business process or business problem.

What Does a Systems Analyst Do?

What does a systems analyst do? How is that a little bit different? What we typically see is that the systems analyst role focuses more on the technology aspect of the solution. You wouldn’t have a systems analyst on just a business process change.

Where a business analyst might work on something that doesn’t actually involve a software change because they just might fix the business process, systems analysts only come in when there is a software change. They’re probably going to go a couple of layers deeper into the software requirements and not just considering the what of the software of how the software needs to function from an end user perspective, but also looking into how that software is built, how the software is configured, potentially, how multiple systems are going to work together to accomplish a specific objective or meet a specific functional requirement.

They’re going to be peeling away the layers of that system and that technology to make sure that the solution, again, meets the business need, but they’re focused more in on the software aspect of the solution, probably not on the business process side. They might be doing more data modeling, more data design, how does data move between systems, how are the systems connected, working and integrated together to meet a feature.

Sometimes, even doing some level of technical coding or programming; sometimes the job title is used in that way, but they are definitely understanding how the code is written, how the code works, and, potentially, just collaborating with other professionals who are actually doing the coding itself.

That’s the difference between the two roles. That business analyst role being more business focused on the business process side, and the systems analyst role being more technically focused on the technical side.

Many Business Analysts Are Also Systems Analysts

Now, many of us play both roles. In my first job as a business analyst, I also had a lot of those systems analysis responsibilities. I wasn’t spec’ing the integrations between the systems, but we had heavy data modeling requirements that required us to understand how that database was built, how the application cleared the database in order to build some specifications that were more technical specifications. You can have a blend of both.

We started with, “What does the product need to do?” “What are the end features that the product needs to do?” In some organizations, you will see a combination of the roles, and that requires a lot of business and technical acumen.

In other organizations, you will see two roles where you have a business analyst and a systems analyst. What’s important, then, that there are tight connection and collaboration between those two individuals. What tends to happen is the business analyst, then, has their requirements, and the systems analyst create their requirements, and there’s an extra layer of requirements documentation in between those two roles as part of that hand-off.

You need to make sure the translation process of what the business wants and what the end problem that’s being solved is making its way through to the more technical specification documents. There should be a lot of connection and collaboration between those two individuals.

Where Do You Want To Go with Your Career?

Where do you want to go with your career? It’s up to you.

• If you like the business side more and you want to be more in connection with business users and solving business problems, you might want to gravitate more towards the business focused role.
• If you like the technology, even if you don’t want to code anymore, you have a deep technology background, that you want to leverage that technical understanding without having to write the code, systems analysis could provide a great career path for you.

What’s Next?

I always like to say you get to create the career that you want and business analysis, as a profession, just creates tons of opportunities for you.

If you’d like to learn more about starting your career as a business analyst, go ahead and click below. There’s a link to a free training on your Quick Start to Success as a Business Analyst. There are additional resources about what a business analyst does, what process to use to be effective, and what are some of the key skills that you need to be successful in today’s competitive job environment.

I hope that you will join us. I’d love to help you take the next step in your business analyst career.

Again, I’m Laura Brandenburg, from Bridging the Gap. We help make career professionals start business analyst careers.

While senior business analyst roles vary widely from one organization to another, in this post, we’ll talk about the 6 areas in which we see senior business analysts taking on increased responsibility.

Before I forget, I want to be sure you know about my Quick Start to Success as a Business Analyst training (it’s free) that’s designed to help you, the mid-career professional, kick-start your business analysis career. This training provides an introduction to what a business analyst does and a deeper dive into what skills you need to be successful as a business analyst.

>> Click here to get the Quick Start to Success Business Analyst Workshop <<

Now, onto the responsibilities of a Senior Business Analyst.

#1 – Senior Business Analysts Tackle More Complex Projects

Typically a senior business analyst takes on complex, high-profile projects. While you’ll likely find yourself leveraging the same foundational business analysis skills, the responsibilities are greater because of the nature of the projects themselves.

Project complexity can take many forms. Multiple, integrated systems create complexity because new requirements need to be traced through the inter-related systems. Multiple stakeholders across several departments create complexity because of the number of perspectives that need to be blended into the final solution. Team make-up can also create complexity because when you blend resources from multiple organizations to implement a project, communication becomes more complex.

#2 – Senior Business Analysts Own Strategic Analysis Responsibilities

A second, but much debated, aspect of becoming a senior-level business analyst is the incorporation of strategic analysis activities into the role.  Most BA roles include strategic analysis at some level. If you ask “why” or define the business need within the context of a specific project, you are doing strategic analysis.

As a senior-level responsibility, strategic analysis can also take the form of planning and scoping several inter-related initiatives and helping senior-level business stakeholders make informed decisions about which initiatives to tackle and how to tackle them, or project portfolio management.

#3 – Senior Business Analysts Understand the Business Process

While some business analyst roles are purely focused around business changes, many of us are “IT Business Analysts” and deal mostly with software changes. If this is the case in your situation, digging deeper into the business and business process changes can provide an avenue to take on more senior-level tasks.

As you learn about the business processes and how people throughout the organization use the software you support, you’ll build better relationships with business stakeholders. Through these discussions, you can create an opportunity for yourself to become a partner in the business change.

Here’s a video on exactly how to analyze a business process.

#4 – New Business Domains Are No Problem for a Senior Business Analyst

Many business analysts thrive during their initial years in the profession because they are experts in the system or business domain. They know everything there is to know about the possibilities of the project. When this is the case, your position of strength comes from your systems knowledge and your BA competencies are not fully stretched to the max.

Senior-level business analysts can often tackle projects across multiple domains and handle new business domains with the same level of confidence as familiar ones. The ability to work across domains and industries is a critical step in the business analyst career path.

#5 – Senior Business Analysts Lead the BA Effort

A business analyst lead is often a senior business analyst working on projects of large enough scope that they demand the efforts of multiple business analysts. In addition to performing many business analyst activities, a lead will coordinate and oversee the work of other BAs as it relates to a specific project.

Part of leading multiple business analysts also means mentoring the junior and mid-level business analysts in your organization. As a senior-level BA, you will be viewed as an expert on the process and best practices for conducting requirements practices in your organization.

#6 – Senior Business Analysts Can Be Consultants for Internal  Stakeholders

An internal business analyst consultant offers technology or process consulting services to a line of business.  Mark Jenkins as BA Manager at Websense enabled his analysts to take on consultant responsibilities. Each BA has a certain amount of their time dedicated to helping a set of business stakeholders diagnose problems and understand needs. They are responsible for maintaining a deep awareness of how a business operation works and helping the stakeholders explore technology possibilities to more effectively execute on their roles.

Here are some other examples:

• Stephanie Belhomme, a Salesforce Business Analyst Contractor, learned how to provide more strategic value to her clients.
• Andrea Wilson became the go-to business analyst, and operates as an internal business analyst consultant for her government agency.
• Dave Gallant became a better agile business analyst to create better user stories, by leveraging analysis tools.

>> Get Your Quick Start to Success as a Business Analyst

At Bridging the Gap, we help mid-career professionals build the foundational business analyst skills they need to thrive in a variety of business analyst roles.

If business analysis is a career that you want to pursue, the absolute best next thing to do is to join my free Quick Start to Success workshop. You’ll learn how to avoid the most common pitfalls faced by new business analysts and the step-by-step business analysis process to create predictable, consistent project success.

>> Click here to register for the free workshop today <<

Build Your Business Analyst Career Path

If you are thinking about a senior business analyst role, then you are going to want to watch this video on building a business analyst career path next.

What follows is the list of the most critical business analysis skills for new business analysts to bring to the table – organized into the categories of core skills, business analysis skills, soft skills, and skills that can be required for specific types of BA jobs. I also recorded a video for you sharing my thoughts on these key business analyst skills.

Before I forget, I want to be sure you know that in addition to our online business analyst training courses and business analyst certification we also offer an absolutely free workshop – Quick Start to Success as a Business Analyst training (it’s free) that’s designed to help you, the mid-career professional, kick-start your business analysis career. This workshop provides an introduction to what a business analyst does and a deeper dive into what skills you need to be successful as a business analyst. 

>> Click here to get the Quick Start to Success Business Analyst Training <<

Now, onto the skills.

Core Skills that are Essential for Success as a Business Analyst

Typically, if business analysis is a good career choice, you’ll be able to tick off these skills (or be extremely excited to go to work right away on improving these skills just because they sound interesting).

Communication Skills

Business analysts must be good communicators. This means they can facilitate working meetings, ask good questions, listen to the answers (really listen), and absorb what’s being said. In today’s world, communication does not always happen face-to-face. The ability to be a strong communicator in a virtual setting (via conference calls or web meetings) is equally important. They are good at engaging stakeholders and cultivating active participation in the requirements process.

As a new business analyst, you may not have experience in a variety of requirements documentation (that comes with time and a variety of project experiences) but it’s quite possible that your strong general documentation and writing skills will get you started.

Problem-Solving Skills

No project is without problems. In fact, the entire project is a solution to a problem. At the highest level, BAs facilitate a shared understanding of the problem, the possible solutions, and determine the scope of the project. You’ll also find BAs in the midst of facilitating teams to solve technical challenges, especially when they involve negotiation between multiple business or technical stakeholders. Often we start this by analyzing the business process.

Critical Thinking Skills

Business analysts are responsible for evaluating multiple options before helping a team settle on a solution. While discovering the problem to be solved, business analysts must listen to stakeholder needs but also critically consider those needs and ask probing questions until the real need is surfaced and understood. This is what makes critical thinking and evaluation skills important for new business analysts.

While communication, problem-solving, and critical thinking skills are core to being a good BA, they are not all that’s required. Let’s look at the skills specific to the business analysis profession next.

Business Analysis Skills

The following skills are specific to the business analyst role, but even as a new business analyst or someone looking to enter the profession. At Bridging the Gap, we organize the key business analysis skills into The Business Analyst Blueprint®.

(You’ll learn all these skills in The Business Analyst Blueprint® certification program, where you can earn your Applied Certification in Business Analysis.)

Analysis & Communication Techniques are Both Key Sets of Business Analyst Skills

The first thing you’ll notice about The Business Analyst Blueprint is that the techniques are organized into Analysis Techniques and Communication Techniques. The Analysis Techniques are the models and templates we use as business analysts to analyze and think through the requirements. But these requirements do not get created in a vacuum. We must elicit or discover them from our stakeholders. This is why knowing the right Communication Techniques to use as a business analyst are equally important.

The key Communication Techniques for collaborating with stakeholders are:

• Discovery Session – to discover information related to the process or requirements from business stakeholders, so the requirements represent their needs.
• Requirements Review Session – to validate the requirements that have been captured are clear and correct.

We also consider the glossary and user stories to be communication techniques, because their primary purpose is to capture and communicate requirements-related information to various stakeholder groups.

The Key Business Analysis Techniques

The second thing you’ll notice about The Business Analyst Blueprint is that there is not just one set of analysis techniques. One of the challenges that plague way too many projects is “missing requirements.” We miss requirements either when we don’t involve the right stakeholders (i.e., apply the right communication skills) or overlook key areas of requirements because we are only looking at one view.

The Business Analyst Blueprint® – our business analyst certification program – walks you the 3 key levels of analysis that are important to fully understanding a problem and solution domain, when software is being implemented as part of the solution. These are:

• The Business-Level, or how the business work flows operationally, often completed by analyzing the business process (a textual model) and creating business process flow diagrams (a visual model).
• The Software-Level, or how the software system supports the business workflows, often completed through functional requirements models like use cases and wireframes.
• The Information-Level, or how data and information are stored and maintained by an organization, completed by data modeling techniques including an entity relationship diagram (ERD), data dictionary, data map, and system context diagram.

When you use multiple techniques, particularly powerful analytical and visual models, you will find that you naturally see gaps that others gloss over and identify the downstream impact of a change or new solution.

The Business Analysis Process Framework

The third thing you’ll notice about The Blueprint is that there is a foundational framework underlying the techniques. This is the business analysis process, or the end-to-end approach you apply to be successful and effective on a typical business process improvement and software project.

As you leverage this process framework, you’ll gain increased recognition for the value of business analysis, and you’ll start to get pulled into more interesting projects, and be engaged earlier in the process. Here’s a video about the business analysis process framework.

And, to complete a self-assessment against these skills, we have an absolutely free business analyst skills assessment for you.

Download the FREE Business Analyst Skills Assessment

In this FREE assessment, you will:

• Discover the essential skills to succeed as a BA.
• Gain clarity on your strengths and transferable skills.
• Define an action plan to expand your business analyst skill set.

>> Download the Assessment <<

Business Analyst Tools

Now that we covered the techniques and framework, let’s look at the tools you use to implement these techniques. As a new business analyst, the ability to use basic office tools such as Word, Excel, and PowerPoint should be sufficient to get you into the profession. Also, a common visual modeling tool is Microsoft Visio.

Other technical skills include the ability to use more sophisticated modeling tools, Enterprise Architect, requirements management tools, such as DOORS or Caliber, or project and defect management tools (there are really too many to list these days). It’s unlikely you’ll find these to be required skills for a large number of positions and they will be skills you learn on the job.

And as important as it is to have specific business analyst skills, no list of BA skills would be complete without the soft skills required to be successful as a BA. Let’s discuss those next.

Key Soft Skills for Business Analysts

Like the core skills, you might find that you already have many of these skills in your repertoire. However, these skills are listed separately because they may not be intrinsic to the roles you’ve had in the past. You may need to actively seek out improving in these areas as you move into your first business analyst role.

Relationship-Building Skills

First and foremost on the list of soft skills is the ability to forge strong relationships, often called stakeholder relationships. A stakeholder is simply anyone who has something to contribute to your project, and often you’ll work with many stakeholders from both the business and the technical teams.

This skill involves building trust and often means stepping into a leadership role on a project team to bridge gaps.

Self-Managing

While BAs are not project managers, the most successful BAs manage the business analysis effort. This means that the BA is proactive and dependency-aware. It also means they manage themselves to commitments and deadlines, a skill set which can involve influence, delegation, and issue management.

A Thick Skin

BAs receive a barrage of feedback – on their documentation and proposed solutions. To succeed as a business analyst you need to be able to separate feedback on your documents and ideas from feedback on you personally.

A Paradoxical Relationship with Ambiguity

Deep down, business analysts despise ambiguity. Ambiguities in requirements specifications lead to unexpected defects. Ambiguities in conversation lead to unnecessary conflict. At every stage of a project, you’ll find a BA clarifying and working out ambiguities.

Yet, at the beginning of a project, before the problem is fully understood and the solution is decided upon, a BA must be able to embrace the ambiguity and work effectively through ambiguity. Managing ambiguity means we embrace new information and learning as it surfaces, even if it surfaces later than we’d like.

And so we’ve reached the end of the important skills for a new business analyst. But no discussion of this topic would be complete without dealing with the 800-pound gorillas in the profession.

If you are thinking of starting a career in business analysis, you are probably wondering what is a typical day like? What can you expect to be experiencing on a day-to-day basis inside a role like this?

While there is no typical day for a business analyst (that’s one of the things many of us like about the role is there’s a lot of variety in the work), there are some definite patterns and different types of days, and different expectations of what you can experience on a day-to-day basis.

I share a sample workday in my book, How to Start a Business Analyst Career. It is available on Amazon. If you are thinking of starting a business analyst career, this is a great way to learn more about the profession and plan out your entire career transition. But for now, let’s talk about the typical types of activities that business analysts do.

The Typical Day of a Business Analyst – Activities

One of the most common activities that we do is requirements meetings. This would be with both business stakeholders to discover and validate the requirements, and with technical stakeholders to validate that the requirements are feasible and implementable, to discuss issues, and to understand how the technology can support what the business wants and what problem is actually trying to be solved. You will find yourself in a variety of different meetings depending on the phase of the project, often, on a daily basis as a BA.

You will also spend time, independently, working on your requirements documentation and your visual models. Things like scope statements, business process models, functional requirements specifications, data models, glossaries, use cases, wireframes, whatever the methodology is in your specific organization along with the tools that you bring, the best practices that you bring to business analysis.

You’re going to spend time independently at your desk working through, thinking through the requirements compiling the information that you’ve gathered in your various meetings, and putting it into a structured format that then you could review and validate, again, in a meeting with a stakeholder.

The Typical Day of a Business Analyst – Meetings Versus Independent Work

One of the questions we often get is, “How much time am I out in meetings vs. working independently?” Of course, these days, for virtual work-from-home time, all of it’s at your computer, or most of it is at your computer if you are working from home. But we do see about 1/3 of a BA role where you’re interacting with people in some sort of a meeting environment, and 2/3 working independently.

Depending on your role and the degree of stakeholder interaction, that could switch to more of a 50/50 split, but it’s probably not going to go much beyond that because you need time to be really in that independent work doing your thinking process and thinking through the requirements. Not to exclude the time actually out with stakeholders discovering what they want in collaborating. It’s both a collaborative and an independent role.

Some of the other things that you will do is prepare for meetings – running an effective working meeting or a workshop takes some planning effort. You would create draft deliverables, put an agenda together, and maybe meet with some key individuals ahead of time if it’s a really significant longer workshop to make sure they’re prepared in terms of what they need to bring to that meeting to be effective as well.

You could spend some time resolving issues – issues with the requirements or issues that surface during implementation or issues that are keeping you from finalizing requirements. You will spend a fair amount of time planning as well, so planning your projects, planning your time, planning your day, planning your week. You need to expect to be intentional about your day and your time and be planning ahead.

The Typical Day of a Business Analyst – This is a Self-Managing Role

Typically, it’s a very self-managing role. You’re going to be spending time planning ahead to make sure that you have things done when they need to be done. No one’s going to be micromanaging that for you. While, also, leaving space for the unexpected because unexpected things do come up that you need to deal with, especially if you’re in an organization that has some aggressive timelines.

You might spend some time, also, estimating for your team for upcoming projects for stories, for features.

Also, sometimes learning new skills, whether those are techniques within business analysis and best practices for your craft as a business analyst, or domains like a specific industry or functional domain, or a business application, how to use the tool that is in place in your organization that your business users are using so that you can be more efficient in terms of analyzing the requirements.

In addition to the working meetings that we talked about before, you’ll spend a fair amount of time, as well, engaging with stakeholders. Collaboration is key. The best BAs set aside time each week to have lunch with a stakeholder or reach out and have an informal chat with someone in the organization may reach up and meet with their manager, or their manager’s manager; have a skip level meeting to be getting a better bigger picture of you, of what’s going on in the organization.

Connection is really key as well.

The Typical Day of a Business Analyst – Different Phases of Projects

Now, one last thing I wanted to talk about was the different phases of projects and how that can shift your workday as a business analyst.

All of those activities that we talked about are different things that you can be doing from week to week. But depending on what phase your project is in, you could be experiencing them in a different way.

The three key phases we’ll talk about are Initiation, and the detail or elaboration phase, and then when that project is in implementation mode.

Initiation Phase

In that initiation phase, when you’re getting the project off the ground, you’re gaining alignment on the business objectives and the project scope. You might feel overwhelmed with new information at that stage. These are steps 1-4 of what we cover in the business analyst process framework. We teach that in more detail at Bridging the Gap in our BA Essentials Master Class.

You can also learn more via the Quick Start to Success workshop.

Steps 1-4 – Getting oriented, discovering the business objectives, finding the scope, and doing the plan. That’s the initiation.

It could feel overwhelming. You’re trying to get a lot of people on the same page who are maybe a little bit all over the place and have their own agendas. You’re consuming this information. You’re drawing it in and you’re taking a very ambiguous set of information and trying to create clarity and action out of it. A “Go Forward” concept for how we will move forward in a touchstone; some clarity around that.

Elaboration Phase

Once you get into the more detailed or elaboration phase, which is Step 5 in our business analysis process framework, you’re going to be in more of a predictable pace, usually. You’ll be discovering. You’ll still be doing discovery but at a more detailed level. You’ll do your analysis and then you’ll go back and validate that work with your stakeholders, and you’ll be iteratively figuring things out. Iteratively getting into more and more of the detail that you need to ensure that the software development team has what they need to design and implement the solution.

There can still be issues that come up or things that create overwhelm, but it’s a lot more predictable and it’s a lot more contained in terms of the information that you’re discovering at that phase.

Implementation Phase

During implementation, you end up in more of a support role. You might be off with your primary focus on another project at that point, but still need to be available if the development team has questions or the testers want you to review their test cases, or the business team needs support in terms of implementing the new solution.

You also can be just managing changes and issues that tend to surface during implementation. By no means is your work done at that point.

The Typical Day of a Business Analyst – In an Agile Environment

Now, in an agile environment as a business analyst, you might be in all of these phases at the same time which can be a little overwhelming, especially when you’re first making that change to having some features in that initial phase, some features that you’re detailing, and some in implementation. You have parts of your work in each of these phases and you might be switching gears between those phases on a day-to-day basis, or even on an hour-by-hour basis. It can be a lot of variety in that case and really planning your time is key in that kind of environment.

You can also be in organizations where you don’t just have one project. It’s relatively rare to have just one project at a time. You might have three projects. I know BAs that have had 10 projects or they handle a bunch of little projects where, again, that are kind of in different times. You might have different parts of your work in different phases.

What Do You Want YOUR Day To Look Like?

That’s just an overview of what you can expect. People who are great at business analysis tend to like the variety that no day is really the same, that they get to be intentional about their time and be pushing things forward in an intentional and purposeful way.

>> Start YOUR Path to Success

If business analysis is a career that you want to pursue, the absolute best next thing to do is to join my free Quick Start to Success Workshop. In that workshop, you will learn more about the business analyst career path as well as details about the business analysis process framework that will give you the structure that you need to manage your day and your projects appropriately.

>> Click here to join the Quick Start to Success workshop <<

Again, if business analysis is right for you, we are here to help you at Bridging the Gap. We provide online training and certification to business analysts who are looking to start and succeed in their business analyst careers.

For now, just remember that we build our profession one business analyst at a time. Success starts with you.

Thanks for being here.

The answer might surprise you…

To learn more about the 8-step business analysis process framework, click here to register for our Quick Start to Success free training.

For those who like to read instead of watch, here’s the full text of the video:

Starting a Business Analysis Career without a Process Framework

Hello, this is Laura Brandenburg from Bridging the Gap. Today I want to talk a little bit about our business analysis process framework. Before I dive into that, let me just tell you a little bit about how I got started as a business analyst and what that looked like.

The brief story is before I was a business analyst I was a Quality Assurance professional.

I asked so many questions in those requirements meetings as a QA analyst that they eventually said, “Why don’t you come over on to the other side and help discover and analyze these requirements yourself?” That is the briefest story (read the elaborated story here), but I was doing a lot of business process analysis, a lot of test case creation and planning as part of that QA role that set me up for that business analyst role.

Not Too Much or Too Little: Building a Business Analysis Process Framework that Makes Sense in the Real World

In that business analyst role, I definitely felt in way over my head and I was lucky to have a mentor. We didn’t have a process. We had some templates that we used and some basic structure for our project. We didn’t have a step-by-step of how to approach our work. We didn’t realize that there were other people at other companies doing work like us. We thought we were special and unique and in this role that was only applicable in our organization.

A lot of BAs in the world today, maybe even you, have felt like this until you stumbled across IIBA® and the fact that there’s a title for the work you do as a business analyst or business systems analyst or business process analyst, whatever you want to call it.

What I learned as I moved from company to company and started the switch industries and then eventually built a team of business analysts and project managers and quality assurance professionals, and then by becoming a contractor and being exposed even more companies and methodologies and industries and realized that I didn’t have to make this up as I went along. There was more the same than there was different.

My work on the project was different. The templates I used in one organization were often a little bit different than another. The questions I asked were very specific to that to mean that I was intuitively following a set of best practices and a best practice approach. I was what you might call an unconscious competent. I was very competent and successful as a business analyst, but I wouldn’t have been able to teach someone else about it.

Fast forward a little bit and I did start to train other business analysts through Bridging the Gap all the way back in 2008. At that time I still didn’t think I had a process. I’ll just be totally honest there. I started teaching the techniques first.

We taught business process analysis and use cases and wireframes and data modeling. Those were the first courses I developed because I knew how I could apply those techniques and we always use them on our projects. But I didn’t have an intro to business analysis or how to get started as a BA, we just focused on the techniques.

I kept seeing this burning need and people were asking me, “Why approach a project?” “What do I need to do to be effective?” “What does it look like from point A to point Z?” “What is the 1, 2, 3 look like of business analysis?”

There were a lot of other options in the industry, but quite honestly, my perspective on those is that they were quite heavy. Heavy meaning they required more time and more formality than most of us had in our real-world work.

A Business Analysis Framework Created from Successful Projects

When we’re in an organization that doesn’t go by the book and needs us to be successful anyway, and so what we needed as a profession was a very simplified process, one that would be both thorough but flexible and that focused on the core essentials of what it took to be successful and effective as a business analyst. And one that would save business analysts’ time rather than creating a lot of extra busywork. Kind of mind-blowing.

On the other hand of our industry, we had too much formality and then we had agile approaches. We still have agile approaches today. Agile is amazing as a software development methodology in practice. Agile is not a business analysis process.

In fact, the success of an agile team depends on so much business analysis happening before we get to a product backlog.

• What problem are we solving?
• What is their key goal here?
• Who is aligned around the scope of this goal and how we’re going to move forward with this goal?

And what the requirements need to be.

We assume that this business analysis has happened before we start, what is covered in a traditional agile approach. We needed, as BAs though, to be cognizant of this and we needed to simplify our process and focus on the essentials. What happened is I saw one of the biggest mistakes that BAs would make when they would be faced with an agile transformation or their organization was going agile.

This is the biggest mistake besides just digging in and resisting it. We know that doesn’t work. The other mistake, once we didn’t dig in and resist it, we would throw away all the important bits and pieces that would truly make us successful as business analysts. We would focus on the agile techniques and lose out on the business analysis techniques that made us successful.

When I sat down and thought through my most successful projects and what I had done and how I had created those successes, what came from that was the business analysis process framework, and it’s really a middle ground. It’s what you need to do to be effective and how to make decisions about what’s important and what’s not important and how to connect our business analysis practices with whatever methodologies, software, project management are in place in our organization. It’s important to be a great partner with everybody else on the team.

I combined what I had done with what I had seen working from our participants all across the globe and hundreds or lots and lots of industries and from that evaluation came the BA process framework.

Since that time, we’ve helped hundreds of business analysts learn and apply this process. It does help people from not even yet a business analyst to even a more senior business analyst. Let’s talk about how it applies in those different situations.

Newer Business Analysts Leverage a Framework to Exceed Expectations

A newer business analyst, they might not know where to start or what expectations to set. They often get into a BA role and feel like they’re going to sink or swim in a situation and nobody’s telling them what to do, but everybody has extremely high expectations of them. They get to avoid a lot more of the more common pitfalls that, quite honestly, most of us need to learn through experience, or most of us had to learn through experience.

How about somebody with a bit more experience who’s learned a few of those lessons and has a fairly consistent track record of success? What I find is that we still have a couple of key challenges that we face again and again in our projects. Or we get into a new environment and we’re not quite sure what to do because we’re that unconscious competent.

So those common challenges, they often come back to just one or two steps of the framework we’ve been skipping. That isn’t needed in my organization, or that doesn’t work for me. We can’t make that work because. When they fill in those gaps, their projects move forward much more smoothly.

They also start to elevate their role as a business analyst in their organization. One of our participants, Amelia McHenry, participated in our full The Business Analyst Blueprint® program first and then joined the BA Essentials Master Class where we teach the business process framework.

Amelia reported going into a rather new role. She was a newish BA at the time. Had quite a bit of professional experience, but it was her first real official business analyst role. There were senior BAs who had a lot of experience that she was working with but she brought out the questions from Step 2, which is discover business objective, and she asked those in a meeting.

She used those to help understand what problem are we trying to solve here? What is the ideal solution look like? The people in that meeting, which were pretty high-level stakeholders, were super impressed. They were like nobody’s asked us these questions before.

This is great business analysis. We need more of this in our organization.

Her credibility in that organization went from the new somewhat having some business analysis experience, new in the organization, new to the domain to top level. This is the person who’s bringing that next level of capabilities to our organization.

There’s a lot that comes from your personal credibility, especially as a more intermediate BA when you start to apply these learnings and these teachings and have the courage to ask the questions that you should be asking.

More Senior Business Analysts Leverage a Framework to Train Others Successfully

How about a more senior business analyst? What I find and what my personal experience was, even as a manager of a BA team, I knew intuitively what made me successful. I knew how to be successful, but had a lot of trouble setting that up in terms of a structure for my team because I hadn’t sat down and created this process framework yet, and quite frankly, I didn’t believe it actually could exist.

I wish I could go back and change that for my team and for myself, but when we do teach a more senior BA to go through this process and they start to see how it’s worked for them in so many of their successful projects, then they could also effectively mentor and train other business analysts.

Instead of being able to maybe be the go-to person that BAs come from for guidance or you’re kind of always in the mix of all the projects because nobody else can do things like you can do, you develop this ability to clone yourself by training other BAs to handle any situation. That’s a next level skill set and it sets you up to be more of a leader and a manager or just get out of the day-to-day grind of having to be everything to everyone.

Even Aspiring Business Analysts Can Leverage the Framework to Increase Their Confidence

Finally, let’s talk about people who aren’t not yet BAs and what happens for them.

Thomas Clarke was one of our participants who was a research assistant when he took the BA Essentials Master Class. Then soon after moved into a project management role within his company doing a lot of business analysis work; a lot of finding the problems and figuring out the solutions and overseeing the solutions to those problems.

What he said is it just gave him an approach. He didn’t know where to start. A lot of “not yet” BAs are scared of getting their first BA position because they don’t know what they’re going to do when they get that first position.

Learning the approach and realizing there is a step-by-step process that they can go through gives them more confidence that when they’re in that situation they will have an approach to follow. They will have handouts and questions and next steps and be able to drive the process forward and they won’t have to make things up as they go along.

If you want to learn more about the process framework, what it is, what the steps are, how it might work for you, I invite you to click here to register for our Quick Start to Success free training and learn more. I’d love to teach you about the business analysis process framework and help you be more effective as a business analyst because we build our profession one business analyst at a time and success starts with you.

Again, I’m Laura Brandenburg with Bridging the Gap. We help you start and succeed in your business analyst career.

In the spirit of keeping it light this week, let’s look at a few of the nicknames business analysts have been given over the years.

1. Colombo (the detective from the television show) – One of my mentoring clients shared that her stakeholders gave her this nickname because she always had “one more question.”
2. Mr. Wolf  –  Even though I could never stomach finishing the movie this character was in – Pulp Fiction – I loved that my stakeholders felt that I was successfully cleaning up their messes.
3. Leonardo (as in da Vinci) – This one comes to us from Bob the BA because we use a tremendous number of skills and have expertise in a variety of different areas.
4. Bad A** – Who says that the “B” is for business and the “A” for analyst? Cecilie Hoffman started a series over at BATimes called the Bad A** BA where she shared her hard-earned lessons from taking the tougher routes.
5. Explorer – This one comes from one of my Twitter followers, Aotea Studios, and I absolutely love it. Business analysts explore everything – business domain, pain points, problems, stories, options, etc.  Here’s a picture they shared of how they put the “Explorer” label right on their laptop!

Do you have a favorite business analyst nickname? Leave a comment below.

Because looking back can help us look forward with more clarity and confidence, in this article we’ll look at 5 ways the profession has changed since 2009 or in the 5 years since the first edition of How to Start a Business Analyst Career was published.

Change 1: New Business Analysis Certifications

While the IIBA® Certified Business Analysis Professional (CBAP®) certification has been available since 2004, two new certifications have been created in the last 5 years.

• First, IIBA® introduced the Certification of Competency in Business Analysis (CCBA®) in 2011, providing a certification option for business analysis without the extensive work history required by the CBAP®.
• Second, Project Management Institute (PMI)® released the Professional in Business Analysis (PMI-PBA)℠ certification in 2014, providing a certification option for business analysts who work primarily inside projects and programs.

New certifications mean a growing awareness of the business analysis profession, along with professionals having options when it comes to adding to their individual credibility. What’s more, the new options have lesser work experience requirements, making certification a more viable option for more professionals relatively new to business analysis. As we look forward, the number of business analysis professionals will continue to grow.

Accordingly, the second edition of How to Start a Business Analyst Career contains a new section on certifications and how they can fit into your career planning.

Change 2: Expanded Set of Business Analyst Job Roles

Despite what we might like to see as business analysis professionals, business analyst job roles are still specialized. In the last 5 years, we’ve seen this pattern become entrenched within the profession, and experienced an increased number of flavors of business analyst job roles.

In the second edition of How to Start a Business Analyst Career, the discussion of specializations was expanded and several examples of how to leverage and highlight your industry and domain experience were included.

The new job roles added include:

• Business Intelligence Analyst
• Business Process Analyst
• Systems Analyst
• Product Owner

The book further explores specializations by splitting apart Industry-Focused, Tool-Specific, and Functional Domain-Focused Business Analyst Roles, which were all covered in the first edition, but not with as much depth.

As more organizations recognize the value of business analysts and look to increase the value provided by their business analysts, I think we’ll continue to see specializations expand, at least at the mid-level and senior-level roles.

Change 3: Increased Focus on Business Process

Although the vast majority of business analyst jobs fit within the IT Business Analyst job description, the business analyst role itself has seen an increased focus on business process. I know in my early days as a business analyst, a lot of product decisions were necessarily driven by technical constraints.

While we haven’t obliterated technical constraints, they tend to have a much less significant role in our early requirements discussions and we are free to explore more in the way of business needs and opportunities. This means business analysts are involved not just in analyzing and specifying software requirements, but also with understanding current state business processes, helping plan business process improvements and changes, and driving the implementation inside the business user community.

For many business analysts, these changes have resulted in a subtle expansion of their role. For others, they’ve found themselves drawn to one side or the other in yet another specialization force within the profession.

Rest assured, we’ve got you covered in the second edition, with additional skills for process analysts, a deeper focus on collaboration techniques, and an entirely new Underlying Core Competencies section. I also updated the discussion of the Business-IT balance specifically to address some of the shifts we are seeing in business analysis work.

Change 4: Increased Adoption of Agile Practices

Five years ago, agile practices were beginning to transition from the latest fad to a respectable trend. The business analysis community was just starting to get engaged in the discussion. As of 2014, the majority of business analysts I talk to have experienced or are working in agile teams. That’s because agile is much more widely accepted and adopted now as a discipline.

Strangely enough, despite historical claims that agile does away with business analysts, we only see positive signs for the business analysis profession so these two disciplines must be co-mingling.

In the first edition of the book, I was unable to cite any resources specifically looking at the intersection of business analysis and agile. Thankfully, this gap has been filled in many ways, and there are several relevant resources suggested in the updated text. The most prominent resource is Discover to Deliver: Agile Product Planning and Analysis, co-authored by Mary Gorman and Ellen Gottesdiener, who also contributed a foreword to the second edition of How to Start a Business Analyst Career.

And while agile is clearly the way of the future, the book still contains a discussion of waterfall and iterative approaches because we still see many business analysts working in environments that approach projects in this way.

Change 5: Increased Awareness of the Business Analysis Profession

Obviously we are still fighting many battles to have our value, skills, and experience appropriately recognized. However, there are many signs that awareness of business analysis is growing.

Let’s look at a few key indicators:

• In 2010 the average business analyst salary as reported by the IIBA® salary survey, was $82,493 in the United States. In 2013, the average US salary for a business analyst rose nearly $10,000 to $91,514.
• Membership in the primary organization for business analysts – IIBA® – rose from 5,000 in 2008 to over 28,000 in 2014.
• There were numerous mentions of roles related to business analysis on top job lists, albeit often under titles such as Computer Systems Analyst, Management Consultant, and Business Technology Analyst.

Everywhere you turn, business analysis is being recognized where it was previously ignored or rising where it was previously under-valued. This doesn’t mean that we don’t individually experience frustration, but overall the tides have turned and are building in a very positive way.

And What Hasn’t Changed (Much)

Despite all the steps forward in the last 5 years, there are still some aspects of business analysis that haven’t changed all that much.

There is still a dizzying array of job titles referring to business analyst jobs and myriad job responsibilities included inside business analyst jobs. The section on hybrid roles was actually expanded to more fully address the challenges an aspiring business analyst faces when exploring job options.

Another aspect of business analysis that hasn’t changed much – and I see this as a positive – are the fundamentals. Here are two sentences that are exactly the same in both the first and second edition of the book.

“What is not going to change all that much are the fundamentals of business analysis. If you focus on learning the fundamentals and work your way through a few projects, you will reach a point where you have mastered the basic techniques but can keep on refining the art. “

And while refined and re-organized, the core business analyst skills and related business analysts skills lists remain essentially the same between the two editions.

It’s Our Time

After taking this look back through the profession, I’m energized because there seems to be so much momentum behind what we are doing in business analysis. I’m happy to see some of the positive changes – the growth in awareness and salary – along with the wider range of opportunities that are available to me with my business analysis background.

To me, this means that the work I love to do and love to help others do will continue to be valued and rewarded for a long time to come. It means that we will all have more opportunities to make a positive impact in our teams, organizations, and last, but certainly not least, our careers.

I can’t think of a more apt way to close this article than with a quote from the conclusion of How to Start a Business Analyst Career:

As business analysts get better, the world gets better.

I’m proud to be part of the business analyst community and to offer this new resource to help more talented professionals expand their opportunities in business analysis.

Click here to learn more about the book

In this article, we’ll look at a concept I call the Business-Technology Balance and then discuss 4 ways that the IT Business Analyst job is expanding as the balance shifts.

The IT Business Analyst Job Description is Impacted by the Business-Technology Balance

One concept I write about in How to Start a Business Analyst Career is the Business-Technology Balance.

While our profession is called business analysis, the vast majority of business analyst roles as they exist today deal specifically with software projects. Business change and software implementations tend to go hand-in-hand. Even so, some roles focus more on aligning the business team around the scope of a solution, and some focus more on detailed requirements for the technical team to implement.

And then:

In a business-focused role, you might have the following responsibilities:

• Understanding the needs of multiple stakeholders.
• Facilitating the negotiation of requirements amongst multiple stakeholders.
• Identifying the current- and future-state business processes.
• Helping the business stakeholders envision the future and how their work will need to change to support the future.

In a technology-focused role, you might have the following responsibilities:

• Creating, analyzing, and validating detailed functional specifications.
• Facilitating design sessions with the implementation team to define the solution.
• Delivering elements of systems design, including data migration rules, business rules, wireframes, or other detailed deliverables.

Source: How to Start a Business Analyst Career, Second Edition. Laura Brandenburg, pages 124-125.

A traditional IT Business Analyst job description was more technology-focused and the role was often defined around a system or small set of systems, commonly proprietary systems in use by only one organization. This kind of job description still exists today, but it is both career-limiting and offering decreased value to the organization.

More and more, we’re seeing expanding IT Business Analyst job descriptions that offer professionals the opportunity to shift more towards a business-focus and/or work at a more strategic level in the technology aspect of their roles. These jobs provide IT Business Analysts the opportunity to grow their skills, expand their value, and become more marketable.

Let’s take a deeper look inside the ways the IT Business Analyst job description is expanding and what this means for your opportunities in a business analysis career.

Expansion #1 – IT Business Analysts Work on More than One System

Historically, companies built and maintained single, monolithic systems or small collections of large systems to run their businesses. With the expansion of Commercial Off-the-Shelf (COTS) systems available to meet almost any business or feature need, organizations are investing in and supporting an increasing quantity of systems. What’s more, in order for these systems to deliver the value business stakeholders expect, they need to talk to one another.

One way that IT Business Analysts’ job descriptions are growing is that they are focused on several systems and integrating those systems to deliver maximum efficiency and business value. When working on multiple systems it becomes more important to consider information flow and data requirements, as well as make strategic decisions about what functionality belongs inside what system.

However, even when working on multiple systems, an IT Business Analyst job description is still focused more on the technology side and less on the business side. There are other ways their role can expand to align more towards the business. Let’s look at that next.

Expansion #2 – IT Business Analysts Evaluate the Business Process

A second way the IT Business Analyst job description can expand is by looking into the business process. Traditionally, requirements discussions might be focused around the features and functions needed by any of the systems under the analyst’s domain. This is still important work.

But again with the introduction of new tools and software, meeting business requirements is becoming easier and easier. This can free up the IT Business Analyst’s time to focus more on the business processes driving the software requirements or helping modifying the business process once the software changes have been made.

This means that even as an IT Business Analyst you can play a role in clarifying, updating, and improving the business processes impacted by the technology changes that are part of your projects. This role requires you to partner more deeply with various members of the business community.

Expansion #3 – IT Business Analysts Support Multiple Stakeholder Groups

One of the recurring themes here is that systems are becoming more complex and technology implementations are able to offer an increased number of features. A corollary to this is that stakeholders from more departments tend to use any given system, meaning that more stakeholders get involved in any given project. For example, a seemingly simple update to the sales system could impact marketing, fulfillment, customer service and accounting.

This means that the IT Business Analyst gets more involved in the elicitation process, navigating the competing needs of multiple stakeholder groups, defining an end-to-end business process that is accepted by all groups, and finally mapping out the requirements for one or more systems to support these needs and the process. This type of job requires stronger communication skills, along with facilitation, prioritization, and scope management.

Expansion #4 – IT Business Analysts Look Beyond One Project

A fourth way that IT Business Analyst roles are expanding is by working on more than one project at a time. Historically, projects were larger in scope and fragile systems required full-time focus on analyzing and specifying requirements for one system inside one project. With the introduction of more fully-featured out-of-the-box systems, scope can be handled in different ways. And with the introduction of more agile processes, more organizations are breaking down big projects so that they can be delivered incrementally.

For the IT Business Analyst, this means you might work on many projects at one time or have the opportunity to participate in pre-project analysis work that helps enable informed decision-making about what investments to make in technology. In this way, you are involved in a more strategic role in addition to your tactical role on projects.

The IT Business Analyst Job is Great Place to Be!

If you find yourself in an IT Business Analyst job or are considering a business analyst career path, the IT Business Analyst role is a great place to start and can provide a launching point for a business analyst career. As you can see, an IT Business Analyst role is necessarily expanding beyond the technology component and into the business component, and that means great things for the career prospects of analysts in this space.

>>Learn More About Becoming an IT Business Analyst

In How to Start a Business Analyst Career, we discuss all types of IT Business Analyst roles in greater depth and look at the wide variety of roles in the IT Business Analyst space.

This book will help you find your best path forward into a business analyst career. More than that, you will know exactly what to do next to expand your business analysis opportunities.

Click here to learn more about How to Start a Business Analyst Career

My past 25 years of work experience has been in the not-for-profit sector, in both program work as well as various IT roles. A part of this work that I have enjoyed very much is when I have had the opportunity to help the organization I was working for to improve its processes to better meet its goals. At times this has involved helping the organization select an appropriate software product, and working with consultants to customize the software to best meet the needs of the organization.

I would like to focus more on this type of work, and am even thinking of taking some formal training in business analysis, but I don’t know if business analysis principles and processes are suited to the not-for-profit sector. Initially I would hope to apply the skills I learn at my current organization, but I would also like to volunteer helping other not-for-profits, and maybe even some day earn a living by doing business analysis with not-for-profits.

Could you tell me if my aspirations are realistic? Are there any BAs out there who do this very thing? Are there any real opportunities available? Thanks.

Doug’s Answer:

Why yes! Yes there are. I can’t tell you strongly enough that you are doing exactly what you should be doing to advance your career. Offering your services to non-profits or small business that cannot afford to hire extra resources will help you work through your growing pains while providing valuable assistance to organizations that are typically desperate for help.

When I speak to working through growing pains, you will have to realize that you are highly likely to make mistakes in judgment and execution as you work on projects. This is absolutely normal and you should look at mistakes and even failures as learning opportunities. The really great thing is that you are able to work through these events without the pressure of getting fired, demoted or having your reputation tarnished. Due to this fact, your confidence grows as you try things again and finesse your techniques along the way. FINALLY, you are less likely to suffer the wrath of your boss due to a mistake, because you are volunteering. This is THE best way to learn a craft, but by combining it with your academic ventures, you are melding book knowledge with life experience and this will yield great results and rewards.

OK, so congratulations on your insight into the things that you need to do. To your comment about whether BA principles are applicable to not-for-profit organizations…..absolutely. Actually, BA principles are applicable in any environment in which there are problems to solve, not just in the business world. Sticking to business, though, ANY business in any industry employs resources in both human and material form, utilizes process to accomplish a task and has inputs and outputs to and from points in the process. Business analysts are skilled in viewing all these components, looking for efficiencies (and deficiencies) and recommending solutions that provide value. From a lemonade stand to a high-tech software company, the analysis is essentially the same at the core.

All the best to you. You’ve got a great start going. Let us know how you progress.

>> Learn More About Business Analysis

What Skills Are Important for a New Business Analyst?

The Business Analyst Career Roadmap

How to Write a Business Analyst Job Description

I have been a developer, and from there moved to doing business analysis. I would call myself a Business Systems Analyst, and love that role. Is becoming an Architect a suitable progression from a BA? I have moved from development to doing business analysis. So, I do understand technology quite well so I was more thinking on the lines of Solution Architect/Enterprise Architect. But does that mean you have to be in the technical stream? Also, at what level does business architect come in? Is it higher or lower than Solution Architect?

Laura’s response:

I do see business analysts with strong technical backgrounds moving into solutions architect roles and I think this can be a great career path for the right person. If you like technology enough to keep up with the latest platforms, tools, and technologies, then solution architect could be a good career path choice. Often we also see strong developers with a big picture mindset and strong people or “soft” skills moving right into these roles, so there are many paths to solution/enterprise architecture.

In full disclosure, my husband is what I would consider an enterprise or solution architect and I often joke with him that he’s doing some business analysis. I’ll hear him on client calls talking about business process, business goals, and suggesting high-level technical solutions, and I’ll be like, “Ah! He needs a BA!”

And while I (as a Business Analyst) could have these initial conversations, I do not have the deep technical background to jump right into suggesting solutions and solving problems immediately following a phone call. It’s a highly valued competency within the business community where decisions need to be made fast. This means it can be much easier to have one person you can talk to and get a solution from rather than the more iterative process of a BA/Developer combo.

But I digress…

Yes, I do think a solutions architect role tends to be in the technical stream a bit. The professionals who are successful in these roles can strongly influence a development team. You will have developers challenging your decisions and you will need to be able to talk their talk, write code to create prototypes, and wrestle with thorny issues. I don’t think one can be a great solution architect in the abstract.

And, as to the relative hierarchy of business architect and solution architect, it will depend on the company and how the roles are defined. Solution architect is the more common role today, but business architect might be more likely to have direct executive exposure and I believe it will grow over time. Since these titles can be used for various types of roles, it will depend on how the roles are defined and what the company values. For example, a high tech company might value a solution architect more highly because their competitive advantage is in the solution, while a growing business might value a business architect more because their competitive advantage will be derived from organizing the business to scale.

>>Learn More About Business Analysis

Pick up a copy of How to Start a Business Analyst Career for a complete walk-through of what a BA does and how to plan out your career transition.

Click here to learn more about the book

Is it a trend that BAs see the project manager role as a natural progression of the BA career path?
I have recently took on a role of a BA Lead and held career development sessions with my team. Often most of them cited becoming project managers as their long term goal. I respect this goal but I just wanted to know is it the BA career path or are there trends that talks to this?

Laura’s answer:

Five or ten years ago, the common career advice to business analysts was that to be promoted, you should become a project manager.  In fact, business analysis was often heralded as an entry level path into project management.And even now, I find that assuming that to get promoted, they need to become a project manager, is a common misconception amongst BAs. This typically happens because their organization does not have a senior-level BA career path.

Today, the path from business analysis to project management is still a legitimate career direction, but it no longer represents the only option. In fact, we are seeing the reverse direction as well, with project management professionals transitioning into business analysis careers. There are many, many project managers who participate in our courses as a way to expand the business analysis aspect of their roles.

In short, the path from BA to PM is a historical trend that is slowly but surely being debunked.

As a manager, you are in a unique position to help drive this change.

• Can you help your business analysts find a career path in your organization?
• Can they move into senior level roles where they are involved in defining the project scope or evaluating new business opportunities?
• Can they move into lead business analyst roles such as your own?

This leads me to another point, as a big part of the answer to this question is “what’s next” for your career?  Your individual climb up the ladder may indeed pave the way for those on your team and, as you lead by example, you may inspire your BAs to also stay business analysts.

• Is the scope of responsibilities fulfilled by your team the full set of business analysis opportunities?
• Are there other opportunities to leverage your team’s strengths to take on new senior business analyst responsibilities and make a positive impact on the business?

As you settle into your new role as lead, these will be important questions for you to consider.

Now, this is not to say that project management is not one possible career path and you are right to respect that goal, if the goal is based on a passion for the role and not an assumption that this is the only promotion opportunity. In my experience some BAs are naturally suited to project management, but most are not. The competencies overlap but the mindsets are different.

>>Learn More About Building a BA Career Path

With our free step-by-step career planning course, you’ll learn how to create and accelerate your business analyst career path.  Upon joining, you’ll also receive our BA career planning guide and follow-up insider tips via email.

Click here to learn more about the free course

Editor’s Note: This relationship started when I queried on Twitter for some help planning a usability study. Leslie Shearer led me to Patrick Quattlebaum, Chief Experience Officer at Macquarium. Patrick graciously suggested a few books. It turned out that Patrick was speaking about BA/UX roles at a Charlotte IIBA Chapter meeting and I thought that would also be a great topic to address here at Bridging the Gap. I was surprised to learn about how much UX and BA roles have in common and have officially found a new profession from which I’ll seek to unapologetically steal as many tools for my professional tool belt as possible, especially when it comes to enterprise analysis.

Laura: Tell me a bit about what you do at Macquarium.

Patrick: As a User Experience (UX) consultancy, we provide strategy, research, and design services primarily to Fortune 1000 companies across a wide range of industries. Our portfolio is equally divided between IT and business customers, such as marketing and product management. This focus on both business and IT customers is somewhat unique in our space, as most user experience firms tend to gravitate towards one side or other, or on a specific genre of work like ecommerce, or a specific technology like SharePoint. This means we tend to compete with web development shops, system integrators, and interactive agencies of all shapes and sizes.

At Macquarium, we believe user experience is an enabler of business strategy and not merely the front-end work of a technology deployment because we view UX as a holistic approach to designing the interactions between people and products/services. With some clients, we help them shape strategic roadmaps at an initiative or feature level. For others we’re helping nail down the detailed requirements and designing the user interface. It really depends on when and why we’re brought in by the specific client. The earlier UX firms or teams like ours are involved in the process, the better.

Laura: I feel a bit uneducated about the UX profession. Can you share a bit more about it?

Patrick: User experience is a very broad field with many disciplines – information architecture, interaction design, graphic design, content strategy, research, and even front-end development. In terms of digital work, like web applications and web sites, we are still very early in maturation of many of these fields, and “user experience” as unifying field for these professions is relatively nascent.

A decade ago, much of the focus was on information architecture, graphic design, and usability. We were inventing best practices for structuring information spaces and giving the web a user interface. We stole methods and lessons learned from software design, user-centered design, library science, and architecture.  As the web has evolved to afford more responsive interfaces, interaction design has become a recognized field for applying an understanding of psychology and human behavior to user experience design.  To put it simply, the growth and specialization of different user experience roles has mirrored the increased use of digital technologies in our culture.

My view of user experience is representative of many of us who see incredible value in applying design to business strategy. A lot of us have moved into leadership positions and have done a lot of thinking about our field and where it is going. Like many professions, we have focused on how to add value earlier and earlier in the solution lifecycle. Today, we see it as a best practice, not a nice to have, to use methods such as user interviews, contextual inquiry, card sorting and usability testing to understand human behavior and apply it to product and service strategy and design. We advocate user experience should have a seat at the table from Day 1 to spur innovation and create human-centered solutions. Essentially, user experience professionals recognize that while there is a lot of discussion about business requirements and technology, eventually a person needs to do something with what we build in order for the business to achieve its goals. Baking into strategy an understanding of the user as well as clear design principles for the solution can make a huge difference.

A greater focus on design and human behavior is not unique to UX. In business schools today, they are teaching design thinking, for example. It’s about understanding people and empathy. It’s about how to create business value holistically by staging experiences instead of an atomistic approach that focuses on individual features and functions only. This is where the UX profession lives.

Laura: This is really interesting. I must admit, my idea of the UX profession was definitely in the user interface “design” box.

Patrick: That’s not uncommon. But truly, design is an entire process. It’s not something that happens at one part of the product or software development lifecycle.

Laura: Let’s talk about that a bit more. Given that BAs and UX professionals are tackling business problems, what examples have you seen of how they can best work together?

Patrick: I coach my team and clients on first embracing a teamwork approach, not a partnership approach. (Pardon the semantics; I’m an information architect by training.) Organizations sometimes place our two disciplines in the same department, such as IT, but I’ve seen UX on the business side or, in Macquarium’s case, as consultants coming in from the outside. Good teams have trust and understanding of one another’s skills at their base, and org structures don’t create or prevent teamwork.

While the nature of most projects necessitates a “divide and conquer” approach, it is important that BAs and UX professionals understand the inputs they are both collecting to define and design the solution. Early in my career, I was working as a user experience architect with a BA on an intranet project. The BA was primarily responsible for eliciting business requirements. I was responsible for understanding the user segments in the hospital and creating personas to represent their goals, tasks and needs. We helped one another by being notetakers in each other’s sessions. I even taught the BA card sorting. She got to see what information I was collecting and its value, and I was able to witness her help a collection of business stakeholders collapse a set of ideas into clear business requirements and gain buy-in. That’s an art too! Our empathy for one another’s role was vital and came through in the work.

Laura: That makes good sense. So you both developed a shared view including each other’s perspective but your work was not competing. Tell me a bit more about what a UX professional does in the upfront part of the project process.

Patrick: UX professionals provide key input into the product or software development process. They are concerned with aligning the strategy with end users. In most solution definition processes, the end user is often overlooked, but for the UX professional, the end users’ collective voice in the process is a must have.

Say we want to build a product. A typical process would elicit requirements from business stakeholders, looking at the competitive landscape, and marketing research. The IT team or technology partner might also provide a list of the features that can be built given the project constraints, such as budget or available technology. The BA is left with quite a long list and the project team is facing the realities of time and budget. What features do you build? How do you sequence these features in releases?

The value of UX early in the process is to introduce the user lens to this upfront work. At a minimum, user research has also brought some feature ideas to the table, and feature prioritization involves finding the sweet spot of features that align business with user value and can be built and maintained within the technology constraints. Ideally, UX has helped frame the design problem around business goals and user goals, not technology. We bring our understanding of human behavior to the process because we see users as the key integration point.

Laura: How do you learn what users want?

Patrick: Much of the focus is on user goals and needs, both functional and emotional. If I’m working on a product for a user internal to a company, I’ll go in and watch people work. We always find gaps between what stakeholders believe people do and what employees actually do and need. Through this process, we often find critical features or design requirements to include that help user adoption rates go up. A lot of times we also find things that stakeholders ask for that users simply don’t need. In this way we’re able to cut scope and increase the value of the project.

Laura: As a BA, I’ve often tried to blend these two perspectives and found that the perspective of the project sponsor and the actual users or subject matter experts can be quite separate. For some projects, I’ve used what in business analysis we call “observation” to find this out. Is that similar?

Yes! In UX, the method you were using is also called observation or sometimes contextual inquiry – essentially you watch someone use an application and look for things in their environment, like sticky notes and work-arounds, that provided insight into their context of use. Context is a critical input to design because your goal is to have the product or service fit into a person’s life or to make it easy and desirable for a person to change their behavior.

Personally, I’m intellectually drawn to formative research like observation. Exploring how people use technology is one of my favorite branches of UX, and makes a huge difference in serving our customers. For example, Macquarium once worked on a project where the goal was to find more efficiencies in the call center without degrading the customer service experience. The company’s brand was very white glove, and the customer service center was handling claims calls for insurance holders whose homes had burned down or who had lost valuables in a burglary. There is a lot of emotion in those calls. In observing several customer service representatives doing their work, the team realized that inexperienced reps were following a very linear process dictated by the system, while the experienced reps had learned to write notes on paper and then to do data entry after the call. This workaround meant they could focus on the customer and have a more fluid, compassionate conversation. Redesigning the data entry forms to be non-linear seems like an obvious solution, but the insights from the observations was the information that showed our clients the value of investing in that design approach.

Laura: Interesting. I could see myself doing something similar as a BA. But I might be more “linear” about it, so focusing on the business objectives within achieving the desired customer experience and then working with the customer experience rep to try to uncover the root causes of those problems. It seems that UX approaches the same problem space in a different way. It’s more fluid and is bringing in all kinds of information to look for possibilities.

Patrick: Yes, that’s a good way to put it. We are looking for possibilities through the lens of the user.

Laura: Interesting. Well, I’m convinced that I should be looking to UX for a few new tools to add to my BA tool belt.

Patrick: The UX profession keeps expanding the toolbox, especially tools used early in the project lifecycle. There are some great tools for BAs to steal there.

On a side note, I’m all about building a tool belt as part of your career strategy. I am always looking to expand the tool kit of my firm and myself. There are some basic core process building blocks of the profession that you need to learn early on. But as you go to different companies throughout your career, you will see different processes or flavors of processes, so it’s important to be flexible and creative. Every project has a different set of challenges and opportunities and therefore the tools you pull out of your kit, or invent, are very contextual.

Laura: 100% agree. Anything you’d like to share with Bridging the Gap readers?

Patrick: If you asked a group of UX professionals what they do and built a word cloud from their answers (I’ve done this), always at the heart of it is design. The nuance is that this is not just technical or user interface design. It is experience design. Experience design is what we all do in one way or another. I believe that BAs are also designers; it’s just a different role in the process. For some reason, design has become synonymous with aesthetics and “look and feel”. This is starting to change where we are repositioning design to mean big-D design. At this level we’re talking about applying design methodology to business strategy.

Laura: What are some resources you’d recommend for learning about user experience and big-D design?

Patrick: I’m a big book guy, so here are a few of my favorites:

• The Elements of User Experience – great overview of the breadth and depth of the concerns of user experience and our process.
• Subject to Change – great summary of our field’s view of the value of design-driven product and service development
• Sketching User Experiences – the importance of visualizing our ideas throughout the software development lifecycle
• Observing the User Experience: A Practitioner’s Guide to User Research – great methods for your toolkit, like user interviews, contextual inquiry, usability testing, and card sorting.
• Design Is How It Works: How the Smartest Companies Turn Products into Icons – case studies in applying design holistically to companies, products and services
• Design of Business – highlights how organizations can use design thinking for a competitive advantage;
• The Experience Economy – this book is over 10 years old but still very current. It’s about staging experiences that are focused on people.

Laura: Thanks for your time today Patrick. I’m really glad I had this opportunity to learn more about the UX profession and I’m excited to share these insights with my readers.

Patrick: I appreciate the opportunity to talk about UX to your readership. We work side by side every day, and it is important for our communities to actively discuss our fields’ views, goals, trends, and how we can better collaborate to design the best user experiences that we can.

New and experienced business analysts alike will start researching jobs, only to discover that an overwhelming number of positions require specific technical skills. Or, they speak with a recruiter who has a myopic view of the role, and are told that if they can’t write code [or insert your favorite technical skill here], they’ll never make it as a BA.

In what follows, I’ll explain why we see BA jobs requiring technical skills, show you how to determine what those technical qualifications really mean, and give you a litmus test to see if you have the technical understanding required to be a successful BA.

Why We See BA Jobs Requiring Technical Skills

In the real-world job market, business analyst roles are messy. There are a specializations, unique qualifications, extensions, and partitions. The short answer to this question is you can find a BA role that does not require technical skills. But you have to be prepared to wade through and ignore those jobs with technical qualifications.

As soon as I find a job with an absolute requirement for SQL or a coding language, I stop reading and move on. If you don’t want to be doing those things, applying to jobs that require those skills is just a waste of time. So is fretting over their existence. Remind yourself that BA roles are messy and set them aside.

(And if you are interested in learning more about the BA job marketplace, be sure to sign up for our free BA career planning course.)

But before you throw out too many job roles, realize that the technical requirements you see in job postings can mean different things depending on the context. And that’s what we cover next.

Sorting Through the Technical Skills Requirements

You may notice that not all jobs with specific technical skills listed require the ability to use those skills. Sometimes these skills are preferred. Sometimes they are not mapped to any of the job responsibilities in the description. Sometimes you can ascertain a bit about the position by looking for the context around the qualification.

Consider the following two hypothetical examples:

• Write SQL reports. Requires SQL report writing experience with deep knowledge developing complex queries across multiple tables.
• Prior experience in SQL preferred. Understanding of database concepts and information models critical.

While the first requirement indicates day-to-day SQL responsibilities, the second does not. Vague or “preferred’ requirements often indicate a desire for a business analyst to think logically and understand big picture technical concepts. Other times, they have seen business analysts trampled by developers because they don’t ask the right questions. The assumption becomes if you can write code now or could write code in the past, you are less likely to be trampled by the developers. (Just because this assumption can turn out to be wrong doesn’t stop well-meaning managers of business analysts from making it.)

When technical skills are couched in conceptual or communication-related contexts, the technical skill may be less important than system-thinking competencies. And as a business analyst, IT-focused or not, you must have good systems-thinking skills.

Technical Understanding vs. Technical Skills

While we are starting to see a growing number of jobs focusing specifically on business process and organizational changes, the reality is that most business analyst jobs involve working on IT projects. By an IT project, I mean that a larger part of the solution is implemented in software. To perform BA work on an IT project does not require a technical background or the ability to write code. I’ve spent most of my career working on IT projects and I hadn’t written a line of programming code since high school when I took a class on PASCAL.

As a business analyst on an IT project, it is important to have a general understanding of software systems. Basic knowledge of servers, databases, and client side technology, augmented with solid logical, systems-thinking will do. Combining both will lead to more effective communication with the implementation team.

Quick Test: Select a software application (client or web-based) that you use often. Select 2 or 3 activities you use it for. Can you identify the main sub-systems and interactions that are in place to enable these activities? If yes, you probably have enough software knowledge for a pure BA position on an IT project.

>>Get Hired as a BA

Our 5-step business analyst job search process will walk you through what you need to do to get hired as a business analyst.

Click here to learn more about the BA job search process

I just realized that what I love to do and have always done best is business analysis. But I am a civil engineer, have no desire to be in IT. I know I can be successful in many other areas but do not want to label myself as a business analyst if it will come across that I am an IT person. Thank you.

Laura’s response:

This is an interesting question and my answers has two perspectives. First, from a pure role definition perspective, nothing about business analysis necessitates working with IT. The BABOK defines business analysis as follows:

Business analysis is the set of tasks and techniques used to work as a liaison among
stakeholders in order to understand the structure, policies, and operations of an organization,
and to recommend solutions that enable the organization to achieve its goals.

Within this definition business analysis can include a IT projects, but it can also focus on business process or policy changes or organizational operations. The BABOK also stresses that you can be a business analyst operating under a different title. Business analysis is more about the activities you do than the title you have (or what you choose to call yourself).

But the reality is that *most* business analyst jobs you see listed today do involve some work with information systems. So the use of the term “business analyst” does confer some relationship of IT, though not to the degree of terms like programmer analyst, systems analyst, and technical analyst. Since you are concerned with labeling yourself as an IT person, you are probably concerned with how the term is used more than how it should be used.

One way to handle this, is if you are applying for a process-oriented position, label yourself as a “business process analyst” or “business operations analyst”. You can still pursue BA training opportunities and use BA tools to build your professional knowledge, without being constrained by the term as it’s currently used.

I had the opportunity to speak personally with Durga Patil, a business analyst with L&T Infotech. Durga has been a business analyst for over three years and prior to becoming a business analyst held various roles in software development and testing. Below is a snapshot of our discussion.

Laura: What is the BA role like in your organization?

Durga: In India, the BA role has become much better defined and valued in the last 3-4 years. In my organization, the BA role used to be part of the project manager’s or project lead’s responsibilities. Now it’s a separate role and that enables the business analyst functions to be much more valued by management. In my organization, the BA manages the client and the PM manages the team.

Laura: Tell me about how domain experience impacts your role.

Durga: I work in the insurance domain and I came into this role with a technical background. The business advised that to jump in my career, I should gain domain expertise. I pursued an academic degree in insurance which taught me much of what she needed to know and helped me understand my customer’s perspective. I chose this academic path because the SMEs I was working with all had it. The rest of the domain knowledge came from experience with different projects.

Laura: That sounds like a great piece of advice. If domain experience is required to advance your career, talk to experts within that domain about what training and education they would recommend. I can imagine each domain would have different requirements.

Durga: Yes. It really made a difference in how I am respected within this organization.

Laura: Tell me about business analyst training opportunities and how that helped your career.

Durga: I was lucky that early in the formation of the business analyst role at this organization, they provided fairly comprehensive training on how to be a business analyst. That training provided a solid base to start working within the role. We learned how to elicit requirements and convert requirements into a language that technical professionals could work easily with. Such a training session sets a strong foundation towards developing strong business analysts in the organization.

Laura: What advise would you give to new business analysts?

Durga: As a new BA, I advise you to leverage others’ experiences. Allow experienced people to help/guide you learn how to use the BA skills and techniques to improve how you do things. Also network extensively to meet BAs outside your organization because you can learn so much from their experiences. My mentor always used to tell me “Learn from the mistakes of others. You can’t live long enough to make them all yourself.”

>>Are You Ready to Hit “Go”?

Start your business analyst career with our free step-by-step career planning course. Upon joining, you’ll also receive our BA career planning guide and follow-up insider tips via email.

Click here to learn more about the free course

When it comes to building a career, there are dozens of reasons to find your way into business analysis. You are a good communicator, you seem to get the business and the systems side of things, you make a lot of positive things happen. You become a business analyst. You excel at your work. You become a senior business analyst. But then you stop and say “where do I go from here?”.

There are many answers to this question. In fact, there are as many answers to this question as there are people bold enough to ask it. Careers paths are personal decisions. What that means is that it is up to each and every one of us to define our career path based on our strengths and our passions, independent of our employer’s promotion path (assuming you are lucky enough to have one) and specific career options.

It’s what smart employees do.

It’s what promotable business analysts do.

That said, there are some career options we generally see BAs fall into as they move up the proverbial ladder.  (Of course, there’s a whole other list of promotion paths within business analysis…You don’t have to leave us to move up.)

• Business Analyst lead or manager (being able to lead other BAs takes many new skills)
• Project Manager (We hate to admit it, but it’s true in many organizations the PM is the senior role. However I’ve also started to learn about PMs wanting to be promoted to BA.)
• Business Architect (Read Pat Ferdinandi’s story about being a Business Architect or “Chief Thought Translator”)
• Enterprise Architect (a combination of up-to-date tech savvy and business analyst skills would make you extremely marketable)
• BA Coach / Mentor
• BA Trainer (A favorite of yours’ truly!)
• Product Manager (product management and business analysis share many competencies)
• Content Developer / Content Strategist (think about the content behind a site like Amazon and what analysis goes into bringing it all together and you’ll see what I mean)
• IT Manager or other IT leadership role
• Blogger / Author (this is one of the paths I’m obviously exploring!)
• Independent Business Owner / Entrepreneur (start your own business, possibly even one supporting business analysis, like Adam Feldman did)
• Business Operations Manager / Director (leading a business operation takes many BA capabilities)

The host of activities involved of business analysis prepares you for a variety of roles across the organization and to take on a host of new responsibilities. I’d also go out on a limb and say that the best of you as a BA is also going to the best of you in another role. The best CEOs and CIOs I’ve worked with would have been very good business analysts earlier in their career. They brought a level of analysis, thoughtfulness, and essence to their work that few leaders I’ve worked with have done.

In discussions about the role of the business analyst, it is common to see professionals insisting on the importance of “going beyond requirements” when describing the BA work. These analysts argue that BA activities such as enterprise analysis and process improvement indicate the need for a broader description. Being myself a consultant who often works in activities related to business process modeling and process improvement, I fail to see the benefit of moving away from the term “requirement” when describing the work of a business analyst, and here I explain why.

The IEEE Standard Glossary of Software Engineering Terminology defines requirement as:

1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).

The BABOK provides a very similar set of definitions (differences underlined):

1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).

Simplifying a bit these statements, it is possible to define requirement as “a condition or capability needed to achieve an objective” (solving a problem can be considered an objective–something toward which effort is directed–, and therefore doesn’t need to be explicitly mentioned here). Based on this definition, it becomes easier to view “requirements” as the core aspect of the business analysis work–even for BAs who don’t belong to the IT space.

Take, for example, business process modeling activities. Process modeling is used to generate a visual representation of the flow and control logic associated with a sequence of related activities or actions. A process model, however, is not an end on itself: models may be created to better understand how certain business scenarios are handled, to help identify problems in the flow, to detect activities that don’t add value to the business, etc. Process models, in most cases, become a source of requirements, helping the organization (and, in particular, the business analyst) identify the conditions or capabilities needed to solve a problem (for example, a bottleneck, or errors caused by a faulty interface between business units), or to achieve another objective (e.g., increase productivity by reducing the time to perform a task or eliminating the wait time between tasks).

Business analysts exist to facilitate organizational change. They study business problems and opportunities and recommend solutions to help corporations achieve their goals. In doing so, BAs are constantly involved in discovering, identifying, analyzing, negotiating, and documenting requirements that address business problems and opportunities.

One of the topics that appear to be on the mind of many business analysts lately is the expansion of the business analysis role. How can a BA make a difference in his/her organization, perhaps going beyond conventional analysis to become a visionary? What are the challenges a BA may need to overcome to respond to the increased expectations of companies who hire business analysts not just to manage requirements, but also to perform project management and participate on decision-making processes?

Questions like these reflect the natural desire that business analysts have to better understand their role and focus on the development of the skills that will not only support their career goals, but also generate the most value for their organization.

Obviously, there isn’t a one-size-fits-all answer, but one thing that may be helpful for BAs pondering these questions is to remember that the most value a business analyst working in the IT solution space can offer to an organization is to excel in the processes related to the discovery, analysis, negotiation, and validation of the requirements of a new or modified software system. End users, project sponsors, subject matter experts, project managers, etc., all get involved in the process of eliciting requirements, but the business analyst (regardless of the job title he or she has) “owns” the requirements processes, and is responsible for making sure that the requirements adequately and completely represent business and user needs. To be truly effective, a BA must consider the project requirements their primary concern, from the development of a product vision and scope to detailed user and software requirements specifications and the change control processes that will be used to manage requirements during the lifetime of the project.

What about blended roles, then? It’s normally hard for a single person to balance goals like getting the project done on time and budget vs. delivering the right product. In my experience as a consultant, the most successful projects typically have a business analyst and a project manager working together to accomplish project goals. Activities such as planning the work to be done, identifying and securing necessary resources, determining tasks that must be completed, assigning the tasks, delegating authority, tracking progress, etc., are the responsibility of the project manager, while the business analyst remains in charge of producing consistent, complete, feasible, truly needed, accurate, traceable and verifiable requirements.

I see the “expansion of the business analyst role” as a double-edged sword. The consequences can be favorable if the intention is, for example, to involve business analysts in enterprise-level activities related to identifying gaps in organizational capabilities, developing models to describe the desired future state of the organization, or performing other tasks that allow BAs to deepen their knowledge of business goals and contribute to the formulation of business transformation projects. If, however, instead of aiming to get more from their analysts’ skills and capabilities by extending their involvement across the enterprise, the organization is simply trying to cut costs by having the business analyst simultaneously act as project manager, tech lead, or QA tester, there’s a substantial risk that the change will result in loss of value and quality of the output provided by the analyst, which in turn may result in extensive and expensive rework, or contribute to the already high statistics of IT project failure.

While discussing the BA role in their organizations, business analysts must be ready to fight unwarranted assumptions, needless compromises, and wild guesses about the responsibilities they have and the contributions they make as part of a solution team. An experienced business analyst is typically busy throughout a software development project, bridging the gap between the business and the technology teams, determining changes in processes and operations that need to take place as a consequence of the new system, investigating and advising on the project’s impact on other systems and initiatives across the enterprise, and so on. While BAs working for smaller organizations (or dedicated to smaller projects) may be able to successfully wear multiple hats, the acceptance of additional responsibilities, particularly when in conflict with business analysis core responsibilities, can have devastating consequences for both the organization and the analysts–a few of whom may even find themselves victims of the infamous Peter Principle.

To borrow the words of Laura Brandenburg,

I do think we need to balance our desire to help with an understanding of what it takes (in terms of time, effort, and focus) to be the best at what our core responsibilities are. It can be tricky… but sometimes it is better to “just say no”.