A Guide to the Business Analysis: "Business Analysis Planning and Monitoring" - Part 1

How many tasks are included in the Business Analysis Planning and Monitoring?

The Business Analysis Planning and Monitoring knowledge area includes the following tasks:

1.  Plan Business Analysis Approach


2.  Plan Stakeholder Engagement


3.  Plan Business Analysis Governance


4.  Plan Business Analysis Information Management


5.  Identify Business Analysis Performance Improvement

1. Plan Business Analysis Approach:

Plan Business Analysis Approach describes the planning of business analysis work from creation or selection of a methodology to planning the individual activities, tasks, and deliverables.

The businesss analyst may also identify an initial set of techniques to use. This list may change as the initiative proceeds and the business analyst gains a deeper understanding of the change and its stakeholder.

The Business Analysis approach may be defined by a methodology or by organizational standards. In some organizations, elements of the business analysis approach may be standardized and formalized into a repeatable business analysis process which can be leveraged for each effort.

If organizational standards do not exist, the business analyst works with the appropriate stakeholders to determine how the work will be completed. For example, if the change is delivered via a project, the standards and approach may be developed during the project planning phase.

The Business analysis approach should:

  - align to the overall goals for the change,
  - coordinate the business analysis tasks with the activities and deliverables of the overall change,
  - include tasks to manage any risks that could reduce the quality of business analysis deliverables or
    impede task efficiency, and

  - leverage approaches and select techniques and tools that have historically worked well.

1.1 Inputs

Needs: the business analysis approach is shaped by the problem or opportunity faced by the organization. It is necessary to consider what is known about the need at the time of planning, while acknowledging that understanding evolves throughout business analysis activities.

1.2 Elements

A. Planning Approach

There are various planning methods used across perspectives, industries and enterprises. Many planning methods fit somewhere along a continuum between predictive and adaptive approaches.

Predictive approaches focus on minimizing upfront uncertainty and ensuring that the solution is defined before implementation begins in order  to maximize control and minimize risk. These approaches are often preferred in situations where requirements can effectively be defined ahead of implementation, the risk of an incorrect implementation is unacceptably high, or when engaging stakeholders presents significant challenges.

Adaptive approaches focus on rapid delivery of business value in short iterations in return for acceptance of a higher degree of uncertainty regarding the overall delivery of the solution. These approaches tend to be preferred when taking an exploratory approach to finding the best solution or for incremental improvement of an existing solution.

Different approaches may be used within the same initiative. Among other factors, the business analyst may consider the organization's standards, tolerance for uncertainly, and previous experience with different approaches when planning for business analysis activities.

B. Formality and Level of Detail of Business Analysis Deliverables

When defining the business analysis approach, consider the level of formality that is appropriate for approaching and planning the initiative.

Predictive approaches typically call formal documentation and representations. Business analysis information may be captured in a formal document or set of representations following standardized templates. Information is captured at various levels of detail. The specific content and format of business analysis information can vary depending on the organizational methodologies, process and template in use.

Adaptive approaches favor defining requirements and designs through team interaction and gathering feedback on a working solution. Mandatory requirements representations are often limited to a prioritized requirement list. Additional business analysis documentation may be created at the discretion of the team, and generally consists of models developed to enhance the team's understanding of a specific problem. Formal documentation is often produced after the solution is implemented to facilitate acknowledge transfer.

C. Business Analysis Activities

A business analysis approach provides a description of the types of activities that the business analyst will perform. Frequently the organization's adopted methodologies influence the activities that are selected. 

Integrating business analysis activities in the business analysis approach includes;

- identifying the activities required to complete each deliverable and then breaking each activity into tasks,

- dividing the work into iterations, identifying the deliverables for each iteration and then identifying the associated activities and tasks, or

- using a previous similar initiative as an outline and applying the detailed tasks and activities unique to the current initiative.

D. Timing of Business Analysis Work

Business analyst determine when the business analysis tasks need to be performed and if the level of business analysis effort will need to vary over time. This type of planning includes determining whether the business analysis tasks performed within the other knowledge areas will be performed primarily in specific phases or iteratively over the course of the initiative. 

The timing of business analysis activities can also be affected by:
- the availability of resources,
- priority and/or urgency of the initiative,
- other concurrent initiative, or 
- constraints such as contract terms or regulatory deadlines.
E. Complexity and Risk

The complexity and size of the change and the overall risk of the effort to the organization are considered when determining the business analysis approach. As complexity and risk increase or decrease, the nature and scope of business analysis work can be altered and reflected in the approach.

The approach may also be altered based on the number of stakeholders or business analysis resource involved in the initiative. As the number of stakeholders increases, the approach may be adjusted to include additional process steps to better manage the business analysis work. 

Other factors that can impact complexity include:

* size of the change

* number of business areas or systems affected,

* technological complexities, and

* an risks that could impede the business analysis effort.

Factors that can impact the risk level of a business analysis effort include:

* experience level of the business analyst,

* extent of domain knowledge held by the business analysis,

* level of experience stakeholders have in communicating their needs,

* stakeholder attitudes about the change and business analysis in general,

* amount of time allocated by stakeholders to the business analysis activities,

* any pre-selected framework, methodology, tools, and/or techniques imposed by organizational policies and practices,

* cultural norms of the organization.

F. Acceptance

The business analysis approach is reviewed and agreed upon by key stakeholders. In some organizations, the business analysis process may be more structured and require key stakeholders to sign off on the approach to ensure all business analysis activities have been identified, estimates are realistic, and the proposed roles and responsibilities are correct. Any issues raised by stakeholders when reviewing the approach are documented by the business analyst and resolutions are sought. Stakeholders also play a role in reviewing and accepting changes to the approach as alterations are made to accommodate changing conditions across the initiative.

1.3 Guidelines and Tools

• Business Analysis Performance Assessment: provides results of previous assessments that should be reviewed and incorporated into all planning approaches.
•  Business Policies: defines the limits within which decisions must be made. They may be described by regulations, contracts, agreements, deals, warranties, certifications, or other legal obligations. These policies can influence the business analysis approach.
•  Expert Judgment: used to determine the optional business analysis approach. Expertise may be provided from a wide range of sources including stakeholders on the initiative, organizational centers of excellence, consultants or associations and industry groups.
•  Methodologies and Frameworks: shapes the approach that will be used by providing methods, techniques, procedures, working concepts, and rules.
•  Stakeholder Engagement Approach: understanding the stakeholders and their concerns and interests may influence decisions made when determining the business analysis approach.

1.4 Techniques

•  Brainstorming: used to identify possible business analysis activities, techniques, risks and other relevant items to help build the business analysis approach.
•  Business Cases: used to understand whether elements of the problem or opportunity are especially time-sensitive, high-value, or whether there is any particular uncertainty around elements of the possible need or solution.
•  Document Analysis: used to review existing organizational assets that might assist in planning the approach.
•  Estimation: used to determine how long it may take to perform business analysis activities.
•  Financial Analysis: used to assess how different approaches (and the supported delivery options) affect the value delivered.
•  Functional Decomposition: used to break down complex business analysis processes or approaches into more feasible components
•  Interviews: used to help build the plan with an individual or small group.
•  Item Tracking: used to track any issues raised during planning activities with stakeholders. Can also track risk related items raised during discussions when building  the approach.
•  Lesson Learned: used to identify an enterprise's previous experience (both successes and challenges) with planning business analysis approach.
•  Process Modelling: used to define and document the business analysis approach.
•  Reviews: used to validate the selected business analysis approach with stakeholders.
•  Risk Analysis and Management: used to assess risks in order to select the proper business analysis approach. 
•  Scope Modelling: used to determine the boundaries of the solution as an input to planning and to estimating.
•  Survey and Questionnaire: used to identify possible business analysis activities, techniques, risks and other relevant items to help build the business analysis. 
•  Workshops: used to help build the plan in a team setting.

1.4 Outputs

Business Analysis Approach identifies the activities that will be performed across an initiative including who will perform the activities, the timing and sequencing of the work, the deliverables that will be produced and the business analysis techniques that may be utilized. The remaining outputs of the Business Analysis Planning and Monitoring knowledge area may be integrated into an overall approach or be independent based upon methodology, organization, and perspective.

Appendix 1: Plan Business Analysis Approach Input / Output Diagram

Appendix 2: Formality and Level of Detail of Business Analysis Deliverables

A Guide to the Business Analysis: "Business Analysis Key Concepts"

What are the elements of the "Business Key Concepts"?

The Business Key Concepts include the information that provides a foundation for all the other contents, concepts, and ideas in order to provides the business analysts with a basic understanding of the central ides necessary for understanding and employing in the daily practice of business analysis.

The Business Key Concepts consist of:

1. Business Analysis Core Concept Model™ (BACCM™)

2. Key Terms

3. Requirements Classification Schema

4. Stakeholders

5. Requirements and Designs

1. Business Analysis Core Concept Model™ (BACCM™)

The Business Analysis Core Concept Model™ (BACCM™) is a conceptual framework for business analysis. It encompasses what business analysis is and what it means to those performing business analysis tasks regardless of perspective, industry, methodology, or level in the organization. It is composed of sex terms that have a common meaning to all business analysts and helps to discuss both business analysis and its relationships with common terminology.

The Six Core Concepts in the BACCM™ are: CHANGE, NEED, SOLUTION, STAKEHOLDER, VALUE and CONTEXT. 

Figure 1: The Descriptions of BACCM™

2. Key Terms

The Key Terms are very important for all business analysts to understand about the process and what we have to analyze.

2.1. 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 and input to, or an output of, business analysis work.

It is essential to expand the object of many business analysis activities from “requirements” to “information” to ensure that all inputs and outputs of business analysis are subject to the tasks and activities described in the guidance.

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

2.3. 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 organization 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.

2.4. 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 material and resources needed, and the stakeholders involved.

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

2.6. 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 uncertainly: 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.

3. Requirements Classification Schema

The following classification schema describes requirements:

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 requirement: 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 requirement that describe the capabilities that a solution must have terms of the behavior and information that the solution will manage, and

* 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 facilities 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.

4. Stakeholders:

Stakeholders, here, are refer to a list of participants who are more likely participate in the execution of the analysis tasks or who will be affected by it. A stakeholder is an individual or group that a business analyst is likely to interact with directly or indirectly. Any stakeholder can be a source of requirements, assumptions, or constraints.

The generic list of stakeholders includes the following role:

Business Analyst: is inherently a stakeholder in all business analysis activities and is responsible also 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.

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: 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 User: 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.

Implementation Subject Matter Expert: is any stakeholder who has specialized knowledge regarding the implementation of one or more solution components. Some of the most common roles are project librarian, change manager, configuration manager, solution architect, developer, database administrator, information architect, usability architect, usability analyst, trainer and organizational change consultant.

Operational Support: is responsible for the day-to-day management and maintenance of a system or product. While it is not possible to define a listing of operational support roles that are appropriate for all initiatives, some of the most common roles are operations analyst, product analyst, help desk or release manager.

Project Manager: 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.

Regulator: 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 or auditors.

Sponsor: 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.

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, or consultants.

Tester: 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 solution meets applicable quality standards, and that the risk of defects or failures is understood and minimized.

5. Requirements and Designs

Eliciting, analyzing, validating, and managing requirements have consistently been recognized as key activities of business analyst. However, it is important to recognize that business analyst is also responsible for the definition of design, at some level, in an initiative. The level of responsibility for design varies based on the perspective within which a business analyst is working.

Requirements are focused on the need; designs are focused on the solution. The distinction between requirements and designs is not always clear. 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.

The classification as a requirement or a design may become less significant as the business analyst’s work progresses to a greater understanding of and eventual fulfillment of the need.

Business analysis can be complex and recursive. A requirement (or set of requirements) may be used to define a design. That design may then be used to elicit additional requirements that are used to define more detailed designs. The business analyst may hand off requirements and designs to other stakeholders who may further elaborate on the designs. 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.

The following table provides some basic examples of how information may be viewed as either a requirement or a design.

Table 1: Requirements and Designs

Table 2: Requirements and Designs Cycle

 

 

 

 

 

 

 

 

Product Company Financial Excel Model

This template is used for education purposes. It prepares the financial model to support the forecasting of future revenues, expenditure and budgeting preparation for a Product Company.

In this financial model, we will show you how we estimate the projection plan with a simple methodology including Revenues Streams, Expenditures, Capital Expenditures, Loan Calculation, Loan Payback Calculation Schedule, Net Working Capital.

Also, it include the summary of some elements of raw data of the projection, in order to prepare a short presentation with the key points that link to the result that are already built up. It may help you to analyze the discounted cash flow (DCF) statement and the way to calculate: Company evaluation, share price calculation, the net present value of the company and some other points that will be essential for the analysis.

Even if this template is not built for an application to a larger size business, it will help you understand some keys point in order to build a Financial Model (Income Statement, Balance Sheet and Statement of Cash Flow).


FOR DOWNLOADABLE TOOL Please go to the Link as following:

https://www.eloquens.com/method/km4bFMq1/product-company-financial-excel-model/details

A Guide to the Business Analysis: "Business Analysis vs Business Analyst"

What is "Business Analysis"?

Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value. 

Business analysis is performed on a variety of initiatives within an enterprise. Initiatives may be strategic, tactical, or operational. Business analysis may be performed within the boundaries of a project or throughout enterprise evolution and continuous improvement. It can be used to understand the current state, to define the future state, and to determine the activities required to move from the current to the future state.

What is "Business Analysts"?

A Business analyst is any person who performs business analysis tasks, no matter their job title or organizational role. Business analysts are responsible for discovering, synthesizing, and analyzing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders.

The business analyst is responsible for eliciting the actual needs of stakeholders—which frequently involves investigating and clarifying their expressed desires—in order to determine underlying issues and causes.

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

• understanding enterprise problems and goals,
• analyzing needs and solutions,
• devising strategies,
• driving change, and

• facilitating stakeholder collaboration.

Other common job titles for people who perform business analysis include:

• business architect,
• business systems analyst,
• data analyst,
• enterprise analyst,
• management consultant,
• process analyst,
• product manager,
• product owner,
• requirements engineer, and
• systems analyst.

Source: BABOK v3, A Guide to the Business Analysis Body of Knowledge® by IIBA (International Institute of Business Analysis™)