Effective Analysis and Documentation

Business Analysis

Many software development teams treat business analysis as a preceding phase to system design, focusing only on identifying what features the system should have. For these teams, business analysis is synonymous with use case analysis, user story analysis, or solution requirements analysis in general. It is a waste of time to debate whether eliciting solution features is part of business analysis or system analysis (see this chapter for more details). The key takeaway here is that business analysis is much broader than just requirements analysis.

The business analysis phase aims to understand a business problem or opportunity and find the best solution for it. This involves understanding why a change in the organization is needed, what the business goals, limitations, assumptions, and risks are, and how the success of the change will be measured in terms of potential value. A vital part of finding the best solution is understanding the current state of the enterprise. Knowing what capabilities the enterprise currently possesses is essential for discovering possible solutions and selecting the best one. However, this phase does not aim to describe the selected solution in detail for implementation. The goal is to provide only a high-level overview of the enterprise components that must change and the impacts those changes will have on the organization.

aa

1. Defining the Business Need

The first step of the business analysis phase is defining the business need. According to BABOK, a business need is "a problem or opportunity of strategic or tactical importance to be addressed." In other words, it is a problem that needs to be solved or an opportunity that the business would like to take advantage of. Business needs may vary in importance, but they are never just minor, day-to-day operational issues, like a missing field in a report. Identifying a business need is a crucial step to understanding the actual motivation behind why stakeholders initiated the activity and what they truly want to achieve.

Examples of business needs:

  • A new data protection law must be reflected in our business (problem)
  • Competitors have started selling electronic tickets and we need to catch up (problem)
  • Retail customers are increasingly demanding the ability to contact our customer care team using online messaging platforms like WhatsApp or Facebook Messenger (opportunity)

To put the business need into context, the description must state the motivation behind it (reasons why it presents an issue) and the benefits expected from fulfilling it:

  • Need: Retail customers are increasingly demanding the ability to contact our customer care team using online messaging platforms like WhatsApp or Facebook Messenger.
  • Motivation: Since we want our customers to perceive us as a modern company, we need to follow new trends. Introducing messaging platforms as a new channel for customer inquiries aligns with our strategy.

Traps

Business needs are usually discussed among management, and a business analyst is rarely present during these initial discussions. There is nothing wrong with this, as confidential internal matters may be covered. However, once the need is finalized, the business analyst must understand it. The problem often lies in how it is presented. In the best-case scenario, the analyst receives a structured document defining the expected goals. In worse cases, the business need is just a couple of vague sentences about what management wants to change. In both instances, you should always keep in mind that business people are experts in their domain but are not trained to create high-quality technical specifications. Thus, you shouldn't expect them to deliver something you can just take and start analyzing right away. It should always be considered a rough idea that needs to be discussed with stakeholders personally before being turned into a nicely structured, organized, and unambiguous document. Since this document is the foundation for all upcoming activities and forms the first "contract" with stakeholders, writing it properly is highly important.

Besides the quality of the business need specification, analysts must cope with another bad habit: presenting needs alongside assumed solutions. In these cases, analysts must use their skills to uncover this trap and separate the actual need from the potential solution. It is necessary to look at the need from a wider perspective, question all assumptions and constraints associated with it, and consider alternative solutions that would solve the underlying problem—not just the single option proposed by stakeholders, who may have a very narrow view.

2. Understanding the Current State

Each change occurs within the context of existing stakeholders, processes, technology, and policies, which together constitute the current state of the enterprise. To understand business goals and identify possible solutions, analysts must look at the problem in the context of how the organization functions today. They must have a comprehensive knowledge of its current capabilities, which helps uncover limitations that may support or constrain potential changes:

  1. Organizational structure and culture
    • Relationships between people and the values they share
  2. Capabilities and processes
    • Activities an enterprise performs, the knowledge it possesses, and the products and services it provides
  3. Technology and infrastructure
    • Systems, applications, and the infrastructure that helps operate them
  4. Policies
    • Rules and guidelines that govern the organization
  5. Business architecture
  6. Internal assets
    • Resources such as funds or intellectual property
  7. External influencers
    • Competitors, customers, suppliers, regulations to follow, or technology trends in the affected business area

Knowing the gap between an organization's current capabilities and those required to solve the problem is crucial for defining requirements. Therefore, the analyst should always put effort into understanding the as-is state before proposing any changes. Being aware of the current state is beneficial not only for discovering capability gaps but also for identifying the impacts of a change. The analyst must understand what potential consequences the changes might have on the enterprise, who will be affected, and how.

For example, if the business wants to switch to delivering documents to customers solely in electronic form, what are the current delivery methods? Which documents are currently delivered, and through which channels? If we switch to electronic documents only, what parts of the enterprise will be impacted, and how?

REMEMBER

The as-is state should be described in layers, starting with the business description and drilling down to details like which system is responsible for a particular part of the process. Furthermore, the aim is not to create exhaustive documentation for the entire enterprise. The current state is explored in just enough detail to validate the need for change and inform the change strategy.

Getting familiar with the as-is state is also crucial for being an equal partner to stakeholders. An analyst needs to react quickly to their questions, ideas, or proposals, which is impossible without knowing the affected areas of the enterprise. Additionally, an analyst cannot earn stakeholders’ trust without speaking their language and understanding the environment where their problems occur.

Describing the as-is state is highly beneficial when a current state exists and is going to change. There are also cases where a brand-new capability is being introduced, meaning a current state does not yet exist. Even so, a current state section should not be omitted; it should explicitly state that the enterprise does not yet possess this capability.

Capabilities and Processes

Capabilities represent all organizational assets, including knowledge, products, services, or methods used to make decisions. Processes are the activities the organization performs. The current state can be described either from the perspective of capabilities or by examining the processes the organization operates. Describing the current state as a capability list is useful when looking for solutions that combine current capabilities to produce a new outcome. The output is a capability hierarchy showing what the organization has and can do in the context of the desired change. Describing the as-is state using processes is useful when the objective is to improve how the organization operates in a specific business area. In this scenario, it is important to understand current activities and the imperfections that block satisfying the need. The output, in this case, is a process map.

Example

The following example uses the process approach to map who works with customer requests, as well as when and how they do so.

Retail customers are increasingly demanding the ability to contact our customer care team using online messaging platforms like WhatsApp or Facebook Messenger.

  • Currently, customers can contact customer care by phone, submit an inquiry via an online form on the company website, or send an email to a dedicated address.
  • All channels (except phone calls) automatically create a ticket in the customer care system.
  • For phone calls, the ticket is created manually by the phone operator.
  • After a ticket is created, an automated email confirmation is sent to the customer.
  • At the moment, it is not possible to create an inquiry using an online messaging platform. Customers can send us a direct message through Facebook, but these questions and requests are handled by our Facebook team and tracked separately.

3. Defining the Future State

Once the analyst has identified what the organization needs to achieve and what its current capabilities are, the next step is to define the future state of the enterprise. This step ensures that the desired state is achievable with available resources and that key stakeholders share a consensus vision of the outcome. The to-be state sets an important baseline for finding the best solution to business problems. It also allows stakeholders to understand the potential value a solution can deliver and provides context during the decision-making process when evaluating options.

This step involves defining business goals and objectives that will demonstrate the business need has been met, and it details what parts of the enterprise must change. Business goals represent a general, long-term strategy, such as addressing a competitive disadvantage, complying with new regulations, or increasing revenue. Objectives are broken down from goals; they are more descriptive and must be measurable, meaning they should always be linked to metrics that allow for an objective assessment of whether they have been achieved. For example, the goal "Increase the number of high-revenue customers" can be further refined into the objective "Increase the number of high-revenue customers by 30% within 6 months."

As soon as it is clear how the company as a whole must change to capitalize on an opportunity or handle a problem, specific parts of the transformation must be identified. Together, these parts form a solution that ensures the company can meet its business goals. Through techniques like requirements workshops and interviews, the analyst compiles requirements, ideas, needs, and constraints to form a concrete picture of the required solution. Although stakeholders may have a highly specific solution in mind, it is important not to mix business goals with their execution. The purpose of future state analysis is not to create an exhaustive description of the outcome for immediate implementation. It should simply outline the scope boundaries of potential solutions. This scope is defined by the components of the organization that do not fully support the goals and must undergo changes. The change might have a major impact, like introducing a new product to the market, or a simpler one, like modifying a step in a process or adding a feature to an existing application. The following list defines organizational components that might require modifications to support the future state and together form a potential solution:

  • Organizational Structure and Culture
  • Capabilities and Processes
  • Technology and Infrastructure
  • Policies
  • Business Architecture

When defining the future state, there may be factors that cannot be changed and which shape or limit the future state. These are called constraints and are an inherent part of future state analysis. In this very early phase, uncertainties related to the future state are also common. These are recorded as a list of assumptions and dependencies, alongside the risks that these uncertainties may generate:

  • Constraints
    • Constraints are predetermined factors that must be taken into account when designing the solution.
    • For example, if a bank must comply with a regulation no later than December 31, 2017, that is a constraint. Another example is an IT policy dictating that only Microsoft technologies may be used to build the new system.
  • Assumptions and Dependencies
    • When defining the future state, not all information is certain. Some beliefs are assumed to be true but may not turn out to be. If they turn out to be false, they can significantly affect the project and introduce risks.
    • For example, the future state analysis for implementing a global regulation assumes that the local version of the regulation will not differ significantly from the global one, allowing the solution to be based on the global version without waiting for local finalization.
  • Risks
    • Risks represent undesirable events that might occur during the transition to, or once established in, the future state.
    • Simply listing risks is not enough. Risks must be assessed based on their likelihood and potential consequences, and each must be assigned a mitigation strategy. This includes accepting the risk, avoiding it, or minimizing its impact.
    • For example, there is a risk that the local version of a regulation will introduce additional changes. This risk is quite probable, so we will keep the implementation team ready until the local version is finalized so they can start working on any new changes immediately.

4. Finding a Solution

Some or even all parts of the future state may already be in place. In such cases, the required change will be relatively small. In other situations, a gap exists between what the organization can currently do and what it needs, meaning a gap analysis must be performed to describe the main components that must change. The result of the gap analysis defines the boundaries of potential solutions. This gap should be described in enough detail to enable stakeholders to understand what new capabilities the change will deliver and how it enables their goals. The gap analysis defines which enterprise components (structure, resources, capabilities, and technology) must change to meet business goals, but it does not prescribe a specific solution. For example, accepting customer inquiries through messaging apps will require changing current processes, modifying legacy systems, and adjusting team composition. This is a strategy outlining necessary changes, but it does not specify how those changes will be implemented—the concrete solution.

The future state can be achieved through multiple solutions. For example, sending a letter to inform a customer that their account has been reported to the government can be handled manually or via a system. The list of affected customers could be generated by a database procedure, and the letters sent manually by an employee. Alternatively, a dedicated function could be developed in the central information system to send the letters automatically using a central print-and-post solution. The choice depends on the volume of reported customers and other criteria.

If multiple alternative solutions are identified, each must be described in enough detail to determine feasibility. Usually, a decision-making process is initiated to discover the best change strategy. Sometimes a separate business case is developed for each option. If not, factors like major costs, timelines, alignment with business objectives, and resource availability should at least be taken into account. The solution comparison can be a formal document, though a spreadsheet or presentation can also do the job in a less formal environment.

In many cases, the solution will not be delivered all at once but will be divided into multiple releases, phases, or versions. For each solution, it must be clear what will be included in each phase and when that phase will occur.

Good Practices

It is highly important to always analyze problems in a top-down fashion, starting with identifying business requirements and then finding ways to meet them. Even when analysts are given a highly specific requirement detailing what part of a system or process must change, they cannot be sure the solution will be complete or bring the expected value without understanding the business motivation. Blindly implementing a new process without knowing its real business purpose often leads to solutions that fail to provide the intended benefits.

In the beginning, the analyst should describe problems in an implementation-independent way. Even if everything indicates that solving the problem will involve just changing two sentences in document DOC-123, the solution should always first be described in pure business language. Stating that new legislation requires a specific type of document to include an additional statement provides a clear business requirement that is understandable to and verifiable by stakeholders. Because it does not include a concrete implementation detail, it allows the analyst to discover all the impacts the solution will need to handle.

Therefore, analysts should never start analyzing changes to specific artifacts, such as documents or screens, without also analyzing the context of the required change. Even small, routine changes should be placed in the context of the business processes or routines they support to see the big picture and uncover potential impacts, additional stakeholders, and related factors.