How to Become a Business Analyst
What Is Business Analysis?
Business analysis is the practice of “enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders,” as defined by The International Institute of Business Analysis – one of the largest professional associations for Business Analysts. That’s pretty clear in terms of what business analysis tries to accomplish – but what about how they do it?
Business analysis is a research-driven practice that “delivers value” in three main ways, all of them predicated on using data to identify different aspects of a business’s operations – namely, its needs, the problems it faces, and the opportunities open to it.
Even more precisely, Business Analysts can improve these three aspects through a wide range of different approaches, such as developing new company policies, making improvements to corporate protocols (that is, to the way things are done internally) and adjustments to the company’s organization (including its managerial structure and hierarchy), and helping to develop and implement new IT systems or even software that better suits the company’s needs. Business Analysts are also an important contributor to a company’s strategy, including the top-level decisions about where and how to invest (or divest) resources, and building the conceptual architecture for new projects – they layout out the groundwork for significant new endeavors to help ensure they have the proper planning in place even before they begin.
Why Use Business Analysis?
Given all the ways that Business Analysts can contribute to a company’s bottom line – whether by expanding into new markets, overcoming hurdles to growth, or introducing new efficiencies – it should be clear why companies rely on them.
You might think of the ways business analysis can help a company in terms of two major categories. The first is primarily descriptive – helping all stakeholders to develop a clearer understanding of the company, its operations, and its goals. A clearer sense of what you’re doing helps to inform and guide decisions at every level. In terms of business analysis, this often focuses on the ways a company is structured and the dynamics of how information moves through it, to identify where and why those dynamics are more or less effective, and to understand how they can be improved. At the highest level, a deeper understanding of what a business does – its strengths and goals, even in the most abstract sense – is the lens through which all other challenges can be approached.
The second category is more directly proscriptive, making specific recommendations about ways individual aspects of the business can be changed, with an eye to improving outcomes. In this, there are as many possible recommendations as there are problems a business can face – more, even. Business Analysts make specific recommendations to help a business maximize its value to stakeholders, with the assurance that those recommendations come backed by data.
What Are the Types of Business Analysis Frameworks?
Business Analysts rely on a number of different mental models or frameworks to help guide their work. While there’s no definitive way to do business analysis, the following seven approaches are among the most popular ways of conceiving the business analysis process.
1. The Five Whys
The “Five Whys” technique is about developing your understanding using a series of interrogations to guide your investigation into the way things work, digging progressively deeper to gain new insights. Like a small child pestering their parents about the way the world works, each “why” questions the cause of the answer given to the previous “why,” building on the one before until root causes can be uncovered. Of course, there can be more or less than five “whys,” but five is typically a good start, as a rule of thumb.
2. Six Thinking Hats
The Six Thinking Hats technique essentially asks you to look at things from different perspectives – to put on different “hats,” conceived as having different colors – to reframe the questions you’re asking. These are typically characterized as:
- White / Facts (looking at the data you have and the data you need in a neutral and objective way)
- Red / Emotion (sussing out your intuition or gut feeling about something)
- Yellow / Logical Positive (examining the situation in an optimistic way, focusing on your opportunities and hopes for a project)
- Green / Creativity (being open to new ideas and areas for growth)
- Blue / Planning (taking an organizational or administrative perspective to understand what has to happen for plans to be successfully executed)
- Black / Logical Negative (looking for flaws in the plan and places where it might break down – in order to avoid them).
All these hats are ruled by the Royal Hat, which takes the top-level stakeholder perspective, holding every decision to the organization’s overarching goals.
Similar to the Six Hats, CATWOE asks Business Analysts to look at a situation from different perspectives. But instead of mindsets, CATWOE’s perspectives are related specifically to different aspects of a business’s organization and functioning – in fact, it’s an acronym for Customers, Actors, Transformation process, Worldview, Ownership, and Environment.
Each of these perspectives poses its own set of questions. For example, Customers – who are they and what do they want? What consequences will a given decision have for them? Or Actors – who is impacted by the situation, both now, during its resolution, and afterwards, including employees, managers, and ownership? By challenging Business Analysts to weigh this spectrum of considerations, CATWOE tries to anticipate each decision’s practical, legal, ethical, financial, and environmental ramifications.
MoSCoW is short for “Must or Should; Could or Would,” essentially asking where on the hierarchy of needs a given consideration falls. Sometimes this is applied to resolve practical constraints, but quite often it’s used to get all stakeholders in agreement on the value of a given proposition. This, of course, rests on plenty of other assumptions. But in general, MoSCoW’s value is in ensuring everyone understands and embraces the same set of priorities, especially as the need for compromise becomes a reality. In short, MoSCoW helps guide decision-making in situations where zero-sum tradeoffs must be made, and to communicate the reasons for those decisions to the people who will be impacted.
MOST is business analysis at its most succinct: Mission, Objectives, Strategies, Tactics. That is, what is an organization hoping to do at the most fundamental level, and how? As you’d guess, MOST is used to develop business plans and mission statements. Mission: what is the purpose of this business or plan? This may be a top-level question, but the answer should be specific. Objectives: what are the individual goals or benchmarks that will make up that mission? Strategy: what’s your roadmap for achieving those goals? That is, what individual campaigns or projects will bring you closer to them? And Tactics: what are the specific steps you’ll take to execute those campaigns? Taken together, MOST helps you work backwards from your ultimate objective to create a detailed, realistic plan for how to get there – without losing sight of that ultimate objective in the process.
6. SWOT / PESTLE
SWOT and PESTLE are both models to help Business Analysts get the lay of the land – to understand as many of the factors that are impacting their situation as possible, in clear terms. SWOT is short for Strengths, Weaknesses, Opportunities, Threats, and focuses first on the organization’s own qualities, and second on the external factors that affect it.
PESTLE is more focused on those external factors, breaking them down not by whether they help or hinder the business, but by the different types of external factors themselves:
Obviously, whether or not all of these factors need to be taken into consideration when making an important business decision depends to some extent on the nature of the business. In general, though, most medium to large businesses will have to grapple with all of these factors on some level.
What Is the Business Analysis Process?
While there is no single process that can be applied universally to all business analysis – the wide range of different conceptual models that guide business analysis can speak to that fact – there are a few stages that most projects go through over the course of analysis. The stages and their names may vary somewhat depending on which process you’re following; there are differing schools of thought, and any given methodology is likely to evolve over time. But while their names can be somewhat opaque and the process itself can be quite complex in its execution, the stages themselves are relatively straightforward.
Steps Involved in the Business Analysis Process
Requirement Elicitation: Business analysis typically begins by defining what the goal is, and what success looks like. That often means research, including interviews with different stakeholders who may not even be able to articulate their needs themselves; the Business Analyst needs to draw this information out so that it can be analyzed, modeled, or otherwise specified. This stage also involves the development of specific metrics that will measure whether a given venture is actually succeeding. With goals and a way to chart progress in place, this stage might conclude with the confirmation of an overall structure for development.
Requirements Analysis: After information is obtained, it needs to be processed and understood. What conditions are we trying to meet? What business needs are we addressing? This stage drills down into that question, examining all the things that need to be defined before they can be incorporated into a plan, including what methods will ultimately be used to organize the research and models that will help shape the rest of the process. The sought-after solutions are also characterized in a general way, but with requirements that are clearly stated, measurable, and testable.
Enterprise / Strategy Analysis: With goals and a rough idea of the plan to achieve them, it’s possible to begin looking at the state of things as they are – the organization’s current structure and direction, its strengths and weaknesses, and what initiatives it will take to move forward. If previous steps introduced the metrics that will measure success, this step takes the baseline reading. What’s the problem, what’s the proposed solution, and is it really the best solution? At this stage, executive-level leadership will likely still be involved, helping to determine how the existing state of affairs will shape the business’s future goals and plans to achieve them.
Solution Assessment / Evaluation and Validation: At this stage, the specific strategies that the business will adopt and execute to reach its goals are evaluated and chosen. What type of solution will best address each problem or need? In answering that question, this analysis needs to include risks, liabilities, dependencies, and any other limitations the business may come up against.
Requirement Planning and Management / Monitoring: Continuing that line of thinking: What are the techniques that will be put in place? What specific list of tasks needs to be completed? Who will do it, and who will lead them? And which tools will they need? In other words, this stage describes what it’s going to take to turn goals into a specific plan of action with enough detail that it can be functionally executed. This is where the development phase truly starts, from defining the key roles on the project team and the way information will be communicated between them to how their work will be monitored and coordinated.
Requirements Management and Communication: Why is this project happening in the first place? This stage helps everyone to understand that – by identifying the business’s needs with an eye to how that translates into a concrete goal, and the scope of the solutions that will need to be effected to reach it. Most importantly, this stage determines how stakeholders will be kept informed throughout the development phase, to keep them on board and on track.
What Techniques Do Business Analysts Use?
Business analysis often relies on conceptual models or maps to help guide their approach to understanding or shaping an organization’s processes, its internal organizational structure, and the tools and technical systems in place to help it do all the things it does – including not only its primary service or product, but also its efficiency in all areas, like hiring and training, customer lifecycle and retention, or adherence to legal requirements.
The model a Business Analyst uses in any given situation will depend on what exactly it is they’re trying to achieve, and which factors they’re evaluating. These are just a few of the most common:
Activity Diagrams: You can think of activity diagrams as a kind of flowchart that shows, in steps, what needs to happen within a given system. These can be of great usefulness when you’re establishing company-wide protocols, for instance – identifying who executes which procedure in a given situation. These are useful not only for macro-level process development, but also for helping Business Analysts understand the individual steps of even the smallest processes they’re trying to improve – what happens when a customer’s subscription approaches its end? How should personnel respond in the case of a system failure? What steps does a user need to go through to log in with third-party verification? Basically, if there’s a task or event that needs to happen, and it has steps, an activity diagram can point the way.
Entity-Relationship Diagrams: Entity-relationship diagrams come into play when a system includes a network of multiple departments, people, objects, or other things that relate to one another in a particular way. This could range from things that are very concrete – like the individuals on a team or the departments in a building – or things that are quite abstract – like a collection of different technical terms where some terms are defined in relation to others, or even the way different business needs affect one another.
Mind Maps: As the name implies, mind maps are used to help visually capture and categorize different ideas or goals in pre-production, especially those early stages when it’s not entirely clear just what a project will turn out to be, and anything-goes brainstorming is still underway. A mind map takes those individual wants and must-haves and organizes them in a way that helps to structure them, understand the relationships between them, and prioritize them according to a sensible hierarchy. Quite often, a mind map is built around a central unifying concept that’s set out before brainstorming begins, which helps to illustrate how different secondary and tertiary ideas are associated, often by depicting them as branches emanating from a central hub.
Org Charts: Organizational charts are a straightforward way to depict a business’s chain of command – the hierarchy of individuals, teams, or departments. Often pyramidal, an org chart typically starts with the boss at the top, with layers of direct reports lined up in successive rows beneath, but mind map–like radial org charts are also common. Cross-departmental communication or accountability can also be indicated.
Process Flow Diagrams: Process flow diagrams effectively illustrate the different steps that it takes to do something, and so are typically most useful in organizations where certain activities need to be executed according to a specific sequence – in manufacturing, for example, where welding happens before painting. But they can also be of use in other types of businesses where sequential organization is important – like with a headhunting, interviewing, hiring, and onboarding process, for example. In fact, any time an activity is governed by a set of rules or follows a specific sequence, a process flow diagram can be extremely useful in communicating to people throughout the organization how that activity should unfold. For a Business Analyst, it’s also a tool to help identify how these activities are carried out, and where they can be improved.
Product Roadmaps: Similar to a process flow diagram, product roadmaps delineate the steps that need to happen for something to take place – but while a process flow diagram illustrates protocols already in place, a product roadmap is a guide to chart future activities (specifically, as the name suggests, how a product or feature will be developed). But while product roadmaps come from the software development world, they’re applicable anywhere a clear and organized plan is needed. One of the advantages of product roadmaps is their specificity – they chart every step and sub-step that it will take to complete a project – but also their adaptability; especially with iterative processes like design thinking or software debugging, where it’s normal to have to go back and repeat steps one or even several times, a product roadmap can keep things on course by monitoring your progress in a way that isn’t a strictly linear path from A to Z.
Kick-Start Your Business Analyst Career
We offer a wide variety of programs and courses built on adaptive curriculum and led by leading industry experts.
- Work on projects in a collaborative setting
- Take advantage of our flexible plans and scholarships
- Get access to VIP events and workshops
Recommended Courses for Business Analyst
The Data Science Full-Time program is an intensive course designed to launch students' careers in data.
Taught by data professionals working in the industry, the part-time Data Science course is built on a project-based learning model, which allows students to use data analysis, modeling, Python programming, and more to solve real analytical problems.
The part-time Data Analytics course was designed to introduce students to the fundamentals of data analysis.
The part-time Machine Learning course was designed to provide you with the machine learning frameworks to make data-driven decisions.
The Python Programming certificate course provides individuals with fundamental Python programming skills to effectively work with data.