Effective Analysis and Documentation

Business Analysis

Many software development teams take business analysis as a preceding phase to system design, which only identifies what features the system shall have. For these teams, business analysis is a synonym to use case analysis, user stories analysis, or solution requirements analysis in general. It is a waste of time to meditate whether eliciting solution features are part of the business analysis or if it is already a system analysis (see this chapter for more details). The message here should be that business analysis is much broader than just requirements analysis activity.

The business analysis phase aims to understand the business problem or opportunity and to find the best solution to them. This involves understanding why the change in the organization is needed, what are the business goals, limitations, assumptions, and risks or how the success of the change in regards to the potential value will be measured. The vital part of finding the best solution is understanding the current state of the enterprise. Knowing what capabilities the enterprise currently has 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 its implementation. The goal is to provide only a high-level overview of the enterprise components that must be changed and the impacts the changes will have on the enterprise.

aa

1. Defining the Business Need

The first step of the business analysis phase is the definition of a 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 which needs to be solved or an opportunity that business would like to take advantage of. Business needs may vary in their importance, but they are never just daily operational problems, such as a missing field in the report. Identifying a business need is a crucial step to understanding the motivation of why stakeholders initiated the activity and what they want to achieve, in fact.

Examples of business needs:

  • A new data protection law must be reflected in our business (problem)
  • The competition started to sell electronic tickets and we need to catch up (problem)
  • Retail customers are increasingly demanding the ability to contact our customer care using online communicators such as Whatsapp or Facebook Messenger (opportunity)

To put the business need into context, the description must state what is the motivation behind it (reasons why it presents an issue) and what benefits are expected to be delivered by fulfilling the need:

  • Need: Retail customers are increasingly demanding the ability to contact our customer care using online communicators such as Whatsapp or Facebook Messenger
  • Motivation: Since we want our customers to perceive us as a modern, company we need to follow new trends. Introducing messengers as a new channel for customers' inquiries is in line with our strategy.

Traps

Business needs are usually discussed among management, and business analyst is rarely present during the initial discussions. There is nothing wrong with it as the internal and secret stuff may be presented during these discussions. However, once the need is finalized, the business analyst must understand it. The problem is the form it is usually presented. In the better case, the analyst is given a structured document defining what the expected goals are. In the worse case, business need is just a couple of very vague sentences of what they would like to change. In both cases, you should always have in mind that business people are good at their subject matter but are not trained to create high-quality specifications. Thus, you shouldn't expect them to deliver something which you just take and start analyzing. It should always be considered a rough idea to be consulted with the stakeholders personally before putting it into a nicely structured, organized, and unambiguous document. Since the document is the foundation of all upcoming activities and forms the first "contract" with stakeholders, it is very important to write it properly.

Besides the quality of the business need specification, analysts need to cope with another bad habit, which is presenting the needs along with presumed solutions. In this case, analysts need to use their skills to uncover this trap and differentiate between the need and the potential solution. It is needed to look at the need from the wider perspective, question all assumptions and constraints associated with the need, and consider all alternative solutions that would solve the problem, not just the one given by the stakeholders as they have a very narrowed view.

2. Understanding the Current State

Each change occurs in the context of existing stakeholders, processes, technology, and policies, which altogether constitute the current state of the enterprise. To understand the business goals, and to identify possible solutions, analysts must be able to see the problem in the context of how the organization functions today. They must have a comprehensive knowledge of its current capabilities which will help discover limitations that may support or constraint the potential changes:

  1. Organization structure and culture
    • Relationships between people and the values they share
  2. Capabilities and processes
    • Activities an enterprise performs, the knowledge the enterprise has, the products and services it provides
  3. Technology and infrastructure
    • Systems and applications, and infrastructure which helps to operate them
  4. Policies
    • Rules and guidance which operate the organization
  5. Business arch.
  6. Internal assets
    • Resources such as money or intellectual properties
  7. External influencers
    • Who are competitors, customers, suppliers, regulations to be followed or trends in technology in the affected business area

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

For example, if the business wants to start delivering documents to customers solely in electronic form, what are the current ways of delivering? Which documents are being delivered to customers and using which channels? If we start delivering 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, going down to details such as which system is responsible for a particular part of the process. Besides, the aim is not to create a complete documentation of the enterprise. The current state is explored in just enough detail to validate the need for a change and/or the change strategy.

Getting familiar with the as-is state is also crucial for being an equal partner to stakeholders. An analyst needs to be able to react quickly to their questions, ideas, or proposals, which cannot be done without the knowledge of the affected areas of the enterprise. Also, the analyst cannot get stakeholders’ trust without being able to speak their language and understanding the environment in which their problems occur.

The as-is state description is beneficial when the current state exists and is going to be changed. There are also cases when a brand new capability is to be introduced, and therefore the current state does not yet exist. Despite this, the current state description should not be omitted and should explicitly state that the enterprise does not yet have such capability.

Capabilities and Processes

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

Example

The following example is using the process approach, and it maps who, when, and how works with the customer requests.

Retail customers are increasingly demanding the ability to contact our customer care using online communicators such as Whatsapp or Facebook Messenger

  • Currently, customers can contact customer care using phone, they can create inquiry through an online form on the company’s website or by sending an email to a dedicated email address
  • All channels (except a phone call) creates a ticket in a customer care system
  • In case of a phone call, the ticket is created manually by the phone operator
  • After the ticket is created an automated email confirmation is sent to the customer
  • At the moment, it is not possible to create inquiry using an online communicator. Customers can send us a direct message through Facebook. However, all these questions and requests are processed by our Facebook team and are tracked.

3. Defining Future State

After the analyst managed to identify what the organization needs to achieve and what are its current capabilities, the next step is to define the future state of the enterprise and to ensure this state is achievable with the resources available, and that key stakeholders have a shared consensus vision of the outcome. The to-be state of the enterprise sets an important baseline for searching for the best solution for business problems. It also allows stakeholders to understand the potential value that can be realized from a solution and help them to have a context during the decision-making process when evaluating the possible solutions. It involves defining business goals and objectives that will demonstrate that the business need has been satisfied and defines what parts of the enterprise need to change. Business goals represent a general strategy and are longer terms, such as addressing a competitive disadvantage, complying with new regulations, or increasing revenue. Objectives are decomposed from the goals, they are more descriptive, and they are measurable, so they should always be linked to measures that make it possible to objectively assess if the objective has been achieved. For example, the goal "Increase number of high-revenue customers" could be further refined to the objective "Increase 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 be able to take advantage of the opportunity or to deal with a problem, concrete parts of the transformation must be identified. These parts together form a solution, which, once implemented, will guarantee that the company will be able to meet the business goals. Through various techniques such as requirements workshops, interviews, etc., analyst puts together all requirements, ideas, needs, and constraints and begins to get a more concrete idea of what solution is needed. Although stakeholders may have a very concrete idea about the solution they want, it is important not to mix business goals and their implementation. The purpose of future state analysis is not to create a comprehensive description of the outcome at a level of detail that will directly support implementation. It should just outline the scope boundaries of potential solutions. This scope is defined by the components of the organization which do not fully support the goals and must undergo changes. The change might have a big impact, such as introducing a new product to the market, but it can also be a simple change, such as changing a step in a process or adding a feature to the existing application. The following list defines organizational components which might require modifications to support the future state and which together form a possible solution:

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

When defining the future state, there might be factors that cannot be changed and which shape or limit the future state in some way. These are called constraints and are part of the future state analysis. In this very early phase of the analysis, it is also common, there are uncertainties related to the future state. They are recorded as a list of assumptions and dependencies along with risks which the uncertainty may generate:

  • Constraints
    • Constraints are something which is given and which must be taken into account when designing the solution
    • For example, if the bank needs to comply with the regulation no later than 31.12.2017, it is a constraint. Another example is when using only Microsoft Technologies to build the new system is dictated by the IT policy.
  • Assumptions and Dependencies
    • When defining the future state, not all information is certain. Some beliefs are supposed to be true but do not necessarily end up being true. Sometimes they may turn out to be false, which can affect the project significantly, adding risks to it.
    • For example, the future state analysis of a global regulation implementation assumes, that the local version of the regulation will not differ from the global one in much detail, so the solution can be based on the global version without waiting for the local one
  • Risks
    • Risks represent undesirable events which might occur during a transition to, or once in the future state
    • Just listing the risks is not enough. Risks must be assessed, which means that according to the possible consequences of the risk and its likelihood, each risk must be assigned a mitigation strategy. This includes accepting the risk, defining a strategy to avoid the risk, or minimalize its impact.
    • For example, there is a risk that the local version of the regulation will introduce additional changes. The risk is quite probable, so we will keep the implementation team ready until the local version of the regulation is finalized so that they can start working on the changes introduced by the local version immediately.

4. Finding a Solution

Some parts or even all parts of the future state might already be present. In such a case, the change will be relatively small. In other cases, there is a gap between what the organization can do or has and what it needs, so a gap analysis must be performed to describe the main components of the organization which must be changed. 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 which new capabilities the change will deliver and how it enables the goals. The gap analysis results include which enterprise components (structure, resources, capabilities, and technology) must be changed to meet the business goals but does not prescribe any concrete solution. For example, accepting customer inquiries through messengers will need changing current processes, making changes to the legacy systems, and even changes to team composition. This is a strategy which outlines the necessary changes, yet it does not say how the changes will be implemented - the concrete solution.

The future state can be achieved through multiple solutions. For example, sending a letter informing the customer about reporting his account to the government can be achieved manually or using the system. The list of affected customers can be generated by a database procedure, and the letters will be sent manually by an employee. Or a dedicated function can be developed in the central information system, which can send the letters automatically using the central print&post solution. This will depend on the number of reported customers and other criteria.

If multiple alternative solutions were identified, all possible alternatives must be described in enough detail to determine which options are feasible. Usually, a decision-making process is started resulting in discovering the best change strategy. Sometimes a separate business case is developed for each solution. But if not, the factors such as major costs, timelines, alignment to the business objectives, etc. should be taken into account at least. The solution comparison can be a formal document, but a spreadsheet or a presentation can also do the job in a less formal environment.

In many cases, the solution will not be delivered at once but will be divided into multiple releases/phases/versions. For each solution, it must be clear what will be included in each phase and the timing of the phase.

Good Practices

It is very important to always analyze problems in a top-down fashion, starting with identifying the business requirements and then finding ways of meeting them. Even when analysts are given a very concrete requirement what part of the system or process must be changed, without understanding the business motivation they cannot be sure whether the solution will be complete and whether it will bring the expected value. Blindly implementing a new process without knowing what its real business purpose is, very often leads to solutions that do not provide the benefit.
In the beginning, the analyst should describe problems in an implementation-independent way. Even though everything indicates that solving the problem will involve just changing two sentences in the document DOC-123, the solution should always be first described in a pure business language. Stating that there is new legislation that requires a specific type of document to include an additional statement provides a clear business requirement that is understandable to and verifiable by stakeholders. And since it does not include a concrete implementation, it allows the analyst to discover all impacts the solution will need to deal with.

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