The Definition of Business Analysis
Business Analysis is a set of practices that are used to analyze an organization, business unit or business process to take advantage of opportunities or solve business problems. The practice encompasses people, processes, and technology.
The business analyst conducts stakeholder analysis, analyzes the data related any errors, and documents the existing process. In addition, the analyst interviews stakeholders at all levels to determine the goals, objectives and rules in an effort to understand the real problem.
There are several contexts in which you can apply business analysis.
A business analyst may work on enterprise initiatives and projects, and continuously make improvements to the solution.
Strategic initiatives: such as the launch of a new product line or the improvement of business operations.
Write a business case providing the options for change including cost benefit analysis, impact to stakeholders, and new processes in technology.
Tactical work often manifests itself as a minor change to the existing state such as software enhancement.
Operational changes may come about because of new business rules, policies, or external drivers such as regulatory changes.
Business analysis may also apply to a project, which is a process that enables change. A project has a start and end date, and it starts once a business case is approved. The business analyst will then provide more detail of business needs in the form of requirements.
Requirements ensure that the change reflects the business need and they must be clear enough for the project team to implement the change.
Continuous improvement includes changes based on feedback loops. For example, a monthly report on cycle time for processing insurance claims indicates that it is taking longer than the departmental objectives indicate that it should. The business analyst would analyze the process, observe the staff at work, and make recommendations for change or not. The business analyst may discover that there is an anomaly in the data and that no changes are needed.
A perspective is the point of view from which you approach business analysis. There are five project perspectives.
Agile projects consist of constant changes requiring the business analyst to be flexible and modify how they approach the business analyst tasks. Changes are implemented in small iterations, requiring the business analyst to either act as the product owner requesting the change, or to liaise with the sponsor or product owner to deliver incrementally over a short period of time.
The business intelligence perspective utilizes data from multiple sources to provide information enabling evidence-based decisions, reporting needs, or changes to data integration systems. The business analyst must have skills such as data modeling, decision modeling, and knowledge of information dashboards.
The information technology perspective focuses on changes to information technology. The scope varies from enhancements to the implementation of large systems. The business analyst is a liaison between the business and information technology.
The business architect perspective provides the blueprints of the business and managers or identifies changes to business capabilities, processes, and they drive the need for a business case and a project. The business analyst does not typically participate at the operational level.
The business process management perspective is about improving business processes. Unlike the business architect perspective, the business analyst does most of the work at the operational level. The process manager will create an as is process model. And after understanding the business goals, objectives, and key performance indicators, will make changes and produce the to be process.
It is possible for all business analyst perspectives to work on one initiative.
The Business Analyst Role
Business analyst isn't just a title, it's the practices, tasks and activities. For example, if you work with a business to understand their needs for changes to processes or how data is collected, or how technology needs to work in order to get the job done, then you are conducting elicitation tasks.
There are five business analyst activities.
Analyzing needs, which is when the information you receive from the business is analyzed against a desired state, outcome, or goal. If the need doesn't contribute positively to the goal, then the business analyst will document it but advise the stakeholder that the requirement is out of scope.
Analyzing solutions occurs once the business analyst analyses that information and then looks for a solution.
When developing strategies, business analysts need to think critically, look at the big picture, and drill down into details, and then create strategies to address business issues.
Facilitating change is an important task for the business analyst. Some of the key business analyst roles are system analyst, management consultant, and product manager. A system analyst focuses on changes to technology. The systems analyst will write functional requirements describing how the system must behave to reach an outcome. The requirements must be written clearly, in enough details that the project team, designer, programmer, and software quality assurance person understand them, so that the changes can be made to the system.
Ensuring collaboration is one of your primary tasks. Without stakeholders you have no requirements. Management consultants work for consulting firms, which advise companies on the best ways to manage and operate their businesses. The firm will take advice on concepts like their business strategy and operational effectiveness and techniques. Management consultants tend to have specialties in niche markets, for example, in insurance or oil and gas. This type of business analyst will conduct benchmark studies, share best practices, and enable change. A product manager is responsible for the development of new products for a company. A product manager needs to understand how a customer perceives the value from the product. New products drive change.
There are also several other job titles under the business analyst function: data analyst, enterprise analyst, process analyst and business architect.
Business Analysis Value
Business analysis can add value to an organization through improved project management. Expectations are defined when a business analyst helps to find solutions at the beginning of a project. They ensure expectations of the stakeholders are properly set in reality and managed throughout the project life cycle. Then, there are no surprises or disappointments at the other end.
Project scope is managed when the business analysis achieves early buy-in from all stakeholders about the solution's scope, so that the scope of the project doesn't expand. The management of the requirements changes also helps to minimize cost and schedule overruns.
Project goals must align with business goals. The business analyst must understand the organization's problems, goals and strategic objectives. This ensures that as a project progresses, the business analyst can tell when the goal of the project doesn't align with business goals and could actually cancel the project if necessary.
Finally, the business analyst ensures that estimates are dependable. Defining exactly what needs to be accomplished allows the team to develop good cost and time estimates for solutions.
Improved cooperation has several benefits to an organization.
It facilitates transition to production. Transitioning from the old to the new state is difficult for users of the solution, so don't underestimate this. A good business analyst knows how to prepare an organization for the change through training and communication. It's important for users to adopt the new way of doing things as soon as possible, so that the organization reaps the benefits of the new system.
Next, it improves communication and collaboration. One of the main roles of a business analyst is to keep everyone communicating and cooperating, and to facilitate understanding. It starts with eliciting needs, clearly communicating them, and translating them into requirements. Then getting stakeholders to collaborate on the design and clearly communicating the solution to the end users.
Finally, improved cooperation improves efficiency. A business architect advising a program office would ensure that there aren't duplicate projects. A good business analyst can elicit and identify true needs and design the best solution to meet those needs, so that there is no trial and error approach to problem solving, saving time and money. Improved efficiency can be achieved in a number of ways. It prevent redundancies, ensures that you get it right the first time and reduces or eliminates waste.
The business analysis processes is iterative. As you gain more knowledge, more opportunities to improve efficiency may become evident. Taking advantages or these opportunities will lead to continuous improvement. Having detailed rules, processes, and instructions for how to roll out and use solutions also decreases the likelihood of user mistakes, and assists in identifying any defects or errors in the software or service prior to rollout.
Business Analysis Knowledge Areas
A knowledge area represents a category of expertise that includes tasks and activities a business analyst would perform. Each knowledge area has a specific purpose, inputs, outputs, and techniques associated with it. The knowledge areas are not sequential, but there is a logic in their application. It's about what a BA does, not how to do it. For any given initiative, a business analyst may use one, but most likely, all of the knowledge areas.
Business Analysis Planning and Monitoring: describes the tasks that business analysts perform to organize and coordinate the efforts of business analysts and stakeholders.
Elicitation and Collaboration: describes the tasks that business analysts perform to prepare for and conduct elicitation activities and confirm the results obtained. It also describes the communication with stakeholders once the business analysis information is assembled and the ongoing collaboration with them throughout the business analysis activities.
Requirements Life Cycle Management: describes the tasks that business analysts perform in order to manage and maintain requirements and design information from inception to retirement. These tasks describe establishing meaningful relationships between related requirements and designs, and assessing, analyzing and gaining consensus on proposed changes to requirements and designs.
Strategy Analysis: describes the business analysis work that must be performed to collaborate with stakeholders in order to identify a need of strategic or tactical importance (the business need), enable the enterprise to address that need, and align the resulting strategy for the change with higher- and lower-level strategies.
Requirements Analysis and Design Definition: describes the tasks that business analysts perform to structure and organize requirements discovered during elicitation activities, specify and model requirements and designs, validate and verify information, identify solution options that meet business needs, and estimate the potential value that could be realized for each solution option. This knowledge area covers the incremental and iterative activities ranging from the initial concept and exploration of the need through the transformation of those needs into a particular recommended solution.
Solution Evaluation: describes the tasks that business analysts perform to assess the performance of and value delivered by a solution in use by the enterprise, and to recommend removal of barriers or constraints that prevent the full realization of the value.
Business Analysis Key Terms and Concepts
Business Analysis Information: Business analysis information refers to the broad and diverse sets of information that business analysts analyze, transform, and report. It is information of any kind—at any level of detail—that is used as an input to, or is an output of, business analysis work. Examples of business analysis information include elicitation results, requirements, designs, solution options, solution scope, and change strategy.
Design: A design is a usable representation of a solution. Design focuses on understanding how value might be realized by a solution if it is built. The nature of the representation may be a document (or set of documents) and can vary widely depending on the circumstances.
Enterprise: An enterprise is a system of one or more organizations and the solutions they use to pursue a shared set of common goals. These solutions (also referred to as organizational capabilities) can be processes, tools or information. For the purpose of business analysis, enterprise boundaries can be defined relative to the change and need not be constrained by the boundaries of a legal entity, organization, or organizational unit. An enterprise may include any number of business, government, or any other type of organization.
Organization: An autonomous group of people under the management of a single individual or board, that works towards common goals and objectives. Organizations often have a clearly defined boundary and operate on a continuous basis, as opposed to an initiative or project team, which may be disbanded once its objectives are achieved.
Plan: A plan is a proposal for doing or achieving something. Plans describe a set of events, the dependencies among the events, the expected sequence, the schedule, the results or outcomes, the materials and resources needed, and the stakeholders involved.
Requirement: A requirement is a usable representation of a need. Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled. The nature of the representation may be a document (or set of documents), but can vary widely depending on the circumstances.
Risk: Risk is the effect of uncertainty on the value of a change, a solution, or the enterprise. Business analysts collaborate with other stakeholders to identify, assess, and prioritize risks, and to deal with those risks by altering the likelihood of the conditions or events that lead to the uncertainty: mitigating the consequences, removing the source of the risk, avoiding the risk altogether by deciding not to start or continue with an activity that leads to the risk, sharing the risk with other parties, or accepting or even increasing the risk to deal with an opportunity.
Project Team Stakeholders
There are several key project team stakeholders including the sponsor, business analyst, project manager, domain subject matter expert, implementation subject matter expert, and tester.
Sponsors are responsible for initiating the effort to define a business need and develop a solution that meets that need. They authorize the work to be performed, and control the budget and scope for the initiative. Alternate roles are executive and project sponsor.
The business analyst is inherently a stakeholder in all business analysis activities. The BABOK® Guide presumes that the business analyst is responsible and accountable for the execution of these activities. In some cases the business analyst may also be responsible for performing activities that fall under another stakeholder role.
Project managers are responsible for managing the work required to deliver a solution that meets a business need, and for ensuring that the project's objectives are met while balancing the project factors including scope, budget, schedule, resources, quality, and risk.
A domain subject matter expert is any individual with in-depth knowledge of a topic relevant to the business need or solution scope. This role is often filled by people who may be end users or people who have in-depth knowledge of the solution such as managers, process owners, legal staff, consultants, and others.
Testers are responsible for determining how to verify that the solution meets the requirements defined by the business analyst, as well as conducting the verification process. Testers also seek to ensure that the solution meets applicable quality standards, and that the risk of defects or failures is understood and minimized. An alternate role is quality assurance analyst.
External Project Stakeholders
Once the project is over, the solution is turned over to Operational support for day-to-day management of the solution. This will include maintenance, updates, and enhancements. There are some of the most common roles are: operations analyst, product analyst, help desk, and release manager.
A customer uses or may use products or services produced by the enterprise and may have contractual or moral rights that the enterprise is obliged to meet.
End users are stakeholders who directly interact with the solution. End users can include all participants in a business process, or who use the product or solution.
A supplier is a stakeholder outside the boundary of a given organization or organizational unit. Suppliers provide products or services to the organization and may have contractual or moral rights and obligations that must be considered. Alternate roles are providers, vendors, and consultants.
Regulators are responsible for the definition and enforcement of standards. Standards can be imposed on the solution by regulators through legislation, corporate governance standards, audit standards, or standards defined by organizational centers of competency. Alternate roles are government, regulatory bodies, and auditor.
The Requirements Classification Schema
Business requirements describe the reason for the change. They are recorded in a business requirements documents, also known as a BRD.
Business requirements: statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.
Stakeholder requirements: describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.
Solution requirements: describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution. Solution requirements can be divided into two sub-categories:
Functional requirements: describe the capabilities that a solution must have in terms of the behavior and information that the solution will manage;
Non-functional requirements or quality of service requirements: do not relate directly to the behavior of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have.
Transition requirements: describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature. Transition requirements address topics such as data conversion, training, and business continuity.
Requirements and Designs
Contrary to popular belief, business analysts are responsible for both requirements and designs. The various techniques used to analyze requirements are also used to design the solution.
The business analyst may create a prototype to describe the functionality of the system and identify if there is functionality missing that needs to change or should be removed. It's an iterative process.
For example, the prototype could be used to validate the requirements, which may prompt the need for more requirements and a change to the design. Like requirements, designs are communicated at various levels of detail known as levels of abstraction. Once the requirements are accepted, and turned over to the implementation team, a designer will add more details to describe the physical level of requirements in another type of design.
Requirements focus on meeting a need. The business analysis elicits information and analyzes that information to answer questions, such as who, what, when, where, how much, and how often. The requirements are validated by stakeholders. The business analyst manages the requirements, and therefore must also manage the supporting designs.
While requirements focus on a need, designs focus on a solution. A design can be used to represent the solution using process models, data models, decision trees, prototypes, or screen captures. Designs can be used to ensure that the solution will satisfy the requirement and fulfill the need.
The requirements and design relationship is iterative, which means that requirements may be revisited and designs updated until the requirements are clearly understood and the design represents an effective solution. The business analyst must clearly define the design and then review the final design.
The Requirements and Design Cycle
In the early stages of the requirements cycle, the business analyst will elicit information from the business to understand goals and objectives. The requirements and design cycle involves four stages.
Stage 1 moves from business requirements to design, to stakeholder requirements;
Stage 2 moves from stakeholder requirements to design, to solution requirements;
Stage 3 moves from solution requirements to design, to transition requirements;
Stage 4 moves from transition requirements to assess outcomes, and back to business requirements.
Business requirements could apply, for example, if a company wanted to provide an advertising and rating service for their customer. In this scenario, the customer would view the advertisement online, rate the advertisement and receive points. Once they reached a certain number of points, the user would get a coupon. The business reason for providing the service would be to sell the resulting data to other customers who need market information. This results in a high level process model which sets forth the tone for eliciting stakeholder requirements for further understand the business rules and needs. The stakeholders would discuss the process and provide details of what needs to be achieved at each step. This results in requirements that list the data needed to create a user profile. This would include the user's email, demographic information, and the need for the user to indicate his or her birth date. They business rule requires that anyone participating in the survey must be 18 years or older. all of this is documented. The stakeholders' requirements result in a high level data model, data flow diagram, detailed process flow, and a paper prototype of the form the user would need to complete. In the scenario the solution requirements detail the system behavior and logic to complete a step.