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
 identify the best business approach for business
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 impact the scheduled end date. The original requirements would have been
impossible to use for the design and construction of the data center.

Question: Does Russ performance on the new project fair enough? Do you think there was
an overlapping of responsibilities between Russ being the project manager and the
business analyst team? Discuss your insights on this.
 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

Business Need 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 judgment is used to evaluate and build the optimal

Expert business analysis approach for your project. Your team will
judgement 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 process assets are an organization’s policies,

Organizational
guideline, procedures, plans, approaches, and standards for
Process Assets
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

Decision Analysis consequences of 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 models are often used by the business analyst to document

the steps of the business analysis approach or process for a project.
Process Modeling 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.
 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
Structured Walkthrough
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 engage- Business Analysis

ment process 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 Conduct Stakeholder lists, roles and

Stakeholder responsibilities
Organizational Process Analysis
Assets (OPA)

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 The more business analysis

at both the overall project level and stakeholders there are, the more
each project phase. Business analysts complicated dealing with them can
should perform this task when a become. Complexity factors that the
business need is identified and revisit business analyst should consider
and revise the results for as long as include the number and variety of end
business analysis work continues on the users for the solution, as well as the
project.
 Assess stakeholder attitudes and Define stakeholder authority
influence levels over business analysis
works
Stakeholder attitudes toward the project
must be assessed and then managed The business analysis team needs to
across the project life cycle. At a know exactly which stakeholders have
minimum, attitudes need to be looked authority over the business analysis
at relative to the business goals, work and deliverables. This includes
objectives, and solution approach for reviewing and approving deliverables
the project (such as 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
Organizational build an organization chart that shows the organizational units, lines
Modeling of reporting, the roles, and the people in those roles.

A RACI matrix is used to defi ne business analysis stakeholder

RACI Matrix roles 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
Specification A I R C C R
Validation I I R,A R R I

A stakeholder map looks at how these stakeholders will be involved

Stakeholder with the resulting solution. This takes the concept of an
Map 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