|
Published:
July 22, 2013

Business Analysis For Dummies

Overview

Build a successful career in business analysis 

When it comes to doing good business, change is a very good thing. And effective business analysts are at the heart of identifying opportunities for growth and implementing the solutions that can transform an organization’s foundation—and ultimately increase its profitability. Whether you’re an aspiring business analysis professional or a seasoned analyst looking for the latest techniques and approaches, Business Analysis For Dummies helps you discover the newest tips and tricks for turning knowledge into the changes that have a real and meaningful impact on business and drive your organization towards value delivery.  

  • Identify areas for growth and create solutions 
  • Learn how to bring people together to collaborate effectively 
  • Discover ways to better understand and serve your customers 
  •  See how business analysis works in the real world  
  •  Learn the technology to make the job easier  
  • Find business solutions to improve your organization’s performance 
  •  Understand how to dig deeply into your organization’s data, processes, and business rules 

Dummies makes the path to business success clear. Start here to turn your love of business analysis into the catalyst that makes a difference.  

Read More

About The Author

Ali Cox has decades of experience in business analysis, agile, project methodology development and training, and systems development. As Lead Expert in Business Analysis + Agile for Netmind, she provides training and mentoring for businesses ranging in size from a single team to Fortune 500 companies worldwide.

Sample Chapters

business analysis for dummies

CHEAT SHEET

Business analysis is a profession, or a set of methods, tools, and techniques, or a role, or a combination of all of these. Your role as a business analyst is critical for successful delivery of value to your customers, whether those customers are external or internal to your organization.You can use business analysis concepts, tools, and technique across your organization to help it to respond quickly and effectively to changes in your world, your environment, your markets, your customer base.

HAVE THIS BOOK?

Articles from
the book

Aside from fulfilling a business analyst (BA) role at a company, you may have the opportunity apply your various business analysis skills to other roles. You can parse out individual business analysis skills to make yourself more marketable, take advantage of opportunities, and meet a company’s specific needs for growth and improvement.
When verifying and validating solutions, you perform a requirements review, a structured audit in which you give participants the opportunity to ask questions and make suggestions in order to improve the quality of the product being reviewed. Keeping the requirements review session moving forward is the facilitator’s job; because you may be wearing that hat during the meeting, here are some tips for conducting the requirements review session: Put on a thick skin when documents you authored are being reviewed.
Business analysis is a profession, or a set of methods, tools, and techniques, or a role, or a combination of all of these. Your role as a business analyst is critical for successful delivery of value to your customers, whether those customers are external or internal to your organization.You can use business analysis concepts, tools, and technique across your organization to help it to respond quickly and effectively to changes in your world, your environment, your markets, your customer base.
The type of project impacts the categories of requirements you elicit, analyze, and communicate in your business analysis. Remember, no one-size-fits-all list exists in business analysis. Instead, make sure you know all the tools that you have at your fingertips to determine how you will complete your project.
A major business analysis task is overseeing process improvement — identifying, analyzing, and improving an existing business process so the company can integrate processes from mergers and acquisitions, improve inefficient processes, meet new goals, and the like. You can identify areas to conduct process imp
Business analysis projects all follow the same basic life cycle. A project is a set of steps that accomplish something, so describing business analysis activities as part of a project life cycle makes sense. Although each project you undertake is different, and you must always remain fluid and flexible to some degree, business analysis tasks follow a general order: Plan the project.
Collaboration is critical to business analysis success. It’s about working together with other people to accomplish common goals whether you’re all in one location or dispersed across many. To collaborate well, team members must understand the goal and purpose of the collaboration and actively contribute to the efforts by freely sharing info, talents, and context.
Definition tools help you define requirements in your business analysis as productively and effectively as possible. Some requirements are best defined by using only text, while other requirements are better served by graphical or visual definition. Definition tools support one or both of these styles. Textual definition tools If you need to define things like glossary definitions, project descriptions and objectives, and stakeholder analysis information, use a textual definition tool.
On new development or mission-critical projects, several people may perform business analysis work. If so, business analysis planning may be divided among different business analysts. In these cases, the lead or senior BA should work with the sponsor, who has acquired funds to do the project and ensures project alignment with strategic goals.
In your business analysis, you should highlight and compare each option that you’ve considered to the others so the reader is aware that you’ve vetted alternatives. For most options, the comparisons are financial in nature, but they can also include time to market, strategic alignment, feasibility rankings, brand image, company politics or culture, technology response time, customer satisfaction, or any other metric that’s critical to achieving success.
Scope creep is what happens when your project experiences changes and increases beyond its original mission. Your job is to make sure your team stays on track by referring to all your documentation anytime a question about scope comes up. You don’t necessarily have to reject every request for a change; you just have to put each request up against your original documents to see whether it’s a fit.
Before you discount or leap to an electronic or particularly feature-full tool for your business analysis, consider how specific the analysis or collaborative exchange needs to be and whether the technology you have in mind is truly the vehicle to get you there. Don’t make the mistake of falling in love with features you don’t need.
After you’ve pinpointed an obstacle, identify its characteristics to get the whole picture. Is the company compelled to meet certain requirements, or are they merely suggestions? What’s the risk to the company of not complying versus changing processes or products so that it does? What exactly are the guidelines?
When taking on large business analysis projects, stakeholders are often tasked with double duty for their current daily job as well as this new project. For that reason, building rapport with stakeholders is crucial. Show them that they are appreciated and respected. Here are some ways to foster trust and respect among stakeholders: Make the best use of people’s time.
Within the requirements section of your business analysis, you should be sure to include a subsection for business rules. These rules are key to the way the business runs, and you need to spend some time focusing on them. Whether implemented in a technology solution or not, business rules define the way that a business works.
In a business analysis report, you want to break down requirements into four core components: data, process, external agents/actors, and business rules. This will allow those stakeholders reading your report to zero in to their own specific area of expertise. Data is information that frequently gets stored. Whether it’s big data (such as volumes and volumes of multimedia or real-time information) or small everyday data (such as invoices, billing, sale projections, and personnel records), requirements for business data define what each piece of data is, what it’s for, what it means, how it’s represented, and what relationship it has to other pieces of data.
In a business analysis report, you should have a subsection of the requirements section dedicated to external agents and actors so that you can better zero in on that aspect of the business. An external agent is the first person, organization, or system identified in requirements. Typically identified during the very early scoping part of a project, external agents are those with which the business area interacts.
Your business analysis should break the requirements into four major core components: data, processes, external agents/actors, and business rules. A process is something a person or thing does that gets stuff done. It’s the collection of individual steps, activities, or other processes that together transform data and achieve an end goal (for example, “pay vendor invoice” or “find a local doctor”).
Requirements have attributes that make up and define the requirement. These attributes ensure that the stakeholders in your business analysis get what they need from the requirements. Not every stakeholder needs to know all the various attributes, however. Categorizing requirements lets you help stakeholders access just the information they need from all the information that surrounds a requirement.
Forget everything your creative-writing teacher taught you in middle school; being predictable and repetitive when you’re eliciting information is good in business analysis! When eliciting, use the clearest communication you can. Make your sentences concise and complete. Avoid long sentences that keep going on and on and on and don’t end and have multiple clauses that keep linking together and leading to a difficult way of interpreting the sentence (sort of like this sentence).
Not only do you need to identify the sources within an organization that you need for your business analysis, but you also need to choose an approach with which to elicit information. You can use 11 major elicitation techniques to draw information from your stakeholders: Document analysis: Look through existing documentation to figure out questions you want to ask stakeholders during your elicitation sessions.
The communication tool or method you choose should be appropriate for the audience, content, purpose, and message giver of the communication (as a business analyst, you may create communications for others to deliver). When evaluating communication tools, consider the following: Number of people involved: What works well for 10 people may not work well for 80.
As you gather all the information about the people, project characteristics, and process, your business analysis plan takes shape. It determines how you go on to elicit, analyze, and communicate requirements, as well as what working products and deliverables you develop. By the time you’re creating your work plan, you’ve determined the tasks to complete your deliverables, including estimates of your time and your stakeholders’ time.
Interviews are probably the most-used elicitation technique in business analysis for a couple of reasons: They’re so easy to do (the business analyst asks a question, the stakeholder responds), and they can be done any time the business analyst and a stakeholder get together, whether in person, over the phone, or via e-mail.
Validation testing as part of the implementation phase of your business analysis project is your chance to review your project deliverables to make sure they Meet the project objectives or requirements and the overall needs of the organization Are within the project scope Conform to organizational standards and strategies When you get to the phases that require you to perform validation testing, you want to start with a usability test.
A requirements review is a structured audit within the business analysis process where participants ask questions, make suggestions, and improve the quality of the product being reviewed. When multiple people play a role in improving the quality of the artifacts under review, the result is a better product. You can conduct a requirements review at anytime during the course of the entire project.
Test cases are step-by-step instructions, including specific inputs and conditions, that testers follow to validate the system’s functionality as part of the business analysis and implementation. They also include the expected result. You and the project team can create hundreds — if not thousands — of test cases when supporting the testing effort.
A use case model is a business analysis presentation of the steps defining the interactions between a user (called an actor) and a system (usually a computer system). It details the interactions and sets the expectations of how the user will work within the system. The use case model consists of two artifacts: the use case diagram, which is a graphical representation showing which actors can operate which use cases, and the use case description (sometimes called the use case narrative), which is the text-based, detailed, step-by-step interactions and dialogue between the actor and the system.
Not all business analysts are screen designers, so you may find creating a mockup a bit challenging. In fact, a field of study called human factors engineering concentrates entirely on the interface between man and machine, which clues you in to how complex it can be. If you can’t consult a human factors engineer, use the best-in-class applications as your base.
After the business has decided a problem is worth pursuing in its analysis, you should create a problem statement. A problem statement is the conglomeration of four key elements into one expression to convey the issue at hand: Root cause problem Impacted stakeholders/product users Impacts of the issues Effects a successful solution must include The problem statement is a critical component of a project’s statement of purpose or charter.
A solution (or product) position statement is a description and positioning of a specific solution approach in a business analysis. It generally follows the format of “For the target audience of U who need V, the new product W is a solution that will do X. Unlike alternative Y, our solution does Z.” An important element of a good solution is that it solves a real problem worth solving and ultimately provides value back to the audience using the solution.
Your unique responsibility as a business analyst is to write and communicate excellent requirements. This job is important because requirements consumers depend on the requirements in order to effectively design and construct solution components. Excellent requirements leave no room for interpretation, create no cause for confusion, and omit no critical detail.
Sometimes, trying to explain what’s within the scope of a business analysis by using just words becomes very difficult. That’s where a scope diagram can be helpful. Instead of just taking notes, you can actually structure your findings graphically in a scope diagram to help you make sense of everything. The scope diagram has three parts: The rectangular boxes represent external agents (or actors).
Whether public, private, or nonprofit, a business serves a market, executes a mission, and — presuming all goes well — fulfills the vision that the leaders have set for that business. Throughout the course of operations, business leaders set goals and objectives for their enterprise, and they rally teams to work hard and deliver on them.
Business requirements are derived from the needs of the business; a good business analyst will recognize that they’re the things that must be in place to benefit the business or enterprise as a whole. They characterize and quantify outcomes desired for the business, and document what business the business decides to be in, what products the business will offer, or what markets the business will expand into or exit.
Needs and requirements may look like they mean the same thing, but there’s a difference when it comes to business analysis: The need is the objective, and the requirement is the decision about whether to do something to achieve that objective. A need turns into a requirement when someone recognizes that having the unmet need is unacceptable and decides he requires the need to be met.
Solution requirements in a business analysis specify the conditions and capabilities a solution has to have in order to meet the need or solve the problem and provide clarity around delivery needs. They don’t define how the solution will solve the problem technically or specifically; that happens later. Solution requirements must meet or support the driving project and business objectives, in addition to meeting stakeholder objectives.
Stakeholder needs in the business analysis are similar to business needs in that they also collect and describe information about business goals, strategies, objectives, targets, and key concerns about successes, challenges, issues, risks, and problems. Whereas business needs describe the needs of the enterprise itself, stakeholder needs describe what a specific stakeholder or stakeholder group needs in order to support the business.
In any business analysis, requirements that describe the needs or problems of the stakeholders in achieving or supporting their goals — whether related to organizational or operational concerns — are stakeholder requirements. Just as stakeholder needs and business needs look alike, stakeholder requirements look an awful lot like business requirements.
In business analysis, transition requirements define any and all temporary capabilities, conditions, or activities that are necessary for moving solutions out of development and into real-world business use. They do the following: Describe what has to be done with people, process, and technology before you can get from the as-is into the to-be.
After you’ve inventoried your current situation, identify the business analysis and other activities your team needs to perform as you collaborate on your project. What does your situation look like after you implement a tool? Look for gaps or challenges where you think your team can use additional support to become more productive — especially if you need to perform activities while separated by time or location.
As the business analyst, you’re charged with finding out how well each stakeholder is completing his job and how well his needs are being met so that he can do his job. After all, each stakeholder — department, group, or leader — has a specific part to play that’s in line with a company’s corporate mission: Deliver effective operations, enable innovations and creative problem-solving, or provide valuable products and services.
You don’t want to waste time in your business analysis putting a solution in place that doesn’t solve the problem, but you definitely don’t want to waste time solving a problem that doesn’t matter! Internally, ask whether it matters that the problem-sufferer has a problem. If it does matter, why does it matter?
In your business analysis, you must consider the needs of a company by interviewing company leaders. Just be sure that when looking to discover these business needs, your research is focused within the context of what the business is trying to achieve or do, not just on what the leaders are trying to do. If you let your team start working on solutions that meet stakeholder’s needs without making sure you’re serving an important business need, your project may not be the best investment.
Most of the time, you can’t fly all around the world to fabulous international destinations to interview all the stakeholders in your business analysis. So how do you gather information from 4,000 users worldwide? Create a survey (some call it a questionnaire). How do you get them all to respond to the survey?
When you write business and stakeholder requirements in your business analysis, you want to capture the problem or opportunity and explain what has to be done (rather than how you’re going to solve the problem or take advantage of the opportunity). As the person performing the business analysis, you’re generally the main person capturing the business requirements because you have a unique ability to drill into the real problem or opportunity rather than just gather a solution request (which is why your process is called “elicitation” and not “gathering”).
Functional requirements section of the business analysis answers the “how” questions, such as “How are we going to change the process? To answer these kinds of questions, your functional requirements should include the following info: Design area scope: The scope of what will be included in the design. Solution design may take on both non-automated solutions (like adding more people to the business area or redesigning the manual process) or automated solutions (creating a mobile app to allow people to order takeout food from a restaurant, for example).
Nonfunctional requirements are just as important to your business analysis as the functional requirements when it comes to defining the look and feel of the solution. Nonfunctional requirements are a challenge because different people interpret them differently from organization to organization (or even from department to department in the organization).
Business drivers are entities that have a major impact on the performance of a specific business, and identifying them is critical to scoping your analysis project properly. Business drivers Reflect the performance and progress of your business Are measurable Can be compared to a standard, such as a budget, last year’s figures, or an industry average Can be acted upon You need to make sure that your scope and the identified problem/opportunity align with the business drivers.
Traceability shows the analyst how the business requirements have been satisfied by functional requirements and ultimately through the technical requirements. Consider the traceability matrix below. It shows the business processes on the rows, from a business perspective, and how they’ve been addressed with the functional requirements in the columns.
Even if the problem you’re trying to solve in your business analysis is painful, you also have to consider what potential business risks and value potential lie in this problem or opportunity. In any decision-making situation, you have to consider two factors: costs and benefits. By identifying pain, you’ve found the source of costs.
Before you invest a considerable chunk of cash or time on a productivity tool, be sure your analysis considers what it’s really going to cost you and where the budget will come from. The initial expense or “purchase price” of your productivity tool may be the most visible financial component, but it’s not the only financial component.
After you’ve discovered your transition requirements, assessed the organization’s readiness, and addressed motivation and competency in your business analysis, you’re ready to choose the approach you want to use to roll out your strategy and actually implement the solution. Note that this phase of the project includes the entire team; it’s not just you and the users of the new solution.
Regardless of how great your business analysis solution is, the individuals impacted by it determine the success or failure of your project, so a big part of your change management plan is managing stakeholders’ experience with change. Failing to address the human side of change can easily result in a failed project.
People want to work with those they know and share similarities with. Communication is easier (and problem-solving is just faster) when individuals have good relationships. You can better manage tasks when you’re familiar with the team members’ strengths. Therefore, a key way you can foster success is to get to know the stakeholders beyond just knowing their titles and roles in the organization.
The type of question you ask as a business analyst determines your source, so after you have your type of question figured out, you know who to go after! At this stage in the game, you may not have actual names of stakeholders; you may only be able to identify your sources by titles or positions. Review the company’s organization chart and ask questions about any positions that are unclear.
Project size is a big factor in determining what tasks you undertake as a business analyst and how long you take to complete them. Factors to consider are the number of features you need to deliver, the number of people you’ll interact with, and the number of people that will use the solution. Eliciting requirements from 1 stakeholder is less time-consuming eliciting than from 50.
When you’re scoping a business analysis project, you want to be able to find all the interfaces that are part of the project. You need to consider three types of interfaces: user, system, and hardware. Look to the data flow diagram and use case diagram to find interfaces. In a data flow diagram, the curved data flow lines from external agents are your interfaces; people are user interfaces, systems and external organizations are system interfaces, and pieces and hardware are (you guessed it) hardware interfaces.
The business analysis project participants also have project-related roles and duties that are separate (although related) from their professional responsibilities. Just like actors in a play, stakeholders have roles in the project. Someone may have the title of Retail Sales Person Level 1, but they’re the subject matter experts for the retail sales project, which ends up being their role in the project.
The key to finding the right tool for your business analysis is identifying the kind of support or productivity boost that would be right for you by inventorying the situation you have now and determining what situation you need or want to have later, while being sure to avoid unnecessary tools. You also need to consider team size and budgetary constraints.
Business analysis solutions deliver or help stakeholders achieve outcomes. People don’t create or use solutions just for fun; they do so because the solutions bring notable value. Commercial solutions find success when they provide so much value that people see it, appreciate it, and are willing to pay something for it.
The use case diagram is a visual scoping tool you use as an analyst to plan the boundaries of the business system that you’re analyzing, the expectations of the system (the use case name), and the potential user of the system. It’s a very useful diagram because it gives the project team a high-level view of the solution scope and allows you and the designer to consider multiple implementation strategies.
Properly managing a requirements workshop is essential to your business analysis. Info and ideas constantly fly business analysis back and forth during workshops, and if you don’t capture them, they disappear. Plus, if you don’t keep the conversation focused on the goal of the session and on the right track, you may not accomplish the elicitation needed for the project.
Understanding and analyzing the risks of a business analysis project is an important part of identifying and documenting the project scope. Risks can be project-related and/or business-related: Project risks: Project risks are potential problems that may impede the completion of a project. They include situations like losing a key person prior to the completion of the project or having a team inexperienced with a commercial off-the-shelf tool (or COTS tool, a pre-packaged, one-size-fits-all solution that may or may not have the ability for customization).
Good communication skills are vital to a business analyst’s success. We live in a time when so many barriers — some of which even seem to be socially acceptable — hinder communication. The more you understand how these obstacles can get in the way, the more you’re prepared to overcome them and be a great communicator.
After you’ve designed all the questions for your business analysis research, it’s time to arrange it all into a master plan. You’re ready to lay everything out so you can move forward and get the information you need. The plan is also vital for keeping everyone on the same page and keeping your session — and therefore, the project — on track.
In starting your business analysis, you’ve evaluated your needs, identified your options, and selected the best tool for you. Great! Now what?! Do you just go forth and implement? In some cases, perhaps (certainly if they’re small tools). But the large, high-tech, enterprise-wide tools are complicated, and they need to be implemented with care for true success.
The details section of a business case provides all the supporting documentation and diagrams for the recommendation that results from your business analysis. You usually include only the details of the recommendation, but you may want to add details of some alternatives if they were close in comparison or the audience may be interested in seeing them.
The verification and validation test plan portion of a business analysis describes how a software product will be tested. Make sure to include the following sections in your verification and validation plan. Introduction Start off by explaining the test and describing the objective of the project. Remember to keep it short.
As a business analyst, you must work with your stakeholders to create the appropriate scope. The more people you bring into your scoping sessions, the better. Involving all the people or representatives that are affected allows for a greater perspective on the project; you get different opinions from different people during the scoping process.
Who participates in the reviews of your business analysis requirements depends on whether the review is formal or informal and on what kind of data/information you want feedback on. We mention a lot of different potential meeting participants, but managers are nowhere to be found. In most cases, managers shouldn’t attend review sessions because They can change the behavior of a room.
All your work defining and framing the right solution in your business analysis has probably created expectations around what it is and what it will most likely look like. You’ve clarified and articulated the problem; you’ve identified different solution options; you’ve figured out some key features necessary for the solution to be valuable and right; and you’ve positioned them accordingly with a powerful solution position statement.
A business analysis message is only as good as how it’s received. Take the time now to get familiar with the ins and outs of different stakeholders; it pays off in dividends down the line. How to work with executive sponsors as a business analyst On a project, the executive sponsor is the your most important stakeholder.
After you finish the usability test portion of your analysis of project implementation, you want to test the interface with people who will actually be using it. How to conduct a user acceptance test The purpose of the user acceptance test (UAT) is to show adherence to the project objectives, not to find bugs or software defects.
The genuine problem or opportunity that the business seeks to address in their analysis is the root cause problem, and it’s not always that easy to uncover. You typically have to ask a lot of questions to get down to that root cause because your stakeholders often report symptoms rather than the real cause. A business analyst’s best question is “why?
Communication is key in any business analysis project. Most people believe that words are the communication of the message when, in fact, words make up only 7 percent of the message. Tone of voice and nonverbal communication make up the other 93 percent. As a business analyst, you should be familiar with the positives and pitfalls of common verbal and nonverbal communication, such as the following: Be precise, direct, and accurate in your communications.
No matter which stakeholder or project team member you’re working with as a business analyst, you need to understand active listening in order to be a great communicator. Communicating is vital to a business analyst’s success, but sometimes people forget that listening is just as important as — or maybe more important than — talking.
Process in business analysis refers to the project processes that are in place at the company where you’re working that you can use as a guide. There are four different methodologies: waterfall, agile, spiral/rational unified process (RUP), and rapid application development (RAD)/evolving prototype. As the business analyst, you must figure out what needs to be addressed when planning under these project processes.
You use decision tables to help analyze and communicate a company’s business rules. They’re a great way to show and clarify complicated business logic, particularly when you need to help stakeholders understand how different values work together to create a conclusion. Decision tables also help identify conditions you may not have thought out, so be on the lookout for conditions for which you have no conclusion.
Document analysis is probably your first stop in elicitation for business analysis. Here, you peruse company documents to glean information about the current environment. Why go off and try and create something new without understanding what the company’s operations are all about? You don’t go into a job interview without understanding the prerequisites and skills needed for the job.
If you’re looking for a way to define how data is set up in your business analysis system, you’re going to love the entity relationship diagram (ERD). The ERD helps you organize and document the various data entities and their relationships to one another within the project. The ERD is primarily a tool to help you communicate with the data analyst on the project.
Even though observation methods for business analysis are pretty simple, there are three different approaches you can use for observing a business user in action: Pure observation without interaction: In this model, you simply show up, remain quiet, and watch the person work. Observation with interaction: Here, you do get to interact with the person who performs the job.
The process decomposition diagram (often called a decomp) explains the breakdown of processes within a project or business area or functional area. The purpose is to show all the processes and identify relationships and dependencies among them. Note that a decomp doesn’t drill into the how; it merely outlines the what.
A prototype is a model of a user interface (UI) in an automated system. For your business analysis, the prototype may be the user interface for a full system or a screen layout, report layout, or data entry form. The project team builds the prototype to demonstrate to stakeholders what the automated system will look like.
Requirements workshops, also known as JAD sessions, facilitated workshops, or work sessions, are well-structured, intensive workshops in which an independent facilitator (the business analyst) leads participants to develop high-quality work requirements (or products). The requirements workshop is one of the best techniques to use if you want high-quality requirements in a short amount of time.
One of the most frustrating things that can happen between two parties is that they think they’ve reached understanding and agreement about the business analysis when they really haven’t. In those cases, both parties may walk away from the initial conversation thinking they’re talking about the same thing but later realize they were talking about two distinctly different points or different levels of acceptability or achievement within the same points.
A workflow diagram (or workflow) is a visual way for your business analysis to show how work gets accomplished. Workflows are composed of a set of symbols that show how various workers accomplish tasks and interact with each other, as well as how information (data) flows through the business area. These diagrams have been around for a long time and come in many varieties: Swimlane: This workflow diagram focuses on interactions between organizational units and exposes bottlenecks and process inefficiencies ANSI flowchart: This style grew out of flowcharting in the 1970s and became the first standard for workflows.
The data flow diagram is a helpful diagram for business analysts that shows the parties and systems involved with a particular process, as well as the data and interfaces involved when dealing with external agents (those parties or systems that exchange information with the project but over which your project has no control).
Verification is what most people think of when they hear the word testing — it’s the process of testing whether a business analysis solution does what it’s designed to do. During verification, the testing team (which may consist of developers, quality assurance [QA] people, and some business analysts [BAs]) put the software through its paces to both confirm that it operates as expected and ensure that it conforms to the design specifications laid out earlier in the project.
As part of a business analysis, a business case outlines an opportunity and a recommendation to invest resources to take advantage of it. Think of the business case as your marketing or sales brochure for your idea. It may be your one shot to get approval for a project that may have a significant strategic, structural, or political corporate impact.
Cost/benefit analysis is an estimation and evaluation of net benefits associated with alternatives for achieving defined goals of the business and is the primary method used to justify expenditures. It’s also a critical piece of the business case. You may or may not need to include a detailed cost/benefit analysis for each alternative in the business case.
You may or may not need to include a detailed cost/benefit analysis for each alternative in the business case. Some opportunities may warrant having just the final recommendation fully documented in this section. The audience and the opportunity drive the level and complexity of the details required. A good rule of thumb is that, if the recommendation is obvious to and will mostly be accepted easily by all individuals responsible for approval, you can simply include the details for only the final recommendation.
Business analysis is a useful tool because companies can lose a lot of time and money chasing ideas and testing concepts in the pursuit of innovation, so they need to successfully identify and distinguish the good ideas from the not-so-good as efficiently as possible. Innovation and idea capture tools capture and categorize information at any level and allow companies to get really good and important ideas identified quickly and easily.
In prototyping, you create a model of the proposed solution. In business analysis, a prototype, or mockup, generally means a representation of a computer screen and examples of how the user will interact with the application to accomplish a task to solve the business problem. The business analyst creates the prototype, usually with help from the technical team.
Reverse engineering refers to looking at the solution to figure out how it works. Basically, you you’re your business analysis backward from the solution to understand the data, processes, and business rules. Reverse engineering is more common than you think. Have you ever looked into a Microsoft Excel formula to figure out where it’s coming up with the calculation?
Dwight Eisenhower once said, “In preparing for battle, I have always found that plans are useless, but planning is indispensable.” Of course, business analysis isn’t quite the same as war (usually), but the main idea of this quotation still applies: Going through the process of planning is a critical task; actually documenting a plan is less critical (although in some cases it may be required).
Although many teams nowadays have one person function as both the project manager (PM) and business analyst (BA), a lot of teams still have different people performing those roles. One of the challenges on a project with a separate BA and PM is clarifying the responsibilities between the individuals. Because you and the PM interact with the same stakeholders, you both need to be very clear on what roles each of you’ll play during a project.
A business impact analysis (BIA) is a business analysis tool that helps you predict how significantly your project will impact the business. You use it to gather information about the project's various elements, players, and entities so you can determine the depth and breadth of your potential efforts. Here's a worksheet to help you complete a BIA.
In business analysis projects, plans become outdated as soon as you start executing. As you discover new information about the people, project characteristics, and process, those changes impact your plan. Things may change from minute to minute, so your plan can only be as good as what you have now. Here are some tips to help you deal with the unforeseen: Tell your team right away about any changes you have to make.
Requirements management tools initially came about to support larger companies in their business analysis. Projects so often went over schedule and budget or came under their scope that companies demanded answers. What was going wrong? Problem analysis identified requirements as the root cause of the delivery issues.
To get your stakeholders to reveal the real issues for your business analysis, you have to do a bit of hunting. Stakeholders aren’t just sitting like ducks in a row around the conference table with all the problems and answers outlined for you on a nice, neat, big master list. Chances are that each person has a different perspective of what’s wrong and how to fix it.
The first step in developing questions for your business analysis that really get to the problem or opportunity is to figure out which type of question — “what,” “how,” “why,” “when,” or “where” — you want to ask based on the information you need to obtain. To determine which kind of question best suits your purposes, consider what you already know, what you don’t know, and what information you need to get started.
“Why” is such a powerful question that it’s the basis for a root cause analysis technique called the 5 whys. The thought is that by the time you ask a stakeholder “Why?” 5 times, you generally have arrived at the root cause. Consider this example: Q: “Why did you submit a purchase requisition for $750?” A: “Because we need to purchase 150 staplers!
In the business analysis profession, there is no one-size-fits-all solution. As you develop your project type, you need to know all the tools available to you; think through all the variables related to the people, project characteristics, and the process; and then determine what tasks you need to complete. Data warehouse projects A data warehouse is a solution that brings together information from diverse sources and puts it in a format that stakeholders can easily access when making complex business decisions.
Several tools facilitate urgent transfer and delivery of messages in business analysis. These choices are good for situations where you can’t be face-to-face in the moment but still need someone’s real-time attention: Text messaging: Great when you just need to share information quickly or ask an immediate yes/no/opinion question that really can’t wait.
Documents useful to business analysis can be many things in many formats, from actual printed documents to printouts of screenshots to websites and blogs containing company and department information. Old doesn’t necessarily mean worthless. Even if a document is a bit long in the tooth, you can still use it as historical data and check to see whether the processes and data it mentions are still valid.
When you’re involved in process improvement projects as a business analyst, a key task is to take time to define the metrics you’ll use to measure success. The measures differ, depending on the industry and what you’re trying to improve, but the important thing is to make sure you have enough time to discover the baseline measurements and then calculate what the measure of success is.
https://cdn.prod.website-files.com/6630d85d73068bc09c7c436c/69195ee32d5c606051d9f433_4.%20All%20For%20You.mp3

Frequently Asked Questions

No items found.