Business Analysis
Planning Guide
..........................................................................................1
What are the Roles of the Business Analyst? .........................................................1
What is the Business Analysis Approach? ............................................................ 2
............................ 3
...................................................................................... 5
.......................................................... 8
Analyzing & Documenting the Business Problem .................................... 8
Evaluating Options & Recommending the Right Solution ........................11
Identifying & Engaging Stakeholders .................................................. 13
Eliciting Business & Stakeholder Needs ............................................... 15
Dening Requirements ........................................................................ 17
Facilitating Collaboration between Business & Development Teams ...... 20
Enabling Business Change & Business Value ......................................21
Ensuring the Solution Delivers Business Value ................................... 26
....................................................... 29
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
Business Analysis Planning Guide
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
1
Business Analysis Planning Guide
is the set of tasks, knowledge, and techniques required to identify
business needs and determine solutions to business problems. Business analysis activities
are the key to a successful organizational change. According to the International Institute of
Business Analysis (IIBA), a (BA) is anyone who performs business analysis,
regardless of their title. BAs have become a valuable resource within most organizations
because they facilitate the completion of major business analysis activities and ensure the
appropriate stakeholders remain involved with the project throughout its lifecycle.
What Are the Roles of the Business Analyst?
Whether a generalist or a specialist, a BA is capable of functioning competently in many
diverse roles. Typically, BAs have a broad educational background and a diverse set of
skills with a wide range of work experience in dierent jobs and industries. The roles of the
business analyst must be clearly dened and understood, since they drive the business
analysis approach. At Enfocus Solutions Inc., we have dened the following eight roles of
the business analyst:
1. Analyzing and Documenting the Business Problem
2. Evaluating Options and Recommending the Right Solution
3. Identifying and Engaging Stakeholders
4. Eliciting Business and Stakeholder Needs
5. Dening Requirements
6. Facilitating Collaboration between Business and Development Teams
7. Enabling Business Change and Transformation
8. Ensuring the Solution Delivers Business Value
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
2
Business Analysis Planning Guide
What is the Business Analysis Approach?
Organized around the previously listed eight roles, the business analysis approach describes
the overall process that should be followed when performing business analysis for a project.
This guide provides analysts with instructions and considerations for planning the business
analysis approach of a singular solution. The business analysis approach should include
information about how and when tasks will be performed, the techniques that will be used,
and the deliverables that should be produced. By organizing the approach around the eight
roles performed by the BA, the analyst can ensure the approach covers all necessary aspects.
Activities related to the BA roles should be planned during the beginning stages of the project.
This plan should be formally documented in a requirements management tool, like Enfocus
Solutions’ RequirementPro™.
Planning business analysis activities is about creating a roadmap to ensure that the
delivered solution meets business and stakeholder needs and delivers value to the
business. The end result of business analysis planning is a business analysis plan (BAP).
The BAP will provide answers to questions such as:
How will business analysis work be executed to meet business and project objectives?
What is the required level of rigor?
What is the required level of detail for the requirements?
Which business analysis techniques will be used?
How will changes to requirements be managed?
How will changes to scope will be managed?
How will communications ow and how will issues be escalated?
How will the deliverables and end product be veried and validated?
How will related requirement risks be managed?
As you put the plan together, remember that business analysis activities are not performed
sequentially. Many tasks are performed iteratively throughout the project. Also, depending
on your project, some tasks that are performed as part of business analysis may not need
to be dened at all.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
3
Business Analysis Planning Guide
Before learning the roles of a business analyst and how to perform them, the BA should
become familiar with key concepts related to business analysis and the factors impacting
the project at hand. The selected approach will vary depending on many dierent criteria.
In developing a business analysis approach, it is important to understand the factors that
are listed below. Many of these should be considered as you create a business analysis
approach that addresses all eight roles performed by the BA.
What, exactly, is the solution? It is important to be able to envision what the nal solution will
be. The team will plan the approach dierently depending on the type of solution they intend
to design. For example, an approach would need to be specially tailored for certain situations,
such as mergers/acquisitions, building bridges, or performing soware upgrades.
Will the solution be purchased or built? If the plans are to buy a packaged solution, the
business analysis approach will be very dierent than if the organization were to build the
solution themselves. The level of detail might be much less for a built solution, because
your team may already be familiar with the system.
Or, will the solution be outsourced? If the plans are to outsource solution development,
requirements will need to be much more detailed and precise than if the requirements
were being delivered to in-house developers.
Who is going to be doing the design? Today, some organizations have their own design teams
and some do not. Often, the design team dislikes it if the BA performs design activities
himself, like modeling or other visualization techniques. Although, sometimes the BA must
perform design activities if there is no design team. In this situation, the BA needs to become
familiar with and include many visualization techniques in the business analysis approach.
What is the organization’s standard development lifecycle? It is important to understand
the development lifecycle most commonly used within the organization when planning
business analysis activities. There may be a prescribed methodology that has already
determined what business analysis activities need to be performed. Agile and waterfall
development styles require dierent types of business analysis deliverables.
Where are all of the solution stakeholders going to be located? This is an important factor
when determining the stakeholder communication plan. If everyone is collocated, it will
be easier to communicate less formally than if they are spread across the globe. Dispersed
SMEs will require dierent techniques for eliciting, analyzing, and approving requirements.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
4
Business Analysis Planning Guide
What is the culture within the enterprise? Dierent organizations have dierent attitudes
toward formality and rigor. In some organizations, requirements are created even for
small maintenance projects. In other organizations, requirements are not considered a
value-adding activity regardless of the size of the project. Culture will have a signicant
impact on determining the right amount of requirements management for a project.
What do the stakeholders want? When communicating and collaborating with stakeholders,
some may require more or less formality. A sponsor may, for example, want formal approval
for requirements but not a documented elicitation plan of where the requirements came
from. Some sponsors may want complete requirements traceability and others may not care.
Are there any politics within the organization that will affect the project? Projects with
signicant related stakeholder politics can make business analysis much more diicult
and may necessitate a special approach for business analysis activities.
How complex will the solution be? A predetermined core formal set of business analysis
activities is required in certain situations:
The project impacts multiple business units.
The solution will require multiple teams to build.
There is a signicant number of complex interfaces.
There are large number and numerous types of stakeholders.
What are the benets that will be provided by the solution? Many organizations are using
business analysts to review and evaluate benets that were realized by the project. The
expected benets realization will impact many business analysis activities.
Are there any organizational changes that will affect the solution? The amount of
organizational change must be considered when determining business analysis activities
and BA techniques that should be applied.
Are there any changes in the organization’s business processes that will aect the solution?
Many solutions involve changing or optimizing business processes. Modifying business
processes may require business process modeling using BPMN, benchmarking, work
sampling, applying six sigma techniques, and measuring process performance.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
5
Business Analysis Planning Guide
As the BA begins to plan the business analysis approach, it is important to remain familiar
with the following key concepts:
According to the PMBOK Guide—Fourth Edition, requirements include documented needs,
wants, and expectations. Unmet stakeholder expectations can derail projects and cause them
to be viewed as failures. However, delivering every want, need, and expectation increases the
scope, adds signicant cost and complexity, and delivers little business value. It is important
to capture needs, wants and expectations and then prioritize them in a fashion that
makes them easily managed and implemented. It is vital that the BA remembers to address
stakeholder expectations must be addressed at all stages within the project duration.
Before preparing scope, it is important to distinguish the dierence between project and
solution scope. Project Scope includes the work needed to create a product or deliver a
service or result. Project Scope denes the work required to create and deploy the product.
The Project scope statement is prepared by the project manager.
Solution Scope describes the characteristics, features, or functions of the product or service
to be built. Solution scope is all about the solution to be implemented: how will it look,
how will it function, and other characteristics, etc. The solution scope should be clearly
documented in a requirements management tool, like RequirementPro™. The solution
scope should be prepared with input from key stakeholders.
Although the industry treats product and solution interchangeably, they are actually
dierent. The product is the end result of the project. The solution is the implementation
of the requirements, which includes how the product was implemented. Keep in mind
that one product may undergo many solutions.
Many people confuse the terms business requirements and solution requirements and
oen think they are the same. They are actually quite dierent. Business requirements
dene what must be delivered to provide value. Solution requirements describe how the
proposed solution will accomplish the business requirements. Solution requirements are
one way of ensuring business requirements are satised. According to Robin Goldsmith in
his book, Discovering REAL Business Requirements for Soware Project Success, dening
business requirements is the most important and, oen, the poorest performed part of
system development. Once implemented, business requirements provide value, which
comes from meeting business objectives through solving problems, taking opportunities,
and meeting challenges.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
6
Business Analysis Planning Guide
Business requirements are written in business language and describe what must be
delivered to meet the business need. When delivered, business requirements provide value
by meeting business objectives. Solution requirements describe the high level design for a
solution that is one of the possible ways to deliver the business requirements. The solution
may work as designed but provides value only if it meets the business requirements.
The IIBA’s Business Analysis Body of Knowledge (BABOK) recognizes the difference
between business and solution requirements, sometimes referred to as system or product
requirements. However, most requirements tools vendors do not recognize the dierence
and focus entirely on dening functional and nonfunctional requirements. Functional and
nonfunctional requirements are solution requirements and not business requirements.
Failure to recognize the dierence between business and solution requirements and failure
to identify and dene business requirements usually results in signicant scope creep and
delivering solutions that provide little business value.
The model above shows the relationship between business requirements and solution
requirements. Business requirements need to be dened in detail. They are hierarchical;
and no matter how far down in detail they go, they are always business deliverables that
provide value when delivered, satised, or met. However, when business requirements
have been defined in detail, then it usually is a relatively straightforward process to
translate them into a product which actually meets the business requirements and
thereby avoids creep.
Product/SyStem/Software
requirementS (HigH-LeveL)
BuSineSS
requirementS
Requirements
(Detailed)
Business
Product/
System/Software
Requirements
(Detailed)
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
7
Business Analysis Planning Guide
If your organization does not already follow a certain development methodology, you will
need to determine the development style that is best for the project at hand and for the
organization as a whole. One very popular style of development is to create and manage
requirements iteratively and incrementally.
means that new features are added in increments, or piece by
piece. For example, soware can be developed using a plan-driven approach with new
functionality sliced up into portions. In each increment, a piece of functionality is delivered
through cross-discipline work, from requirements development to the deployment.
Incremental business analysis means that requirements are dened for an increment
and new requirements are added for each increment.
implies planned rework. Requirements are expected to evolve and
change. Therefore, changes to requirements are expected and usually viewed as part of
the development process and not as a defect. Each iteration evaluates what has been built,
and then the product is rebuilt as needed. Iterative renement is about feedback-based
improvement. Among other things, developing a software system is an act of learning,
which means that we have a better idea of what we should have built when we’re nished
than when we started. Each iteration implies planned rework, so there should be a process
in place to accommodate changes to requirements. The diagram below shows an iterative
development model.
Requirements
Planning
Initial
Planning
Evaluation Testing
Deployment
Implementation
Analysis & Design
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
8
Business Analysis Planning Guide
Role One: Analyzing and Documenting the Business Problem
Output: Problem Analysis Plan
The rst role a BA must perform is that of analyzing and documenting the problem that will
be addressed by the solution. When planning the business analysis approach, the BA must
determine which problem analysis techniques should be used to analyze the problem. The
list of techniques that will be used to dene the problem make up the problem analysis plan.
By far, the easiest way to document the problem is to follow Robin Goldsmith’s
. However, according to The Thinker’s Toolkit: Fourteen Powerful Techniques
for Problem Solving by Morgan D. Jones, there are other techniques that may be useful in
documenting and analyzing the problem, as well:
—Simply restating a problem can broaden your perspective of the
problem, helping to identify the central issues and alternative solutions.
—This six-step technique deals with the problem of negative thoughts
by compensating for negative thinking by forcing the BA to identify the positives rst.
—The most common technique involving divergent
thinking is to hold brainstorming workshops in which individuals can generate creative
ideas about the topic at hand.
—These are structuring techniques. Sorting is the
most basic structuring technique. The analysis of even the simplest problems benets from
simple sorting. Chronologies and timelines are a couple more highly useful elementary
techniques for organizing information. These three techniques are quite simple and useful,
but seldom remembered.
—Flow diagrams help answer the questions, “What is causing
the problem?” and, “How are the major factors interacting to produce this result?”
—A matrix is a technique that enables the BA to separate elements of a problem
and then categorize and compare dierent types of information.
—A scenario tree is a diagram that graphically shows choices and their
outcomes at dierent junctures in alternative sequences or chains of events.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
9
Business Analysis Planning Guide
—Weighted Ranking is a systematic technique that enables the BA to
determine which criteria are the most important and apply them equitably to all the items
being ranked.
—In this structured technique, the analyst ensures all hypotheses are
considered suiciently to test their degree of validity. In hypothesis testing, the BA ranks
competing hypotheses by the degree to which relevant evidence is inconsistent.
—Closely related to hypothesis testing, this technique challenges the
proposition to test its validity.
—A probability tree enables the BA to estimate which scenario is most
likely and which is least likely, as well as which decisions and events within the alternative
scenarios are most likely and least likely.
—Utilities are reasons for performing certain actions. A utility tree helps to
perform utility analysis, the purpose of which is to rank any number of options according
to how they serve the decision maker’s self-interest.
—A matrix is another possible technique for performing utility analysis. In a
matrix, the relative dierences in utility values of outcomes are more easily perceived in a
matrix than in a tree.
—According to Jones, an Advanced Utility Analysis is referring
to analysis that involves multiple options, outcomes, and perspectives. A matrix is a helpful
technique for analyzing a problem from dierent perspectives.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
10
Business Analysis Planning Guide
Problem Pyramid
Robin Goldsmith developed the Problem Pyramid™ as a tool to help business analysts
focus on identifying the REAL business requirements. The Problem Pyramid™ as depicted
in the diagram below consists of six boxes or steps that should be performed in the
numbered sequence.
must be completed first. It involves identifying the problem, opportunity, or
challenge that will provide value when addressed appropriately. Not surprisingly, it’s
common for the problem to not be identied correctly, which makes chances for proper
solution implementation essentially impossible. To help get the problem right, we identify
measures of the problem.
describes the measures of how things are now, which tell us we have a problem.
identies Goal Measures that tell us the problem has been solved, the opportunity has
been taken, or the challenge has been met. Achieving the Goal Measures provides the
value, so identifying and quantifying the value is part of getting the problem right. One doesn’t
solve a problem directly. Rather one must identify and deal with the causes of the problem.
describes the current As Is process causes that result in the measures which
tell us we have a problem.
The thing that will
provide value when
fixed or eliminated.
Problem
1
The measure of the
problem now that tells
us it is a problem.
Measure-Now
2
The way things are now
that cause the undesirable
results we are getting.
Cause(s) As Is
4
The desired measure of
the problem that indicates
it’s been solved.
Measure-Goal
3
Deliverable results, that when
delivered, reasonably will
achieve the Goal Measure.
What Should Be
(Requirements)
5
A specific way the
Should Be results
can be delivered.
How (Design)
6
Problem
Pyramid™
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
11
Business Analysis Planning Guide
is the To Be process—the business requirements deliverable that when reasonably
delivered will lead to accomplishing the Goal Measures, which achieve the value.
The Problem Pyramid identies the high-level business requirements, which then need to
be described in greater detail. No matter how far down in detail they are driven, they are
always business deliverables that provide value when delivered.
is the design of a product—how to satisfy the business requirements. is
where we get the solution requirements. should be a response to . However,
people ordinarily start with and not surprisingly fail to provide desired value, because
they haven’t dened the business requirements that the product must satisfy
to provide the value. By following the numbered sequence from through
before getting into the how, project success improves dramatically.
Getting the business requirements right in the first place is the key to providing value
and cutting creep. The Problem Pyramid may be a diicult tool to use, but it is powerful
in getting the problem, value, and requirements right.
Role Two: Evaluating Options and Recommending the Right Solution
Output: Solution Evaluation and Selection Plan
Before the BA can start to plan the business analysis approach, he must select the solution
for which he will be developing the approach. Knowing the solution is an important factor
in planning the approach of a project. At this point, the BA knows the problem, and now
the analyst must explore all possible options for correcting the problem. Before the BA has
the ability to recommend the right solution, he/she needs to have enough information to
evaluate the options. The information required by the BA to successfully evaluate solutions
can include:
—The project vision statement summarizes the long-term purpose and intent
of the project, providing the context for making decisions throughout the course of the
project’s life. The vision statement will contribute to the decision to initiate the project.
—A balanced scorecard describes measures within four perspectives
that will contribute to the development of business objectives. The BA must ensure the four
perspectives are addressed and documented in a requirements management tool:
—The easiest way to express cost measurements is in terms of the return
on investment (ROI).
—Describe measures that will indicate customer satisfaction.
—Measure the costs and quality related to business processes.
—Specify measures that indicate employee satisfaction,
employee retention, and knowledge management.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
12
Business Analysis Planning Guide
—Once the capability gaps preventing the enterprise from meeting
business needs are identied and the current process is assessed, business analysts are
able to determine a solution approach and develop a business case.
—The formal business case is the document that will be presented
for project approval. The purpose of a business case is to provide justification for an
investment in a project by comparing the cost of a project with the benet that it provides.
—The purpose of defining the solution scope is to identify the new
capabilities a project will deliver. Without knowing the exact functionality the solution
will oer, it may not be possible to gain project approval.
Before the BA can evaluate solutions, he/she must determine the criteria for eliminating
unviable solutions. Examples of dierentiating criteria include:
Demonstrates a rm understanding of the requirements and business objectives.
Addresses each requirement and business objective.
Delivers a complete plan for implementing the solution.
The team works closely together and demonstrates complementary skills.
The user interface or experience of the proposed solution complements its functionality.
Once the business analyst has determined the dierentiating criteria, there are a few other
planning and preparation activities to determine the evaluation and selection approach of
the proposed solution. Proper preparation is a very important part of the project and can
actually make or break the success of your soware evaluation. Ensure the following tasks
have been performed to complete the preparation activities:
1. Build the project evaluation team.
2. Identify roles and responsibilities of team members.
3. Dene necessary organizational change tasks to help
the enterprise make a unied decision.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
13
Business Analysis Planning Guide
Role Three: Identifying and Engaging Impacted Stakeholders
Output: List of Impacted Stakeholders and Stakeholder Engagement Plan
Aer identifying all the stakeholders that are impacted by the project, the BA will be able
to determine which stakeholders are inuential and which need to be consulted in the
requirements development process.
Oen, to identify stakeholders, the project manager holds a brainstorming session, which
involves the core project team; this group of people identifies potential stakeholders.
The core project team needs to use business case information determined earlier to help
identify who will be impacted and how those organizations, groups, and/or individuals
will be aected. This list should contain details like the specic names of individuals who
represent stakeholder groups, ensuring that the core project team is communicating
directly with the appropriate people. When identifying stakeholders, keep track of the
following topics:
Who is aected by your work?
Who falls into what group; what groups are aected?
Who has, or does not have, a clear role in the project?
Who could be aected second-handedly?
Who can support or inuence the outcome?
Stakeholders can be divided into three dierent categories. One possible method for
identifying stakeholders is to focus on the three following areas:
Project Sponsor
Customers
Users
Business SMEs
Business Process Experts
Business Rules Experts
Technical SMEs
Internal Auditors
Compliance Oicers
Market Analysts
Legal
Organizational Change
Help Desk
Business Process Models
Product Plans and Roadmaps
Regulations
Audit Reports
Development Team Members
Designers
System Architect
QA and Testing
Network Engineer
DBA
Data Warehouse
Workow Rules manager
Business Continuity
Security
Conguration Management
End User Training
Business Rulebook Owners
Maintenance and Support
Sta
Help Desk
Technical Writers
Project Sponsor
Business Process Owner
CEO
CFO
CIO
Project Investors
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
14
Business Analysis Planning Guide
Once stakeholders have been identied, we suggest ensuring that they are documented. This
activity can be performed by creating stakeholder personas for each group of stakeholders.
A stakeholder persona is an individual or group of individuals with similar roles who hold
a specic interest in the business. Personas represent individuals who exert inuence on
business operations in some way, impacting the success or failure of a project. Documenting
stakeholder personas in a requirements management tool will ensure the elicitation process
is eicient and addresses all stakeholders.
Aer all stakeholders and stakeholder personas have been identied, the analyst must
develop a plan that ensures they are properly engaged throughout the project lifecycle.
In terms of keeping stakeholders up-to-date, talk to each group or individual about
how they would like to receive information from you (hint: the easiest way is via a
stakeholder collaboration tool like StakeholderPortal™) and what their preferred means
of communication are. It may be possible that each type of stakeholder has a dierent
preference for communication. It is the responsibility of the BA to develop a plan for
communicating with the various stakeholders. A set of requirements management tools
like Enfocus Requirements Suite™ is the easiest way to collaborate with stakeholders.
Enfocus Requirements Suite™ helps to ensure stakeholders participate in activities
throughout the project lifecycle, such as:
Reviewing design documents
Participating in soware and prototype demonstrations
Participating in retrospectives and capturing lessons learned
Providing additional information for unclear requirements
Building test scenarios and test cases for user acceptance testing
Performing user acceptance tests
Approving changes to requirement specications
Dening transition requirements
Preparing the organization for change
By using a stakeholder collaboration tool, stakeholders have access to all the information
they need to know, and can participate in the project by providing feedback to the analysts
via features such as news posts, comments, and action items.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
15
Business Analysis Planning Guide
Role Four: Eliciting Business and Stakeholder Needs
Output: Elicitation Plan
Aer identifying the impacted stakeholders with which the BA will need to keep in contact,
the analyst must determine the elicitation techniques that will be best for the entire group
of stakeholders. This will depend on stakeholder preferences regarding engagement. Oen,
you may nd the best decision to be a combination of multiple techniques.
—One of the fundamental concepts behind this type of
tool is the direct entry of needs by stakeholders. Using this intuitive approach to elicitation,
a business analyst can save a lot of time and energy by having stakeholders input needs
through a system such as Enfocus Solutions’ StakeholderPortal™. Another similar technique
would be to use one of the methods mentioned below followed by an analyst’s input of
data from an elicitation session into the stakeholder collaboration tool.
—Focus groups are a qualitative research method that is used to explore and
deepen the knowledge of certain aspects and topics. It is a good practice to assemble
a group of typical users, users of a previous service, or even users of a similar service.
—An elicitation interview comes down to one idea—building a great product
begins with asking great questions. One-on-one interviews are a great tool because they
can be used in many dierent situations.
—An analyst observes users (or prospective users) perform their work with
an existing service. This is a great technique to validate the data that you have collected
from previous elicitation sessions, and, in addition, it can serve as a stimulus for generating
new interview topics and questions, catching errors in the existing system, and recognizing
possible changes to the service that would improve workow.
—Many requirements can be extracted from review and analysis
of documents such as business process models, existing user documentation, or rules
and regulations.
—Facilitated requirements elicitation workshops that permit
collaboration between analysts and customers are a powerful way to explore user needs
and to draft requirements documents. In a requirements workshop, an experienced
facilitator will guide workshop by didactically presenting topics and delivering best
practices to be discussed.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
16
Business Analysis Planning Guide
—Well-designed surveys, or questionnaires, are a viable means of familiarizing
yourself with user needs. The business analyst oen holds a focus group or requirements
workshop before or aer releasing an employee survey. Surveys are a useful technique for
quickly gathering data from a large group of participants, and they are an inexpensive way
to gather objective data from stakeholders.
Stakeholder needs do not always have to come directly from the stakeholders. If
possible, stakeholder needs should be elicited from the actual stakeholders themselves;
however, the BA may discover needs by reviewing existing systems and business process
documentation. When determining the elicitation techniques that will be used, the BA
should try to answer the following questions as completely as possible:
Will needs be gathered in an iterative and incremental fashion or all at once? This
information should aect the scheduling and type of elicitation activities.
Will business rules be gathered by business stakeholders? If so what rule books are
needed? The BA may need to set up the necessary rule books in a requirements
management tool so that related stakeholders have the ability to maintain rules.
How will assumptions be documented? Often, stakeholders just assume the BA
knows about certain needs that are obvious to stakeholders themselves. Consider
the following common types of assumptions:
Transaction volumes
Data volumes
Number of users
Hours of use
Which individual stakeholders will be included in elicitation eorts? Oen, the project
has too many stakeholders for the BA to ask each individual person about their needs.
In this case, it is best to select a couple respected stakeholder representatives
from each persona to work with the BA and participate in elicitation workshops,
requirements validation, and other activities.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
17
Business Analysis Planning Guide
Role Five: Defining Requirements
Output: Requirements Development Plan
An essential part of the business analysis approach is a plan for defining requirements
once needs have been elicited and use cases have been developed. Although documenting
requirements is as simple as entering them into a requirements management tool like
RequirementPro™, developing them takes a considerable more amount of deliberation.
To create a requirement development plan, the BA must consider the amount of design that
will be included in the requirements. Remember, earlier we mentioned design teams may
dislike the BA to perform design activities, like modeling or other visualization techniques.
But, if there is no design team a lot of the design work will fall on the shoulders of the BA.
The amount of design that is necessary will dictate how much detail the BA must add and
the type of visualizations he/she must create to complete the requirement. If the BA has an
understanding of how much design he/she must provide, he will be able to determine the
following aspects about the requirements that will be developed:
Data or document driven?
Light or heavy in detail?
Formal or informal?
Iterative or Fixed?
Incremental or Fixed?
Knowing the approved development style (Agile, Waterfall, etc.), the BA can make a
decision concerning the format of the requirement specications. Requirements are not
complete as simple statements. They need to adhere to some sort of format that has been
set in place prior to beginning to develop requirements. The list below includes possible
considerations for the format of your requirements:
may be the best way to represent user requirements. This method is
commonly employed in Agile development.
are another method commonly used in Agile development that present
requirements from the perspective of an actor.
imply that all descriptions and details are provided via text,
and not the use of visualizations. Textual requirements without visualizations may
be appropriate for developing requirements that avoid design.
are templates that provide guidance on how to write specic
types of requirements.
are additional characteristics of a requirement that are needed
to ensure all details are provided to the design team. If a seemingly non-functional
requirement is not atomic, or independent of other requirements, then it is probably an
attribute of another requirement.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
18
Business Analysis Planning Guide
is an approach that emphasizes early and continuous
involvement of users in the design and evaluation process. If there is no design
team, the BA will want to consider user-centered design elements in the requirement
development process.
There are many techniques created specically for aiding the denition of requirements.
Before the BA can begin developing requirement specifications, he/she will need to
determine the techniques that would be best for the project at hand. The following tools
and techniques are described by Ellen Gottesdeiner and Mary Gorman in their book,
Discover to Deliver: Agile Product Planning and Analysis.
—Used to identify what to test when you’re validating
a solution, feature, or requirement.
—Precise textual statements that dene, constrain, or enable
the behavior of systems, business processes, and data structures.
—Shows the ows between related actions needed
to achieve a valued result.
—Identies your organization’s business capabilities: a combination
of people, process, and technology.
—Illustrates interfaces in a logical manner by showing a system or
portion of a system in its environment along with the external entities that send data
to the system and receive data from it.
—The study of users in their environment by eliciting details about
what users do to understand their needs.
—A catalog of the data attributes that a product needs.
—Provides concrete, specic data used to explore, evaluate, and conrm
system needs.
—Illustrates a set of conditions to reach a business conclusion.
—Visualizes relationships between elements in which one element
(the client) requires or depends on another element (the supplier).
—A table displaying events, the triggers that cause the business
to respond, and the triggers’ responses, or predened actions.
—A way to express a scenario with data, including preconditions
and postconditions.
—A collection of business terms and concepts relevant to the system, along
with their denitions.
—A means to explore, evaluate, and conrm the expected benets
of actions on data.
—A visual space, usually mounted on a wall, used by a team to explore
and evaluate system options.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
19
Business Analysis Planning Guide
—A written description of a typical user’s background, including relevant
details such as responsibilities and goals.
—A keyword-driven language designed to specify product needs
quantitatively in natural language.
—Consists of the best estimates of what might be delivered during a given planning
horizon to achieve value.
—A document that articulates the long-term concept of a product.
—A representation of a solution. Popular examples include wireframes and
detailed mock-ups.
—Characterizes quality attributes as high-level scenarios
using a template specication.
—A text description of an instance of use which helps to validate system needs.
—Uses scenarios as a path to explore options across planning views.
—Shows the allowable transitions from one data state to another.
—A system need expressed as a user’s goal. A story can be catalogued in a queue
or product backlog.
—Organizes stories in logical order according to two dimensions: usage
sequence and business importance.
—Describes how a user’s goal is achieved through interacting with a system.
—Visually represents the various types of user roles and their
relationships among them.
—Shows the end-to-end sequence and movement of information,
materials, and actions in the value stream.
—Tools that help to ensure that the product’s options align with your
strategy and are feasible, desirable, and nancially viable.
If the BA is going to be responsible for the design of the system, he/she will benet from the
use of certain modeling techniques. Consider the following types of requirements models
and determine if any will work with your requirements development plan.
—Represents the processes of the organization so that they
can be analyzed and improved.
—Denes and analyzes data requirements that are needed to support
business functions.
—Identies how users will use the system by dening actors and
use cases.
—A prototype depicting the system’s interfaces, which
is built, tested, and reworked until an acceptable prototype is achieved.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
20
Business Analysis Planning Guide
Role Six: Facilitating Collaboration between Business
and Development Teams
Output: Collaboration Plan
The analyst mainly collaborates with two separate entities—enterprise stakeholders and
developers working for the organization. The language you use when communicating with
each group and the ways in which you work with the two dierent groups will dier will dier.
When performing Role Two, the BA identies all relevant stakeholders and determines a plan
all the business units involved with the project. The form of communication will need to be
appropriate for the team’s level of expertise and understanding. For example, communication
with developers must be crystal clear to enable developers to create the system required
by the stakeholders.
Ensuring collaboration between business and development teams is one of the most
vital roles performed by a business analyst. Without business analysts, the stakeholders
and developers must communicate directly, and developers themselves are faced with
the task of determining what to develop to satisfy stakeholder needs. Assuming that
developers have no time to spend attention to organization or analysis, this can present
a problem: the goal of the stakeholders is to get what they want very quickly, and the goal
of the developers is to give the stakeholders what they want as quickly as the developers
can provide it. This can lead to creating changes in a vacuum and not necessarily taking
the needs of all users of the system into account, depending on the organizational
knowledge skills of the involved developers.Then the organization is in a situation where
there are rarely any detailed definitions of the requirements. Furthermore, the real
reason for a stakeholder need oen may not make good business sense or provide any
quantiable value. One of the responsibilities of the BA is to ensure proposed solutions
provide business value.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
21
Business Analysis Planning Guide
Role Seven: Enabling Business Change and Transformation
Output: Change Management Plan
The implementation of an application usually results in changes to the organization’s
structure, process, systems, and/or jobs. Whenever change occurs within the organization,
it requires planning to ensure the change is implemented in a manner embraced by all
stakeholders. Business change is inevitable; however, stakeholder acceptance of change
often varies. It is the responsibility of the BA to facilitate change throughout various
business units, acting as an “agent of change” and ensuring changes are successfully
accepted by the impacted individuals. The BA must also ensure that changes are deployed
in a way that provides value to the organization. The business activities that are involved
with enabling business change include the following:
Delivering communications
Collaborating with business units
Planning testing and training activities
Facilitating post implementation support
An important part in planning the business analysis approach is to determine how to
handle change in the organization. When it comes to handling new solutions, there are a
few common mistakes that can possibly lead to organizational opposition, and possibly/
eventually to an unsuccessful change or solution. Before the BA can facilitate any changes,
it is important to determine the techniques and methods that will be best for introducing
change to the organization. We suggest using a set of requirements management tools like
Enfocus Requirements Suite™ and a good requirement development process to ensure the
following common IT failures do not happen to your organization or project:
—IT describes the changes and benets of a project in IT terms
and not in terms of business value, alienating stakeholders and giving them no reason
to accept changes.
—IT does not provide opportunities to engage clients in
development of changes, and does not seek adequate input to changes until
it is too late to make corrections.
—Only general training is provided, oen without adequate hands-
on experience. Users do not know how to adapt to changes in their work scenarios.
—Aer implementation, IT closes the book and moves onto the next
project. In the meantime, stakeholders are still trying to come to grips with the new
methods and no support is provided.
Using a requirements management tool helps to ensure you have eicient methods of
communication and collaboration. Developing a good requirement development process
will help to ensure you do not forget to address the training and support requirements.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
22
Business Analysis Planning Guide
It is essential to remember the three C’s when preparing and performing a change
management plan. If the BA focuses on these three goals, he/she can successfully reduce
resistant behaviors, facilitate faster organizational uptake, and expedite the delivery
of full benets of change.
—The BA needs to communicate with the stakeholders to ensure
they understand why the change must occur. It is important that the BA eectively
describes to the stakeholders how a problem is being solved and how it will impact
them. Communication helps to ensure stakeholders support the solution. When
communicating change to stakeholders, a good practice is to describe the benets in
terms that are popularly used by stakeholders. For example, tell the stakeholders how
the changes will enable them to perform their work faster and reduce the amount of
data entry. Do not tell them that the Web-based customer management system will
improve backup and recovery times. They do not care how it works, only how it will
help them work.
—When the BA collaborates with all of the dierent stakeholder groups,
he/she can ensure benets will impact the entire organization. Ensuring all impacted
business units successfully work together helps the organization to achieve one
shared vision.
—Stakeholder condence in the nal solution is essential. By including
users in testing and ensuring they are provided with the necessary training and
support, the BA can successfully build the confidence needed for the solution to
meet its goals and provide benets. Keep in mind that the greatest opportunity for
stakeholder condence building is when they can see and touch the nal product for
themselves. Also, stakeholder participation in testing will help to conrm that the new
system operates as designed. However, it is important for the BA to remember that
he/she cannot build stakeholder condence unless the BA has already developed a
communicative and collaborative relationship.
As you work through your project, you will most likely find that requirements tend to
change over time. One responsibility of the BA is to ensure there is a plan in place for
change management. A change management plan consists of multiple components. The
most important aspects that should be planned include the types of communication that
will be used and the training and support that will be required to facilitate change.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
23
Business Analysis Planning Guide
Communication Plan
The most important part of the change management plan is the communication aspect.
Before the BA can begin to provide stakeholders with an understanding of solution
importance, he/she must determine the techniques that will be best. There are four
major project phases for which you will need to determine the appropriate methods
of communication:
Focus communications in this phase on securing senior management support for upcoming
changes.The goal here is to strengthen executive buy-in. The most important messages
should come from leaders in the organization who have the ability to garner support for
change. The types of communication that should be used at this point can include:
Project Kicko Formal meeting to launch the project, raise awareness, and
get support for high level objectives and goals of the change.
Status Meetings/Reports Provide updates on project progress to project
stakeholders and keeps them engaged. If meetings are not
possible, reports can be made via email (but beware: some
stakeholders lose emails among the crowd) or through
a requirements management tool like RequirementPro™.
Informal Discussions/
Elevator Speech
Informal one-on-one or small group discussions to answer
questions, ensure understanding, and gain support.
Risk/Issues/Exception
Reports/Meetings
Ensure issues are addressed and demonstrate IT’s
ability to anticipate and resolve problems. We suggest
communicating issues via a requirements management tool.
Email Updates Communicate project information that does not require
critical decisions.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
24
Business Analysis Planning Guide
Phase 2: Design/Build
In this phase, talk to project stakeholders who will provide support and be advocates
for change throughout the project. The goal for the BA at this phase in the project is
to direct the team and define usable requirements. It is important that the BA begins
communication early in this phase and frequently states the project objectives and goals
to ensure stakeholders do not lose focus on why the change is needed. When planning
the communication during this phase, consider the following types:
One-on-One Engage and get input from individual stakeholders.
Focus Groups Engage and get input from large groups of stakeholders.
Dene Requirements Document the agreed understanding of the change impacts.
Project Plan Communicate project tasks and timelines for each project
contributor, building accountability.
Phase 3: Deploy
It is important that stakeholders are given the facts before they begin to make up their
own. Remember that ignorance is not bliss and will most likely sabotage your acceptance
generating eorts. The goal during the deployment planning phase is to prepare users for
the new processes. The BA is responsible for telling stakeholders what is going to happen,
when it will happen, and how it will impact them. In addition to the possible communication
types listed below, you may decide to communicate with stakeholders via email. We
suggest that you remember to use email sparingly, as important information oen gets
lost in daily email clutter. When determining the change communication plan, consider
the following communication types for the deployment phase:
Demos Stakeholders are shown how the system works
to remove fear of the unknown.
Road Shows Town-hall style presentation of project to build
awareness of change.
Posters/Trinkets Reminders that change is coming and to keep
awareness alive.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
25
Business Analysis Planning Guide
Phase 4: Post Implementation
It is the responsibility of the BA to ensure the appropriate channels of communication are
provided for post-implementation support to enable dialogue about issues and problems.
He/she can do this by ensuring the necessary requirements are developed. The goal
at this phase in the project is to ensure users are provided with post-implementation
support. The BA should consider the following communication types when planning
post-implementation communication:
Frequently Asked Questions By providing a document to which users can easily refer
when in search of answers to common questions, the BA
demonstrates IT’s ability to anticipate user issues and
proactively solve them.
Project Review Performed once a solution is delivered to show the
organization that IT values stakeholder input.
Lessons Learned Hosting a Lessons Learned session will demonstrate the
organization’s commitment to improvement.
Stakeholder transparency is key in ensuring the changes sparked by the solution are
accepted by the users that are affected by the changes stated earlier. As we said before,
it is important that the BA lets stakeholders know what is going to happen, when it will
happen, and how it will impact them. It is a good idea to let managers make these kinds
of announcements, because when people can’t get information from official sources,
they’ll most likely turn to the rumor mill. If stakeholders know they are being informed
of important information as soon as it is known, it’s more likely they will be accepting of
change and willing to collaborate with the BA to ensure the solution meets their needs.
Some of the most important information includes issues that were encountered and
lessons learned after the project. This information should be available to stakeholders
as it will benefit them to have that knowledge in future projects. Remember, failure to
communicate important information will increase stakeholder resistance and prolong
post-implementation support. On the other hand, open communication of issues and
their resolutions as they occur will help to maintain IT’s credibility with the rest of
the organization.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
26
Business Analysis Planning Guide
Training and Support Plan
After communication, the next important activity when facilitating change within the
organization is to ensure the users of a new or updated application are provided with
a comprehensive training and support plan. When developing this part of the change
management plan, it is important to work closely with developers and the stakeholders
working with the application. To create a training and support plan, BA must perform
the following activities:
This can include knowledge, resources, etc.
You will most likely need to consult developers to determine these requirements.
Identify areas aected by the change. List all the impacted services or business units.
How much training will each
business unit need? What functions will they need to perform?
The user skills
of stakeholders oen varies.
Ensure the stakeholders are provided with enough time
away from their duties to attend necessary training sessions. Remember to allow time
for slower learners. You may need to provide small group or one-on-one training.
This should be something that clients can
fall back on, if needed. Necessary user manuals or FAQ guides should not be neglected
in the requirements specications.
Role Eight: Ensuring the Solution Delivers Business Value
Output: Benefits Realization Plan
The last role performed by a business analyst is arguably the most important. To ensure
solutions deliver business value, many organizations today are implementing Benets
Realization Management plans.
Benefits are defined as the measurable improvements that will result from solution
outcomes perceived as positive by stakeholders. Note that the benets of a solution are
not the actual outcomes themselves—an outcome is the source of a benet. Benets such
as “more sales” or “faster response time” cannot directly be made to happen. To ensure
the solution delivers value to the business, the BA must collaborate with various business
units to determine which solutions will provide the desired benets. It is also important for
the BA to collaborate with benet owners (individuals positively aected by the benets)
and stakeholders in the identication of measurements that indicate whether benets
have been achieved.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
27
Business Analysis Planning Guide
That’s where benets realization management comes in. Benets realization management
(BRM) is the process of organizing and managing potential benefits that arise from
investment in change to ensure the benets are achieved. BRM is a continuous process that
occurs throughout the project lifecycle. The process begins once the BA has documented
the business case, which includes a section listing the benets of the proposed solution.
To ensure benets are successfully achieved, it is good practice for the the project team
to ensure the following activities are performed:
Prepare a realistic and accurate business case. The business case should not just be used
to secure funding, but should also be used as a management tool to measure success.
Develop measures for determining project success. The measures should be based
on whether the business benets proposed in the business case were achieved. The
ultimate success of a project involves much more than successfully delivering the
solution on time, on budget, and within planned scope.
Use the right process and tool to ensure value is achieved. Currently, there is only one tool
on the market that helps manage value delivery from concept to achievement of business
benets—Enfocus Requirements Suite™. Enfocus Requirements Suite™ and its integrated
business analysis methodology, Requirements Excellence Framework™, provide full
support for capturing the business case, eliciting needs from stakeholders, developing and
prioritizing requirements to meet stakeholder needs and provide value, and managing the
benets through the solution lifecycle including development and post-implementation.
The benets realization plan, a vital component of the business analysis approach, must
be created early in the project lifecycle, once the business case has been documented. The
benets that were outlined in the business case must be listed in the plan, along with the
information that will help to evaluate the benets realization. The benets realization plan
must include four key components:
1. Descriptions of all benets of the solution.
2. How the benets are to be measured.
3. Who will be accountable for measuring and delivering benets.
4. When benets will be measured.
The most important element of the benets realization plan is to document how the benets
are to be measured and exactly what measurements are to be used. These measurements
must be referred to throughout the project lifecycle. The ROI will most likely be the ultimate
indicator of project success, but the BA should ensure there are more measures set than
that. A common method for determining measurements is to use Key Performance Indicators
(KPIs), which are signicant measures used to monitor how well a business is achieving its
quantiable objectives. Many KPIs have already been dened for various situations; for an
extensive collection of example KPIs that can be used or altered to t the organization’s
needs, BAs may refer to a best practice research community like RequirementCoach™
(provided with Enfocus Requirements Suite™), which contains hands-on, one-on-one
information, guidance, and mentoring in developing and managing requirements.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
28
Business Analysis Planning Guide
Once the benet measurements have been determined, the BA must then determine and
document the methods for collecting measurements, as well as the required effort to
obtain measurements and the necessary time frames. For example, one possible method
for determining user satisfaction is to distribute a satisfaction survey among stakeholders.
In the benets realization planning phase, the BA should determine the details of the survey
(the date the survey will be distributed, how the content of the survey will be determined,
the date the survey must be completed by, etc.) before moving further along in the project
lifecycle. Lastly, the BA must determine and document the roles and responsibilities of
project contributors. It is important that all benet owners and relevant stakeholders are
aware of and understand their part in the benets realization process.
The benets realization plan should be easily documented in a requirements management
tool. As the information is known, the BA should enter it into the application. The information
included in the business objectives of the solution makes up the required information in the
plan. Refer to the screenshot below for an example of a business objective (benet) record
in RequirementPro™. In a requirements management tool like this, the BA can document
the measure that will be used, the method for collecting the measures, the current baseline
measurements, as well as all of the other important details. To extract a copy of the plan,
use the report tool in the top right corner of the menu bar.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
29
Business Analysis Planning Guide
According to BABOK V3, business analysis is dened as:
“The practice of enabling change in an organizational context by defining needs and
recommending solutions that deliver value to stakeholders.”
This denition clearly shows that the business analyst serves as a facilitator for business
change and transformation. This new denition of business analysis comes from IIBA’s
Business Analysis Core Concept Model (BACCM). The BACCM is a tool for analyzing change
at any level in an organization, which includes activities like setting organizational strategy
or implementing a single feature/component on a small maintenance project. At the
foundation of BACCM™ are six core concepts: change, need, solution, context, stakeholder,
and value. All of the concepts are equally necessary and no single concept can be fully
understood until all six are understood. The six core concepts are presented in the
diagram below. Ensure that each of the considerations for the core concepts provided
in the following sections have been addressed.
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
30
Business Analysis Planning Guide
Stability
User adoption
Is it plan-driven?
Is it change-driven?
Business Intelligence
Merger or Acquisition
Collaboration
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
31
Business Analysis Planning Guide
Number of stakeholders
Number of impacted business processes
Location of stakeholders
Amount and nature of risk
Purchase
Build
Outsource
Multi-Source
People
Process
Technology
Budget
Time
Architecture and Technology
Quick Wins
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
32
Business Analysis Planning Guide
ROI
Impact and Consequences
Application and Implementation
Learning
Reaction and Perceived Value
Finance
Customer
Business Process
Learning and Growth
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
33
Business Analysis Planning Guide
Will it increase revenue?
Will it decrease costs?
Will it increase shareholder/taxpayer value?
Will it bring in new customers?
Will it bring in more money from existing customers?
Cash Cycle
Days of inventory
Days of receivables
Days of payables
Eiciencies
Headcount reduction/avoidance
Productivity
Employee turnover
System end-of-life
Discounts
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
34
Business Analysis Planning Guide
Hardware/soware investment avoidance
Unit cost and other cost avoidance
Factory uptime
Reduce waste
Risk avoidance
Time to market
Markets
Opening new markets
Optimizing existing markets
Cross-selling
Customer excellence program
Personal Gains
Relieving Pains
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved
35
Business Analysis Planning Guide
Executives
Project Management
Business Stakeholders
End Users
Developers
QA
Compliance
Collocated
Geographically dispersed
Customers
Suppliers
Partners
Others
