Module in Strategic Business Analysis

Lorenzo B. Cabili, CPA, JD, DM

Faculty, College of Business Administration

2 Business Analysis Planning & Monitoring

“An hour of planning can save you 10 hours of doing.”

-Dale Carnegie

Overview

Now that you are more familiar with the discipline

of business analysis, you are ready to address
planning the business analysis activities for a
project or initiative. Using those foundation, you
will begin to apply business analysis tasks and
techniques as we walk through the first knowledge
area. The first skills you will put to use are
analytical thinking and problem solving. After all,
before you can begin a project or project phase,
it’s a good idea to know what work you need to do.
In order to achieve a controlled start to a project
or project phase, you must be
methodical and consistent in your planning, definition, and decisions. This is
the first step in planning the business analysis work effort for a project.

Learning Objectives

At the end of this module, you should be able to:

Identify the various tasks of business analysts under

knowledge area of planning and monitoring
identifythebestbusinessapproachforbusiness analysis planning
understand the importance of stakeholder identification,
analysis and categorization
 Business Analysts Tasks

The Business Analysis Planning and Monitoring knowledge area also

addresses monitoring and reporting on the business analysis work being
performed on a project once the planning is complete and the work efforts
are underway. This ensures the project’s business analysis effort produces
the desired outcome and that the business analysis work is done right.

The Business Analyst’s Task List

The business analyst has six tasks to perform in the Business
Analysis Planning and Monitoring knowledge area. The task list
includes:

 Planning the business analysis approach

 Conducting stakeholder analysis
 Planning business analysis activities
 Planning business analysis communication
 Planning the requirements management process
 Managing business analysis performance

These tasks focus on planning how the business analysis team will approach
a specific effort. The business analyst is responsible for developing, defining,
and managing the roles and tasks associated with this work. The goal of the
project is to define, develop, and deliver a solution that addresses a business
problem, need, or opportunity. To achieve that goal, the business analyst
must have detailed knowledge of each task, be able to apply the
recommended techniques, and produce high - quality deliverables as a
result.

MIND CHALLENGE #
1
Russ discovered early in his career as a project manager that all plans are not
created equal. He was a replacement for the project manager on a fairly complex
data center consolidation project. Russ stepped in near the end of the first major
phase of project work, which was developing the user requirements for the new data
center.

One of his first tasks was to review the current project plan and evaluate the
progress to date. Russ noticed that the requirements development work was shown
as a single two - week task in the project plan with no additional details about the
requirements process itself. Because the resulting user requirements document was
shown as a completed deliverable and this task was marked as 100 percent
complete, he decided to look at the new capabilities the project would provide to the
business and its users. So he did.

After reading the first four pages of the document, Russ knew there was a problem.
He finished reading the user requirements document, closed the file on his
computer, and reached for the phone to call the lead business analyst for this effort
into his office. When Mary arrived, he asked her, “What exactly is this document
supposed to be? Is this just a high - level concept that we need to now go out and
define? ” Mary replied that the document was the final, approved user requirements
document. All the business analysis team had to do now was give the document to
the developers. The developers would figure out the rest.

Russ asked Mary to explain the process she and her team had gone through to
produce the deliverable. She explained that she had worked in tandem with the
development director to elicit, analyze, and specify the user requirements for the
project. Basically, the key users had not been involved or consulted at all. As Mary
was quick to point out, “That wasn’t in the plan so that wasn’t how I did the work.”
Basically, the user requirements work had to begin all over again and had to be done
correctly the second time.

Russ worked closely with his business analysis team to plan the requirements
development work in far greater detail. This time around, the team gave themselves
adequate time to elicit and analyze the requirements and planned the time to
validate the requirements when everything was complete. Completing the rewritten
user requirements took five additional weeks of work. Funny enough, this didn’t
 Business Analysis Approach

The first task in the Business Analysis Planning and Monitoring knowledge
area is to plan the business analysis approach. There are many ways to
approach business analysis work on a project. In order to get the business
analysis work started on a project, you must first decide how to go about
doing it. The overall business analysis process for performing work consists
of:

 Deciding how and when business analysis tasks will be performed

 Agreeing on the techniques to be used
 Defining the deliverables to be produced

The best business analysis approaches are based on the organizational

environment where they will be used. The business analysis approach is a
subset of the overall project approach. It defines the set of processes,
templates, techniques, and activities used to perform business analysis on a
project or initiative. When documented, the business analysis approach
creates a formalized and repeatable methodology. In comparison, the project
approach describes the way all of the project work will be approached.

Plan Driven vs. Change Driven Approaches

When you define your business analysis approach, you must decide where it
falls across the spectrum of plan-driven approaches and change-driven
approaches. Plan – driven approaches focus on ensuring that the solution is
fully defined before its implementation begins. Change - driven approaches
are used on projects where many small iterations are defined and developed
en route to the final result.

Plan-driven business analysis tries to minimize your up - front uncertainty (or

risk) and maximize your control over the business analysis activities on your
project. This is a more traditional style of development. The biggest issue
with plan-driven approaches is whether or not the solution requirements can
actually be well defined prior to commencing the overall solution delivery
efforts. In effect, plan-driven approaches use structure to control project risk.

Change-driven business analysis approaches target rapid delivery of business

value. In order to achieve that goal, they accept greater uncertainty (risk)
relative to the overall solution delivery. This is an exploratory approach to
finding the best solution, using short iterations to incrementally develop
components of the solution. Change - driven approaches that you may be
familiar with include agile development methods and many continuous
process improvement projects being done in organizations. One key feature
of change -driven approaches is that they use flexibility to control project risk.

Plan the Business Analysis Approach

Now let’s get to the task at hand, which is planning the business analysis
approach. Every task has inputs, outputs, elements, and techniques. This
task is no exception. Let’s start with the inputs. Inputs are either
informational in nature or outputs produced by other business analysis tasks.
Inputs are acted on by the task elements and techniques, producing one or
more task outputs. Let’s take a look at the task inputs used when planning a
business analysis approach:

The business analysis approach is impacted by the

Business Need business need that is driving the project. Both the
project
 approach and the business analysis approach
will be impacted by the problem or opportunity
it is addressing.

Expert judgement Expert judgment is used to evaluate and build the

optimal business analysis approach for your
project. Your team will rely on individuals or groups
with specialized knowledge or skills in business
analysis and other aspects of the domain to assist
in defining the approach.

Organizational Organizational process assets are an organization’s

Process Assets policies, guideline, procedures, plans, approaches,
and standards for conducting work.

The experienced business analyst spreads their attention across eight

elements when they consider the contents of the business analysis
approach. The results of each element are formally documented as part of
the business analysis approach for the project. The detailed elements
necessary to plan the business analysis approach include:

Determining timing of business analysis work

Deciding degree of formality and level of detail for business analysis
deliverables Methods for prioritizing the requirements
Building an appropriate change management approach
Planning and integrating the execution of business analysis
activities Creating an approach to stakeholder communications
Identifying any requirements analysis or management tools to be
use Considering project complexity

Be sure you remember the six factors that increase the

complexity of
business analysis work. The rule of thumb is that as these factors
increase, so does the project complexity. They are:

 The number of stakeholders

 The number of business areas affected
 The number of business systems affected
 The amount and nature of risk
 The uniqueness of requirements
 The number of technical resources required

There are a number of techniques that you might choose to apply when
building a business analysis approach for your project. You may use the
decision analysis technique in order to consider alternative business analysis
approaches before making your final decision. Let’s take a look at that
technique in greater detail.

It allows the business analyst to examine and model the consequences of

Decision Analysis different decisions before actually making or recommending a particular
decision. It is typically done by using some form of mathematical modeling
to assess possible outcomes.

Process Modeling
Process models are often used by the business analyst to document the steps
of the business analysis approach or process for a project. Think of
graphically depicting a series of business analysis process steps on a
whiteboard with arrows between them to show the sequence of events. That
is a simple process map that can be used to build and decide on a business
analysis approach.
Structured Walkthrough

Experienced business analysts use a structured walkthrough to validate the

business analysis approach for a project with key stakeholders and team
members. This is a meeting with a tour guide. Your destination is the
business analysis approach, and your meeting agenda will walk you through
the possibilities in order for the group to decide on the approach that is right
for their project.

Once you have chosen one or more techniques, you are

ready to create your business analysis approach. We’ll
discuss that next. But before that treat yourself for a
break and afterwards you may answer the activity
below.

MIND CHALLENGE #
2

Inside or Out?

Imagine that you are a coffee vendor dealing with the weather prediction:
There’s a 50 percent chance of sun today, a 35 percent chance of some clouds,
and a 15 percent chance of rain. You have two options for where you place your
coffee cart on this particular day: inside a downtown office building or outside on
the sidewalk.

Based on your previous experience. When you set up your coffee cart outside on
a sunny day you typically make about P300 in profit. Selling coffee outside on a
rainy day equals a net loss of P100. Last but not least, being outside selling coffee
on a cloudy day yields an estimated P200 profit.

You do the same for your alternative location, setting up your coffee cart inside
the office building. Setting up your cart inside requires you to pay a fee, which
reduces your profits. Inside on a sunny day it has an estimated P250 profit. If it is
a nice day and you are inside, many of your customers will not come inside to
look for you. You figure that being inside on a rainy day equals a P225 estimated
profit and that having your coffee cart inside on a cloudy day equals an estimated
P250 profit.

What to do?: Make a graphical decision tree. Regardless of where you set up your
coffee cart, the weather prediction tells you that the probability of sun today is 50
percent, the probability for clouds is 35 percent, and that there is a 15 percent
probability of rain. For each of your possible locations (inside or outside), you
note these numbers. Make sure that all three probabilities add up to 100 percent
so that all options are covered. Given this data for comparison, which option
would you choose that would yield a high expected monetary value for your
business? Present and discuss your decision.
Create the Business Analysis Approach

The business analysis approach specifies how the business analysis team
plans to perform the business analysis work on their project. Essentially, this
approach is the business analysis methodology for the project. Once the
business analysis approach is complete, it is used as an input by other
business analysis tasks.

Output: Plan Business Analysis Approach

Task Output Destinations Source Knowledge Area

Business Analysis Plan business analysis Business Analysis

Approach activities Planning & Control

Plan requirements Business

engage- ment process Analysis
Planning &
Control

The recommended contents of the business analysis approach include:

 Team roles and responsibilities
 Business analysis deliverables
 Business analysis techniques
 Timing and frequency of stakeholder interaction
 Elements of the business analysis process

A number of stakeholders are involved with planning the business analysis

approach for a project. Some stakeholders should participate in building all
or part of the approach; others are only affected by the approach. As
previously mentioned, the project manager must make sure that the
business analysis approach aligns with the project approach. In a similar
vein, testers must ensure that the approach facilitates appropriate testing of
the resulting solution.

Stakeholder availability and involvement across the project life cycle may
impact the contents of the business analysis approach. Key stakeholders
involved with this deliverable include:

 Customers
 Domain SMEs
 End users
 Suppliers
 Sponsors
 Stakeholder Analysis

Effective business analysts recognize the importance of

knowing, understanding, and involving your project
stakeholders. Stakeholder analysis should begin early in
the project life cycle when the business requirements
are being developed. The resulting stakeholder
information is then revisited and revised throughout the
project life cycle. Without up - to - date stakeholder
analysis information, it is not easy to elicit, validate,
or approve project requirements with the appropriate individuals or groups.

Analysis activities at this point in time focus on key stakeholders who are
impacted by the business need and the proposed solution. The initial
stakeholder list, roles, and responsibilities are enhanced and revised with
each subsequent project phase as the business, stakeholder, solution, and
transition requirements are developed for the project.

Let’s take a look at the task inputs used when analyzing our project stakeholders.

Business needs Enterprise

Architecture
Organizational Process Assets Conduct Stakeholder Analysis
(OPA) Stakeholder lists, roles and
responsibilities

In this task, the focus is on the stakeholders who will be affected by the
business need that is driving the project. Over time, you may discover and
analyze new stakeholders that the business analysis team was unaware of at
the beginning of the project. You also need to beware of the stakeholders
who change their position as the project progresses. The business need for
the project is defined during Enterprise Analysis.

Looking at the organization and how it is sliced and diced assists the
business analyst in stakeholder analysis activities.

Organizational process assets are an organization’s policies,

guidelines, procedures, plans, approaches, and standards for conducting
work. The business analyst should seek out and use any existing policies,
procedures, methods, and templates as part of stakeholder analysis.

Business analysts performing stakeholder analysis at any point in their

projects should apply four detailed elements as they
build their stakeholder list, roles,and responsibilities.
The detailed elements necessary to analyze stakeholders
and document meaningful information about them include:

Identify stakeholders
Analyze stakeholder complexity
Stakeholder identification should occur at
Themorebusiness analysis
both the overall project level and each
stakeholdersthereare, themore
project phase. Business analysts should
complicated dealing with them can
perform this task when a business need is
become. Complexity factors that the
identified and revisit and revise the results for
business analyst should consider
as long as business analysis work continues
include the number and variety of end
on the project.
users for the solution, as well as the
 Assess stakeholder attitudes and
Define stakeholder authority levels
influence
over business analysis works
Stakeholder attitudes toward the project must
The business analysis team needs to know
be assessed and then managed across the
exactly which stakeholders have authority
project life cycle. At a minimum, attitudes
over the business analysis work and
need to be looked at relative to the business
deliverables. This includes reviewing and
goals, objectives, and solution approach for
approving deliverables (such as
the project
requirements), requesting and approving
changes, and vetoing

There are three techniques that we highly recommend you use when
analyzing business analysis stakeholders:

When you use this technique for business analysis, you basically build an
Organizational Modeling organization chart that shows the organizational units, lines of reporting,
the roles, and the people in those roles.

A RACI matrix is used to defi ne business analysis stakeholder roles

RACI Matrix across four designations: R esponsible, A ccountable, C consulted, and I
nformed. The matrix may be created for the entire business analysis
effort, a particular business analysis task, or a specific business analysis
deliverable.

Sample RACI Matrix

Garcia Vineyards Requirements Development

Tasks William Hector Paula Kyla Gab Pia

Elicitation I I R,A R R R
Analysis I I R,A R R R
Specificatio A I R C C R
n
Validation I I R,A R R I

A stakeholder map looks at how these stakeholders will be involved with

Stakeholder Map the resulting solution. This takes the concept of an organizational model
one step further by visually relating the identified business analysis.

Onion diagram

External stakeholders : our customers

Organization Management and SMES: Gab, William

End users: Paula, Kyla

Solution delivery:
Pia, Hector
There are also additional techniques to consider in analyzing your stakeholders
for your project. They are summarized for you here.

 Acceptance and Evaluation Criteria Definition. As part of stakeholder

analysis, the business analyst must determine the specific
stakeholders possessing the authority to either accept or reject the
resulting solution based on the defined and agreed - upon acceptance
criteria.

 Brainstorming. This is an excellent technique to

use when the business analysis team is
generating a list of all possible stakeholders for
the business analysis effort. Generating ideas
about who the business analysis stakeholders
are could reveal hidden stakeholders that
should be involved with your efforts.

 Interviews. When interviewing business analysis stakeholders, the

business analyst should always ask the interviewees to identify
additional stakeholders.

 Process Modeling. It is the graphical

representation of a company's business
processes or workflows, as a means of
identifying potential improvements.
Anyone involved with the business processes that are
affected by the proposed solution should be identified as a
stakeholder. Process models can assist the business analyst with that
identification, as they show the related processes and systems.

 Requirements Workshop. When conducting requirements workshops on

any project topic, the business analyst should always ask the
participants about any additional stakeholders.

 Risk Analysis. The results of stakeholder analysis may

contribute to the risks for the business analysis effort
and to the project. The people involved with your
efforts can be the source of possible risks, and they
can also help the team identify additional risks that
may be important downstream.

 Scenarios and Use Cases. Identified stakeholder roles can be used

as the basis for actors and roles if the business analysis team has
selected the scenarios and use cases modelling technique.

 User Stories. Identified stakeholder roles can be used as the basis for
actors and roles if the business analysis team has selected the user
stories modelling technique.

 Scope Modeling. Scope models can show the business analysis team
the set of stakeholders external to the solution scope who interact with
the solution in some way.

 Survey/Questionnaire Business analysts may use this technique to

identify shared characteristics of a particular business analysis
stakeholder group.
 MIND CHALLENGE
#3

Phil is on a project that had been divided into three phases.

The first two phases were relatively inexpensive
commitments that were easily implemented. However, the
third implementation phase involved much higher vendor
involvement at a much higher cost. When the time came to
begin the third phase of this effort and the vendor’s work
estimates, which added up to several hundred thousands of
dollars, was presented to the project sponsor, the sponsor’s
support for the effort vanished. The sponsor’s recollections
of support for the previous two project phases also
disappeared. Adding insult to injury, the sponsor made a
point of disparaging the entire effort in the next executive
staff meeting.

Question: If you were Phil, was there anything you could have
done to prevent this?

Where you able to answer the self-assessment questions? Well done!

You are now through with module 2. Did you find this module
enriching? Keep that stock of knowledge. You will need it on the
succeeding module.
Congratulations, you are done with Module 2!

Recall that in Module 2, you have learned that the business analysis
deliverables and activities also need to be planned. Business analysts put on
their project management hats for a while and plan this work using a
common set of tools and techniques. The business analysis team has to
decide on the process they will follow to perform that work, either a plan-
driven approach that focuses on ensuring that solution is fully defined
before its implementation begins or a change-driven approach where many
iterations are developed enroute to final result.

There are a number of techniques that you might choose to apply when
building a business analysis approach for your project. We have decision
analysis, process modelling and structured walkthrough.

Understanding the lists and roles of stakeholders is essential to business

analyst and some of the task inputs in analyzing pout project stakeholders
are: business needs, enterprise architecture and organizational process
assets

There are three highly recommended techniques when analyzing business

analysis stakeholders: organizational modelling, RACI matrix and stakeholder
map.
Weese, S., Wagner, T., CBAP CCBA Certified Business Analysis Study Guide

Kupersmith, K & Mulvey, P., Business Analysis for Dummies