Before we can start building a business solution, we need ...open.uci.edu › upload › files ›...
Transcript of Before we can start building a business solution, we need ...open.uci.edu › upload › files ›...
-
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