The Business Analytics Guide

To conclude de series of posts regarding Business Analysis skills required to work in analytics, I am creating this post to make a final summary.

Remember that there is deeper content on every of the topics if you need it:

WHAT is Business Analysis?

Business analysis is the process of enabling change inside an organization by identifying problems and suggesting solutions that benefit all parties involved.

An organization can communicate needs and the case for change through business analysis, and to create and outline strategies that can produce value.

It can be used to comprehend the present situation, define the future state, and decide what steps need to be taken to get from the present state to the future state.

There are different perspectives, think about them like lens through which the business analysis views their work activities based on the current context.

WHO is a Business Analyst?

Business analysts are tasked with gathering, combining, and interpreting data from a range of internal sources, such as tools, procedures, documents, and stakeholders.

In order to identify underlying problems and causes, the business analyst is in charge of eliciting the actual demands of stakeholders, which frequently entails looking into and explaining their professed wants.

Business analysts play a role in aligning the designed and delivered solutions with the needs of stakeholders. The activities that business analysts perform include:

The important thing here is, that even if your title is not estrictly BA, is it in your interest to perform such activities to deliver the best (most meaningful) work, I would recommend you to continue reading, no matter which job title your linkedin shows.

HOW can I start cultivating a BA mindset?

Let’s break it down, as the following concepts are key.

Be sure that you are able to identify all of these when you start wearing your BA glasses.

Business Analysis Key Concepts

  • Change is The act of transformation in response to a need. Change works to improve the performance of an enterprise. These improvements are deliberate and controlled through business analysis activities.

  • Need is a problem or opportunity to be addressed. Needs can cause changes by motivating stakeholders to act. Changes can also cause needs by eroding or enhancing the value delivered by existing solutions.

  • Solution is a specific way of satisfying one or more needs in a context. A solution satisfies a need by resolving a problem faced by stakeholders or enabling stakeholders to take advantage of an opportunity.

  • Stakeholder is a group or individual with a relationship to the change, the need, or the solution.

Stakeholders are often defined in terms of interest in, impact on, and influence over the change. And they are 
grouped based on their relationship to the needs, changes and solutions.
  • Value is the worth, importance, or usefulness of something to a stakeholder within a context.
Value can be seen as potential or realized returns, gains, and 
improvements. It is also possible to have a decrease in value 
in the form of losses, risks, and costs.

Tangible value is directly measurable. Tangible value often has a significant monetary component. Intangible value is measured indirectly.

Intangible value often has a significant motivational component, such as a company’s reputation or employee morale.

In some cases, value can be assessed in absolute terms, but in many cases is assessed in relative terms: one solution option is more valuable than another from the perspective of a given set of stakeholders.

  • Context The circumstances that influence, are influenced by, and provide understanding of the change.
    • Changes occur within a context. The context is everything relevant to the change that is within the environment. Context may include attitudes, behaviours, beliefs, competitors, culture, demographics, goals, governments, infrastructure, languages, losses, processes, products, projects, sales, seasons, terminology, technology, weather, and any other element meeting the definition.
  • An Organization is 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 chieved.
  • 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.
  • 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.
  • Risk is the effect of uncertainty on the value of a change or solution.

Business Analysis Key Questions

While planning or performing a task or technique, business analysts can consider how each core concept is addressed by asking questions such as:

  • What are the kinds of changes we are doing?
  • What are the needs we are trying to satisfy?
  • What are the solutions we are creating or changing?
  • Who are the stakeholders involved?
  • What do stakeholders consider to be of value?
  • What are the contexts that we and the solution are in?

If any of the core concepts experience a change, we should re-evaluate these core concepts and their relationships to value delivery.

Requirements Overview

  • Business requirements: statements of goals, objectives, and outcomes that describe why a change has been initiated.

  • 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 behaviour and information that the solution will manage.
    • Non-functional Requirements or quality of service requirements: do not relate directly to the behaviour 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

Eliciting, analyzing, validating, and managing requirements have consistently been recognized as key activities of business analysis. However, it is important to recognize that business analysts are also responsible for the definition of design.

The distinction between requirements and designs is not always clear, you can remember this: Requirements are focused on the need. Designs are focused on the solution.

The same techniques are used to elicit, model, and analyze both. A requirement leads to a design which in turn may drive the discovery and analysis of more requirements. This is a source of complexity and recursiveness in Business Analysis.

The business analyst may hand off requirements and designs to other stakeholders who may further elaborate on the designs.

Owning the final design - Whether it is the business analyst or some other role that completes the designs, the business analyst often reviews the final designs to ensure that they align with the requirements.

Stakeholders Overview

In one sentence - Make sure that everyone is on the same page, understanding which will be their contribution to the solution and in which step of the process their input will be required.

  • 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

  • Domain subject matter expert - SME 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

  • 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

  • An implementation SME is any stakeholder who has specialized knowledge regarding the implementation of one or more solution components.

  • Operational support is responsible for the day-to-day management and maintenance of a system or product.

  • 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.

  • 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.

  • 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.

Competencies for a Business Analyst

Knowledge areas represent areas of specific business analysis expertise that encompass several tasks.

Business Analysis Planning and Monitoring:

  • Describes the tasks that business analysts perform to organize and coordinate the efforts of business analysts and stakeholders.
    • These tasks include planning the business analysis approach, planning stakeholder engagement, planning business analysis governance, planning business analysis information management, and identifying business analysis performance improvements.
    • Planning Methods: The article discusses various planning methods used across industries, which can be categorized into predictive and adaptive approaches.
    • Stakeholder Engagement: The article emphasizes the importance of effective collaboration with stakeholders for maintaining their engagement in business analysis activities. It provides several factors to consider while arranging a collaboration.
    • Techniques that can be used for better planning and monitoring: brainstorming, business cases, document analysis, estimation, financial analysis, functional decomposition, interviews, item tracking, lessons learned, process modeling, reviews, risk analysis and management, scope modeling, survey or questionnaire, and workshops.

Elicitation and Collaboration:

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.
    • Elicitation Techniques:The process of gathering information from sources such as stakeholders or other sources. It is the primary method for learning about needs and designs, and it may involve speaking with stakeholders directly, doing research, conducting experiments, or simply receiving information.
    • Collaboration: Collaboration is the process by which two or more people cooperate to achieve a common objective. In business analysis, elicitation and collaboration work is ongoing as long as business analysis work is being done. It can happen on purpose, accidentally, or both.
    • Steps for Better Elicitation and Collaboration: preparing for elicitation, conducting elicitation, confirming elicitation results, communicating business analysis information, and managing stakeholder collaboration.
    • Types of Elicitation: collaborative, research, and experiments.
    • Elicitation Examples: The article provides examples of elicitation techniques, including document analysis, interviews, prototyping, observation, focus groups, requirements workshop, interface analysis, brainstorming, surveys, mind mapping, and Delphi Techniques.
    • Gaining Agreement on Commitments: The article emphasizes the importance of gaining agreement on commitments. Participants in business analysis activities may need to dedicate time and resources. As early in the project as possible, the business analyst and stakeholders define and accept these obligations.
    • Requirements gathering vs elicitation: Requirements gathering is the overall process of collecting and organizing the project requirements, while requirements elicitation focuses on extracting specific information from stakeholders.

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.
    • The requirements life cycle management, which begins with the representation of a business need as a requirement and ends when a solution and the requirements that represent it are retired.
    • The guide also discusses the concept of trace requirements, which are used to control the consequences of change at one level on related needs and to ensure that requirements and designs at various levels are in sync with one another.
    • Maintaining requirements is crucial to ensure they stay accurate and up to date. Prioritizing requirements is also important, and the guide provides factors to consider when prioritizing, such as benefit, penalty, cost, risk, dependencies, time sensitivity, and stability.
    • The guide also covers the process of assessing requirements changes, verifying requirements, validating requirements, defining requirements architecture, defining solution options, and analyzing potential value and recommending a solution.
    • The RACI matrix, a tool used in project management to identify and assign roles and responsibilities to different stakeholders, is also discussed. The guide also mentions the use of diagrams in representing a need or group of requirements visually.

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.
    • Strategy is defined as the best way to use a team or organization’s resources to accomplish a particular set of goals and objectives. It can be applied to the entire company, a division, department, region, product, project, or iteration.
    • The goal of strategy analysis is to identify the future and transitional stages required to satisfy the business need. It includes finding or conceiving potential solutions that will allow the firm to produce more value for stakeholders and/or capture more value for itself.
    • The guide outlines steps to set up a proper strategy, which include analyzing the current state, defining the future state, assessing risks, and defining the change strategy.
    • Risk assessment is emphasized as a crucial step. It involves understanding the uncertainties around the change, considering the effect those uncertainties may have on the ability to deliver value through a change, and recommending actions to address risks where appropriate.

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.
      • The requirements life cycle management, which begins with the representation of a business need as a requirement and ends when a solution and the requirements that represent it are retired.
      • Trace requirements, which are used to control the consequences of change at one level on related needs and to ensure that requirements and designs at various levels are in sync with one another.
      • Maintaining requirements is crucial to ensure they stay accurate and up to date. Prioritizing requirements is also important, and the guide provides factors to consider when prioritizing, such as benefit, penalty, cost, risk, dependencies, time sensitivity, and stability.
      • The process of assessing requirements changes, verifying requirements, validating requirements, defining requirements architecture, defining solution options, and analyzing potential value and recommending a solution.
      • The RACI matrix, a tool used in project management to identify and assign roles and responsibilities to different stakeholders, is also discussed.

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 analysts perform duties to evaluate a solution in use by the enterprise’s performance and value delivered. They also advocate removing any obstacles or limitations that inhibit the full realization of value.
    • Solution Evaluation tasks include measuring solution performance, analyzing performance measures, assessing solution limitations, assessing enterprise limitations, and recommending actions to increase solution value.
    • Examples of potential recommendations to increase solution value, including doing nothing, organizational change, reducing complexity of interfaces, eliminating redundancy, avoiding waste, identifying additional capabilities, and retiring the solution.
    • Several factors that may impact the decision regarding the replacement or retirement of a solution, including ongoing cost versus initial investment, opportunity cost, necessity, and sunk cost.