-
Before we can start building a business solution, we need to
know what the
users of that solution want it to do for them! Thus, the
business analyst's most
important role is to ensure that what the users (and other
stakeholders) want
is carefully captured, documented, analyzed, and then
transmitted
unambiguously to the people who are actually going to implement
it.
In many cases, the term "business solution" implies an
information
technologies (IT) solution with a software application as one of
the end
products. However, a solution can involve other technologies as
well, or it
might even encompass a simple business process improvement
project with
no new technology added.
-
Business Analysis Planning and Monitoring
The project manager and project team rely on the business
analyst to provide well-defined and documented
requirements. This requires a disciplined and methodical
approach to requirements elicitation, documentation,
and communication. The Business Analysis Planning and Monitoring
Knowledge Area in Chapter 2 of the BABOK®
focuses on this topic, presenting specific tasks that the
business analyst should carry out in order to achieve
high-quality, unambiguous, and actionable requirements.
This planning process allows the business analyst to
identify both tasks and people (including project team
members and stakeholders) that are instrumental for
effective requirements elicitation. The success of the
requirements elicitation process and the quality of the
requirements themselves depend on quality work, for
which an effective plan addressing tasks and overall
process management is quite important.
However, before any work is done, the Business
Analyst needs to carefully plan the work to be done,
which deliverables to produce, identify the
stakeholders involved (and how he will communicate
with them), and how to monitor whether the BA efforts
are on course with the overall project. These tasks are
described in the Business Analysis Planning and
Monitoring Knowledge Area.
-
Deliverables
As it turns out, the well-documented techniques of project
management are well-suited to defining how business
analysis activities are going to be performed in the context of
the project. In some ways, you might consider this
planning process as a mini-project within the scope of the
"actual" or overlying project.
If the project were to be developed sequentially, business
analysis planning would begin after the enterprise
analysis has been completed. In reality, of course, you may need
to start planning your requirements gathering
even before all the enterprise analysis is finished.
The deliverables of BA Planning and Monitoring include lists
of:
Identified stakeholders associated with the project, along with
their roles and responsibilities.
Deliverables to be produced along with the templates, standards,
etc. used by the organization.
Specific tasks for requirements gathering along with the people
responsible for those tasks.
Techniques used to perform the elicitation and communication
activities, as well as to estimate the amount
of BA work required.
Metrics used to assess the BA work and estimates on the duration
of BA tasks.
-
Upon completing this lesson, you should be able to:
Identify the stakeholders for a particular project or
initiative.Define the roles and responsibilities for the
differentstakeholders as they pertain to the current
project.Determine the approach to be selected for performing
BAwork, including the SDLC methodology to be used.Develop a
Business Analysis Plan, which includes theplanned BA activities,
estimates to complete requiredbusiness analysis tasks, and
deliverables that the BA willproduce.Develop a communication plan
for the BA effort.Develop a plan to manage requirements
implementation (i.e.,how requirements are approached, traced and
prioritized), aswell as define a process for requirements
change.Define the metrics to be used in assessing the
businessanalysis work effort and the process used to determine if
theBA effort needs preventive or corrective action.
-
Plan Business Analysis Approach
Carrying out the project-related business analysis
activities requires a carefully assembled plan. Developing
this plan is the responsibility of the project manager
working with the business analyst. Without a good plan,
there is a danger of not capturing all the requirements or
defining them poorly, which could lead ultimately to a
final product that doesn't meet the users' acceptance
criteria.
Some industries or organizations have specific
methodologies for building their products. For instance,
software development has the System Development Life Cycle
(SDLC) and Project Life Cycle (PLC)
methodologies. Since these kinds of methodologies usually
include requirements elicitation, a business analyst
working for a company that has adopted such a methodology will
need to follow it in developing a requirements
process plan.
Additional factors to consider during this planning stage
include:
Stakeholder expectations
Organization or industry standards (that may govern how projects
are implemented)
Do the business analysis planning activities need to be tailored
for a particular project or initiative?
-
Steps to Implementation
The first step is to identify all the stakeholders from
whom the business analyst will elicit requirements. These
stakeholders include anyone who has an interest in the
functional aspects of the final product. For example, the
user of a software package definitely has an interest in
how the package works. However, an upper-level
manager who only wants to see reports (printed on
paper) generated by that software package may not care
how the software works. She only wants to see the
reports!
At this point, the business analyst must decide how to
approach the relevant stakeholders. Some may be physically
remote and require travel or teleconference
sessions while others are local and amenable to in-person
meetings.
Next, the analyst must determine which specific methods of
eliciting requirements are appropriate both for the
stakeholder being interviewed and the type of information that
needs to be acquired. Details of these methods
are presented in Lesson 4.
After the business analyst has captured and compiled all the
requirements, he must decide upon an appropriate
approach for analyzing these requirements and determine the best
approach for documenting them. Along with
documentation, communication plays a critical role. No matter
how well requirements are written down, they are
not very useful unless the business analyst can communicate them
effectively to various decision makers and the
technical personnel who will implement them. These activities
are covered in Lessons 5 and 6.
Finally, business analysts must work with a project delivery
team to identify implementation tasks in the form of
a work breakdown structure (WBS) and formalize a means of
evaluating how well the solution meets
stakeholders' needs. This is covered in Lesson 7.
-
The Business Analysis Approach
According to the BABOK,® a Business Analysis Approach describes
the set of processes, templates and activities
that will be used to perform business analysis in a specific
context (i.e., a project or initiative).
There are many ways to approach business analysis work. One
approach is to use established methodologies for
software development (Waterfall/Agile) or business process
improvement (Lean/Six-Sigma). An organization can
also use a proprietary methodology or in-house practices and
process. The Organizational Process Assets defines
the standards, templates and deliverables regarding how business
analysis is done in the organization and how it
fits into a project and other activities.
Other factors to consider when planning the BA approach are:
the Business Need - the problem of opportunity faced by the
organization (and the reason for the project!)
and
Expert Judgment - the BA expertise either from within the
organization and/or the industry at large
-
BA Methodologies
A plan-driven methodology emphasizes
planning and formal documentation of the
processes used to accomplish a project and of
the results of the project. This methodology is
concerned about reducing upfront risk and
having control over outcomes over the delivery
of a solution. This approach is preferred when
requirements can effectively be defined in
advance of implementation and the risk of an
incorrect implementation is unacceptably high
(think medical equipment or an oil refinery), or
when managing stakeholder interactions
presents significant challenges.
Change-driven methodology focuses on rapid
delivery of solution capabilities in an
incremental fashion (i.e., Agile) and direct
involvement of stakeholders to gather feedback
on the solution's performance. This
methodology will accept a higher degree of
uncertainty (risk) regarding the overall delivery
of the solution in exchange for the flexibility to
manage requirement changes.
-
Plan-driven vs. Change-driven Methodologies
Almost all methodologies fit along a spectrum between
Plan-driven and Change-driven methodologies.
-
1. Which one of the following activities is not part of thePlan
Business Analysis Approach task?
a. Abiding to regulatory standards and federal guidelines. b.
Understanding the problems or opportunities facing the
organization. c. Developing a marketing plan to promote the
product in
the local market. d. Using the standard document templates
mandated by the
organization.
-
2. According to the BABOK,® Organizational ProcessAssets is an
input to all of the tasks in the Business
Analysis Planning and Monitoring Knowledge Area. Assuch, it
includes:
a. Methodologies for process change or softwaredevelopment, i.e.
Waterfall or Agile.
b. Real estate and other assets as described in
theorganization's Annual Report.
c. Corporate governance standards followed by
theorganization.
d. A and C only.e. A and B only.
-
Team Roles
Stakeholder roles are usually described in a responsibility
matrix (RAM), or roles and responsibilities table,
sometimes called a RACI matrix.
The initial step in the requirements planning process is to work
with the project manager to identify all roles
needed to carry out the project (the entire project, not just
the roles associated with requirements gathering).
Some organizations have defined roles while others give the
project team more flexibility. The BABOK® lists
numerous possible roles; here are just a few of them:
Executive sponsor - has final go/no-go decision authority.
Business analyst - works with project requirements.
Project manager - oversees the overall strategy and tactics for
completing a project.
Developer - Usually a technical person who creates IT or
engineering solutions designed to meet
stakeholder needs.
Quality assurance analyst - ensures that project activities are
carried out as formally specified by
organizational, industrial, or professional standards.
Application architect - creates a high-level design or approach
for solving a particular business problem.
Database architect or analyst (often a database administrator,
or DBA, with development skills) - technical
person who establishes the data storage structure to be used in
a given solution.
End users - people who interact directly with the project's end
product.
Stakeholders - anyone affected or impacted by a project's end
product.
-
Information about each stakeholder
should include the following:
Name
Job Title/Description
Organization/Company
Mailing and/or Physical Address
Phone Numbers
Email Address
Stakeholders
Project stakeholders are perhaps the most important people in
the life
of a project because they have so much influence over the
project's
existence. They control financial resources and specify the
desired end
product. Different stakeholders have different "stakes" in the
project
so the analyst must look at each stakeholder and identify
their
individual needs and interests in the project. Sometimes
stakeholders
may not be obvious - end users, the public, the government,
and
other people or entities may all be stakeholders in some
capacity.
It is very important to identify all stakeholders at the
beginning of a project. Stakeholders that emerge late in the
project's lifespan may demand changes that require substantial
rework or may even become adversarial to
project outcomes.
The business analyst needs to create a list of all stakeholders
- including groups as well as individuals - that have
any connection to his/her project. This list should contain
names of individuals along with their titles, contact
information, etc. For groups, there should be one representative
on the list. As a starting point, the business
analyst should consult all the documents prepared up to this
point in connection with the project.
-
To identify stakeholders, the business analyst can begin by
sending out questionnaires to potential stakeholders
and interviewing the likely candidates. The results of the
questionnaires and interviews allow the business analyst
to classify the stakeholders in terms of their influence on the
project. The questionnaires can also help uncover
additional stakeholders before the project gets too far along.
The BABOK® lists many relevant questions that
business analysts can ask to elicit this information.
Once the business analyst has compiled all the information, she
can prepare a summary table similar to this one
(only three rows are excerpted here):
StakeholderName/
Job Title
Project Stake Description
John Smith,ExecutiveDirector
Has been given a goal ofincreasing the number ofrecipients of
program servicesby 15% over the coming fiscalyear.
Oversees all program activities andstrategies; is responsible
forapproving program expenses,including those for
informationsystems upgrades.
Joan Carlson,Board Member(representsBoard ofDirectors)
Responsible for ensuring theprogram's success and
securingprivate funding.
Together with the rest of the Board,provides leadership and
direction forthe program; ensures the programachieves its
goals.
Jason Flowers,IT Director
Directs the program'sinformation system capabilitiesincluding
the development ofnew applications used byprogram staff
members.
Leads the IT staff in supportingprogram activities with
appropriatehardware and software components.Directs all in-house
softwaredevelopment efforts.
The main goal is to ensure that the execution of the project
goes as smoothly as possible. By identifying all
stakeholders and knowing how they might influence the project's
execution and eventual outcome, the business
analyst can help the project manager avoid decisions that later
end up creating more obstacles and delays.
-
R=Responsible
(does the work)A=Accountable
(decision maker)C=Consulted
(must be consulted before workproceeds)
I=Informed (only needs to be informed afterwork is
completed)
Role RACIExecutive Sponsor CBusiness Analyst RProject manager
ADeveloper CQuality AssuranceAnalyst
I
Trainer IApplication Architect
CDataModeler/InformationArchitect
C
Database Analyst (DBA) CBusiness Architect RSolution Owner CEnd
User ISubject Matter Expert C
RACI Matrix
In order to understand the nature of each role, the
BABOK® encourages the use of the RACI Matrix, as
defined in the table shown here.
After specific roles have been identified, the business
analyst must identify the people that will fill those roles
for the given project. The stakeholder role is especially
important and we will take a closer look at it in the
following pages.
-
Stakeholder Map
It is often useful to categorize stakeholders
and put them in groups representing the
amount of power (influence) they have and
whether they represent inhibiting or supporting
factors for the current project or initiative. The
Stakeholder Map is a technique that
graphically displays the relationship of
stakeholders to the initiative and to one
another. A typical mapping shows stakeholder
influence and the level of interest in the
project. From the BA perspective, this map can
determine where the stakeholder focus should
be.
See additional information on this technique.
Figure 2-5: Stakeholder Matrix, Business Analysis Body of
Knowledge® (BABOK® guide), Version 2.0, 2009,
International Institute of Business Analysis, Toronto, Ontario,
Canada, page 30.
http://www.mindtools.com/pages/article/newPPM_07.htmhttp://www.mindtools.com/pages/article/newPPM_07.htm
-
Stakeholder Onion Diagram
Another way to group stakeholders and their
relationship to the solution is by creating a
Stakeholder Onion Diagram. This diagram
consists of an inner circle (the solution),
surrounded by outside circles. For example,
stakeholders placed in circles closer to the
solution are those that will have a day-to-day
interaction with the solution. On the other hand,
stakeholders placed in the outer circles will have
less involvement with the solution, but still can
benefit from it. This diagram can provide insights
to potential conflicts of interest between the
different stakeholders with respect to the
solution.
See additional information on this technique here.
Figure 2-6: Stakeholder Onion Diagram, Business Analysis Body of
Knowledge® (BABOK® guide), Version 2.0,
2009, International Institute of Business Analysis, Toronto,
Ontario, Canada, page 30.
http://tynerblain.com/blog/2007/03/13/visualize-stakeholder-analysis/
-
1. A network integration engineer who is assigned towork on a
project that involves modifications to the
existing IT network infrastructure would receive whichRACI
rating?
a. "C" because she needs to approve any work that willinvolve
changes to the network.
b. "R" because she is one of the people actually carrying
outwork on the project.
c. "A" because she is responsible for identifying whichbusiness
units will be responsible for developing andpromoting new
products.
d. "I" because she does not need to know about any
networkchanges until after users have had time to gain
familiaritywith the new system.
-
2. Which of the following people have the most authorityto
"kill" a project?
a. Senior Business Analyst. b. Project Manager. c. The company's
private owners. d. The Chief Financial Officer.
-
Plan Business Analysis Activities
The fundamental goal when planning the business
analysis activities is to develop a concise and clear set of
steps or tasks that lead to the implementation of a well-
accepted solution. The Plan Business Analysis Activities
task includes the following general activities:
Identify the BA deliverables.
Determine the scope of work for the BA effort.
Determine the activities that will be carried out by
the business analyst.
Develop estimates for the BA work.
Which activities and how they are executed will determine the
business analysis deliverables quality and
timeliness.
When completed, this task will produce the Business Analysis
Plan which includes a detailed list of all the
activities including the resources needed (a work breakdown
structure {WBS} is one way of presenting this list)
and a description or diagram presenting the logical dependencies
among the activities.
-
What's Needed for Planning BA Activities
In developing Business Analysis Plans, the BA will use
previously collected information from other tasks:
BA Approach - information on the SDLC, deliverables, templates,
and tasks that should be included
BA Performance Assessment - information on metrics and
assessment of the BA effort
Stakeholder List (including stakeholder roles and
responsibilities) - information on individual stakeholders'
behaviors and preferences.
In addition, the organization or a regulatory body might mandate
specific deliverables. This comes under the
umbrella of Organizational Process Assets.
-
Keep in Mind ...
In planning the activities to be carried out, particular
elements will influence the types of activities and how
they'll be performed:
Geographic Distribution of Stakeholders, i.e., whether
stakeholders are co-located or dispersed will
affect the complexity of the project and impact the estimate of
activities.
Type of Project or Initiative. The type of project or initiative
will influence the business analysis
activities being planned (i.e., a new software development
project and a process improvement project
have different characteristics and will have a different set of
activities).
Business Analysis Deliverables. Deliverables in the Requirements
Package will vary according to the
initiative in question.
Determine Business Analysis Activities.Typical activity lists
are in the WBS. WBS defines scope of
work to help with estimation within a hierarchy, decomposing
activities and tasks to a greater detail (e.g.,
work packages). Create a WBS list by decomposing the project by
deliverable, dividing the project into
phases or iterations, or by using a previous similar project as
an outline for current project.
-
Steps to Implementation
Even though the business analyst has a list - perhaps
even a very detailed list - of requirements activities,
he still needs to estimate the scope of each activity,
the resources needed, and the time that will be
required to carry each activity out.
First, the business analyst can divide the entire
requirements process into a collection of milestones,
which mark significant events or accomplishments in
the execution of a project. Having a project charter
signed is an obvious example of a milestone.
Delivering a product to the customer for acceptance
testing is another.
Next, the analyst must identify individual work units,
which consist of very specific tasks or activities that
have a clearly identifiable "product" or end result
(which usually feeds into another work unit). Some
people define work units as tasks that cannot be
decomposed into smaller tasks. Others define work
units as activities that have a finite duration with a
minimum length. (In other words, you don't want to
break down a task into such small pieces as to be
ridiculous!). Obviously, judgment and experience are
important.
-
Communication
Today, many projects rely upon workers who are distributed
globally. Consequently, communications can be
challenging despite email, instant messaging, web-based
conferencing tools, and other technological aids. It is
still important for project leaders to engage in some
face-to-face meetings - even if only occasionally - to foster a
sense of cohesion.
The internet makes it easier to share common project files so
all workers can use the same design templates,
electronic interface standards, and technical specifications as
they build their portions of the project deliverables.
Everyone should be able to look up documented requirements,
business process documentation, and other
organizational documents that have an impact on their work
products. Many project leaders set up online portals
for their project teams so everyone can monitor milestones, view
current issues, and contribute to forum-like
discussions - all from the convenience of their desktops.
Another important component of a successful project is a
mechanism for sharing undocumented knowledge that
an individual worker may possess but hasn't been formally
captured. This knowledge-sharing is very important in
the earlier stages of a project when several business analysts
may be gathering requirements in geographically
different places from stakeholders who rarely communicate with
each other. A senior business analyst needs to
ensure that everyone shares the information they are
accumulating in order to reduce redundancy and resolve
conflicts.
-
Plan Business Analysis Communication
A project involves many levels of communication throughout its
lifespan. These communications may involve
project managers, business analysts, stakeholders of all kinds,
and the people who actually design and
implement the solution. On top of this, there may be occasional
needs to communicate externally, to the general
public, for instance, on projects that have especially high
visibility.
The business analyst must plan all avenues of communication in
advance as part of the broader business analysis
effort. This plan must include interactions with stakeholders,
including the actual requirements elicitation
activities themselves, along with communications targeting
managers and the solution development team. Each
deliverable has some element of communication associated with it
and the analyst needs to plan those elements
at the same time she identifies the deliverables.
The BA Communication Plan is included in the overall Project
Plan. Here are the kinds of things the business
analyst needs to consider for each deliverable of the plan:
What is being communicated and what is the most appropriate
format given the contents and the audience
Who should be party to the communication
When does the communication need to happen
-
Plan Business Analysis Communication
The communication of requirements is perhaps one of the most
important tasks associated with communications
planning. The audiences to which the business analyst must
present technical information can range from high-
level managers, who may have little technical knowledge, to
engineers and technicians, who will create the
solution. The format of the communication must match the
audience or the message will be lost. The
consequences of not paying attention to the audience range from
bad to worse: the project might be executed
incorrectly by technical professionals who misunderstand the
requirements or it might not be approved in the
first place by high-level leaders who don't see any business
benefits.
Various stakeholders must review project information at many
points during the project's lifecycle. It is the
responsibility of the business analyst to understand each
requirement thoroughly and present those requirements
in a manner that is understandable and actionable by these
stakeholders.
-
Communication Types by Stakeholder
Makeup of
Audience/StakeholdersType of Communications
Sponsors, CEOs, high-level managers
This audience requires summaries and, generally, high-level
descriptions. Members of this audience tend to befocused on major
outcomes, especially in terms of thefinancial benefits that could
accrue to their organization.
Users (or customers)of the businesssolution
This audience understands the business aspects but maynot
understand the technical aspects of a proposedsolution.
Requirements must be cast strictly in terms ofbusiness functions
and outcomes. Members of thisaudience need to see the requirements
in a fair amount ofdetail since they are the most affected by the
solution.
Engineers, applicationdevelopers, systemsanalysts
These people are the "builders" of the solution. They needfull
specifications that can be translated into specifictechnological
features of the solution they areimplementing. It is also very
important to provide themwith unambiguous success criteria that
must be met forthe project to be considered successful.
Designers anddevelopers
This category of stakeholder is in many ways similar to
theengineers and systems analysts. The main difference isthat these
people focus more on the functional elementsand user interface
characteristics of the solution. Theyneed to understand both the
technical and the businessrequirements.
Testing and qualityassurance personnel
QA personnel need to be involved nearly from thebeginning of a
project. They need to understand thefunctional requirements of the
solution so they candesign test procedures that ensure 1) the
solutionworks correctly and 2) the solution solves thebusiness
problem. They need both descriptive andtechnical details.
In general, the analyst can choose written (text) formats and
visual (physical models or abstract diagrams)
formats to present the requirements. Text is useful for
describing abstract concepts or for setting the context of a
requirement while diagrams are better-suited to show
relationships among objects or process flows through a
system. Sometimes, it's best to have a combination of the two
for even more clarity.
-
Communication Criteria
When deciding the best way to present requirements to a
stakeholder (or group of stakeholders), the business
analyst needs to consider the following criteria and/or
elements:
Purpose of the communication - What will the stakeholder(s) do
with the information?
Approve a requirements change request?
Provide comments and/or constructive criticism?
Brainstorm new requirements or refine existing requirements?
Specific contents - what does this specific group need to know?
How would another group of stakeholders
with different needs interpret the contents of the same
communication?
Level of detail needed - What is the lowest level of detail that
will serve the needs of the audience? How
about the needs of the business analyst or project manager?
Audience's technical background and/or familiarity with the
topic - Do they have the prerequisite
knowledge not only to understand the requirement, but to work
with it?
Degree of formality - How formal does this communication need to
be? What is the audience expecting?
Backup documentation - How much formal documentation needs to
accompany any verbal or live
presentations?
Version control - Which version of the requirement documentation
is to be presented? Is this a final
version (which is more formal) or an update (which could be
rather informal)?
It is important to note that a typical project is usually
accompanied by a wide variety of "deliverable" documents
ranging from informal work papers or work products to formal
reports. For instance, a requirements package is a
"deliverable" item that is clearly specified in the project
plan. There are usually many deliverables throughout a
project.
-
Degrees of Formality in Communication
Another aspect of technical communications involves
the degree of formality that is needed for a particular
project or a particular audience. Projects require more
formality if they are large and complex (in terms of
implementation strategy and the nature of the
business area), the technology being used is new or
controversial, the project's success is of mission-
critical importance, the project sponsors require
formality, regulatory review will be involved at some
point, or the project will be designed in-house but be
produced by external developers.
There is one important caveat to mention at this point.
If the business analyst decides to create different
versions of a particular requirements document in
order to address the needs of different audiences, she
needs to ensure that they all are consistent. If a
requirement changes, she needs to ensure that those
changes propagate throughout all the documentation.
For large projects this might become a non-trivial task!
It's best to plan carefully what needs to be
documented and how it will be documented so that not
only the audiences' needs are met but the
documentation is easily kept up-to-date.
-
Communications Plan
In smaller projects, the communications plan may not need to be
written down formally; in larger ones, it is
essential to write the plan down. In many cases, the
requirements elicitation activities are included within the
communications plan. After all, the main product of requirements
elicitation is a document that communicates
user and stakeholder needs to members of the project team. As an
example of a communications plan,
consider the following sample tasks from a software development
project for ABC Corporation's
Human Resources Department:
Task Audience Forum Deliverable CommunicationsMethod
Hold therequirementskick-off event
Stakeholdersand projectteam members
Group meeting PowerPointpresentationdescribing theproject's
vision
Verbalpresentation
Elicitpreliminaryrequirementsfrom HRmanagement
Managers andsupervisors inthe HR dept.
Small groupbrainstormingsession
Notes andsketches
Writtendocuments to besummarized at alater date
Elicit detailedrequirementsfrom HRmanagement
Managers andsupervisors inthe HR dept.
One-on-onediscussions
Notes andsketches
Writtendocuments to besummarized at alater date
Elicitrequirementsfrom HR staffmembers (whoare the onesthat will
use thenew applicationmostfrequently)
Senior HRrepresentatives,clerks, dataentry
specialists,departmentadministrators
RequirementsWorkshop
Grid capturingsystematicallyderivedrequirementsbased
onmanagementneeds andexpectations
Document to besent to uppermanagement forreview andcomment
viaemail
Prepare apreliminary costestimate fordeveloping thesolution
Developers,uppermanagement
Requirementsdocumentationreview - WBSdevelopment
Preliminaryfeatures list,infrastructurerequirements,and
laborrequirementsestimate
Formal documentto be delivered touppermanagement andproject
teammembers viaemail
-
1. A junior business analyst working for you just broughtyou a
full-color printout depicting a proposed web
interface for an application to be used by thepurchasing
department to manage their internal
operations. To which audience are you most likely toshow the
printout?
a. Project Sponsors b. The CEO and CFO of the company c.
Designers and developers d. The company's customers
-
2. You need to gain the support of a group of
companyshareholders for a telecommunications upgrade
project that will enable field workers to process textmessages
as well as make voice calls. Which of the
following communications approaches will you take?a. Demonstrate
the value that the project will bring to the
organization in terms of financial performance; avoidtechnical
details.
b. Present detailed wiring and cabling diagramsdemonstrating
your grasp of the technical intricacies ofthe project; the goal is
to build confidence in yourapproach.
c. Present a detailed, step-by-step implementation planreplete
with technical diagrams.
d. Gather the shareholders together in a conference roomand hold
a brainstorming session to come up with thebest implementation
plan.
-
Plan Requirements Management Process
The purpose of this task is to define (and then follow) the
process for planning the requirements work throughout
the project or project phase. It defines the process for
approving the appropriate requirements for an initiative,
as well as the process to manage changes to the solution or
requirements scope.
This process also determines:
The process for requirements change
Who will be informed on changes
Which stakeholders need to approve changes
Who does not need to be involved on changes
The need for requirements traceability and which requirements
attributes to capture
-
Inputs to the Plan Requirements Management ProcessTask
The previously defined Business Analysis Approach and the
Business
Analysis Plans, as well as the organization's approach to
requirements
definition, are used to determine the process used to manage
requirements implementation and change.
Some organizations have a formal requirements process as part of
their
Organizational Process Assets. Others have inconsistent
processes,
while some might not have a process at all. In these cases,
requirements are either ignored or folded into other phases of
the
project or initiative.
-
Planning the Requirements Management Process
In planning for requirements implementation and changes, the
business
analyst needs to address the following questions:
Does the organization have a requirements repository? Are
requirements organized for re-use?
How are the requirements set for traceability?
What requirement attributes are going to be selected?
What process will be used to prioritize requirements?
What criteria is going to be used to allow requirement
changes?
Who will authorize the changes?
Does the requirements management process need to be tailored
for a particular project or initiative?
-
Requirements Attributes
Requirements attributes provide metadata about the requirements
but are not part of the solution definition.
Attributes, however, provide useful information that can help
the project team efficiently and effectively make
tradeoffs between requirements, identify stakeholders affected
by potential changes, and understand the impact
of a proposed change. Therefore, requirement attributes need to
be planned for and determined, along with the
requirements themselves.
For a list of commonly used requirements attributes, go to the
BABOK®, page 44. Do you use any of
these attributes? Which of these attributes do you use?
-
Handling Changes
As the project moves forward, there will be changes or updates
to the recorded requirements, as well as
conflicting requirements or conflicting priorities over
requirements.
Organizations have either a formal or an informal change
management process to deal with these issues.
Business analysts need to consider these items when planning how
they will handle requirement changes:
The process has built-in authorization levels for approving
changes based on a set criteria like a dollar
amount or a certain number of hours.
The organization has a formal Change Control Board (CCB) that
authorizes requirements changes after
they've been approved.
A project team or product owner has direct control over
requirements changes (i.e., an Agile SDLC
environment)
Impact of changes to business processes, hardware/software
(including interfaces) and other
requirements, as well as expected risk from the change.
Change request documents - wording and structure.
Requirements change prioritization, again based on a set
criteria.
-
Tailoring Changes
The requirements management process sometimes is tailored to
meet the needs of a particular project. A
business analysis needs to consider the following:
Organizational culture - is the culture formal or informal, and
how does this formality/informality react to a
change in the normal requirements management process.
Stakeholder preferences - distinct stakeholders want different
levels of formality for change approvals
and/or process documentation.
Complexity of the project or product to be delivered - tailoring
based on unique characteristics of product
or product component or project/project phase.
Organizational maturity - how mature is the organization in
terms of an established requirements
management process.
Availability of resources - a major consideration and always a
challenge, especially if the organization is
launching many projects simultaneously.
-
Requirements Management Plan
This plan is an output of the Plan Requirements Management
Process Task.
The plan:
Describes the approach to be taken to structure traceability
Defines which requirements attributes will be used
Identifies a requirements prioritization process
Identifies a requirements change process and how changes will be
requested, analyzed, approved, and
implemented
-
1. How do change-driven methodologies (for exampleAgile software
development) handle requirements
change management?a. Change-driven methodologies use a formal
requirements
change control process and a formal requirementsprioritization
process.
b. Change-driven methodologies do not typically have achange
control process that is separate from therequirements
prioritization process. All requirements("new"/"changed") are
recorded in the product backlogand prioritized.
c. Change-driven methodologies don't prioritizerequirements.
They handle requirements change in asomewhat arbitrary way,
sometimes formally, sometimesinformally.
-
2. Even simple changes in requirements can have far-reaching
consequences for the project. So, the
Business Analyst involved in planning any type ofrequirements
change management process should be
concerned with:a. Determining the cost/time estimate of making
the
change, as well as either benefits or risks for making
thechange
b. Adopting techniques like risk analysis that could
establishwhether the change is feasible
c. Following an established process for requesting changeand
determining who will authorize any changes.
d. All of the above.e. A and C only.
-
Manage Business Analysis Performance
The primary purpose of this task is to manage (and monitor) the
performance of business analysis activities to
ensure that they are effectively executed.
In the planning stage, the business analyst needs to determine
which metrics will be used to measure the work
performed, such as:
Tracking the BA work
Assessing the quality of the work
Reporting issues
Managing problems
-
Project and Product Metrics
The next item in this topic focuses on project and product
metrics, that is, the processes and methods of
measuring how well the project is proceeding.
Project metrics focus on three primary criteria:
-
More about Metrics
The three criteria of Time, Quality, and Money are measurable
and need
a benchmark for comparison. This is so the business analyst
(and
project manager) can evaluate the project's status and make
decisions
to remain within the specified constraints.
By monitoring these metrics, analysts and project managers can
make
adjustments to resources (hire more people, ask for more
money,
negotiate for requirements changes, etc.). Generally, metrics
should be
collected and reported on a regular basis (such as weekly) and
allow
ample time for analysis and further data collection, if
needed.
-
BA Performance Metrics
Typically, the performance metrics used for BA work are aligned
with the overall project metrics. For example,
performance metrics could define a certain number of hours to
produce a deliverable or a particular due date.
Also, the metrics could be the deliverable itself. It all
depends on how the metrics are defined at the beginning of
the project.
When defining metrics, there are three elements to consider:
-
Variance Analysis
Please refer to pages 51 and 52 of the BABOK® for more
information and examples of this technique.
Variance analysis is a technique that the business analyst
can use to analyze discrepancies between planned and
actual performance. One aspect to keep in mind is the
magnitude of the variances based on the metric that is
being analyzed.
If variances are found, the BA will determine if any
corrective actions are necessary.
-
1. The organization has identified specific due dates
forbusiness analysis work within the project. While
assessing the performance of the BA work so far, youdiscover
that some of these dates might slip because
the work is going slower than expected. Therefore, youa. Keep
quiet about this discovery because it will probably
correct itself.b. Decide to take corrective action by analyzing
the gap
between the expected BA work and the current work sofar.
c. Update the project team on your findings, incorporatingthe
variance analysis findings and describing a correctiveline of
action to keep the project on track.
d. A and C only.e. B and C only.
-
In this lesson, you learned about the Business Analysis
Planningand Monitoring Knowledge Area. Key topics included:
Plan Business Analysis ApproachConduct Stakeholder AnalysisPlan
BA ActivitiesPlan BA CommunicationPlan Requirements Management
ProcessManage BA Performance
The planning and management of the requirements processresembles
in many ways traditional project management, whichyou may have
studied in an introductory course on the subject.Though the BABOK®
focuses on the requirements gatheringfunction, it is very useful
for business analysts to understandmodern project management
methodology in general - not onlybecause it helps them create a
better requirements implementationand management plan but it helps
them understand how toparticipate on a project effectively.
9PQzEzMDUwMTUtbDN0MnA2Lmh0bWwA: question[1]: Off
9PQzEzMDUwMTUtbDN0MnA3Lmh0bWwA: question[1]: Off
9PQzEzMDUwMTUtbDN0M3A3Lmh0bWwA: question[1]: Off
9PQzEzMDUwMTUtbDN0M3A4Lmh0bWwA: question[1]: Off
9PQzEzMDUwMTUtbDN0NXA4Lmh0bWwA: question[1]: Off
9PQzEzMDUwMTUtbDN0NXA5Lmh0bWwA: question[1]: Off
9PQzEzMDUwMTUtbDN0NnA4Lmh0bWwA: question[1]: Off
9PQzEzMDUwMTUtbDN0NnA5Lmh0bWwA: question[1]: Off
9PQzEzMDUwMTUtbDN0N3A2Lmh0bWwA: question[1]: Off