Business Analysis Performance (BA Planning & Monitoring)

At last we arrive at the end of chapter2. After a long sub-chapter about approach, stakeholder, activities, communications, requirements and now the last is performance. We as a BA  must ensure all activities are executed correctly and efficiently. Managing performance is also helpful for review and improve business analysis performance. Let's learn more from BABOK about the this performance of business analysis.

2.6 Manage Business Analysis Performance

#Purpose
To manage the performance of business analysis activities to ensure that they are executed as effectively as possible.

#Description
This tasks covers determining which metrics will be used to measure the work performed by the BA. It includes how to track, assess, and report on the quality of the work and take steps to correct any problems that may arise.

#Input
Business Analysis Performance Metrics : Actual performance measures are captured, analyzed, and become the basis for taking corrective or preventive action. Capturing actual performance metrics is a process that occurs through the business analysis effort and is implicitly a potential output from every business analysis task.

Business Analysis Plan(s) : These plans describe deliverables, activities, tasks, and estimates for all business analysis work. Conformance to these plans may be the primary metric used to judge performance.

Organizational Performance Standards : May include mandated performance metrics or expectations for business analysis work.

Requirements Management Plan : The requirements management plan may also set expectations for the frequency of changes to requirements and the work involved in managing that change.

#Elements
1. Performance Measures
Performance measures are used to set expectations regarding what constitutes effective business analysis work in the context of a particular organization or initiative. Performance measures may be based on deliverable due dates as specified in the business analysis plan, metrics such as the frequency of changes to requirements or the number of review cycles required, or qualitative feedback from stakeholders and peers of the BA. Appropriate performance measures should enable the BA to determine when problems are occurring that may affect the performance of business analysis or other activities, or identify opportunities for improvement.

2. Performance Reporting
Reports can be in written format to provide for archival and tracking, or they can be informal and verbal, based on the needs of the project. Some reports may be made formally and orally as presentations to various levels of stakeholders and management.

3. Preventive And Corrective Action
The BA should assess the performance measures to determine where problems in executing business analysis activities are occurring or opportunities for improving the business analysis process exists. Once this assessment is complete the BA should engage the necessary stakeholders to identify the correct preventive or corrective actions. Preventive or corrective actions is likely to result in change to the business analyst plan.

#Techniques
1. General Techniques

Interviews (9.14) : Stakeholders may be interviewed to gather assessments of business analysis performance.

Lessons Learned Process (9.15) : Helps identify changes to business analysis processes and deliverables that can be incorporated into future work.

Metric and Key Performance Indicators (9.16) : Can be used to determine what metrics are appropriate for assessing business analysis performance and how they may be tracked.

Problem Tracking (9.20) : May be used to track issues that occur during performance of business analysis for later resolution.

Process Modeling (9.21) : Can be used to define business analysis processes and understand how to improve those processes to reduce problems from handoffs, improve cycle times, or alter how business analysis work is performed to support improvements in downstream processes.

Root Cause Analysis (9.25) : Can be help identify the underlying cause of failures or difficulties in accomplishing business analysis work.

Survey/ Questionnaire (9.31) : Can be used to gather feedback from a large number of stakeholders.

2. Variance Analysis
The purpose of this technique is to analyze discrepancies between planned and actual performance, determine the magnitude of those discrepancies, and recommend corrective and preventive action as required. Variances can be related to planned versus actual estimates, cost, scope, product expectations, or any measure that have been established during the planning process.

#Stakeholders
Domain SME and End User : Should be informed of the performance of business analysis activities in order to set expectations for their involvement.

Implementation SME, Operational Support, and Test : Dependent on the effective performance of business analysis activities to perform their role. Should be consulted when assessing those activities.

Project Manager : The project manager is accountable for the success of a project and must be kept informed of the current status of business analysis work.

Sponsor : May require reports on business analysis performance to address problem as they are identified. A manager of BA may also sponsor initiatives to improve the performance of business analysis activities.

#Output
Business Analysis Performance Assessment : This include a comparison of planned versus actual performance, understanding the root cause of variances from the plan, and other information to help understand the level of effort required to complete business analysis work.

Business Analysis Process Assets : When the analysis of the performance of the business analysis work yields less than satisfactory result, it is helpful to review not only the result themselves, but also the process that produced those result. This process analysis often result in recommendations for improvement to the business analysis process. The revised process and templates for business analysis deliverables should be analyzed and documented and lessons learned should be recorded. These may be incorporated into Organizational Process Assets.

Next : Chapter 3 - Elicitation

Requirements Management Process (BA Planning & Monitoring)

Every project initiated with requirements. Gathering requirement is a tricky thing. Sometimes it is hidden at first, and show up in the middle or last. It might be not BA mistakes only, but also can come from clients. It is very important that every requirements should be managed and approved, or the scope will become wider. Previously we talked about communication, and now from the same source : BABOK, let's improve our knowledge about requirements management process.

2.5 Plan Requirements Management Process

#Purpose
Define the process that will be used to approve requirements for implementation and manage changes to the solution or requirements scope.

#Description
This task determines the appropriate requirements management process. It includes determining the process for requirements change, which stakeholder need to approve change, who will be consulted or informed of changes, and by extension, who does not need to be involved. The task also include assessing the need for requirements traceability and determining which requirements attributes will be captured.

#Input
Business Analysis Approach : The selected approach may include a definition of appropriate requirements managements processes.

Business Analysis Plan (s) : The business analysis plan define which deliverables are to be produces and when. Deliverables cannot be managed until they are created.

Organizational Process Assets : Standard templates or processes for requirements management within the organization may exist.

#Elements
1. Repository
A requirements repository is a method of storing requirements, including those under development, those under review and approved requirements. Repositories may include whiteboards, word processing documents, diagrams and model, wikis, requirements management tools and application, or any other method of recording information that allows requirements to be single-sourced and available to all relevant stakeholders for as long as they are needed.

2. Traceability
Determine whether and how to trace requirements based on the complexity of the domain, the number of views of requirements that will be produced, potential impacts from risk, and an understanding of the costs and benefits involved.

***Manage Requirements Traceability (4.2)

3. Select Requirements Attributes
Requirements attributes provide information about requirements, such as the source of the requirement, the importance of the requirement, and other metadata. The information documented by the attributes helps the team efficiently and effectively make tradeoffs between requirements, identify stakeholders affected by potential changes, and understand the impact of a proposed change.

Some commonly used requirements attributes include :

 --Absolute reference is a unique numeric (preferred) or textual identifier. The reference is not to be altered or re-used if the requirement is moved, changed or deleted.

 --Author of the requirement. If the requirement is later found to be ambiguous, the author may be consulted for clarification.

 --Complexity indicated how difficult the requirements will be to implement. This is often indicated through qualitative scales based on number of interfaces, complexity of essential processes or the number and nature of the resources required.

 --Ownership indicates the individual or group that needs the requirement, or will be the business owner after the project is released into the target environment.

 --Priority indicates which requirements need to be implemented first.

 --Risks associated with meeting or not meeting the requirements.

 --Source of the requirement. Every requirement must originate from a source that has the authority to define this particular set of requirements. The source must be consulted if the requirement changes, or if more information regarding the requirement or the need that drove the requirement has to be obtained.

 --Stability is used to indicate how mature the requirement is. This is used to determine whether the requirement is firm enough to start work on. Note that the ongoing presence of large numbers of unstable core requirements may indicate significant risk to project continuance.

 --Status of the requirement, indicating such things as 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.

 --Additional attributes may include information such as cost, resource assignment, and revision number, traced-from and traced-to.

4. Requirements Prioritization Process
Requirements do not all deliver the same value to stakeholders. Requirements prioritization focuses effort on determining which requirements should be investigated first, based on the risk associated with them, the cost to deliver them, the benefits they will produce, or other factors. Timelines, dependencies, resource constraints, and other factor influence how requirements are prioritized.

5. Change Management
Some considerations when planning for handling changes are:

 --Determine the process for requesting changes. The process can, but doesn't not have to, set authorization levels for approving changes.

 --Determine who will authorize changes. The planning activity needs to include a designation of who can approve changes after requirements have been approved.

 --Impact analysis. Specify who will perform the analysis of such impacts as business processes, information requirements, system and hardware interfaces, other software products, other requirements, test strategies and plan, to name a few.

 --Plan the wording of the request. It is important to set the expectation at the beginning of the business analysis activities. The requested change must be expressed in unambiguous terms. Therefore, it will be necessary to discuss the nature of the request with the requestor and other interested stakeholders.

The requirements process needs to spell out the nature of the components within a request for change. These might include :

• Cost and time estimates of change :

• For each item, work product, or technical product affected, a brief assessment of the expected cost of change is to be estimated.

• The estimate will provide an integrated view of the costs, resources needed, implementation timeframe, and any dependencies.

• Benefits and risks of the change.

• How the change aligns with the project and business objectives to help ensure all changes add business value.

• Since there are often unintended consequences to what seems like a favorable change, the request should include a well-structured change analysis form (written or verbal), statements of the expected risks, including both negative and positive influence on project objectives. Benefits considered may include not only financial benefits, but also technical aspects of product features, influences on project scope, time, cost, quality, resources, and the business case.

• Recommended course of action for change.

• The course of action for the change needs to be explained with the understanding of benefits and risks in the previous section.

• The various options considered and the reasoning for the option finally selected needs to be recorded.

• The recommended course of action needs to be complete enough to permit clear coordination of the parties affected by the change.

• Update to the communications plan and the method for communication of the change to affected stakeholders.

• Configuration management and traceability discipline should establish product baselines and version control practices, that will clearly identify which baseline is affected by the change.

 --Coordinate Prioritization Of Change. The priority of the proposed change must be established relative to other competing interests within the current project phase.

6. Tailoring the Requirements Management Process
An organization's requirements management process may need to be tailored to meet the needs of a specific initiative or project. Factors in the tailoring process include:

 --Organizational culture. In organizations where the culture does not support formality, but where informality jeopardizes the end product, it will be necessary to work with the stakeholders to negotiate an appropriate process.

 --Stakeholder preferences. Some stakeholders may require more or less formality.

 --Complexity of project, project phase, or product (product, service or result) being delivered. Formal processes for configuration management and change management are more likely to be used for:

• Projects that have many interfaces, many business and/or system impacts or span a variety of functional areas.

• Products that are built with many components and sub-components, have complex interfaces, will be used by a variety and number of stakeholders, or have other complexities.

 --Organizational maturity. Less mature organizations tend to be less likely to want to spend time or money creating a requirements process, and there may be outright resistance to the idea of having a process to define requirements.

 --Availability of resources needed to support the effort of creating such a process is a major consideration. Internal groups, such as a Project Management Office and external sources such as consulting firms and even vendors may be able to augment organizational resources.

#Techniques

Decision Analysis (9.8) : Can be used to assess the possible value delivered by a change and assess areas of uncertainty.

Problem Tracking (9.20) : Used to track possible changes and ensure that a decision is reached.

Risk Analysis (9.24) : Used to identify possible risks associated with the change management process and possible risks associated with making or choosing not to make the change.

#Stakeholders

Domain SME : Consulted in order to determine the importance of requirements and to assess the value of change requests.

End Users : Consulted in order to determine the importance of requirements and to assess the value of change requests.

Implementation SME : Consulted in order to determine the difficulty of implementing a requirement or proposed change.

Operational Support : Informed of changes to requirements to ensure that the solution can operate effectively.

Project Manager : Responsible for managing changes to the project scope and accountable for delivery of the project scope.

Tester : Informed of changes to requirements to ensure that test plans are effective.

Sponsor : Accountable for the solution scope and must approve prioritization of requirements and changes to requirements.

#Output
Requirements Management Plan. A requirements management plan describe the:

• Approach to be taken to structure traceability.
• Definition of requirements attributes to be used.
• Requirements prioritization process.
• Requirements change process, including how changes will be requested, analyzed, approved, and implemented.

Next : Business Analysis Performance

Business Analysis Communication (BA Planning & Monitoring)

Communication is something that cannot be separated from business analysis. As a BA, we have to prepare and plan for communication method in managing business analysis activities. BABOK will tell us about how and when the BA will work with stakeholders.

2.4 Plan Business Analysis Communication

#Purpose

A business analysis communications plan describe the proposed structure and schedule for communications regarding business analysis activities. Record and organize the activities to provide a basis for setting expectations for business analysis work, meetings, walkthroughs, and other communications.

#Description

Planning business analysis communications includes determining how best to receive, distribute, access, update, and escalate information from project stakeholders, and determining how best to communicate with each stakeholder.

Considerations for the business analysis communications plan include:

• What needs to be communicated.
• What is the appropriate delivery method.
• Who is the appropriate audience.
• And when the communication should occur.

Stakeholder needs and constraints relevant to communication include:

• Physical location/ time zone of the stakeholders.
• Communication approach for the stakeholder.
• What types of communications will be required(e.g. status, anomalies, issues and their resolutions, risks, meeting results, action item,s etc.)
• What type of requirements will be elicited (business, stakeholder, solution, or transition; high level vs. details) and how best to elicit them (see the Elicitation KA for options).
• How best to communicate requirements conclusions / packages, including authority level (sign-off authority, veto authority, or review only).
• Time and resource availability constraints.

#Input

Business Analysis Approach : May include standards and templates used for communication, and expectations regarding when and how communication should be occur.

Business Analysis Plan(s) : Determintes when work will be performed and the deliverables that will produced, and which need to be communicated.

Organizational Process Assets : May include a defined set of templates for use in business analysis communication, including presentation formats, requirements documentation templates, and others.

Stakeholder List, Roles and Responsibilities : Used to identify the stakeholders who will require information regarding business analysis work, determine when information needs to be provided, and how a stakeholder is expected to use that information.

#Elements

1. Geography

The communications needed for a team that is collocated will be different from communications required for a project with geographically dispersed stakeholders.

2. Culture

Cultural diversity should also be taken into account when planning communications.

 --Relationship to time.

Some cultures view deadlines as firm commitments, while others may view deadline as a goal to be balances against other concerns and interest.

 --Relationship to task completion.

Some cultures complete tasks because they have committed to the planned activities. Others complete tasks primarily when trust and the human relationship have been built.

 --Relationship to contracts.

Some cultures believe in the letter of the law, others in the spirit of the contract. This difference might surface when creating Requests for Proposal, for example.

 --Relationship to formal and informal authority.

Some cultures prefer a centralized power structure where decisions.

3. Project Type

Different projects will necessitate different deliverables, and the extent of documentation that is need in a requirements package will vary depending on the project. Some examples are :

 --A new, customized in-house software development project. 

In this scenario, all requirements may need to be included.

 --Upgrading the technology or infrastructure of a current system. 

In this scenario, only the technical requirements may need to be included in the package.

 --Change in a business process or new data for an existing application. 

In this scenario, the process and data requirements, business rules,functional and technical requirements will be needed.

 --Purchase of a software package. 

This type of project will likely require a request. For Proposal, and the package will need to include the business requirements, technical requirements, limited functional requirements and other vendor specification.

 --Short, focused, agile style iterations of software development. 

Agile focuses on creating the minimum necessary of documentation to deliver the requirements, and many agile teams will prefer to document the solution after it has been delivered.

4. Communication Frequency

Investigates the frequency required by various stakeholder for each type of communication.

5. Communications Formality
Planning communications requires taking into consideration the level of formality that is needed.

Communication tends to be more formal under the following circumstances:

• The project is unusually large (by organizational standards) and will be delivered in phases.The level of communications formality tends to increase as the scale of project increases. This is because more stakeholders are typically involved and more communication is required.

• The domain involved is very complex. Note that the domain affected by the project may span departmental and divisional boundaries within the organization.

• The technology employed, if any, will be new, or new to the organization.

• The project is considered to be mission critical, in that it is tied directly to strategic objectives.

• The executive sponsor and/or key stakeholders require formality.

• The requirements are likely to be subject to regulatory review.

• The requirements will be presented to suppliers in an RFQ/RFI/RFP.

#Techniques

• Prepare Requirements Package (4.4)
• Communication Requirements (4.5)
• Communication Skills (8.4)
• Structure Walkthrough (9.30)

#Stakeholders
Customer and Supplier : Major customers of an organization or suppliers to that organization (particularly institutional customers) may need to b e informed of planned changes well in advance of implementation.

Domain SME : May be involved in review and approval.

End User : May be involved in review and approval.

Implementation SME : May be involved in review and approval.

Operational Support : May be involved in review and approval.

Project Manager : In a project, the business analysis communication plan will generally be integrated into the overall project communications plan.

Tester : Will primarily be involved in verification and validation of the requirements.

Regulator : Regulators may require that requirements, decisions, and other regarding the execution of business analysis processes or the definition of the solution be retained and made available to the for review.

Sponsor : Communication needs for the sponsor are likely to focus on business requirements and high-level stakeholder and solution requirements.

#Output

Business Analysis Communication Plan : Describes how, when and why the BA will work directly with stakeholders. Components can include :

• The stakeholder communications requirements for business analysis activities.
• Format, content, medium, level of detail.
• Responsibility for collection, distributing, accessing, and updating information.

Next : Requirements Management Process

Work Breakdown Structure / WBS Overview

WBS is a tool that used by Business Analyst in order to plan business analysis activities. Today I will share about some great articles about it from workbreakstructure.com and tutorialspoint.com. As far as I read, I found that this WBS is also used by Project Manager. I think both BA and PM should collaborate to create a great WBS. This post is just an overview, maybe I will update about this later.

Tutorialspoint :

#Introduction
Dividing complex projects to simpler and manageable tasks is the process identified as Work Breakdown Structure (WBS).

Usually, the project managers use this method for simplifying the project execution. In WBS, much larger tasks are broken down to manageable chunks of work. These chunks can be easily supervised and estimated.

WBS is not restricted to a specific field when it come to application. This methodology can be used for any type of project management.

Following are a few reasons for creating a WBS in a project :

• Accurate and readable project organization.
• Accurate assignment of responsibilities to the project team.
• Indicated the project milestones and control points.
• Helps to estimate the cost, time and risk.
• Illustrate the project scope, so the stakeholders can have better understanding of the same.

#Construction of a WBS
Identifying the main deliverables of a project is the starting point for deriving a work breakdown structure.

This important step is usually done by the PM and the SME involved in the project. Once this step is completed, the SME start breaking down the high-level tasks into smaller chuncks of work.

In the process of breaking down the tasks, one can break them down into different levels of detail. One can detail a high-level task into ten sub-tasks while another can detail the same high-level task into 20 sub-tasks.

Therefore, there is no hard and fast rule on how you should breakdown a task in WBS. Rather, the level of breakdown is a matter of the project type and the management style followed for the project.

In general, there are a few "rules" used for determining the smallest task chunk. In "two weeks" rule, nothing is broken down smaller than two weeks worth of work.

This means, the smallest task of the WBS is at least two-week long. 8/80 is another rule used when creating a WBS. This rule implies that no task should be smaller than 8 hours of work and should not be larger than 80 hours of work.

One can use many forms to display their WBS. Some use tree structure to illustrate the WBS, while others use lists and tables. Outlining is one of the easiest ways of representing a WBS.

#WBS Diagram
In a WBS diagram, the project scope is graphically expressed. Usually the diagram starts with a graphic object or a box at the top, which represents the entire project. Then, there are sub-components under the box.

These boxes represent the deliverables of the project. Under each deliverable, there are sub-elements listed. These sub-elements are the activities that should be performed in order to achieve the deliverables.

Although most of the WBS diagrams are designed based on the deliveries, some WBS are created based on the project phases. Usually, information technology projects are perfectly fit into WBS model.

Therefore, almost all information technology projects make use of WBS.

In addition to the general use of WBS, there is specific objective for deriving a WBS as well. WBS is the input for Gantt charts, a tool that is used for project management purpose.

Gantt chart is used for tracking the progression of the tasks derived by WBS.

Following is a sample WBS diagram:

#Conclusion
The efficiency of a work breakdown structure can determine the success of a project.

The WBS provides the foundation for all project management work, including, planning, cost and effort estimation, resource allocation, and scheduling.

Therefore, one should take creating WBS as a critical step in the process of project management.

...

Work Breakdown Structure :

#Overview

A work breakdown structure is a key project deliverable that organizes the team's work into manageable sections. The Project Management Body of Knowledge (PMBOK) defines the work breakdown structure as a "deliverable oriented hierarchical decomposition of the work to be executed by the project team." The work breakdown structure visually defines the scope into manageable chunks that a project team can understand, as each level of the work breakdown structure provides further definition and detail.

#Why use a Work Breakdown Structure?
The work breakdown structure has a number of benefits in addition to defining and organizing the project work. A project budget can be allocated to the top levels of the work breakdown structure, and department budgets can be quickly calculated based on the each project's work breakdown structure. By allocating time and cost estimates to specific sections of the work breakdown structure, a project schedule and budget can be quickly developed. As the project executes, specific sections of the work breakdown structure can be tracked to identify project cost performance and identify issues and problem areas in the project organization. For more information about Time allocation, see the 100% Rule.

Project work breakdown structures can also be used to identify potential risks in a given project. If a work breakdown structure has a branch that is not well defined then it represents a scope definition risk. These risks should be tracked in a project log and reviewed as the project executes. By integrating the work breakdown structure with an organizational breakdown structure, the project manager can also identify communication points and formulate a communication plan across the project organization.

When a project is falling behind, referring the work breakdown structure will quickly identify the major deliverables impacted by a failing work package or late sub- deliverable. The work breakdown structure can also be color coded to represent sub- deliverable status. Assigning colors of red for late, yellow for at risk, green for on-target, and blue for completed deliverables is an effective way to produce a heat-map of project progress and draw management's attention to key areas of the work breakdown structure.

#Work Breakdown Structure Guidelines
The following guidelines should be considered when creating a work breakdown structure:

• The top level represents the final deliverable or project
• Sub-deliverables contain work packages that are assigned to a organization’s department or unit
• All elements of the work breakdown structure don’t need to be defined to the same level
• The work package defines the work, duration, and costs for the tasks required to produce the sub-deliverable
• Work packages should not exceed 10 days of duration
• Work packages should be independent of other work packages in the work breakdown structure
• Work packages are unique and should not be duplicated across the work breakdown structure

Business Analysis Activities (BA Planning & Monitoring)

Previously we talked about stakeholder analysis, now we will talk about business analysis activities. As a Business Analyst we know or we must plan about our next activities. BABOK is a good foundation to understand more about that business analysis phase.

2.3 Plan Business Analysis Activities

#Purpose
Determine the activities that must be performed and the deliverables that must be produced, estimate the effort required to perform that work, and identify the management tools required to measure the progress of those activities and deliverables.

#Description
The BA Determines which activities are required for a given initiative, how those activities will be carried out, the work effort involved, and an estimate of how long the activities will take. This task includes activities to :

• Identify business analysis deliverables
• Determine the scope of work for the business analysis activities
• Determine which activities the BA will perform and when
• Develop estimates for business analysis work.

#Input
Business Analysis Approach : Defines the lifecycle, deliverables, templates, and tasks that should be included. Plan driven approaches seek to define requirements as early as possible to reduce uncertainty, while change-driven approaches encourage requirements to be defined as close to implementation as possible.

Business Analysis Performance Assessment : The BA must use prior experiences on this initiative or on others to determine the effort involved in performing business analysis work.

Organizational Process Assets : The organizational standards and process assets in place may mandate certain deliverables.

Stakeholder List, Roles, and Responsibilities: Stakeholders will exhibit individual behaviors and preferences that may need to be met. Understanding their roles and responsibilities on the project will help to  determine how much those preferences will shape the plan. The role of each stakeholder must be understood so that the appropriate activities can be scheduled and the necessary time alloted.

#Elements

1. Geographic Distribution of Stakeholders
The BA must consider the physical location of key stakeholders on the same project.

 --Collocated : All key stakeholders are located in the same local geographic area.

 --Dispersed : These more complex projects have some key stakeholders located in different geographic regions or countries.

**If stakeholders are dispersed. It may be necessary to have more teleconferences or video conferences rather than face to face meetings.

2. Type of Project or Initiative
The type of project or initiative to which the BA is assigned may have a significant impact on the activities that need to be performed. Different kinds of business analysis initiatives include, but are not limited to :

• Feasibility studies
• Process improvement
• Organizational change
• New software development (in-house)
• Outsourced new software development
• Software maintenance or enhancement
• Software package selection

3. Business Analysis Deliverables
A list of deliverables is useful as a basis for activity identification. Methods are identifying deliverables include, but are not limited to :

• Interviews or facilitated sessions with key stakeholder
• Review project documentation
• Review organizational process assets, such as methodologies and templates, which may dictate which deliverables are required.

An organization may have a standard set of deliverables, or multiple sets that are used to support different approved methodologies. The breakdown of deliverables may also be dependent on the techniques selected by the BA, and may include deliverables such as interview questions, meeting minutes, use case diagrams, and descriptions, and as-is/ to be business process models.

4. Determine Business Analysis Activities
An important tool in defining the scope of work and in developing estimate is the work breakdown structure (WBS). The WBS decomposes the project scope into smaller pieces, creating a hierarchy of work. A WBS may break down the project into iterations, releases or phases; break deliverables into work packages; or break activities into smaller tasks.

**Click here for further information about WBS..

Work packages include at least one and usually many activities, which can be further broken into smaller tasks. This decomposition activities and tasks creates the activity list.

The activity list can be created in different ways, such as by :

• Taking each deliverable, assigning the activities required to complete the deliverable, and breaking each activity into tasks.
• Dividing the project into phases, iterations, increments, or releases, identifying the deliverables for each, and adding activities and tasks accordingly.

Using a previous similar project as an outline and expanding it with detailed tasks unique for the business analysis phase of the current project.

The elements identified for each activity and task may include :

• Unique Number to uniquely identify each task.
• Activity description labeled with a verb and a noun, and describing the detailed tasks that comprise each activity. For example, an activity might be labeled "Update Requirements Document".

In addition, it may include other information, such as :

• Assumptions : For each task, there may be factors or conditions which are considered to be true. The BA can document these factors, and where present estimates will be development using these assumptions.

• Dependencies : Identify logical relationships, such as which activities have to be completed before subsequent tasks can begin.

• Milestones : Represent significant events in the progress of a project. Milestones are used to measure the progress of the project and compare actual progress to earlier estimates. Milestones can be used as a time to celebrate the completion or delivery of a major deliverable or section of project work. An example of a major milestone is the stakeholders' and sponsor's formal approval of a requirement document.

#Techniques
Estimation (9.10) : A variety of estimation techniques can be used to produce an overall assessment of the amount of business analysis work required.

Functional Decomposition (9.12) : Decomposition of the tasks in a project (using a work breakdown structure) or product (using a solution breakdown structure) can be used to facilitate an understanding of the work at a sufficient level of detail to enable estimation of tasks.

Risk Analysis (9.24) : Identify risks that might impact the business analysis plan(s).

#Stakeholders

Customer, Domain SME, End User and Supplier : Domain SME's will likely be a major source of requirements and their availability is critical when planning activities.

Implementation SME : The implementation SME's may participate in business analysis activities in order to facilitate understanding of stakeholder needs.

Operational Support : May use business analysis deliverables  a basis for planning operational support activities or developing appropriate documentation.

Project Manager : In a project, the business analysis plan is integrated with and a component of the overall project plan.

Tester : Will need to know in what form and when deliverables will be produces as inputs into their own activity planning.

Sponsor : Must participate in the approval of business analysis deliverables.

#Output
Business Analysis Plan(s) : This business analysis plan(s) may include information such as a description of the scope of work, the deliverable Work Breakdown Structure, an Activity List, and estimates for each activity and task.


Next : Business Analysis Communication

Stakeholder Map From DTA & BABOK

This post is some definition and technique taken from Design Thinker Academy and IIBA about stakeholder map. This technique is related with stakeholder analysis. I put some picture taken from 'Google' to enable us understand more about it.

Design Thinker Academy :

In it’s simplest form Stakeholder Mapping will help you to quickly create an overview, an helicopter view, of the stakeholders in your eco-system. An oversight many organizations, or departments do not have visualized and made explicit. It’s an easy way to visualize and understand more of the context you operate in and the eco-system in which value is being created for all stakeholders. It will also allow your team to have conversations and get a shared understanding, develop a shared language, vision and decide on the most important areas for further exploration.

BABOK :

Stakeholder maps are visual diagrams that depict the relationship of stakeholders to the solution and to one another. There are many forms of stakeholder map, but two common ones include :

#A matrix mapping the level of stakeholder influence against the level of stakeholder interest.

#An onion diagram indicating how involved the stakeholder is with the solution (which stakeholders will directly interact with the solution or participate in a business process, which are part of the larger organization, and which are outside the organization)

Example : 

 Stakeholder Onion Diagram

Stakeholder Matrix

RACI Matrix From IIBA BABOK & Wikipedia

Related with business analysis, especially in stakeholder analysis, we need to learn some knowledge and technique. Here are some techniques taken from Wikipedia and IIBA.

Wikipedia :

A responsibility assignment matrix (RAM), also known as RACI matrix or ARCI matrix or linear responsibility chart (LRC), describes the participation by various roles in completing tasks or deliverables for a project or business process. It is especially useful in clarifying roles and responsibilities in cross-functional / departmental projects and processes. RACI and ARCI are acronyms derived from the four key responsibilities most typically used: Responsible, Accountable, Consulted, and Informed.

#Responsible

Those who do the work to achieve the task. There is at least one role with a participation type of responsible, although others can be delegated to assist in the work required.

#Accountable (also approver or final approving authority)

The one ultimately answerable for the correct and thorough completion of the deliverable or task, and the one who delegates the work to those responsible. In other words, an accountable must sign off )approve) on work that responsible provides. There must be only one accountable specified for each task or deliverable.

#Consulted (sometimes counsel)

Those whose opinions are sought, typically SME (Subject Matter Experts) and with whom there is two way communication.

#Informed

Those who are kept up-to-date on progress, often only on completion of the task or deliverable; and with whom there is just one-way communication.

Very often the role that is accountable for a task or deliverable may also be responsible for completing it. Outside this exception, it is generally recommended that each role in the project or process for each task receive, at most, just one of the participation types. Where more than one participation type is shown, this generally implies that participation has not yet been fully resolved, which can impede the value of t his technique in clarifying the participation of each role on each task.

BABOK :

The RACI matrix describes the roles of those involved in business analysis activities. It describes stakeholders as having one or more of the following responsibilities for a given task or deliverable :

#R : Responsible does the work.
#A : Accountable is the decision maker. (Only One)
#C : Consulted must be consulted prior to the work and gives input.
#I : Informed means that they must be notified of the outcome.

Example : 

Wikipedia

Google

Stakeholder Analysis (BA Planning & Monitoring)

Previously we learn about plan business analysis approach. Now, still in "Business Analysis" knowledge from IIBA - BABOK, we will learn about conduct stakeholder analysis. At a glance from the title, this analysis definitely related with person or people. We as a BA will deal with not just a circumstances but also politics (the other name of stakeholder). So let's begin our study.

 

2.2 Conduct Stakeholder Analysis

#Purpose

Covers the identification of stakeholders who may be  affected by a proposed initiative or who share a common business need, identifying appropriate stakeholders for the project or project phase, and determining stakeholder influence and/or authority regarding the approval of project deliverables.

#Description

Stakeholder analysis is performed as soon as a business need identified and will usually be an ongoing activity as long as business analysis continues. Stakeholders may be grouped into categories that reflect their involvement or interest in the initiative. The roles, responsibilities, and authority over the requirements for each stakeholder must be clearly described.

#Input

Businees Need : Identify and analyze the position of the stakeholders affected by the business need.

Enterprise Architecture : Describe the organizational units that exists, their interactions with other organizational units, customers, and suppliers, their responsibilities within the organization, and the roles and relationship within each organizational unit.

Organizational Process Assets : These include organizational policies and procedures, forms that must be completed, suggester or prescribed methodologies, templates, and project authorization guidelines. They may be mandated or expressed in the form of guiding principles.

#Elements
Stakeholder roles must be identified early in the project in order to help ensure timely delivery of requirements deliverables.

1. Identification
Understanding who the stakeholders are and the impact of proposed changes on them is vital to understanding what needs, wants, and expectations must be satisfied by a solution.

2. Complexity of Stakeholder Group
The complexity of interactions with a stakeholder group may be affected by factors such as :

• Number and variety of direct end user.
• Number of interfacing business process and automated system.

3. Attitude and Influence
Assess stakeholder attitudes toward and influence over the initiative. Factors to consider include:

Attitude towards:
 --The business goals, objectives, and solution approach:

• Do they believe that the solution will benefit the organization?
• Will the benefits affect them directly?
• Will the benefits be accrued elsewhere?
• Are the possible negative effects of the initiative on this stakeholder greater than the rewards?
• Do they believe that the project team can successfully deliver the solution?

 --Attitude toward business analysis :

• Do the see value in defining their requirements?
• Do they present solutions and expect the requirements to be contained in that solution and believe that will enable them to avoid requirements definition?

 --Attitude towards collaboration :

• Have they had success on previous collaborative efforts?
• Does the organization reward collaboration?
• Is the organization hierarchical in nature, rather than being team based?
• Are personal agendas the norm?

  --Attitude towards the sponsor :

• On cross-functional efforts, do all the SMEs support the sponsor?
• Are there SMEs who would prefer another sponsor?

 --Attitude roward team members :

• Have key members of the project team built trusting relationships or have there been prior failed projects or projects phases involving those people?

Influence : Understanding the nature of influence and the influence structures and channels within an organization can prove invaluable when seeking to build relationships and work towards building trust.

• Influence on the project. How much influence does the stakeholder have on the project?
• Influence in the organization. Authority or positional power.
• Influence needed for the good of the project. The BA should analyze how much influence is needed to make the project succeed compared with the amount of influence the key stakeholders, such as the project sponsor have.
• Influence with the other stakeholders. Within most organization there is an informal way influence occurs. It is best to be aware of this informal influence structure.

4. Authority Levels For Business Analysis Work
Identify which stakeholders will have authority over business analysis activities, in relation to both business analysis work and product deliverables. Stakeholders may have authority to :

• Approve the deliverables
• Inspect an approve the requirements
• Request and approve changes
• Approve the requirements process that will be used
• Review and approve the traceability structure
• Veto proposed requirements or solutions

#Techniques

1. General Techniques

• Acceptance and Evaluation Criteria Definition (9.1) : The BA should, as part of the stakeholder analysis, identify which stakeholders have sufficient authority to accept or reject the solution.

• Brainstorming (9.3) : May assist in identifying needs and requirements that lead to possible stakeholders, or in creating a listing of possible stakeholder roles.

• Interviews (9.14) : Interviewees may be able to identify other stakeholders.

• Organization Modeling (9.19) : Assess to determine if the organizational units or people listed have any unique needs and interests that should be considered.

• Process Modeling (9.21) : Any person involved in the execution of business processes affected by the solution will be a stakeholder.

• Requirements Workshop (9.23) : During requirements workshop, the BA may ask participants if they can suggest other stakeholders.

• Risk Analysis (9.24) : Risks to the initiative may result from stakeholder attitudes or the ability of key stakeholders to participate in the initiative.

• Scenario and Use Cases (9.26) and User Stories (9.33) : Identified stakeholders roles may serve as a useful starting point for identifying actors and roles.

• Scope Modeling (9.27) : Scope models should know stakeholders that fall outside the scope of the solution but sill interact with it in some way.

• Survey / Questionnaire (9.31) : Useful for identifying shared characteristics of a stakeholder group.

2. RACI Matrix

The RACI matrix describes the roles of those involved in business analysis activities. It describes stakeholders as having one or more of the following responsibilities for a given task or deliverable :

R : Responsible
A : Accountable
C : Consulted
I : Informed

3. Stakeholder Map

Stakeholder maps are visual diagrams the depict the relationship of stakeholders to the solution and to one another.

#Stakeholders

• Domain SME : May be able to recommend other business experts to assist in defining requirements.
• Implementation SME : May be able to identify and recommend stakeholders.
• Project Manager : May be able to identify and recommend stakeholders.
• Tester : May be able to identify and recommend stakeholders.
• Regulator : May require that specific stakeholder representatives or groups be involved in the process.
• Sponsor : May be able to identify domain subject matter experts to help with requirements definition.

#Output

• List of required roles 
• Names and titles of stakeholders 
• Category of stakeholder
• Location of stakeholder
• Special needs
• Number of individuals in thee stakeholder role
• Description of stakeholder influence and interest
• Documentation of stakeholder authority levels

Next : Business Analysis Activities