Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Mine 1,2,3


Shraiz Elias

on 21 October 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Mine 1,2,3


By: Shiraz Elsaid
Bsc. & MSc Computer Sciences, Khartoum University
Core Banking System
1. Briefing on the project
2. Preparing the RFP
3. Prepare the vendor list from the top 50 core banking
4. Request LOI from the vendor list
5. Prepare the short
6. Prepare the short list
7. Arrange for the walk through sessions in order for the vendor to demonstrate their systems
8. Lessons Learned
9. My own benefits, lessons, experience
10. Project Pics

Bank of Khartoum (BOK) with 17 branches in the capital and 33 branches nationwide is the biggest bank in Sudan.
Briefing on the project
PMI Professional in Business Analysis (PMI-PBA®).
What is Business Analysis (BA) PMI-PBA ?
Business Analysis is the evaluation of an organization’s needs—followed by the identification and management of requirements—to arrive at a solution.

In short, business analysis is the set of activities performed to identify business needs and recommend relevant solutions; and to elicit, document, and manage requirements
What is Business Analysis (BA) ?
Requirements are an inherent aspect of Project Management (and Program Management) and Business Analysis is an important function that identifies, analyzes, and manages those requirements in order to ensure the goal of the project is achieved
How is Business Analysis related to project management?

Discusses the business analysis work that is conducted to analyze a current business problem or opportunity and to assess the current internal and external environments of the organization for the purpose of understanding that needs to occur in order to attain the desired future state.
Discusses the work that is conducted in order
to define the business analysis approach and plan for the completion of the requirements-related activities necessary to meet the needs of the project.

Discusses the iterative nature of the work performed to plan, prepare, and conduct requirements elicitation and to analyze and document the results of that work. A number of elicitation and analysis techniques are defined and explained.
Provides a formal requirements change process and
discusses how changes to requirements are analyzed, assessed, approved, communicated, and managed throughout a project. Baselining requirements, impact analysis, configuration management, and version control are also addressed.
Discusses the business analysis tasks that are performed to validate a solution that is either implemented or ready to be implemented. This section focuses on both qualitative and quantitative evaluation methods; discusses how evaluation criteria and acceptance levels are used to perform an evaluation of the solution
Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements.
Business analysis is the application of knowledge, skills, tools, and techniques to:
Determine problems and identify business needs;
Identify and recommend viable solutions for meeting those needs;

Elicit, document, and manage stakeholder requirements in order to meet business and project objectives;
Facilitate the successful implementation of the product, service, or end result of the program or project.
Analytical skills
Business and Industry Knowledge

Conflict Management
Cultural Awareness
Decision Making
Familiarity Project Management
Issue Management
Learning Skills
Presentation Skills
Systems thinking
Definition of Requirement :
In the PMBOK® Guide – Fifth Edition, the term requirement is defined as:

“a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.

A requirement represents something that can be met by a product or service, and can address a need of the business, person, or group of people.
A requirement should be independent of the design of the solution that addresses it.
A requirement may explain a feature that is to be met by a product or software component.
When a specific type of requirement is under discussion, the term requirement is preceded by a qualifier such as stakeholder, business, or solution.
Who has the Responsibility for the Requirements?
The responsibility for defining requirements should be assigned to resources that have sufficient business subject matter expertise and decision-making authority.
The project manager is accountable for ensuring that requirements-related work is accounted for in the project management plan and that requirements-related activities are performed on time and within budget and deliver value.
Requirement Types
Product requirements
: are the primary focus of Business Analysis role and can be further categorized with additional qualifying terms.
In the PMBOK ® Guide – Fifth Edition, the primary types of requirements discussed include :
Business Requirements:
Describe the higher-level needs of the organization as a whole, such as business issues or opportunities, and reasons why a project has been undertaken.
Solution Requirements:
Describe the features, functions, and characteristics of a product, service, or result that will meet the business and stakeholder requirements
Functional Requirements:
Describe the behaviors of the product.
Nonfunctional Requirements:
Describe the environmental conditions or qualities required for the product to be effective.
Transition Requirements:
Describe temporary capabilities, such as data conversion and training requirements, and operational changes needed to transition from the current state to the future state
Requirement Types
Over10 years of experience in the banking sector in the areas of IT projects management, business analysis, products development and business process re-engineering
Products & Business Development Manager, Bank of Khartoum
Projects: ATM National Switch, Currency conversion, Core Banking, Cash Management system, BOK Strategic Plan, ...etc
Introduce Yourself ;





Education Background :

Why are you here ?

Project Management Institute is the world's leading not-for-profit professional membership association for the project, program and portfolio management profession.
Founded in 1969, PMI delivers value for more than 2.9 million professionals working in nearly every country in the world through global advocacy, collaboration, education and research.
Inaccurate requirements gathering is the second highest cause of project failure yet only half of organizations have the resources in place to perform this function properly,

According to PMI Pulse of the Profession® research. Through 2019, over half of organizations expect to see an increase in their demand for BAs and the integration of requirements management and business analysis with project management.
Problem /
Business Analysis
The person(s) who performs business analysis tasks (regardless of the person’s title) in the context of programs and projects will be referred to as a business analyst
Who Performs Business Analysis?
In order to perform the business analysis role effectively a number of varied skills and competencies are needed.
Project Requirements ,
Quality Requirements,
Product Requirements
The following requirement types are assumed to be in scope for the elicitation and analysis efforts on projects
PMI-PBA Five Domains
1. Needs Assessment
2. Planning
3. Analysis
4. Traceability and Monitoring
5. Evaluation
Domain 1 : Needs Assessment

• Why Perform Needs Assessments
• Identify Problem or Opportunity
• Assess Current State of the Organization
• Recommend Action to Address Business Needs
• Assemble the Business Case

Domain 2 : Planning
• The Importance of Business Analysis Planning
• Conduct or Refine the Stakeholder Analysis
• Create the Business Analysis Plan
• Plan the Business Analysis Work

Domain 3: Analysis
• What it Means to Elicit Information
• Plan and Prepare for Elicitation
• Conduct Elicitation Activities
• Document Outputs from Elicitation Activities
• Complete Elicitation
• Elicitation Issues and Challenges
• Analyze Requirements
• Model and Refine Requirements
• Document the Solution Requirements
• Validate and Verify Requirements
• Approval Sessions
• Resolve Requirements-Related Conflicts

Domain 4: Traceability and Monitoring
• Traceability
• Relationships and Dependencies
• Approving Requirements
• Baselining Approved Requirements
• Monitoring Requirements Using a Traceability Matrix
• The Requirements Life Cycle
• Managing Changes to Requirements

Domain 5 : Evaluation
• Purpose of Solution Evaluation
• Recommended Mindset for Evaluation
• Plan for Evaluation of the Solution
• Determine What to Evaluate
• When and How to Validate Solution Results
• Evaluate Acceptance Criteria and Address Defects
• Facilitate the Go/No-Go Decision
• Obtain Signoff of the Solution
• Evaluate the Long-Term Performance of the Solution
• Solution Replacement/Phase out

Discusses the business analysis work that is conducted to analyze a current business problem or opportunity and to assess the current internal and external environments of the organization for the purpose of understanding that needs to occur in order to attain the desired future state.

Domain 1 : Needs Assessment

• Why Perform Needs Assessments

• Identify Problem or Opportunity

• Assess Current State of the Organization

• Recommend Action to Address Business Needs

• Assemble the Business Case
1. Why Perform Needs Assessments
Our Reference for PMI-PBA
" Business Analysis for Practitioners -
A Practice Guide "
Needs assessments are performed to examine the business environment and address either a current business problem or opportunity.
Needs assessment work is undertaken before program or project work begins, therefore it is said to involve the pre-project activities.
Identify Stakeholders

Investigate the Problem or Opportunity

Gather Relevant Data to Evaluate the Situation

Draft the Situation Statement

Obtain Stakeholder Approval for the Situation Statement
2: Identify Problem or Opportunity
The analysis completed during the needs assessment is then used for the development of a business case
The needs assessment and business case that build the foundation for determining the project objectives and serve as inputs to a project charter.
Identify Stakeholders
A stakeholder is an individual, group, or organization
that may affect, be affected by, or perceive itself
to be affected by a decision, activity, or outcome of a program or project
Sponsor who is initiating and responsible for the project,

Stakeholders who will use the solution,

Stakeholders whose role and/or activities performed may change as a result of the solution,

Stakeholders who may regulate or otherwise constrain part or all of a potential solution,

Stakeholders who will implement the solution,

Stakeholders who will support the solution.
The affected stakeholders for a needs assessment can be categorized into one of four categories using a responsibility assignment matrix such as a RACI model
Identify Stakeholders
R—Responsible. A—Accountable. C—Consult. I—Inform.

Investigate the Problem or Opportunity
Collaboration Point
—Both project managers and business analysts have an interest in stakeholder identification and RACI analysis.
The business analyst focuses on learning enough about the problem or opportunity to adequately understand the situation,
avoids conducting a complete requirements analysis at this stage.
with stakeholders to investigate the situation and learn about the current environment.

any existing
about current processes, methods, or systems that support the business unit.
Process modeling
(document the "as-is" process)
: monitor or observe the business performing their work in order to discover elements of the current “as-is” process.
Gather Relevant Data to Evaluate the Situation
• Once a broad understanding of the situation is obtained : “
sizing up
” the situation
When no internal data exists or when it cannot be feasibly collected -----> benchmarking
“Benchmarking is a comparison of the metrics or processes from one organization against a similar organization in the industry that is reporting or finding similar industry averages”
• Once the desired data is assembled, techniques such as Pareto analysis and trend analysis can be used to analyze and structure the data
"Pareto : This technique helps to identify the top portion of causes that need to be addressed to resolve the majority of problems "80/20" rule "
Draft the Situation Statement
Once the problem is understood, the business analyst should draft a situation statement by documenting the current problem that needs to be solved or the opportunity to be explored
The format of a situation statement is as follows :
Problem (or opportunity) of “a”
Has the effect of “b”
With the impact of “c”
Example :
Consider an insurance company that is interested in reducing the processing times and costs for automobile and homeowner claims.
Like many companies, this insurance carrier took advantage of new technologies across its business and has an extensive Internet presence. The organization now wants to exploit mobile technology to improve its claims processing.

The cost for processing claims has been rising steadily
, increasing at an average rate of 7% per year, over the last 3 years. The existing method for submitting claims either by phone or the Internet involves significant
processing delays
and has resulted in the
need to increase staffing to process the calls and personally investigate the claims
Situation Statement
Situation Statement
Obtain Stakeholder Approval for the Situation Statement
Once the situation statement is drafted, agreement is obtained from the affected stakeholders that were previously identified.

The business analyst initiates and facilitates the approval process, which may be formal or informal, depending on the preferences of the organization.

The business analyst leverages skills such as
, and
decision making
to lead stakeholders through this process.
3. Assess Current State of the Organization
Assess Organizational Goals and Objectives
SWOT Analysis
Relevant Criteria

Perform Root Cause Analysis on the Situation
Determine Required Capabilities Needed to Address the Situation
Assess Current Capabilities of the Organization
Identify Gaps in Organizational Capabilities
Once the relevant stakeholders agree on the problem that needs to be solved or the opportunity the organization wishes to exploit, the situation is analyzed in greater detail to discover important components such as the root causes of the problems identified in the situation statement.
Understand Organizational Goals and Objectives
Root causes of Problems that prevent achievement
Assess Organizational Goals and Objectives
Review business strategy documents and plans in order to
Potential new products or services
Understanding of the industry and its markets
The competition
Products and services currently available
In the absence of such plans, interview stakeholders
Goals and objectives that are relevant to the situation provide the context and direction for any change or solution that addresses the business need.
Goals and Objectives
: are typically broad-based and may span one or more years.
Objectives :
on the other hand, are used to enable goals; these are more specific and tend to be of shorter term than goals, often with durations of 1 year or less
Programs and projects are linked to the goal and objectives through the business case.

Consider an insurance company that is interested in reducing the processing times and costs for automobile and homeowner claims.
— The company had a goal of reaching $5 billion in revenue within 5 years, with a 20% net profit margin.
• Increase revenues by 10% by December 31 necessary to
help them reach their 5-year goal),

• Decrease overall claims costs by 5% in the same time period,
• Reduce time needed to process claims by 6.25% in each
quarter of the year.
The company also had the following supporting objectives for the coming year:
SMART Goals and Objectives
If goals and objectives are not specified or are not clear, the business analyst should document them to establish the basis for subsequent work that relies on them. Well-written goals and objectives are also said to be “SMART”
SWOT Analysis
In the absence of formal plans, the business analyst may use SWOT analysis to help assess organizational strategy, goals, and objectives.
SWOT (Strengths, Weaknesses, Opportunities, Threats) is a common method used to facilitate discussions with stakeholders when articulating high-level and important aspects of an organization, especially as it pertains to a specific situation
SWOT helps to translate organizational strategy into business needs
Perform Root Cause Analysis on the Situation
After agreeing on the problem to be solved, the business analyst needs to break it down into its root causes or opportunity contributors so as to adequately recommend a viable and appropriate solution.

An analytical technique used to determine the basic underlying reason that causes a variance, defect, or risk.

When applied to business problems, root cause analysis is used to discover the underlying cause of a problem so that solutions can be devised to reduce or eliminate them.
• Five Whys
• Cause-and-Effect Diagrams
Root Cause Analysis:
Relevant Criteria
Goals and objectives provide criteria that may be used when making decisions regarding which programs or projects are best pursued.
—One objective of the insurance company is to increase revenues 10% by December 31. In this case, revenue is a highly relevant criterion.
The organization needs to sell new insurance policies and possibly expand its markets; therefore, programs or projects that improve sales will be significant.
Initiatives that support expense reduction are very important too because the company also needs to reduce expenses.
Criteria that were identified when reviewing the organizational goals and objectives will be useful later when comparing and rank-ordering potential solution options.
Five Whys
Talichi Ohno, the creator of the 5-Why technique
The objective of Five Whys is to ask for the cause of a problem up to five times or five levels deep to truly understand it.
1. “Why did the robot stop?”
The circuit has overloaded, causing a fuse to blow.

2. “Why is the circuit overloaded?”
There was insufficient lubrication on the bearings, so they locked up.
3. “Why was there insufficient lubrication on the bearings?”
The oil pump on the robot is not circulating sufficient oil.
4. “Why is the pump not circulating sufficient oil?”
The pump intake is clogged with metal shavings.
5. “Why is the intake clogged with metal shavings?”
Because there is no filter on the pump.
What do you think? Is “NO FILTER ON THE PUMP” a root cause?
Cause-and-Effect Diagrams
Cause-and-effect diagrams decompose a problem or opportunity to help trace an undesirable effect back to
its root cause. These diagrams help to break down the business problem or opportunity into components to aid understanding and generally provide the main aspects of the problem to analyze.
Fishbone Diagrams

Interrelationship Diagrams
Fishbone Diagrams
Formally called Ishikawa diagrams,
these diagrams are snapshots of the current situation and high-level causes of why a problem is occurring. These diagrams are often a good starting point for analyzing root cause.
Interrelationship Diagrams
This special type of cause-and-effect diagram is helpful for visualizing complex problems that have seemingly unwieldy relationships among multiple variables.
• Process Flows
The interrelationship diagram can help stakeholders understand the relationships between causes and effects and can identify which causes are the primary ones producing the problem.
The arrows represent the direction of the cause.
The arrow starts from the cause factor and points to the effect.
When two factors influence each other, understand which of the two is stronger
Process Flows
Process flows are used for many things, primarily to document and analyze current and future (e.g., proposed) processes. Another use for these models is to analyze a process for the ways in which a current process contributes to a given problem
Determine Required Capabilities Needed to Address the Situation
Once the root causes or contributors to a situation are known, the methods to correct them and/or take advantage of opportunities can be specified
When formal root cause analysis is not performed, business people may “jump to solutions” to solve their perceived problems. The result is often adding new capabilities that address only part of a situation and may also be more expensive than needed.
Capability Table
Affinity Diagram
Capability Table
Capability table, where the business analyst lists each limiting factor or problem, specifies the associated root causes, and then lists the capability or feature required to address the problem

Affinity Diagram
For problem solving, an affinity diagram is used to help organize and structure major cause categories and organize them by the capabilities needed to solve them.
Affinity diagrams show categories and subcategories of ideas that cluster or have an affinity to each other.
Another way to determine new capabilities
is to conduct benchmarking studies of external organizations that solved similar problems or seized opportunities that the organization is considering.
Benchmarking studies often guide final recommendations to address the situation as well as highlight which recommendations not to make.

The insurance company could discover through benchmarking
that a competitor offers video chat sessions between customers and their claims adjuster. This discovered capability should be scrutinized to determine the amount of value it would add to the potential solution under consideration

Assess Current Capabilities of the Organization
Once it is known which capabilities are needed to correct a situation, it is necessary to determine the organization’s current capabilities. The organization may have the necessary capabilities to resolve a situation without needing to add new ones.
Process flows
: Performing “as-is” process analysis or reviewing existing models
Enterprise and business architectures :
Enterprise and business architectures are methods to describe an organization by mapping its essential characteristics such as people, locations, processes, applications,data, and technology
Capability frameworks :
A capability framework is a collection of an organization’s capabilities, organized into manageable pieces, similar to business architecture.
Enterprise and business architectures
Capability frameworks Example
Identify Gaps in Organizational Capabilities
After identifying needed capabilities and assessing current capabilities related to a given situation, any gaps or missing capabilities that exist between the current and needed states are the capabilities that need to be added.
Gap analysis :
is the technique of comparing the current state to the future state to identify the differences or gaps.
In the insurance company example, at this stage of the needs assessment, the business analyst is analyzing the current capabilities to the list of needed capabilities in order to identify the capabilities that are missing to achieve the desired future state.
The needed capabilities that are required to solve the business problem become the rationale for creating a program or project.
These capabilities are commonly referred to as the “to be” features and functions and are easily identified by performing this gap analysis.
4. Recommend Action to Address Business Needs
Include a High-Level Approach for Adding Capabilities
Provide Alternative Options for Satisfying the Business Need
Identify Constraints, Assumptions, and Risks for Each Option
Assess Feasibility and Organizational Impacts of Each Option
Recommend the Most Viable Option
Conduct Cost-Benefit Analysis for Recommended Option
Include a High-Level Approach for Adding Capabilities
A complete recommendation includes a high-level proposal stating how the needed capabilities will be acquired.
This approach is not a detailed project management plan and
does not
include the level of detail in a project charter.
It is a suggested path for adding the capabilities
The business analyst should solicit preliminary
feedback from business and technical architects
when the recommendation is going to include new or modified hardware
or software.
Provide Alternative Options for Satisfying the Business Need
While there are often multiple approaches for adding new capabilities, a recommendation should include all of the most viable options.
The business analyst evaluates and analyzes all the information gathered during the needs assessment to produce multiple possible solutions.

Another reason for including alternatives is because the preferred approach may not be acceptable.
The primary reason for providing alternatives is to show that the alternatives were considered and to forestall objections from those who favor them.
Business analyst does not decide which solution may be the best one, the business analyst is usually expected to make a recommendation and to support the recommendation with facts and evidence.
Identify Constraints, Assumptions, and Risks for Each Option
Business analysts may draw on a project manager’s expertise in risk planning and mitigation. Both roles are concerned with risk management.

Collaboration Point
Project managers are focused on assessing the risks of the project as a whole, while the business analyst is focused on assessing the product risks.
Constraints :
are any limitations on a team’s options to execute a program or project and may be business- or technical-related.
Ex: if a time constraint to deliver a solution is imposed on a potential project, a custom-built solution may not be a viable option and would
need to be removed or, at best, not be listed as a preferred option
Assumptions :
are factors that are considered to be true, real, or certain, without actual proof or demonstration.
If any assumptions are proven to be incorrect, it is important to reassess the identified needs or perhaps the entire business case
Risks :
are uncertain events or conditions that may have a positive or negative effect on one or more project objectives if they occur.
Major risks for each alternative should be noted along with potential mitigation strategies and their costs
Assess Feasibility and Organizational Impacts of Each Option
Before deciding which option is preferred, the business analyst assesses the feasibility of each potential option.
The assessment involves comparing potential solution options for how viable each appears to be on key variables or “feasibility factors”
Operational Feasibility
Technology/System Feasibility
Cost-Effectiveness Feasibility
Time Feasibility
The business analyst assesses the feasibility factors of each prospective solution option
to determine how well these options contribute to the goals and objectives assessed
Recommend the Most Viable Option
After examining potential options for addressing a business need, the
business analyst needs to recommend the most viable option.
Assuming that more than one option remains viable after feasibility
analysis, the business analyst should recommend the most feasible option.
Ranking two or more options can be done using various techniques method such is to use a weighted ranking matrix..
When faced with two or more feasible options for solutions, the remaining choices can be rank-ordered based on how well each one meets the business need.
Conduct Cost-Benefit Analysis for Recommended Option
Before recommending a preferred option, a cost-benefit analysis should be performed. The expected project benefits and costs
need to be articulated in greater detail during a cost-benefit analysis than during a feasibility analysis
Payback Period (PBP)
Return on Investment (ROI)
Internal Rate of Return (IRR)
Net Present Value (NPV)
5. Assemble the Business Case
Organizations often have their own standards for what to include in a business case and will employ a set of templates or business case
software to simplify and standardize the process.
Specify what is prompting the need for action. Use a situation statement or similar way to document the business problem or opportunity to be accrued through a program or project. Include relevant data to assess the situation and identify which stakeholders or stakeholder groups are affected.
The analysis performed in the business case helps organizations select the best programs and projects to meet the needs of the business. Business cases help organizations scrutinize programs and projects in a consistent manner. When this process is embraced, organizations will consistently make better decisions
Executives in an organization may approve programs and projects based on competitive pressure, government mandate, or executive inclination. In those cases, a project charter to initiate a program or project is sufficient
Business Case Main Component
Analysis of the Situation:
Organizational goals and objectives are listed to assess how a potential solution supports and contributes to them. Include root cause(s) of the problem or main contributors of an opportunity. Support the analysis through relevant data to confirm the rationale. Include needed capabilities versus existing capabilities. The gaps between them will form the program or project objectives
Business Case Main Component
Present results of the feasibility analysis for each potential option. Specify any constraints, assumptions, risks, and dependencies for each option. Rank-order the alternatives and list the recommended one; include why it is recommended and why the others are not. Summarize the cost-benefit analysis for the recommended option. Include the implementation approach, including milestones,dependencies, roles, and responsibilities
Include a plan for measuring benefits realization. This plan typically includes the metrics to evaluate how the solution contributes to goals and objectives. It may necessitate additional work to capture and report those metrics
Value of the Business Case
When a business case is created, it becomes a valued input to project initiation, providing the project team with a concise and comprehensive view of the business need and the approved solution to that need.
A business case is a living document that is constantly referenced throughout a program or project of work. It may be necessary to review and update a business case based on what is discovered as a program or project progresses over time
When a business case is inadequate or nonexistent, the product scope may be unclear or poorly defined. This in turn often leads to scope creep, which results in rework, cost overruns, and project delays
Collaboration Point
Business analysts work closely with the sponsor to create a business case. When the project manager is known, the business analyst consults with the project manager to achieve a stronger business case through close collaboration.
Discusses the work that is conducted in order
to define the business analysis approach and plan for the completion of the requirements-related activities necessary to meet the needs of the project.

Domain 2 : Planning
• The Importance of Business Analysis Planning

• Conduct or Refine the Stakeholder Analysis

• Create the Business Analysis Plan

• Plan the Business Analysis Work

Why do we plan for the Business Analysis ?
• To ensure that the
optimal business analysis approach
is selected
for the project
• Stakeholders are thoroughly identified and analyzed
• Business analysis activities and deliverables are defined and agreed to
• Processes that will be used for validating, verifying, and approving
requirements and solutions are acceptable to key stakeholders
• The process for proposing changes to requirements is defined
and understood
• Key stakeholders are aware of and support the activities and time
commitments required to complete the requirements effort
The business analysis approach
is simply the method the business analyst uses when managing and performing the business analysis activities on the project. As described later in this section, the approach is described within the business analysis plan

Business analysts who begin elicitation sessions without a well thought out roadmap of how they will address the work will often find themselves pressed for time and rushing through activities to meet a schedule to the detriment of the project

Business analysis planning achieves the following
Sets expectations with the sponsor, project team, and key stakeholders as to the business analysis activities that will be performed
Ensures that roles are identified, understood, and communicated to everyone participating in the business analysis process
Achieves buy-in and support for the business analysis process before work begins
Provides context to support estimation of the business analysis activities
Produces a more efficiently run business analysis process, because activities are not missed or excessively performed
Too much planning can be counterproductive, therefore the business analyst needs to plan a sufficient level of detail to address the specific needs of the project such as the size, complexity, and risk level
Business Analysis Planning and Project Management Planning
Business analysis planning and scheduling is not performed independent of project management scheduling activities. It is a best practice to have the project manager and business analyst working closely together while the business analysis approach and plan is formulated

Business analysts will develop a work plan to cover the activities they are responsible for performing; however, the work plan should be integrated into the overall project management plan managed by the project manager

Conduct or Refine the Stakeholder Analysis
Techniques for Identifying Stakeholders
• Brainstorming
• Organizational Charts
Determine Stakeholder Characteristics
• Attitude
• Complexity
• Culture
• Experience
• Level of Influence
• Location and Availability
Techniques for Grouping or Analyzing Stakeholders
• Job Analysis
• Persona Analysis
Assemble the Stakeholder Analysis Results
Stakeholder analysis is often conducted during the planning phase so that the project team can understand the Stakeholder impacts and influences on the business analysis process as early as possible.
Stakeholder Analysis
Stakeholder analysis is performed iteratively and is revisited throughout the project as new stakeholders are discovered or existing stakeholders are determined to no longer be impacted by the proposed solution.

Early planning will produce the initial stakeholder list, but further stakeholder identification will maintain the list. When there are a large number of
stakeholders identified, stakeholder analysis may involve grouping the list by common characteristics which helps to streamline analysis

Collaboration Point
Kraft entered the Chinese market in 1984, intending to build a $1 billion business based on the company’s existing roster of successful products. By 2006 revenue had reached only a tenth of that goal, and the business was losing money.
Kraft Story in China
To turn the situation around, Kraft sent in three senior leaders to head up a “blank check” initiative, which gave them the freedom within a set time frame (12 months) to make any changes they saw fit.
Business Analysis Planning

Would an Oreo still be an Oreo if it weren’t round? Or if it were made up of different flavors?”
they asked,

The three spent time talking to consumers in order to understand their problems and to begin considering solutions and workable business models. On the basis of the initial insights they gained, they floated a questions:
Kraft Story in China
After field research indicated that consumers in China found the cookies too bitter and the filling too sweet.
Kraft Story in China
Eventually the willingness to rethink boundaries paid off as revenue swelled sixfold and Oreo became the number one cookie brand in China
The innovation team needed to develop more
than 20 prototypes of the Oreo for the Chinese market.
Among the successful variations were not only familiar tweaks,
like smaller package sizes and a less sweet version, but also entirely different flavors (including peanut butter and green tea ice cream), a version with many layers, and one in the shape of a drinking straw.
Kraft Story in China

Sudanese Example
Your Thought ?
Organizational Charts
: The business analyst reviews the chart to locate stakeholder groups who may be impacted by the product or service. This may include departments who operate or maintain a system, produce a product or service,
support customers,
or influence product or service decisions
within the area under analysis.
Techniques for Identifying Stakeholders
Brainstorming :
Brainstorming is a data gathering technique that can be used to identify a list of ideas in a short period of time
(e.g., list of risks, stakeholders, or solutions to issues) .

Common techniques that can be used in the discovery of stakeholders are Brainstorming, decomposition modeling, interviews, surveys, or organizational modeling.
Brainstorming is conducted in a group environment and is led by a facilitator
A topic or issue is presented and the group is asked
to generate as many ideas or solutions as possible
about the topic. Ideas are provided freely and rapidly
and all ideas are accepted

Techniques for Identifying Stakeholders
Determine Stakeholder Characteristics
Level of Influence
Location and Availability
After developing or refining the stakeholder list, the business analyst analyzes the characteristics for the stakeholders identified. The list of characteristics is almost endless, so the analyst will choose those that have the most significance or most relevance to the project
Uncovering stakeholder likes and dislikes may even bring to the forefront unspoken concerns about the proposed business analysis process.
Consider analyzing stakeholder attitudes to identify which stakeholders support the project and proposed solution and which stakeholders do not.
Stakeholders who are positive about the project and solution may serve as project champions; these stakeholders will assist the project team in building excitement and support for the solution.

Identifying non-supportive stakeholders can help identify areas where additional collaboration is needed. Spending more time with these stakeholders may uncover unspoken business needs, requirements, training issues, resource constraints, or past and current experiences important for the project team to understand
A stakeholder group can be considered complex for a number of reasons, including but not limited to whether the group
Is comprised of a large number of stakeholders
Is made up of stakeholders with widely different needs
Has a number of business processes impacted by the project
Exhibits a lack of uniformity across business processes
Interacts with a number of business units to complete their work
Performs work across a number of IT systems, and/or systems external to the organization
PMI’s Pulse of the Profession ® In-Depth Report: Navigating Complexity

Understanding complexity levels will help
when determining the right amount of requirements-related documentation to produce
when determining the level of formality to apply in those deliverables.
when quantifying and planning the number of requirement sessions to conduct
Complexity levels are also helpful to understand when assessing solution options and the change impacts that a project will have on stakeholder groups
Collaboration Point

Consider the cultural diversity that exists among stakeholders and make necessary adjustments to the business analysis process to ensure these differences are considered
Many aspects of culture may be worthy of analysis,
including age, nationality, or group, departmental, or organizational culture
Culture can impact how the business
analyst proposes communicating with stakeholders, eliciting requirements, conducting requirement walkthroughs,
and running the prioritization, approval, and change processes
Cultural differences impact how stakeholders
Perform their work
Interact with other team members
Contribute to the decision-making process
Interpret nonverbal communication
Understand the primary written and spoken language of the team,
Question or interact with authority,
View their role on the team
Raise questions or issues
Negotiate, and Deal with conflicts
Level of Influence
Understanding the amount of influence
a stakeholder has within an organization
helps to identify where influence can serve
as a motivator as much as it can serve to distract or deter others from embracing the work of the project team
Through this analysis, the business analyst will be able to identify influential stakeholders and areas where more time needs to be spent on building relationships and collaborating with key individuals
A person’s level of influence not solely associated to a person’s rank, reporting structure, or job title also affected by business relationships, reputation, knowledge or level of experience, or successes within the organization
Location and Availability
The business analyst should review the stakeholder list
and identify where each stakeholder is based and the
locations from which each conducts their work.
If stakeholders work from multiple locations, then the frequency that stakeholders work from each location should be noted.
Location affects a number of business analysis planning decisions such as:
Determining the techniques that are most effective to elicit requirements,
Estimating how much time is required to complete business analysis activities
Deciding on the formality and level of detail required for the business analysis deliverables
Deciding on the types of models to use

Determining the approach and frequency of collaboration
Determining how requirements will be managed, maintained, and shared with project stakeholders.
Techniques for Grouping or Analyzing Stakeholders
Stakeholders can be grouped once their characteristics are nderstood.Groupings can be structured by similar interests, common needs, level of importance, by roles, motivations, complexity level, location or many other qualities.
There are several techniques that can be used to group or analyze stakeholders such as job analysis, organizational modeling, personas, process modeling, risk analysis, and stakeholder maps
Persona Analysis
Job Analysis
Job Analysis
Job analysis :
is a technique used to identify the job requirements and competencies needed to perform effectively in a specific job or role. The technique is often used when a new job is created or when an existing job is modified
When the project entails the creation of a new job, job analysis may be used to specify the tasks required for the new role.
Business analysts can review the job analysis to understand how particular roles are performed by stakeholders.
When the project entails replacing or revising workflow and business processes, the business analyst uses the job analysis to understand how the existing job is currently performed
Persona Analysis
Persona analysis :
is a technique that is
conducted to analyze a class of users or process workers
Assemble the Stakeholder Analysis Results
As stakeholder characteristics are analyzed, the business analyst may choose to document the results of the analysis
in a way that can be shared with the project
manager, project team, and sponsor
Much of the information being gathered and
analyzed could be considered sensitive in
nature; therefore, the business analyst should exercise care when distributing the analysis to a broad distribution group
The additional stakeholder characteristics shared after the stakeholder analysis provides the project team with insights for determining how best to collaborate and work with the stakeholders throughout the entire project life cycle, especially during the business analysis activities

A business analysis plan is created to document how the business analysis process will be performed, including the plan decisions agreed to by the project team.

Create the Business Analysis Plan
While it is often not possible to obtain requirements for every stakeholder on the stakeholder list, it becomes necessary to group the list of stakeholders into various user classes and then build a persona for each class.
The objective is to analyze usage information or draw out user requirements to determine how a user class interacts with a system or how a user class would use a product.
The plan can be constructed formally and be reviewed and approved by the project team or the document can be more informal, simply serving as a record of team decisions.
Much value is obtained when building the plan as a team and in collaboration with the stakeholders
involved in the business analysis activities
Create the Business Analysis Plan
Collaboration Point :
A plan that is constructed by the team
provides a sense of ownership to those involved and sets expectations by bringing awareness to how the work will be performed.
Business Analysis Plan vs. Requirements Management Plan
What to Include in the Business Analysis Plan
Understand the Project Context
Understand How the Project Life Cycle Influences Planning Decisions
Leverage Past Experiences When Planning
Plan for Elicitation
Plan for Analysis
Define the Requirements Prioritization Process
Define the Traceability Approach
Define the Communication Approach
Define the Decision-Making Process
Define the Requirements Verification and Validation Processes
Define the Requirements Change Process
Define the Solution Evaluation Process
Business Analysis Plan vs. Requirements Management Plan
In the project management discipline, a requirements management plan is a component of the project management plan and describes how the overall requirements of the project will be elicited, analyzed, documented,
and managed across the project for both
Products & Project Requirements

In the business analysis discipline, the requirements management plan referred to a document that contained planning decisions about how requirements were to be stored and maintained, as well as decisions about baselining, updating, and change impact analysis in addition to how requirements will be elicited, analyzed, documented, and managed across the project.. It called
Business Analysis Plan

Collaboration Point
The business analysis plan works in conjunction with the requirements management plan.
What to Include in the Business Analysis Plan
The business analysis plan is focused on the scope of the business analysis effort. This includes :
List of the activities to be conducted
The business analysis deliverables to be produced.
List of the roles required to successfully conduct the business analysis process
Key process decisions are also included, the approach for prioritizing, documenting, validating, communicating, approving, and changing requirements.
Where team members disagree with one or more of the decisions being made, the
business analyst assumes responsibility for negotiating and bringing the team to consensus
Once decisions are made, these should be documented so conflicts do not resurface later when the business analysis work is being performed.
What to Include in the Business Analysis Plan
The business analysis plan should be written in a manner that will be easily understood, because it will be reviewed and may need to be approved by key stakeholders. When developing the business analysis plan, it is a good practice to provide explanations for the planning choices made.
Determining the Proper Level of Detail
Ensure that a sufficient level of planning occurs in order to minimize the risks of developing poor estimates; misguiding stakeholders regarding the amount of required commitment; and mis-communicating the important decisions regarding requirement signoff, prioritization, and change management.
Should avoid being too prescriptive and try to find a balance in the amount of planning performed. When rolling wave planning is used, consider the planning horizon and provide planning details only for the activities that are on the short-term horizon
Balancing between flexibility and management.

Do not sacrifice good management practices for flexibility.

Business Analysis Plan vs. Requirements Management Plan
Project Life Cycle
A project life cycle is the series of phases that a project passes through from its initiation to its closure.
The life cycle provides the structure for managing the project and is determined by factors such as managerial preferences, project characteristics, or how the organization desires to maintain and control projects.
Project life cycle models range from predictive (fully plan-driven)
to adaptive (change-driven), and hybrid approaches fall anywhere between the two
Predictive Project Life Cycle
(Plan-Driven/Traditional/Waterfall )
Emphasis is on minimizing uncertainty.
Scope is entirely defined up-front.
Time and cost estimates are determined for the entire project when scope is defined.
Business analysis is conducted mostly up-front; requirements are completed before product development begins
Deliverables are determined at the onset of the project
Business value is delivered through one implementation.
The need and solution are known and do not change throughout the project
The business analyst should work closely with the project manager to ensure content is not duplicated between the documents and that the planning decisions for both the project requirements and product requirements are covered.

Project Life Cycle
Project is split into phases and project phases are intentionally repeated.
Project work is performed sequentially or with some overlap in iterations
High-level scope is defined up-front and the detailed scope is elaborated upon for each iteration.
Scope for future phases is defined when the prior phase starts or completes
Product is developed iteratively as features are added incrementally
Business analysis is performed up-front and then in small amounts throughout the project.
Requirements analysis is performed in time-boxed iterations
The need and solution become more stable as the project progresses
Phase 1
Project Initiation
Phase 2
Project Initiation
Adaptive Project Life Cycle (Change-Driven or Agile)
Business value is emphasized over minimizing uncertainty
Iterations are conducted quickly.
Changes are expected; when new requirements are presented,
these are captured in a product backlog, and then the backlog is re-prioritized.
Business value is delivered iteratively.
The need and solution are unknown and unstable.
Overall scope is agreed to early.
Detailed scope and product requirements are defined for a single iteration at a time
How Project Life Cycle Impacts Business Analysis Work
The project life cycle impacts a number of decisions about the business analysis process, such as:
Business analysis activities that are to be performed,
Order in which the activities will be completed,
Timing of activities,
Level of formality required for deliverables,
Approach for prioritizing requirements
Methods for addressing requirement changes
Leverage Past Experiences When Planning
Lessons learned
: is the knowledge gained during a project, which shows how project events were addressed or should be addressed for the purpose of improving future performance. The lessons learned process is a best practice used by project teams to discuss, analyze, and document feedback about completed project activities
When determining a business analysis approach, the business analyst looks for similarities with other ongoing projects or previous projects that had successful business analysis approaches,
reviews lessons learned,documentation,
and applies relevant lessons in whole or in
part to the current business analysis process
Collaboration Point
Project managers and business analysts may each conduct lessons learned sessions; the project manager obtains feedback on completed project activities and the business analyst focuses on completed business analysis work.
Retrospectives :
In adaptive life cycle projects, retrospectives are meetings that are scheduled on a regular basis or conducted when a body of work is completed, such as the conclusion of an iteration or at the end of a project phase
Leverage Past Experiences When Planning
The purpose of a retrospective is to task the project team with identifying those areas where team performance can be improved.
Retrospectives use the following steps :
Set the stage :
The context and tone for the meeting is established.

Gather data :
Factual and relevant data is pulled together to support feedback.
Generate insights :
The team looks for commonality in the feedback including cause and effect.
Decide what to do :
The team
collaborates to determine a course of
action for improvement.
Close the Retrospective :
The session is ended
Plan for Elicitation
At this stage of planning, the business analyst should begin to think about how and when to elicit, which techniques to use, and the sequence of the elicitation activities.
Elicitation planning helps to ensure sufficient time is allocated for the elicitation work.
For example, when a survey comprises a part of the elicitation effort, sufficient time needs to be allocated to design, build, administer, and analyze the survey results.
When subsequent work is dependent on the survey results, the business analyst should identify and plan for that also
Plan for Elicitation
There are a number of factors to consider when planning for elicitation:
Stakeholder group characteristics and dynamics,
Project life cycle
Characteristics of the technique (e.g., speed of use, particular advantages)
Type of project,
Time constraints,
Number of stakeholders,
Location of stakeholders,
Types of requirement deliverables being produced,
Level of detail required in business analysis deliverables
Strategies for Sequencing Elicitation Activities
Where to start eliciting requirements often poses a challenge. Business analysts know they need to acquire a lot of information, they are constrained by the project timeline, their stakeholders availability, ...etc
There are a number of strategies the business analyst may consider when determining which areas of requirements elicitation to address first such as :
Significant amounts of business value to be gained,
Required third-party resources that the project is
dependent on,
Greater risks,
Many project unknowns or uncertainties,
Significant technical challenges,
Dependencies on other components or interfaces,
Limited number of resources or a risk that a key resource
may leave the project or company
Collaboration Point
When deciding the order of business analysis activities, the project manager and business analyst should work together to determine how the resource availability will impact sequencing decisions
Plan for Analysis
Planning for analysis occurs at a high level.
The business analyst will begin to think about which analysis techniques will be best suited to meet stakeholder
and project needs and start to think about
how the analysis work may be
performed and determine the tools,
templates, or training that need to be
acquired prior to the start of the
actual work.
Planning for analysis is iterative and occurs throughout the project
Define the Requirements Prioritization Process
Prioritizing requirements is an important step in managing product scope.
To minimize conflict during the requirements prioritization activities, the business analyst should define the process for establishing priorities before the requirements are elicited. Setting expectations early with stakeholders helps to minimize situations where stakeholders become unhappy when their requirements are prioritized to the bottom of the list
Some common factors to consider when defining the prioritization process are:
• When requirements prioritization will occur,
• The likelihood that priorities will change,
• Stakeholders who will be involved in the prioritization
• Techniques that will be used for prioritization,
• Criteria that will be used to prioritize, and
• Stakeholders who will approve the prioritization decisions.

Traceability involves documenting requirement relationships and is used in business analysis to maintain product scope.
When a traceability approach is defined, requirement relationships are created, which allow the project team to,
Trace backwards to identify the origin of a requirement
Trace forward to identify how the requirement was tested and implemented
Trace in-between requirements to provide insight int the value a group of related requirements can deliver.
Requirements that are documented but fail to trace to a business need are considered out of scope
Requirements that fail to trace to a solution component identify areas where the product is not in compliance with the requirements
Collaboration Point
The right amount of traceability helps to reduce project risks, but too much traceability works against the project team and incurs costs and schedule impacts unnecessarily. The project team has an opportunity to collaborate and define a traceability approach that is suitable for the needs of the project.
Define the Traceability Approach
The types of traceability decisions the business analyst should consider are:
• Types of requirements to be traced,
• Level of detail to trace to,
• Relationships that will be established and maintained,
• Requirement attributes to be tracked,
• Requirement states that drive the requirements life
cycle (for example, approve, defer, reject, etc.),
• Tools used to perform the traceability, and
• Process decisions regarding how traceability will be
established and maintained
The approach can be formally documented in the business analysis plan or in a separate business analysis communication plan if the project or organizational needs require this level of structure or formality
Define the Communication Approach
A communication approach describes how business analysis information will be structured and when communication to stakeholders will occur.
The business analyst also receives input about how stakeholders wish to receive information on requirements and how often they wish to receive information.
Collaboration Point
The business analyst should not create the communication plan independently of
the project manager. If the business analysis communication plan is formally documented, agreement should be reached on whether the information will be kept as a subplan or included within the project manager’s communication plan
Define the Communication Approach
When defining the business analysis communication approach, consider the following:
• Stakeholder preferences for receiving information (e.g., summary level or detail),
• Preferred delivery methods for distributing or accessing
requirements and requirement related information,
• Level of formality required in the communication,
• Tools, including requirement repositories, which stakeholders will need access to
Define the Decision-Making Process

Throughout the business analysis process, there are a number of decisions that need to be made before work can commence.
Special tools or techniques that may be used to help teams evaluate alternatives, for example, decision analysis, decision modeling, decision trees etc
The decision-making process should be defined collaboratively with stakeholder input. Once the team determines the decision process, it is documented within the business analysis plan so the team has a point of reference when the work begins.
The following information can be considered when defining the decision-making process:

Define the Decision-Making Process
• Types of decisions that will be made, including how requirements will be
• Roles and authority levels, for example, who is involved in the
discussions and who makes decisions, etc.,
• Process to follow when consensus cannot be reached and requirements-
related issues need to be escalated,
• Required turn-around time for a decision to be reached,
• How decisions are documented and communicated,
including requirements signoff,
Verification Vs Validation
: Are we building the right product?
is the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders.
: Are we building the product right?
is the evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition
• Who requires communications and what information they expect,

• Types of requirements and requirements-related information that will be
Define the Requirements Verification and Validation Processes
Verification is performed to ensure that requirements are constructed properly and that models are clear enough to be used effectively.
Requirements validation is the process of ensuring that all requirements accurately reflect the intent of the stakeholder and that each requirement aligns to one or more business requirements.
During business analysis planning, the business analyst defines how verification and validation activities will be conducted.
Validation is performed through the use of structured walkthroughs and traceability.
Define the Traceability Approach
Define the Requirements Change Process

Changes to requirements may
involve a change in scope,
a restated business objective,
or the addition or deletion of features
to the product or service being developed;
therefore, the business analyst will need to determine how requirements documentation should be updated once a change is approved.
The requirements change process depends on the selected project life cycle
Define the Requirements Change Process
Consider the following type of information when defining a requirements change control process
• How requirement changes will be proposed,

• How changes will be reviewed,
• How change management decisions will be documented,
• How requirement changes will be communicated,
• How changes to requirements, models, traceability, and other
requirements-related information will be
• Completed and made available once a change is approved
Collaboration Point
The requirements change control process may be documented by the project manager in the change management plan. The business analyst and project manager should work together to determine who takes ownership for documenting the plan and whether the business analysis plan or change management plan is the source for this information

Define the Requirements Change Process
The business analyst also needs to ensure the project team understands the roles and responsibilities for the requirements change process, for example:
• Responsibility for proposing changes,
• Responsibility for conducting the assessment
or impact analysis,
• Roles that participate in change discussions
• Responsibility for approving changes
Define the Solution Evaluation Process
Defining the solution evaluation process identifies how a solution is evaluated during the evaluation phase, which activities will be performed, what techniques will be applied, and how information will be analyzed

The expected benefits for the product or solution were defined in the business case. The work in planning is to determine how to measure these benefits.
Solution evaluation planning involves defining the following:
• Evaluation criteria and acceptance levels
• Qualitative and quantitative evaluation activities to be performed
• How the solution will be evaluated;
• When and how often evaluation will be performed;
• Evaluation techniques that will be used, for example, focus groups,
observations, surveys
• Whether any special measurement tools will be required;
• How results will be analyzed and reported
Define the Solution Evaluation Process
Qualitative and Quantitative Data
Plan the Business Analysis Work
• Determine Who Plans the Business Analysis Effort
• Build the Business Analysis Work Plan
• Assemble the Business Analysis Work Plan
• Document the Rationale for the Business
Analysis Approach
• Review the Business Analysis Plan with Key Stakeholders
• Obtain Approval of the Business Analysis Plan
Determine Who Plans the Business Analysis Effort
The business analyst can help support the project manager, because the business analyst has expertise with the business analysis process and can provide specifics on the business analysis work that is recommended to meet project objectives.
Ultimately the project manager is responsible for the project management plan and is accountable for managing all project activities.
Planning is an area where project managers and business analysts will find that their roles overlap.
Collaboration Point
Build the Business Analysis Work Plan
The business analysis work plan is the project plan that covers the work to be performed during the business analysis process. The business analyst is responsible for identifying this work using all the project and environment information known to them
In building the plan the business analysis can follow the below steps:
 Identify the Deliverables
 Determine the Tasks and Activities
 Determine the Timing and Sequencing of Tasks
 Determine the Roles and Responsibilities
 Identifying the Resources
 Estimate the Work
Identify the Deliverables
The business analyst collects many forms of information over the course of the project, but not all information collected and documented is considered to be a project deliverable
: is any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project
: are required and often impact the work of individuals who perform activities later on in the project life cycle such as (high-level requirements document, software requirements specification, user stories, a nonfunctional requirements list, .. etc)
Collaboration Point
The business analysis deliverables produced for the project are determined by the business analyst but these decisions are not made independently. The business analyst solicits input from the sponsor, project manager, and key stakeholders to ensure that expectations are met.
Identify the Deliverables
The business analyst should consider the following when planning the business analysis documentation:
• What deliverables will be produced;
• How deliverables will be used by other team
members and key stakeholders;
• How changes to deliverables will be managed;
• Required formality of the deliverables;
• How deliverables will be accessed and by whom;
• Tools that are required to produce, maintain, or store deliverables

• Whether requir ements will be reused on future projects.

Determine the Tasks and Activities
After agreeing on the list of deliverables that will be produced to satisfy the project objectives, the business analyst begins to define the activities required to produce them.
The business analyst may use a number of techniques to help identify a complete list such as brainstorming, decomposition modeling, interviews, and lessons learned, ... etc
Each deliverable requires the completion of one or more activities. The project team should work together to define the task list.
Decomposition Model
A decomposition model is an analysis model used to break down a high-level object into smaller more discrete parts.
In business analysis planning, a decomposition model is used to identify business analysis tasks, activities, and deliverables by detailing out the business analysis work.
Typical objects often analyzed with decomposition may be solution scope, organizational units, work products, processes, functions, or any other object types that can be subdivided into smaller elements
How to create the process decomposition diagram in
Business Analysis
Three ways
Choose one of three ways to build your decomp: top-down, bottom-up, or event-driven.
: Start with the high-level processes (requirements) you identified during scoping if you have them (if you don’t, elicit them from your stakeholders). From there, keep drilling down until you get to processes that contain a how; that’s your stopping point.
: Think of all the detailed tasks you have to do in the area of study (or scope) and then find common groupings. When determining the groupings, a process may fall into different headings; the goal is for the team to determine the best approach. Remember, what you want to do is make sure you don’t miss any processes.
: Think of all the triggers (directives that lead to a series of actions) and the tasks that follow. Take notes and make a rough sketch.
How to document the processes for business analysis
When you have your decomposition diagram created, you’re only halfway done. The diagram shows you the processes, but you still have to actually document the details.
For each process, you have to define what attributes and information make up each process by answering questions such as the following:
• Who are the external agents involved in the process? Who currently performs the process today? How do they do it? Who uses the output of the process?
• What causes the process to start? What is the trigger?

• What happens after the process is complete? What are the postconditions?

• What data does the process use? Who creates the data? Is it created, read, updated, or deleted?
• How often is the process performed? How long does it take? How efficient is it?
Determine the Timing and Sequencing of Tasks
The timing of business analysis tasks is directly influenced by the selected project life cycle. Sequencing is also influenced by a natural order, because some tasks require the completion of outputs produced by other activities.
The business analyst analyzes these factors and may consider one or more of the following when determining the sequence of activities for the work plan:
Availability of resources required to perform or contribute to the work,
Needs of downstream recipients whose work relies on the business analysis deliverables,
Relationship of project work to other work being performed within the organization,
Contractual and statement of work obligations,
Dependencies on training and tools to perform the business analysis work,
Staffing and new hire needs
Risk and complexity level of tasks
Determine the Roles and Responsibilities
RACI analysis is also performed in business analysis when determining roles and responsibilities for the business analysis effort. The business analyst cannot assume that everyone involved in the business analysis process knows their role or what they are accountable for.

In business analysis activities, it is essential to understand who is responsible for providing requirements, who has authority to approve requirements, who can make decisions or settle differences when they arise, and who is involved when changes to requirements are proposed.

Collaboration Point
The business analyst and project manager share a common interest in ensuring that key stakeholders fully understand and agree to the roles and responsibilities they hold on a project.

Collaboration Point
The business analyst may have prior experience working with key resources and specifics that influence task allocations and assignments that the project manager may benefit from prior to finalizing the overall resource plans for the project.
Identifying the Resources
The business analyst will review the planned work, determine which resources will be needed for the work, and identify any areas where resources may be overallocated or missing.
As a minimum, the business analyst needs to ensure that all functional areas impacted by the project are represented by a resource during requirements elicitation, validation, and approval activities.
There are a number of estimation techniques that may be used to help support the estimation process. The project manager may have a preference as to which techniques are applied
Estimate the Work
As the work plan details begin to emerge, the business analyst plays a key role in defining the level of effort required for the defined activities and deliverables.
Collaboration Point
The project manager and business analyst should determine how revisions to the business analysis estimates will occur. Project managers facilitate the estimation work when building the project management plan. Business analysts may be asked to facilitate the estimation work for the business analysis activities,

The following considerations should be factored into the estimates:
Estimate the Work
Project size and complexity,
Selected project life cycle,
Amount of ambiguity surrounding the proposed solution
Number of stakeholders and stakeholder groups involved in the elicitation activities
Types of elicitation techniques being considered,
Location of those involved in the business analysis activities
Schedule and budget constraints,
Number of business analysis deliverables being produced
Formality and level of detail required for the business analysis deliverables,
Experience level of the project team
Assemble the Business Analysis Work Plan

Once the business analysis deliverables, tasks and activities, and required resources for completing the work are known, the information is assembled in a plan that clearly depicts the timing of the work and any dependencies.
The business analyst and project manager need to agree on the level of detail needed for the project management plan. The level of detail maintained in the project management plan can vary based on a number of factors minimally depending upon:
The sponsor should understand the approach to champion, lend support, and rally stakeholders around the importance of the business analysis activities
Document the Rationale for the Business Analysis Approach
Documenting the basis for the decisions made during the planning efforts helps to reduce uncertainty. Sharing the rationale with the stakeholders provides assurance that the plan is thought out and purposeful.
For the project team, understanding the rationale behind the chosen business analysis approach provides context and helps answer questions regarding why the work is being conducted and why it is being performed in a specific manner.
For the project manager, understanding the rationale for the business analysis approach provides the context needed to support and fund the work, manage it, and justify the roles and resources required to complete the work.
Stakeholders need to be comfortable with their role in the process, be aware of the time commitment to participate in the process, and understand how decisions about requirement priorities and changes are handled.
Review the Business Analysis Plan with Key Stakeholders
Once the business analysis plan is completed, the business analyst reviews the plan with the key project stakeholders.
The objective for the review is to reduce the risk of stakeholders failing to support business analysis activities when the work begins.
Conducting these discussions up-front helps to obtain buy-in early and minimizes the risk of stakeholder conflict when the activities are underway

Review the Business Analysis Plan with Key Stakeholders
Key stakeholders in the business analysis activities should be invited to participate in the review process, for example, those having:
Collaboration Point
The business analyst should ensure to discuss the business analysis process with those who are tasked with performing the work. Key stakeholders who have an opportunity to provide input to structure the process are more likely to support the requirements-related activities.
• Responsibility for approving, prioritizing, or validating requirements;
• Responsibility for a role in the change control process;
• Management responsibility for staff participating in the requirement

• Responsibility for serving as a subject matter expert on the project.
Obtain Approval of the Business Analysis Plan
The business analysis plan may need to be revised to accommodate the feedback received from stakeholders.
Once all concerns are resolved, the business analyst takes steps to obtain approval on the plan.
Obtaining approval on the plan helps to reduce the following project risks:
Approval may be formal and require a signature or may be informal and only require verbal acceptance.
Once the business analysis plan is approved, updates to the plan should be made in a controlled fashion.
The business analyst works through the issues raised and facilitates resolutions in order to avoid discouraging or disengaging stakeholders.
Obtain Approval of the Business Analysis Plan
Stakeholders do not support the business analysis process once it starts.
Project team underestimates the amount of time that business analysis activities will take.
Funding allocated to the requirements phase of the project is inadequate.
Key stakeholders underestimate the level of involvement or participation necessary for the requirement activities.
Key resources are unavailable to participate in requirement activities, when required.
Stakeholder expectations with regard to how requirements are documented and communicated are missed.
Complexity of the business analysis effort,

Size of the project,

Amount of business analysis work being tracked,

Type of project life cycle.

Discusses the iterative nature of the work performed to plan, prepare, and conduct requirements elicitation and to analyze and document the results of that work. A number of elicitation and analysis techniques are defined and explained.
Domain 3: Requirements Elicitation and Analysis
• What it Means to Elicit Information
• Plan and Prepare for Elicitation
• Conduct Elicitation Activities
• Document Outputs from Elicitation Activities
• Complete Elicitation
• Elicitation Issues and Challenges
• Analyze Requirements
• Model and Refine Requirements
• Document the Solution Requirements
• Validate and Verify Requirements
• Approval Sessions
• Resolve Requirements-Related Conflicts

What it Means to Elicit Information
Requirements elicitation is the activity of drawing out information from stakeholders and other sources.
The elicitation process is more than collecting or gathering requirements. The terminology “collecting” or “gathering” requirements implies that stakeholders already have requirements ready to be collected or gathered.
Part of the business analyst’s job is to help
the stakeholders define the problem or
opportunity and determine what should
be done to address it. The elicitation process
helps facilitate this work.
Some stakeholders may not even know their needs.
Importance of Eliciting Information
The results of elicitation are a core input for business analysis work. The information elicitated becomes the basis to effectively complete other business analyst tasks, such as:
Support executive decision making:
the business analyst objectively obtains the information necessary for these decisions to be made.
Apply influence successfully :
Business analysts have no vested authority; therefore, they should use influence in order to get things done. Influence is more successful when it is backed with information that supports the goal.
Assist in negotiation or mediation:
Negotiates on behalf of the project team, management, or business. In all such negotiations, the business analyst first elicits information and understands the motivations and/or goals of all sides in the conflict and then negotiates based on principle or objective facts.
Resolve conflict :
Conflict is generally resolved with information, because conflict in business is usually the result of misinformation or assumptions based on a lack of information.

Define problems:
The business analyst provides information to identify the real problem by identifying and analyzing the business processes that need improvement over the course of the analysis
The art of elicitation is to obtain enough information to be able to validate requirements through a process of learning in order to confirm that the project team is delivering the right solution.
Importance of Eliciting Information
Failing to elicit enough information can result an increased number of assumptions
But too much information may hinder the team’s ability to move forward.
Plan for Elicitation
Prepare for Elicitation
Conduct Elicitation Activities
Elicitation Techniques
o Brainstorming
o Document Analysis
o Facilitated Workshops
o Focus Groups
o Interviews
o Observation
o Prototyping
o Questionnaires and Surveys
Document Outputs from Elicitation Activities
Complete Elicitation
Elicitation Issues and Challenges
Plan for Elicitation
Prior to elicitation, the business analyst begins to focus on more specific details such as how to conduct elicitation, which stakeholders to involve, and which order to schedule elicitation sessions.
An elicitation plan is a tool used by business analysts to help formulate ideas about how to structure the elicitation activities.
• Better overall focus on the entire elicitation process.
A well thought out approach to elicitation provides the following benefits:
• Clearer idea of the necessary information to
define a problem, or produce a solution
• Fewer unnecessary elicitation activities
• More valuable results from each elicitation session;
• More efficient and predictable use of stakeholder
time to elicit the information
Develop the Elicitation Plan
The plan is not a formal document and does not take a lot of time to create. It can be documented or can be the thought process used to prepare for the forthcoming elicitation efforts
Some of the elements in an elicitation plan include :
What information to elicit ?
Where to find that information ?
How to obtain the information ?
Sequencing the Elicitation Activities ?
Finding Information
Sources of information may be :
An individual the business analyst plans to elicit information from
A Model,
Other documented reference
Individuals in the elicitation plan should be identified by role rather than name
Develop the Elicitation Plan
Try to identify at least two sources for each topic or question to be explored, in order to avoid proposing any requirement or solution that is based on the opinion or information derived from a single source
Example of a completed elicitation plan to move office staff to a new location
The business analyst may create informal preparation notes to organize and to help facilitate the session.
Prepare for Elicitation
Elicitation preparation is the planning performed to conduct an effective elicitation session. Elicitation preparation may be formal or informal
Preparation notes can be used to measure the progress achieved in a session against what was planned to be achieved and can be used to adjust expectations for future sessions
Prepare for Elicitation
Determine the Objectives :
The business analyst should set an objective for each session to achieve, to ensure elicitation activities are effectively performed,

Determine the Participants :
The business analyst schedules the appropriate amount of time for each stakeholder group; it may be appropriate to schedule less time with executives than with end users
Determine the Questions for the Session :
The business analyst may want to prepare some questions prior to conducting the elicitation when using interviews, focus groups, facilitated workshops, or other techniques used to elicit information directly from stakeholders, in order to ensure the session objectives are achieved
Questions that do not move the session forward to achieving the desired
objectives or those questions that obtain data that do not have a specific purpose should be avoided

Example of preparation notes for an elicitation session to discuss an office move
Conduct Elicitation Activities
There are four stages during the
actual elicitation activity in which information is gathered:
: The introduction sets the stage, sets the pace, and establishes the overall purpose for the elicitation session
The body is where the questions are asked and the answers are given
The close provides a graceful termination to the particular session
The follow-up is where the information is consolidated and confirmed with the participants
Parking lots
The parking lot, created on easel pads, white boards, or electronic equivalent, is a place to store topics that have been raised by the participants which do not relate to the session objectives.
The business analyst should consider use of a “parking lot” as a tool to keep participants on track. Parking lots
are used to minimize sidetracking, derailing, or hijacking of the meeting by participants.
Elicitation Techniques
o Brainstorming

o Document Analysis

o Facilitated Workshops

o Focus Groups

o Interviews

o Observation

o Prototyping

o Questionnaires and Surveys

Elicitation Techniques
Document Analysis

Document analysis is an elicitation technique used to analyze existing documentation and identify information relevant to the requirements. Business analysts can start their analysis work with this technique to gain some understanding of the environment and situation prior to engaging directly with stakeholders

Facilitated Workshops

Facilitated workshops, also known as requirements workshops, are focused sessions
that bring key cross-functional stakeholders together to define product requirements. Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences.

Due to their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus
A focus group is an elicitation technique that brings together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result. Focus groups are used to gain feedback on completed work or prototypes.
Elicitation Techniques

The facilitator is often provided with an outline or a list of objectives to achieve in the session. Sessions are facilitated in a manner that allows for healthy team dynamics, a free flow of ideas, and a sufficient level of feedback to meet the session objectives. A group size of 8 to 12 is optimal.
Generally, group members are prequalified or prescreened to ensure they meet the desired or targeted representation.
Focus Groups
An interview is a formal or informal approach to elicit information from stakeholders. It is performed by asking prepared and/or spontaneous questions and documenting the responses.
Interviews are often conducted on an individual basis between an interviewer and an interviewee, but may involve multiple interviewers and/or multiple interviewees
Elicitation Techniques
Observation is a technique that provides a direct
way of viewing people in their environment to see
how theyperform their jobs or tasks and carry out
processes. It is particularly helpful for detailed processes
when people who use the product have difficulty or are
reluctant to articulate their requirements. Observation is also called job shadowing.

Passive observation.
The business analyst observes the worker at work without interrupting, asking questions, or seeking clarification

Active observation.
During active observation, the observer interrupts the process or activity, asks questions about what the worker is doing, seeks clarification, and asks for opinions, etc.
•Participatory observation.
During participatory observation, the observer takes part in performing the
activities being observed. It allows the observer to generate questions that would never have been thought of otherwise.

The observer simulates the activities, operations, or processes of the work using a tool that recreates the work of a process worker in a simulation.
Elicitation Techniques

Prototyping is a method of obtaining early feedback on requirements by providing a working model of the expected product before building it.
Since prototypes are tangible, stakeholders are able to experiment with a model of the final product rather than discussing abstract representations of the requirements. prototype can be a mockup of the real result as in an architectural model, or it can be an early version of the product itself
Low-fidelity prototypes:
are completed with a pen and paper, marker and whiteboard, or modeling tool on the computer such as Mockups of interface screens or reports
High-fidelity prototypes
: create a representation of the final finished product and are usable by the stakeholders who are reviewing them.
Throwaway prototypes
Evolutionary prototypes

Elicitation Techniques

Questionnaires and surveys are written sets of questions designed to quickly accumulate information from a large number of respondents. Respondents represent a diverse population and are often dispersed over a wide geographical area.

Questionnaires and Surveys
This method is beneficial for collecting a large amount of information from a large group over a short period of time at a relatively small expense.
However, questionnaires and surveys
also have these disadvantages

The primary documented result is a set of elicitation notes comprised of a wealth of information for performing other business analysis tasks. The results may come in the form of sketches, diagrams, models, flipcharts, sticky
notes, or index cards, to name a few.

Document Outputs from Elicitation Activities
It is important to document the results of elicitation activities, either formally or informally. Documentation can range in formality from snapshots of whiteboards to fielded information recorded in requirements management tools.
When the elicitation results are analyzed, the results are documented into the deliverables and forms geared to the audiences who will use them.

This continues until the analysis produces no further questions and the information is reduced down to a depiction of the solution to the business problem or when the risk of problems emerging from the lack of complete information
is considered to be acceptable
Complete Elicitation
The elicitation process is an iterative process of alternating the steps of eliciting information and analyzing the information obtained. It can be considered a progressive elaboration of information.
Complete Elicitation
The following may indicate when sufficient information has been elicited:
The model on which the information is based can be completed.
The stakeholder or problem owner approves the results.
A successful prototype is completed.
The objective has been reached
The solution(s) has been identified.
Elicitation Issues and Challenges
The business analyst cannot gain access to the right stakeholders :
The business analyst can address this issue by focusing on the information not the individual. Sometimes the desired information is available from multiple sources, for example, documentation, training materials, operating procedures, etc. The business analyst may look to these other sources when gaining access to stakeholders proves to be difficult but needs to realize that doing so comes with great risk.

Stakeholders do not know what they want
To address this challenge, using techniques such as prototyping or storyboards may help the stakeholders visualize each of the possible solutions. The project team may consider using an adaptive project life cycle since it a preferred approach when there are changing customer needs or when stakeholders need to visualize the solution to further define their requirements

Elicitation Issues and Challenges
Stakeholders are having difficulty defining their requirements:
To address this challenge, the business analyst should ask the business stakeholders for help in understanding the problem domain and focus their attention on the problem or opportunity they wish to address. After clarifying the situation, the discussion should be focused on the high-level requirements.

When the business analyst helps to break down the high-level requirements and walks the stakeholders through the process, the stakeholders will be prevented from moving directly to the solution
Stakeholders are not providing sufficient detail to develop the solution:
To address this issue, the business analyst should try to elicit requirements through visual modeling techniques. Engaging stakeholders in modeling can open up dialogue that may not be possible through interview questions, surveys, or straight discussion.
Elicitation Issues and Challenges
Ask stakeholders to help complete a workflow or
to assist with breaking down a problem into a hierarchical model. This process focuses the stakeholder on completing the visual elements, resulting in discovery of details that might not be possible to obtain without the imagery.

o Analysis Defined

o Plan for Analysis

o What to Analyze

Analyze Requirements
The business analysts perform analysis,
with much effort focused on requirements-related information.

Analysis is the process of examining, breaking down, and synthesizing information to further understand it, complete it, and improve it.
Analysis entails looking closely at the parts of the information and how they relate to one another.

Analysis involves progressively and iteratively
working, it is used to provide structure to the
requirements and related information
Plan for Analysis
Planning for analysis involves thinking about what activities and techniques are likely to be useful and when they should be used

Part of planning for analysis includes determining which types of models would be most beneficial given what
is known about the project and to consider which analysis and modeling tools could be used

What to Analyze
Choose the correct information to analyze and separate out those things that interfere with a proper analysis
Use visual models to help establish a boundary on exactly what needs to be analyzed and to help facilitate discussions with stakeholders and subject matter experts
Business analysts conduct analysis on the outputs of elicitation activities. In addition, analysis frequently provokes relevant and important questions about the situation, requiring more elicitation

Description of Models

Purpose of Model

Categories of Models

Selection of Models

Use Models to Refine Requirements

Modeling Languages

Model and Refine Requirements
Description of Models
A business analysis model is a structured representation of information.
Models are diagrams, tables, or structured text.

Models are created with a variety of tools, ranging from formal modeling tools to whiteboards to artistic software.
The model refers to a visual representation of information, both abstract and specific, that operates under a set of guidelines in order to efficiently arrange and convey a lot of information in a concise manner.
Purpose of Models
Business analysis models are helpful to find gaps in information and to identify extraneous information.

Models provide context to better understand and more clearly convey information. Requirements are modeled and refined to achieve further clarity, correctness, and to elicit additional information to define the details necessary for the product to be built
When the correct models are applied, analysis becomes simple relative to analyzing the information in pure text form, because the models help visualize and summarize complex information. When the correct models are applied, analysis becomes much easier

Categories of Models
Scope Models
: Models that structure and organize the features, functions, and boundaries of the business domain being analyze Exp. Context diagram , Organizational chart, Use case diagram, Decomposition model
Process Models
: Models that describe business processes and ways in which stakeholders interact with those processes Exp. Process flow, Use case, User story
Rule Models
: Models of concepts and behaviors that define or constrain aspects of a business in order to enforce established business Policies. Exp Decision tree, Decision table, Business rules catalog

Categories of Models
Data Models
: Models that document the data used in a process or system and its life cycle. Exp : Entity relationship diagram, Data flow diagram, Data dictionary, State table, State diagram
Interface Models
: Models that assist in understanding specific systems and their relationships within a solution. Exp Report table, System interface table, User interface flow, Wireframes, Display-action-response
Use Models to Refine Requirements
Business analysts use models to determine what is important and valuable so that the right requirements are created. Models are used during elicitation sessions to refine requirements with stakeholders or subject matter experts. Through an iterative process, the details become sharper and sharper until there is a clear enough picture as to what is important and what is not.

Methodology of the Project
Characteristics of the project
Timing within the project life cycle
Categories of models
Level of abstraction
Business analyst should consider the following when choosing which models to use
Modeling Languages
There are many modeling languages, and each has its strengths and weaknesses.
Whether a specific modeling standard is used during analysis or not is unimportant; what is important is to use consistent syntax each time a similar model is used so as not confuse stakeholders. For example, when creating process flows, use the same shapes to mean the same things. In addition, it is helpful to keep the models as simple as possible.
A mock project called “recipe box” for a grocery chain. This is a mobile application project that allows users to select recipes, look up grocery stores that have the ingredients, and then map the location of the ingredients in the store.
A new recipe is sent daily by email to participating customers. Ingredients for the recipe are on sale at each of the grocery stores.
Customers can use a mobile device to run the Recipe Box application to display the current and past recipes. The application also shows the location of the items for the recipe at the store selected by the customer
Scope Models
• Goal Model and Business Objective Model

• Ecosystem Map

• Context Diagram

• Feature Model

• Use Case Diagram

Goal Model and Business Objective Model
Goal models and business objective models are diagrams for organizing and reflecting goals, business problems, business objectives, success metrics, and high-level features. Chains of business problems and business objectives easily show where the project value comes from

Whether the value is identified as increasing revenue, decreasing
cost, or avoiding penalties, goal models and business objective models visually represent the value that supports feature prioritization decisions and product scope management

Collaboration Point
The project manager may be able to help complete portions of the goals and business objectives
Usage: Although commonly constructed during the planning phase, a goal model or business objectives model can be created at any time during the project.
Ecosystem Map
An ecosystem map is a diagram that shows all the relevant systems, the relationships between them, and optionally, any data objects passed between them.
An ecosystem map is used to understand all of the systems that may be affected by or that will impact the in-scope systems. It is a good model to represent systems that are in scope early in a project.
Context Diagram
A context diagram shows all of the direct system and human interfaces to systems within a solution. The diagram shows the in-scope system or systems and any inputs or outputs including the systems or actors providing or receiving them.
Context diagrams are particularly useful early in a project to specify the scope of the project, including any interfaces that have to be developed. It also shows all of the external touch points between the system under development and other systems or people.
Feature Model
A feature model is a visual representation of all of the features of a solution arranged in a tree or hierarchical structure. The structure can be horizontal or vertical. A feature is a group of related requirements described in a few words.
Feature models are helpful to show how features are grouped together and which features are subfeatures o
Full transcript