Business Analyst via Babok

Logistics are planned prior to an elicitation activity include:

. The logistics for each elicitation activity include identifying: • the activity's goals, • participants and their roles, • scheduled resources, including people, rooms, and tools, • locations, • communication channels, • techniques, and • languages used by stakeholders (oral and written).

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.

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.

Need

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. choose a business analysis approach that provides adequate analysis for the change.

Solution

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. evaluate if business analysis performance was a key contributor to the successful implementation of a solution.

Task

A task is a discrete piece of work that may be performed formally or informally as part of business analysis.

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.

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.

Perspectives

Perspectives are used within business analysis work to provide focus to tasks and techniques specific to the context of the initiative. Most initiatives are likely to engage one or more perspectives.

Example of Business Analyst Package

Possible forms for packages may include: • Formal Documentation: is usually based on a template used by the organization and may include text, matrices, or diagrams. It provides a stable, easy to use, long-term record of the information. • Informal Documentation: may include text, diagrams, or matrices that are used during a change but are not part of a formal organizational process. • Presentations: deliver a high-level overview appropriate for understanding goals of a change, functions of a solution, or information to support decision making

Assessment Measures

Some possible measures are: • Accuracy and Completeness: determine whether the business analyst work products were correct and relevant when delivered, or whether ongoing revisions were needed to gain acceptance by stakeholders. • Knowledge: assess whether the business analyst had the skills and/or experience to perform the assigned task. • Effectiveness: assess whether the business analyst work products were easy to use as standalone deliverables or whether they required extensive explanation in order to be understood. • Organizational Support: assess whether there were adequate resources available to complete business analysis activities as needed. • Significance: consider the benefit obtained from the work products and assess whether the cost, time, and resource investments expended to produce the work products were justified for the value they delivered. • Strategic: look at whether business objectives were met, problems were solved, and improvements were achieved. • Timeliness: evaluate whether the business analyst delivered the work on time per stakeholder expectations and schedule.

Business Analysis Scope

The Business Analysis Scope section describes the key stakeholders, including a profile of the likely types of sponsors, the target stakeholders, and the business analyst's role within an initiative. It also defines likely outcomes that would be expected from business analysis work in this perspective.

Change Scope

The Change Scope section describes what parts of the enterprise the change encompasses when viewed from this perspective and to what extent it impacts both the objectives and operations of the enterprise. The change scope also identifies the type of problems solved, the nature of the solutions being sought, and the approach to delivering these solutions and measuring their value.

Description

The Description section explains in greater detail what the task is, why it is performed, and what it should accomplish.

Elements

The Elements section describes the key concepts that are needed to understand how to perform the task. Elements are not mandatory as part of performing a task, and their usage might depend upon the business analysis approach.

Guidelines and Tools

The Guidelines and Tools section lists resources that are required to transform the input into an output. A guideline provides instructions or descriptions on why or how to undertake a task. A tool is something used to undertake a task.

Inputs

The Inputs section lists the inputs for the task. Inputs are information consumed or transformed to produce an output, and represent the information necessary for a task to begin.

Outputs

The Outputs section describes the results produced by performing the task. Outputs are created, transformed, or changed in state as a result of the successful completion of a task. An output may be a deliverable or be a part of a larger deliverable. The form of an output is dependent on the type of initiative underway, standards adopted by the organization, and best judgment of the business analyst as to an appropriate way to address the information needs of key stakeholders.

Purpose

The Purpose section provides a short description of the reason for a business analyst to perform the task, and the value created through performing the task.

Stakeholders

The Stakeholders section is composed of a generic list of stakeholders who are likely to participate in performing that task or who will be affected by it. perform a stakeholder analysis to ensure planning and monitoring activities reflect stakeholder needs and account for stakeholder characteristics. They could be ... • Customers: a source of external stakeholders. • Domain Subject Matter Expert: may help to identify stakeholders and may themselves be identified to fulfill one or more roles on the initiative. • End User: a source of internal stakeholders. • Project Manager: may be able to identify and recommend stakeholders. Responsibility for stakeholder identification and management may be shared with the business analyst. • Regulator: may require that specific stakeholder representatives or groups be involved in the business analysis activities. • Sponsor: may request that specific stakeholders be involved in the business analysis activities. • Supplier: a source of external stakeholders.

Techniques

The Techniques section lists the techniques that can be used to perform the business analysis task

Change

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. are responsible for determining how changes to business analysis results will be requested and authorized.

Context

The circumstances that influence, are influenced by, and provide understanding of the change. ensure a complete understanding of the context under analysis in order to develop an efficient business analysis approach.

Business Analysis Core Concept Model

The six core concepts in the BACCM are: Change, Need, Solution, Stakeholder, Value, and Context. The BACCM can be used to: • describe the profession and domain of business analysis, • communicate about business analysis with a common terminology, • evaluate the relationships of key concepts in business analysis, • perform better business analysis by holistically evaluating the relationships among these six concepts, and • evaluate the impact of these concepts and relationships at any point during a work effort in order to establish both a foundation and a path forward

Value

The worth, importance, or usefulness of something to a stakeholder within a context. conduct performance analysis to ensure business analysis activities continue to produce sufficient value for the stakeholders

• Domain Subject Matter Expert:

can be a source of risk when their involvement is required and availability is lacking. The approach taken may depend on availability and level of their involvement with the initiative.

• Sponsor:

can provide needs and objectives for the approach and ensures that organizational policies are followed. The selected approach may depend on availability and involvement with the initiative.

• Business Policies:

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

• Project Manager:

determines that the approach is realistic for the overall schedule and timelines. The business analysis approach must be compatible with other activities.

• Business Analysis Approach:

identifies the business analysis approach and 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.

Collaboration

is the act of two or more people working together towards a common goal.

Elicitation

is the drawing forth or receiving of information from stakeholders or other sources. It is the main path to discovering requirements and design information, and might involve talking with stakeholders directly, researching topics, experimenting, or simply being handed information.

• Regulator:

may be needed to provide approval for aspects of the business analysis approach or decisions made in tailoring the process, especially in organizations where the business analysis process is audited.

• Business Analysis Performance Assessment:

provides results of previous assessments that should be reviewed and incorporated into all planning approaches.

• Methodologies and Frameworks:

shape the approach that will be used by providing methods, techniques, procedures, working concepts, and rules. They may need to be tailored to better meet the needs of the specific business challenge.

• Stakeholder Engagement Approach:

understanding the stakeholders and their concerns and interests may influence decisions made when determining the business analysis approach.

• Expert Judgment:

used to determine the optimal business analysis approach. Expertise may be provided from a wide range of sources including stakeholders on the initiative, organizational Centres of Excellence, consultants, or associations and industry groups. Prior experiences of the business analyst and other stakeholders should be considered when selecting or modifying an approach.

Requirement Attributes

• Absolute reference: provides a unique identifier. The reference is not altered or reused if the requirement is moved, changed, or deleted. • Author: provides the name of the person who needs to be consulted should the requirement later be found to be ambiguous, unclear, or in conflict. • Complexity: indicates how difficult the requirement will be to implement. • Ownership: indicates the individual or group that needs the requirement or will be the business owner after the solution is implemented. • Priority: indicates relative importance of requirements. Priority can refer to the relative value of a requirement or to the sequence in which it will be implemented. • Risks: identifies uncertain events that may impact requirements. • Source: identifies the origin of the requirement. The source is often consulted if the requirement changes or if more information regarding the requirement or the need that drove the requirement has to be obtained. • Stability: indicates the maturity of the requirement. • Status: indicates the state of the requirement, whether it is proposed, accepted, verified, postponed, cancelled, or implemented. • Urgency: indicates how soon the requirement is needed. It is usually only necessary to specify this separately from the priority when a deadline exists for implementation.

The business analysis approach should:

• align to the overall goals of 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.

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.

The timing of business analysis activities can also be affected by:

• the availability of resources, • priority and/or urgency of the initiative, • other concurrent initiatives, or • constraints such as contract terms or regulatory deadlines.