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