Learner Guide

259280: Plan and monitor the business analysis process 

Learner Information:
Details Please Complete this Section
Name & Surname:
Organisation:
Unit/Dept:
Facilitator Name:
Date Started:
Date of Completion:

Copyright
All rights reserved. The copyright of this document, its previous editions and any annexures thereto, is
protected and expressly reserved. No part of this document may be reproduced, stored in a retrievable
system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or
otherwise without the prior
permission.

Page 2 of 78
©Copyright Reserved
Key to Icons
The following icons may be used in this Learner Guide to indicate specific functions:

This icon means that other books are available for further
information on a particular topic/subject.

Books

This icon refers to any examples, handouts, checklists, etc…

References

This icon represents important information related to a specific topic

or section of the guide.
Important

This icon helps you to be prepared for the learning to follow or assist
you to demonstrate understanding of module content. Shows
transference of knowledge and skill.
Activities

This icon represents any exercise to be completed on a specific topic at

home by you or in a group.
Exercises
An important aspect of the assessment process is proof of competence.
This can be achieved by observation or a portfolio of evidence should be
submitted in this regard.
Tasks/Projects

An important aspect of learning is through workplace experience.

Activities with this icon can only be completed once a learner is
in the workplace
Workplace
Activities

This icon indicates practical tips you can adopt in the future.

Tips

This icon represents important notes you must remember as part of the
learning process.
Notes

Page 3 of 78
©Copyright Reserved
Learner Guide Introduction

About the Learner This Learner Guide provides a comprehensive overview of the Perform
Guide… Enterprise Analysis, and forms part of a series of Learner Guides that have been
developed for National Certificate: Business Analysis LEVEL 6- SAQA-
63909-149 CREDITS. The series of Learner Guides are conceptualized in
modular format and developed for National Certificate: Business Analysis
LEVEL 6- SAQA-63909-149 CREDITS. They are designed to improve the
skills and knowledge of learners, and thus enabling them to effectively and
efficiently complete specific tasks. Learners are required to attend training
workshops as a group or as specified by their organization. These workshops are
presented in modules, and conducted by a qualified facilitator.

Purpose The purpose of this Learner Guide is to provide learners with the necessary
knowledge related to Perform Enterprise Analysis

Outcomes A person credited with this unit standard is able to:

 Conduct stakeholder analysis to identify all stakeholders for a project.
 Plan business analysis activities for a project.
 Plan business analysis communication for a project.
 Plan requirements management process for a project.
 Plan, monitor and report on business analysis performance . 

Assessment The only way to establish whether a learner is competent and has accomplished
Criteria the specific outcomes is through an assessment process.
Assessment involves collecting and interpreting evidence about the
learner’s ability to perform a task.
This guide may include assessments in the form of activities, assignments, tasks
or projects, as well as workplace practical tasks. Learners are required to
perform tasks on the job to collect enough and appropriate evidence for their
portfolio of evidence, proof signed by their supervisor that the tasks were
performed successfully.

To qualify To qualify and receive credits towards the learning program, a registered
assessor will conduct an evaluation and assessment of the learner’s portfolio of
evidence and competency
Range of Learning This describes the situation and circumstance in which competence must be
demonstrated and the parameters in which learners operate

Responsibility The responsibility of learning rest with the learner, so:

 Be proactive and ask questions,
 Seek assistance and help from your facilitators, if required.

Page 4 of 78
©Copyright Reserved
Learning Unit 1 Plan and monitor the business
analysis process

UNIT STANDARD NUMBER : 259280

LEVEL ON THE NQF : 6
CREDITS : 10
FIELD : Physical, Mathematical, Computer and Life Sciences
SUB FIELD : Information Technology and Computer Sciences
PURPOSE
This unit standard will enable learners to plan and monitor the business analysis process for the
duration of a project.

A learner credited with this unit standard will be able to:

Conduct stakeholder analysis to identify all stakeholders for a project.
Plan business analysis activities for a project.
Plan business analysis communication for a project.
Plan requirements management process for a project.
Plan, monitor and report on business analysis performance.

LEARNING ASSUMED TO BE IN PLACE:

It is assumed that the learner has the following knowledge and skills: •
Understanding of SDLC (systems development lifecycle) methodologies,
techniques, notations, and stakeholder roles NQF Level 5.
Communication NQF Level 5. • Information gathering techniques at NQF Level 5.

Page 5 of 78
©Copyright Reserved
SESSION 1:
Conduct stakeholder analysis to identify all stakeholders for a
particular project.
Learning outcome
 Organisational standards and type are identified to determine potential stakeholders.
 Stakeholders are identified in accordance with the impact that a project would have of their business need.
 Stakeholders are analysed to determine their influence and authority on the project.
 Stakeholders are assessed to determine their attitude to the project requirements.
 A stakeholder list is produced to reflect their roles, responsibilities and impact on the project.

1.0 Introduction

Stakeholder analysis in conflict resolution, project management, and business administration, is the
process of identifying the individuals or groups that are likely to affect or be affected by a proposed
action, and sorting them according to their impact on the action and the impact the action will have on
them. This information is used to assess how the interests of those stakeholders should be addressed
in a project plan, policy, program, or other action. Stakeholder analysis is a key part of stakeholder
management.

Stakeholder analysis is a term that refers to the action of analyzing the attitudes of stakeholders
towards something (most frequently a project). It is frequently used during the preparation phase of a
project to assess the attitudes of the stakeholders regarding the potential changes. Stakeholder analysis
can be done once or on a regular basis to track changes in stakeholder attitudes over time.

As part of defining a particular business need, business analysts are asked to analyze the
organization’s business goals and objectives. Here is the strategy implementation:

Organisational standards and type are identified to determine potential stakeholders

Vision -> Mission -> Strategic Plan -> Business Goals and Objectives -> Business Needs ->
Portfolios, Programs, Project

The Business Need is the first building block that you need to define the business requirements for
your project.

The business need is not typically a standalone deliverable or document. It is a very high-level
business requirement and should be included in the business requirements document or business case
for a project.
Using the business need and desired outcome, you will define the required capabilities that the
organization must have to meet the business need.

1.1 Stakeholders are identified in accordance with the impact that a project would have of their
business need.

Stakeholder identification

 Stakeholder analysis for a discussion of people or organizations (legal entities such as companies,

standards bodies) that have a valid interest in the system. They may be affected by it either directly or
indirectly. A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is
increasingly recognized that stakeholders are not limited to the organization employing the analyst.
Other stakeholders will include:

 anyone who operates the system (normal and maintenance operators)

 anyone who benefits from the system (functional, political, financial and social beneficiaries)

 anyone involved in purchasing or procuring the system. In a mass-market product organization,

product management, marketing and sometimes sales act as surrogate consumers (mass-market
customers) to guide development of the product

 organizations which regulate aspects of the system (financial, safety, and other regulators)

 people or organizations opposed to the system (negative stakeholders; see also Misuse case)

 organizations responsible for systems which interface with the system under design

 those organizations who integrate horizontally with the organization for whom the analyst is
designing the system

Requirements analysis issues

Stakeholder issue

Steve McConnell, in his book Rapid Development, details a number of ways users can inhibit
requirements gathering:

 Users do not understand what they want or users don't have a clear idea of their requirements

7
  Users will not commit to a set of written requirements

 Users insist on new requirements after the cost and schedule have been fixed

 Communication with users is slow

 Users often do not participate in reviews or are incapable of doing so

 Users are technically unsophisticated

 Users do not understand the development process

 Users do not know about present technology

This may lead to the situation where user requirements keep changing even when system or product
development has been started.

Engineer/developer issues

Possible problems caused by engineers and developers during requirements analysis are:

 Engineer/developer starts coding/implementation immediately before they really understand

the whole requirement from analyst, which usually causes lots of defect fixing or reworking
in test/verification phase.

 Technical personnel and end-users may have different vocabularies. Consequently, they may
wrongly believe they are in perfect agreement until the finished product is supplied.

 Engineers and developers may try to make the requirements fit an existing system or model,
rather than develop a system specific to the needs of the client.

 Analysis may often be carried out by engineers or programmers, rather than personnel with
the domain knowledge to understand a client's needs properly.

1.3 Stakeholders are analysed to determine their influence and authority on the project.

Stakeholder analysis

Stakeholder analysis (SA) identifies and describes stakeholders and assesses their respective interests
in a particular issue. SA is used in the policy and project context, during planning and development,
implementation, and evaluation and analysis. It is a useful management tool as it poses strategic
questions such as who should be considered, and what is the best strategy to manage the particular
stakeholder. In the context of policy making, there are, according to D. Strauss, four types of
stakeholders that have to be considered:

 those with formal power to make a decision,

 those with power to block a decision,

 those affected by a decision, and

 those with relevant information or expertise.

SA also helps in understanding the complexity of an issue. The result of SA is a list that encompasses
the main relevant characteristics of each of the stakeholders. The characteristics considered vary
depending on the purpose of the SA. They can include a description of the stakeholders' involvement
in the issue, an assessment of their level of interest in the issue, influence, position towards the issue,
and the impact of an issue on a particular stakeholder. Relationships between different stakeholders
can also be part of an SA

How to Conduct a Stakeholder Analysis

The different purposes of an SA

A stakeholder analysis can be conducted at different stages of the project and policy cycle and for
different purposes. In a project implementation purpose, an SA can be used to identify potential
project partners and supporters. It also provides information on possible risks to the project's success.
Furthermore, the SA may lead to mapping all those stakeholders that need to be informed about the
project, and those that can evaluate the results/impact of that project.
An SA can also be useful for organizational development, such as setting up a trade facilitation body
or working group. In this case the SA provides information on who should be involved in the
organization itself and who constitutes the organizational environment.

Timeframe of SA

The timeframe for an SA depends on the purpose and the number of potential stakeholders and
resources available. In the project scenario, an SA can be a short time analysis conducted once at the
beginning of the project. In the context of the development of an organization, an SA can be
conducted periodically in line with the evolution of the organization and the stakeholders and their
relationships. It can become a measure of the success of organizational development. Attention has to

9
be paid to not collecting too much information. The scope of the SA should be clearly defined at the
beginning of the analysis. The scope can include the stakeholders' attributes (numbers, size, market
value, etc.), their interests, resources and influence/power. More in-depth information, including the
origin of the influence and resources as well as the relationships between the different stakeholders,
may take a longer time.

External versus internal analysts

The analysis can be undertaken by an external or an internal analyst. An external analyst is a person
who is not involved in the project or organization and who is not affected by the issues. Both options
have their advantages and disadvantages. An external analyst is a neutral actor who does not hold
preconceived opinions about the other stakeholders, and is not embedded in any form of relationship
with them. The disadvantage of external analysts is that they may not have the necessary knowledge
of, and familiarity with, the environment, and will not easily notice subtle characteristics, in particular
any constrains in the relationships between the stakeholders. Internal analysts have better levels of
familiarity and knowledge. This, however, does not automatically mean that the analyst has analytical
understanding of the environment. It is also more difficult to neutralize any potential biases against
the stakeholders and the analysts in the case of an internal analyst.

Analysis process

SA is based on bilateral interviews to collect information and data. The interviews make use of
standardized questions. The analyst records the answers and his/her perceptions and assumptions. The
information is than organized and analysed before being presented to the stakeholders who were
interviewed. It is necessary to ask for confirmation of the analysis and its underlying perceptions and
assumptions by presenting the findings to individual stakeholders. The results of an SA are often
presented in tables, maps or matrices. In a table the characteristics and other information collected for
each stakeholder is presented (see example below). The information in the table can be text based or
standardized by using qualifiers such as high, medium, low, supportive, opposed, etc. Using
standardized qualifiers allows the information to be presented to all stakeholders in matrices
combining one or two characteristics.

 
1.4 Stakeholders are assessed to determine their attitude to the project requirements

Expert Judgment

It is used to evaluate and build the optimal business analysis approach for the project. The team will
rely on specialized knowledge or skills in business analysis from groups or individuals in defining the
approach.

In the case of developing a project charter, expert judgment would be helpful in assessing the inputs
of this process, the environmental factors, and organizational assets -that is, the project statement of
work, product descriptions, strategic plan, project selection methods, and historical information.
These groups of people may be stakeholders, consultants, other experts in the organization, or
technical or professional organizations.

Why identify and analyze stakeholders and their interests?

The most important reason for identifying and understanding stakeholders is that it allows you to
recruit them as part of the effort. 

It puts more ideas on the table than would be the case if the development and implementation of the
effort were confined to a single organization or to a small group of like-minded people.

 It includes varied perspectives from all sectors and elements of the community affected, thus
giving a clearer picture of the community context and potential pitfalls and assets.

 It gains buy-in and support for the effort from all stakeholders by making them an integral
part of its development, planning, implementation, and evaluation.  It becomes their effort,
and they’ll do their best to make it work.

11
  It’s fair to everyone. All stakeholders can have a say in the development of an effort that may
seriously affect them.

 It saves you from being blindsided by concerns you didn’t know about. If everyone has a seat
at the table, concerns can be aired and resolved before they become stumbling blocks.  Even
if they can’t be resolved, they won’t come as surprises that derail the effort just when you
thought everything was going well.

 It strengthens your position if there’s opposition. Having all stakeholders on board makes a
huge difference in terms of political and moral clout.

 It creates bridging social capital for the community. Social capital is the web of
acquaintances, friendships, family ties, favors, obligations, and other social currency that can
be used to cement relationships and strengthen community.  Bridging social capital, which
creates connections among diverse groups that might not otherwise interact, is perhaps the
most valuable kind. It makes possible a community without barriers of class or economics,
where people from all walks of life can know and value one another.  A participatory process,
often including everyone from welfare recipients to bank officers and physicians, can help to
create just this sort of situation.

 It increases the credibility of your organization. Involving and attending to the concerns of all
stakeholders establishes your organization as fair, ethical, and transparent, and makes it more
likely that others will work with you in other circumstances.

 It increases the chances for the success of your effort. For all of the above reasons, identifying
stakeholders and responding to their concerns makes it far more likely that your effort will
have both the community support it needs and the appropriate focus to be effective.

1.5 A stakeholder list is produced to reflect their roles, responsibilities and impact on the
project.

WHO ARE POTENTIAL STAKEHOLDERS?

As we discussed, there are primary and secondary stakeholders, as well as key stakeholders who may
or may not fall into one of the other two categories.  Let’s examine possible stakeholders using that
framework.

PRIMARY STAKEHOLDERS

Beneficiaries or targets of the effort

Beneficiaries are those who stand to gain something – services, skills, money, goods, social
connection, etc. – as a direct result of the effort.  Targets are those who may or may not stand to gain
personally, or whose actions represent a benefit to a particular (usually disadvantaged) population or
to the community as a whole.

Some examples are:

 A particular population – a racial or ethnic group, a socio-economic group, residents of a

housing project, etc.

 Residents of a particular geographic area – a neighborhood, a town, a rural area.

 People experiencing or at risk for a particular problem or condition – homelessness, lack of

basic skills, unemployment, diabetes.

 People involved or participants in a particular organization or institution – students at a

school, youth involved in the justice system, welfare recipients.

 People whose behavior the effort aims to change – delinquent youth, smokers, people who
engage in unsafe sex, people who don’t exercise.

 Policy makers and agencies that are the targets of advocacy efforts.

SECONDARY STAKEHOLDERS

Those directly involved with or responsible for beneficiaries or targets of the effort

These might include individuals and organizations that live with, are close to, or care for the people in
question, and those that offer services directly to them. Among these you might find:

 Parents, spouses, siblings, children, other family members, significant others, friends.

 Schools and their employees – teachers, counselors, aides, etc.

 Doctors and other medical professionals, particularly primary care providers.

 Social workers and psychotherapists.

 Health and human service organizations and their line staff – youth workers, welfare case
workers, etc.

 Community volunteers in various capacities, from drivers to volunteer instructors in training

programs to those who staff food pantries and soup kitchens.

Those whose jobs or lives might be affected by the process or results of the effort

13
Some of these individuals and groups overlap with those in the previous category.

 Police and other law or regulation enforcement agencies.  New approaches to violence
prevention, dealing with drug abuse or domestic violence, or other similar changes may
require training and the practice of new skills on the part of members of these agencies.

 Emergency room personnel, teachers, and others who are legally bound to report possible
child abuse and neglect or other similar situations.

 Landlords. Landlords’ legal rights and responsibilities may be altered by laws brought about
by campaigns to stop discrimination in housing or to strengthen tenants’ rights.

 Contractors and developers. Open-space laws, zoning regulations, and other requirements, as

well as incentives, may affect how, where, and what contractors and developers choose to
build.

 Employers. A workplace safety initiative or strengthened workplace safety regulations, health

insurance requirements, and other mandates may affect employers’ costs. Those that hire and
make a commitment to workers from at-risk populations may also have to institute worker
assistance programs (personal and drug/alcohol counseling, for example, as well as basic
skills and other training).

 Ordinary community members whose lives, jobs, or routines might be affected by an effort or
policy change, such as the location of a homeless shelter in the neighborhood or changes in
zoning regulations.

KEY STAKEHOLDERS

Government officials and policy makers

These are the people who can devise, pass, and enforce laws and regulations that may either fulfill the
goals of your effort or directly cancel them out.

 Legislators. Federal and state or provincial representatives, senators, members of parliament,

etc. who introduce and pass laws and generally control public budgets at the federal and state
or provincial levels.

 Governors, mayors, city/town councilors, selectmen, etc. The executives that carry out laws,
administer budgets, and generally run the show can contribute greatly to the success – or
failure – of an effort.
  Local board members.  Boards of health, planning, zoning, etc., through their power to issue
permits and regulations, can be crucial allies and dangerous opponents.

 State/federal agencies.  Government agencies often devise and issue regulations and reporting
requirements, and can sometimes make or break an effort by how they choose to regulate and
how vigorously they enforce their regulations.

 Policy makers.  These people or groups often have no official power – they may be “advisers”
to those with real power – but their opinions and ideas are often followed closely.  If they’re
on your side, that’s a big plus.

Those who can influence others

 The media

 People in positions that convey influence. Clergy members, doctors, CEOs, and college
presidents are all examples of people in this group.

 Community leaders – people that others listen to. These might be people who are respected
because of their position of leadership in a particular population, or may be longtime or
lifelong residents who have earned the community’s trust over years of integrity and
community service.

Those with an interest in the outcome of an effort

Some individuals and groups may not be affected by or involved in an effort, but may nonetheless
care enough about it that they are willing to work to influence its outcome.  Many of them may have a
following or a natural constituency – business people, for instance – and may therefore have a fair
amount of clout.

 Business. The business community usually will recognize its interest in any effort that will
provide it with more and better workers, or make it easier and more likely to make a profit. 
By the same token, it is likely to oppose efforts that it sees as costing it money or imposing
regulations on it.

 Advocates.  Advocates may be active on either or both sides of the issue you’re concerned
with.

 Community activists. Organizations and individuals who have a philosophical or political

interest in the issue or population that an effort involves may organize to support the effort or
to defeat it.

15
  People with academic or research interests related to a targeted issue or population. Their
work may have convinced them of the need for an intervention or initiative, or they may
simply be sympathetic to the goals of the effort and understand them better than most.

 Funders.  Funders and potential funders are obvious key stakeholders, in that, in many cases,
without their support, the effort won’t be possible.

 Community at large. When widespread community support is needed, the community as a

whole may be the key stakeholder.

Self-check

 Organisational standards and type are identified to determine potential stakeholders.

 Stakeholders are identified in accordance with the impact that a project would have of their
business need.

 Stakeholders are analysed to determine their influence and authority on the project.

 Stakeholders are assessed to determine their attitude to the project requirements.

SESSION 2:
Plan business analysis activities for a project
Learning outcome
 The work products that affect the analysis process are used to plan the process to be followed.
 Business analysis deliverables are identified and established in order to produce a plan.
 The scope of work for the business analysis activities is defined in order to determine the extent of the
analysis required.
 Tasks for the business analysis activities are classified in order to identify the work breakdown structure.
 Task dependencies and interfaces between tasks are identified to influence the sequence in which the tasks
need to be performed.
 Estimates for business analysis activities are developed to assist with project planning processes.
 Business analysis plans are produced to include aspects of analysis.

2.1 Planning business analysis activities

Do:

 Plan Business Analysis Preliminary Activities

Define:

 Measure the efforts: Business Analysis Performance

 Plan Business Analysis Communication

Do:

 Get the Business Goals and Objectives

 Preliminary stated requirements and concerns from stakeholders (Emails, memos, etc)

 Document Enterprise Environmental Factors

 Identify Organizational Process Assets

Plan:

 High-level Enterprise Architecture diagram (Example: Zachman Context row)

 Business Need (Templates needed to document customer requirements)

17
  Stakeholders analysis (Stakeholder List, Roles, and Responsibilities)

Do:

 High-level Enterprise Architecture diagram (Example: Zachman Context row)

 Document the Business Need in the proper template (Example: Requirements Traceability
Matrix)

 Conduct Stakeholders analysis (Stakeholder List, Roles, and Responsibilities)

 Look for Expert Judgment if needed

 Define the Business Analysis Approach

 Make the Business Analysis Activities Plan (Enterprise Analysis < - > Enterprise
Architecture)

 Project Time Management and Human Resource Management Organizational Process Assets
assessment

It’s important to state that certain activities are not necessarily executed linearly. Some might need to
be executed concurrently.

Plan Business Analysis preliminary Activities

To come up with a plan, you need to have the Business Analysis Plan inputs: Business Analysis
Approach, Business Analysis Performance Assessment, Organizational Process
Assets, and Stakeholder List, Roles, and Responsibilities.

2.2 The work products that affect the analysis process are used to plan the process to be
followed.

Business Goals and Objectives

Business goals and objectives describe the ends that the organization is seeking to achieve. Some of
them are found in the statements of vision (Describes a future identity), mission (Describes why that
future identity will be achieved), and values (Boundaries for how an organization defines its mission
in order to achieve its vision) outlining what the organization wants to achieve and how they see
themselves doing it.
A single business goal may be subdivided into one or more focus areas, such as customer satisfaction,
operational excellence, or business growth. They must be decomposed into a set of more quantitative
business objectives.

A common test for assessing objectives is to ensure that they are Specific, Measurable,

Achievable, Relevant, and Time-bounded.

Goals examples:

 Improve Business Process Performance (Increased process throughput, Consistent output

quality, Predictable process costs)

 Decrease Costs

 Improve Business Operations (Decrease costs and time-to-market)

 Improve Management Efficacy (Shorter time to make decisions, Higher quality decisions)

 Reduce Risk

 Improve Effectiveness of IT Organization (Use of products, Software re-use, Decreased time

to rollout new projects)

 Improve User Productivity (Consistent user interface, Integrated applications, Data sharing)

 Improve Portability and Scalability

 Improve Interoperability

 Increase Vendor Independence

 Reduce Lifecycle Costs

 Improve Security

 Improve Manageability (Reduced operation, administration, and maintenance costs)

Preliminary Stated Requirements and Concerns from stakeholders

As of this stage, there is only a very general project request statement from a single source. You need
to retrieve requirements from the stakeholder’s point of view.

Since this is a planning phase, document identified stakeholders and address who would be impacted
by the proposed solutions as well as those who would use or benefit from the ultimate deliverable.

19
2.3 Task dependencies and interfaces between tasks are identified to influence the sequence in
which the tasks need to be performed.

Understanding Task Dependencies in Project Management

Dependencies are the relationships among tasks which determine the order in which activities need to
be performed. There are four (4) types of dependency relationships.

Types of dependencies

Finish to Predecessor must finish before Successor can start. [Land must be
Start purchased before road building can start]

Start to Predecessor must start before Successor can start. [Road excavating
Start must start before Asphalt can be laid]

Finish to Predecessor must finish before Successor can finish. [Laying

Finish Asphalt must be complete before line painting can be completed]

Start to Predecessor must start before Successor can finish. [Road

Finish excavating must start before line painting can be completed]

Dependencies are the relationships of the preceding tasks to the succeeding tasks. Tasks may have
multiple preceding tasks and multiple succeeding tasks. The most common dependency relationship is
a finish-to-start relationship. Task P (predecessor) must be finished before task S (successor) can start.
The least common relationship is the start-to-finish relationship. Project Insight, project management
software, supports all four dependency relationships.

Product Development Activity List

The chart above shows how a Product Development Activity List may look after the project team
determines the task relationships. In our example, only finish-to-start relationships were used.

It is always easier to arrange all tasks in terms of a finish-to-start relationship and an 'as soon as
possible' constraint. This dependency type is the easiest relationship for others to understand and will
usually result in a longer than normal schedule. This gives the schedule more 'slack.' You may then
utilize the other relationships as ways to shrink the duration of the overall schedule.

21
2.4 Business analysis deliverables are identified and established in order to produce a plan.

Deliverables are the “outputs” or the “end products” of the contract and are evidence of a contractor’s
performance in meeting the contract requirements. Most deliverables take the form of a tangible
product (written report, hardware, software, data, etc.). Deliverables should always be defined in the
contract or in a separate mutually agreed document incorporated by reference in the contract. Since
the definition of the deliverables is the primary yardstick for contractor performance, all other
contractual protections rely upon this definition.

Deliverables should be:

  Specific

 Have clear instructions regarding their submission

 Clearly define the manner and standards by which the Agency will determine whether they
are acceptable

15 Deliverables Required for a Classic Business Analysis Effort

1. The business drivers, or the reasons why, for the proposed initiative. These help formulate the
high level business requirements which determine the scope and purpose of the project.

2. The problem statement describing the reasons for the project in practical business related
terms using real examples to emphasise the need for the new initiative.

3. A list of stakeholders required for further consultation.

4. A stakeholder model of the internal workers (i.e., roles and entities that work within the
system) and the external actors (those who interact externally with the system).

5. A stakeholder consultation plan describing who you will be eliciting requirements from and
how.

6. A domain model showing a high level view of the business objects and entities within the
problem domain.

7. Business use cases identifying the functional areas of the business that will be modelled.

8. Business activity diagrams for each business use case.

9. More detailed domain models showing constraints and relationships between entities.

10. Platform independent, relevant, and traceable business requirements, which are realised
against the business use cases.

11. System use cases identifying the function or service that a system will provide.

12. Traceable user requirements which are realised against the system use cases.

13. System activity diagrams describing the interactions between an actor and the system.

14. Class diagrams showing domain concepts traced back to the use cases.

15. Low level requirements and features that are platform dependent and testable.

23
2.5 The scope of work for the business analysis activities is defined in order to determine the
extent of the analysis required.

1 Scope of Work Guidelines

Purpose
The scope of work should consist of a highly tailored series of carefully worded statements that
answer the following questions:
 What is to be done?
 What are the deliverables?
 Who is going to do it?
 When is it going to be done?
 How will it be done?
 How can you tell when it is done?
 How much will it cost? 

2 Duties and Responsibilities

The purpose of this contract paragraph is to define the duties and responsibilities of both the entity
awarding the contract and the subrecipient.  Do not forget to include and clearly define the
responsibility and authority of the employees that are charged with the administration of the contract
or management of the project or both. For large and complex contracts it is not uncommon to divide
the duties between several individuals – project, contract and acceptance.

Time Frame
Some contacts are unsuccessful not because the contractors fail to meet their objectives, but because
they fail to do so in a timely manner, or within the agreed upon deadlines. Time schedules in any
contract are as important as deliverables or payments. Always clearly specify contractor submission
requirements. The number of calendar or work days from the date of contract execution, contract
effective date is often used. This technique prevents errors and misunderstand in Grants Specialist.
For example: “Contactor agrees to deliver the Final Project Plan to the Project Manager for approval
within ten (10) calendar days from contract execution”. Of course, what constitutes an acceptable
final project plan is defined in the definition section of the contract. After acceptance of the project
plan, the contractor is bound to the tasks and time frames documented in its plan. This technique is by
far the best way to handle this often difficult contract administration necessity.
Examples of time frames are:
  Within thirty calendar days after contract execution
 Within five working days after the end of every month
 Ten days after receipt of Agency recommendations
 Specific date
 Completed within one year from receipt of authorization

2.6 Tasks for the business analysis activities are classified in order to identify the work
breakdown structure.

Tasks
Tasks are the activities and milestones that need to be completed to accomplish the contract
objectives. Tasks are the narrative description of the spectrum of services to be rendered or work to be
performed. Tasks can be structured by milestones, deliverables, or process. Clear definition of the
tasks is a must in order to reduce scope creep.
Following are some specific guidelines and examples:
 Define the range of contractor activities, beginning the following tasks with the phrase “All work
required to”.
1. Design, sample, and test
2. Develop, manufacture, and field test
3. Test and evaluate
4. Collect and analyze
 Define all detailed requirements that are required in the delivered product or service.
 Categorize requirements (reporting, documentation, survey, design, etc).
1. The survey shall include a minimum of 10,000 households.
2. Analysis shall be made to determine the statistical relationship between ____.
3. The equipment shall operate in the temperature range of -20 to + 60 degrees
centigrade.
4. Use an appropriate industry recognized formatting system if one is available.
5. Define the major tasks in such a way that the sequence allows for progress
measurement and easily measured task costs.

Writing Tips:
The following writing tips should help you produce high-quality documents that are clear and
unambiguous:
 Choose one term to define the contractor’s obligations and use it consistently thereafter (e.g.,
“Subcontractor agrees...”).

25
  Use short sentence length.
 Use active voice, task oriented statements.
 Limit the length of a statement to three sentences or less.
 Avoid abbreviations, acronyms and words that have special meaning as much as possible, or
define them in the definitions section of the contract, and then be consistent thereafter.
 Avoid using “any”, “either”, “and/or” and “never”. 

The ambit of investigation is defined using selected techniques in accordance with project standards
in order to prepare the business case.

2.7 Estimates for business analysis activities are developed to assist with project planning
processes.

Activity Resource Estimating

INPUTS TOOLS   AND OUTPUT

TECHNIQUES

1. Enterprise Environmental 1. Expert judgment 1. Activity resource

Factors requirements
2. Alternatives analysis
2. Organizational Process 2. Activity attributes
Assets 3. Published estimating (updates)
data
3. Activity list 3. Resource breakdown
4. Project management structure
4. Activity attributes software
4. Resource calendars
5. Resource availability 5. Bottom-up estimating (updates)
6. Project Management Plan 5. Requested changes

Activity Duration Estimating

INPUTS TOOLS   AND OUTPUT

TECHNIQUES

1. Enterprise Environmental 1. Expert judgment 1. Activity duration

Factors estimates
2. Analogous estimating
2. Organizational Process 2. Activity attributes
3. Parametric estimating
 Assets 4. Three-point estimates (updates)

3. Project scope statement 5. Reserve analysis

4. Activity list

5. Activity attributes

6. Activity resource
requirements

7. Resource calendars

8. Project management plan

Schedule Development

INPUTS TOOLS   AND OUTPUT

TECHNIQUES

1. Organizational Process 1. Schedule network 1. Project schedule

Assets analysis
2. Schedule model data
2. Project scope statement 2. Critical path
method 3. Schedule baseline
3. Activity list
3. Schedule 4. Resource requirements
4. Activity attributes compression (updates)

5. Project schedule network 4. What-if scenario 5. Activity attributes

diagrams analysis (updates)

6. Activity resource 5. Resource leveling 6. Project calendar

requirements (updates)
6. Critical chain
7. Resource calendars method 7. Requested changes

8. Activity duration 7. Project 8. Project management

estimates management plan (updates)
software
9. Project management plan
8. Applying calendars

9. Adjusting leads and

lags

10. Schedule model

Schedule Control

27
 INPUTS TOOLS   AND OUTPUT
TECHNIQUES

1. Schedule 1. Progress reporting 1. Schedule model data

management plan (updates)
2. Schedule change
2. Schedule baseline control system 2. Schedule baseline
(updates)
3. Performance reports 3. Performance
measurement 3. Performance
4. Approved change measurements
requests 4. Project management
software 4. Requested changes

5. Variance analysis 5. Recommended corrective

actions
6. Schedule comparison
bar charts 6. Organizational process
assets (updates)

7. Activity list (updates)

8. Activity attributes
(updates)

9. Project management plan

(updates)

Self-check

  Work products include but are not limited to Stakeholder list, Stakeholder roles and
responsibility designation, Organizational Standards.

  Business analysis deliverables are identified and established in order to produce a

plan.

  The scope of work for the business analysis activities is defined in order to determine
the extent of the analysis required.

SESSION 3:
Plan business analysis communication for a project.
Learning outcomes
 The business analysis plan is used to determine the communication requirements of the project.
 The information required by various stakeholders is established in order to provide the results of the
business analysis process.
 A decision is made on which communication method is best suited for specific stakeholder.
 A communication plan is produced to regulate the flow and dissemination of project related information to
all stakeholders.

3.1 Communication with stakeholders (Communication Needs).-Communications can be written or

verbal, formal or informal. This involves determining the communication needs of the stakeholders by
defining the types of information needed, the format for communicating the information, how often
it’s distributed, and who prepares it. For now, we gather communication needs (format, timing).

A decision is made on which communication method is best suited for specific stakeholder.

3.2 Plan Business Analysis Communication

Effective business analysts recognize that planning for effective stakeholder communications is a key
to project success. The business analysis team must determine the stakeholder requirements for
communicating about both business analysis activities and the related deliverables. The team must
decide what, who, how, and when —what business analysis information needs to be communicated,
who needs to receive that information, how the information will be delivered, and when the
information will be required. The business analysis communication plan schedules and structures
business analysis work, meetings, and walkthroughs. These events range from very informal
conversations to quite formal affairs. The focus is on receiving, accessing, updating, and escalating
information to and from the business analysis stakeholders. The initial business analysis
communication will require revision based on discovering new stakeholders, addressing major
changes, or before each new project phase begins. Experienced business analysts make sure that
methods exist to update and refine the communications approach across the project life cycle. The
business analysis communication plan is often a subset of the overall project communication plan.
The business analysis team must ensure that their approach to business analysis communications
integrates with the project manager’s approach to communication at the project level. When building

29
the plan, ask yourself “What is the urgency of information need and the availability of technology on
this project?” Then, factor the answers into your business analysis communication planning efforts for
your project environment.

 The business analysis plan is used to determine the communication requirements of the
project.

The most important aspect of business analysis communication is communicating requirements

information across the project life cycle. It is essential to elicit the right information from key
stakeholders about the capabilities of the desired solution and to validate that the analysed
requirements information is correct and complete.

Several key inputs are used in plan business analysis communication information for the project
stakeholders. The majority of these inputs are produced by other business analysis planning tasks,
including the business analysis approach, the business analysis plan or plans, and the stakeholder list,
roles, and responsibilities. The four task inputs used for planning business analysis communication
are

3.3 Business Analysis Approach

The business analysis approach defi nes any standards and templates to be used for business analysis
communication activities. Business Analysis Plan or Plans The deliverables and activities found in the
plans may drive the contents of the communication plan if the results need to be communicated. In
addition, any significant business analysis communication activities should become part of the
business analysis plans.

3.4 Stakeholder List, Roles, and Responsibilities

Understanding the communication preferences of key business analysis stakeholders assists the
business analysis in communication planning. The list of stakeholders can be used to plan the what,
who, how, and when for the stakeholder communication efforts. Organizational Process Assets
Organizational process assets are an organization’s policies, guidelines, procedures, plans,
approaches, and standards for conducting work.

A communication plan is produced to regulate the flow and dissemination of project related
information to all stakeholders.
A subset of these assets may directly define or indirectly govern business analysis work on a project.
The business analyst should seek out and use any existing templates for business analysis
communications, such as presentation formats, sample meeting agendas, and requirements documents
outlines or templates. The location of business analysis stakeholders links directly to the complexity
of the business analysis communication plan. Collocated stakeholders might easily attend a face-to –
face meeting with the business analysis team. A more geographically dispersed set of stakeholders
could find a team conference call more challenging due to time zone and technology concerns. The
business analyst is going to have to design a business analysis communication approach that
accommodates the range of stakeholder locations and time zones.

3.5 Factor in Cultural Diversity

Cultural considerations play a part in planning business analysis communications, regardless of where
the business analysis stakeholders are located. There might be language issues and different views of
time, task completion, contracts, and levels of authority. All of these factors must be considered in the
business analysis communication plan, as they can have a negative impact on overall project success.
Your goal is to plan for them so that they produce a positive impact on your business analysis efforts.

3.6 Consider Project Type

The number and formality of project deliverables depends on the type of project being done.
Remember the discussion of plan-driven versus change-driven business analysis approaches earlier in
this chapter? More traditional, complex projects typically require more formal requirements
documentation, while agile development efforts tend to be quite informal in their documentation.
Plus, your communication plan needs to be aligned with your project size and complexity. A simple,
straightforward project should have a simple, straightforward communication plan.

3.7 Determine Communication Frequency

Different business analysis stakeholders may want to hear from the business analysis team at differing
time intervals. The business analysis communication plan should define how often business analysis
information is shared with the stakeholders. The business analysis team should spend some time
defining the communication type and frequency requirements for their key stakeholders. The
executive stakeholders may just want a weekly status summary via email while your end users may
want to attend a weekly status meeting to discuss the details of this week’s efforts.

The information required by various stakeholders is established in order to provide the results
of the business analysis process.

31
3.8 Decide on Level of Formality

The level of formality required for business analysis communications varies across stakeholders and
project phases. The communication plan needs to take this into account instead of using a “one size
fits all” approach to communicating business analysis information. The degree of formality is tightly
linked to the communication medium and the frequency of sharing information. All three factors
should be thoroughly addressed as part of the business analysis communication plan. Be aware that
the formality of business analysis communications may vary widely across the stakeholders, project
phases, or even for pieces of work contained within a project phase. Be sure that you can list and
explain the seven factors driving more formal business analysis communication. They include:

 Delivering a large, phased project

 Addressing a complex solution domain

 Implementing a new technology

 Developing a mission - critical solution

 Having an executive sponsor and key stakeholders who require formality

 Developing requirements that will be subject to regulatory review

 Presenting requirements to suppliers for vendor selection

SESSION 4:
Plan requirements management process for a project.
Learning outcome
 The business analysis plan is used to determine the requirements management processes of the project.
 The approach to requirements changes and traceability is explored to ensure consistency and accountability
in respect of analysis decisions.
 A Project plan is discussed reflecting the format in which requirements will be captured and
communicated.
 A management plan is produced to ensure that requirements are managed throughout the life cycle of a
project.

4.1 Planning

Two of the key outputs from requirements management are a planned and communicated approach to
business analysis and a requirements management plan.

The business analysis approach. The approach that we take to business analysis work is primarily
concerned with the type of framework, method, or methodology we use to capture our requirements.
The approach is the cornerstone of our effort, and it determines how we go about collecting and
managing requirements. It describes the processes we will follow and the templates, if any, that we
will complete. The approach will probably be different for different methodologies  and frameworks.

33
For example, prioritizing requirements on an Agile project is different from prioritizing them on a
Waterfall project. In choosing an approach, we need to make sure that it's communicated to all
appropriate stakeholders and that they are onboard with the approach that will be taken.

• The business analysis plan is used to determine the requirements management processes
of the project.

The requirements management plan (RMP) describes how the business analysis work will be
completed. It describes processes for how requirements will be documented, traced, prioritized,
baselined, and changed. We might also think of the RMP as a collection of the plans that are used to
manage business analysis. The RMP can be a formal set of documents with many subsidiary plans,
such as a business analysis communication plan, business analysis risk plan, estimates for the business
analysis work effort, and many more. This type of RMP might be appropriate for larger, riskier
projects. On some smaller efforts the RMP can be an informal roadmap. In either case, it is subsidiary
to the overall project management plan.

4.2 DOCUMENTING "GOOD" REQUIREMENTS

Requirements documentation. Requirements are always documented, either formally or informally.

Requirements might be documented as part of a detailed requirements specification, in the form of a
short text known as a user story, or as part of one or several models, such as a business process, data,
or use case model, or as a prototype or mock-up. There is no right way or wrong way to document
requirements, as long as all the requirements are understood by everyone who hears or reads them--
which means they need to be "good."

A Project plan is discussed reflecting the format in which requirements will be captured and
communicated.

What makes a good requirement?

In order for a requirement to be worth managing, it must be useful. To be useful, a requirement has to
be understood by all key stakeholders. Sponsors and business subject matter experts need to know that
the ultimate solution will solve their problem and meet their objectives. Developers need to
understand how to design and build the final product. The testing staff needs to be able to find and
remove any defects the product may have. Change managers (Human Resources staff, consultants,
business managers, etc.) need to understand how the end product will affect the organization. If a
requirement is not clear, some or all of the components that comprise the product could be defective.
To that end requirements must be clear and unambiguous, consistent, complete, concise, and
confirmed (validated and verified). They must also be testable and traceable. Here are some tips to
make requirements "good."

 Describe what is needed rather than how the need will be implemented.

 Use units of measure or specific words to reduce ambiguity. So, "less than five seconds" is
preferable over "fast," for example.

 Use a glossary to reduce ambiguity. As new stakeholders become involved over the life of the
project, a glossary can prevent misinterpretations and increase productivity. It is also helpful
to include an acronym reference list with the glossary for easy access to those acronyms.

 Keep sentences concise and simple in relationship to number of words and grammatical
structure.

 Organize and group requirements into a hierarchical list, with high-level requirements broken
down into sub-requirements as they are uncovered.

 Uniquely identify each requirement. Use a hierarchical numbering system (1.0, 1.1, 1.1.1, 1.2,
etc.). Such a scheme can be used to more easily trace requirements (see below).

 Remove redundant requirements or clarify requirements that seem similar but are really
unique.

 Use graphical models, diagrams, and prototypes where appropriate.

4.3  TRACEABILITY

Requirements traceability is a structured way to keep track of requirements. Requirements are traced
back to their source, to themselves as detailed requirements are discovered, and throughout the
project. Tracing requirements back to their source is sometimes called backwards or upwards
traceability and involves linking requirements to the identified business problem, business objectives,
and project objectives. Figure 1 illustrates the concept of backwards traceability.

35
 Figure 1 - Backwards
Traceability 

The approach to requirements changes and traceability is explored to ensure consistency and
accountability in respect of analysis decisions.

Tracing requirements throughout the project is called forwards allocation or forwards traceability and
involves documenting the linkage between the requirements and other requirements, and requirements
to the design, development, testing, and deployment work products. Figure 2 illustrates the concept of
forwards traceability.

  Figure 2 - Forwards Traceability

Requirements traceability aids requirements management by ensuring that each requirement:

 Adds value. By tracing each requirement, its value in helping the organization solve its
problems and meet its objectives becomes apparent, thus helping the organization focus on
doing all the right things and only the right things.

 Belongs in the approved scope. Requirements that cannot be traced do not belong in the
project. Scope management is one of the biggest project challenges, so traceability is a useful
tool in controlling scope.

 Is actually delivered at the end of the project or project phase. Once the right requirements
have been identified and agreed upon, it is important to ensure that all the pieces needed to
satisfy those requirements are designed, built, tested, and delivered.

Traceability also aids in determining impacts and interrelationships, so that:

 The cost of each requirement and requested changes can be more easily estimated.

 Testing coverage can be planned.

 Risks can be more easily identified, and a risk response plan developed.

TRACEABILITY TIP
Use traceability to help ensure that each requirement is linked with project deliverables, project
objectives, business problems, and business objectives, thereby preventing rogue requirements from
sneaking into the project.

4.4 MANAGING CHANGES

An important part of requirements management is handling changes. During requirements planning,

processes to handle changes are established, including who requests changes, who authorizes them,
and who vetoes them. The "who" might be an individual, or it might be some type of change control
board. Once the change process is approved, it is necessary to follow it. The approved process
depends on the business analysis approach taken, and might vary from project to project. For
example, the process for handling changes on an Agile project might well be different from a
traditional project. Regardless of what that process is, however, it must be communicated and agreed
to by affected stakeholders.

A management plan is produced to ensure that requirements are managed throughout the life
cycle of a project.

SUMMARY

We have looked at a few of the key ingredients in managing requirements. They included planning
tasks of determining the approach and creating the requirements management plan, which needs to be
appropriate for the business analysis effort. As we do the business analysis work, we document
"good" requirements in the format and to the level of detail required for the project at hand. Finally, to
help control the scope, we trace requirements and manage changes.

Self-check

  The business analysis plan is used to determine the requirements management

processes of the project.

  The approach to requirements changes and traceability is explored to ensure

consistency and accountability in respect of analysis decisions.

37
   A Project plan is discussed reflecting the format in which requirements will be
captured and communicated.

SESSION 5:
Manage business analysis performance
Learning outcome
 Work products are utilised to determine how the performance of the business analysis activities are
measured.
 The identified metrics are used to monitor the progress of the business analysis processes and activities.
 Problems are identified and appropriate corrective action is determined to facilitate successful
implementation and conclusion of the project.
 A project review is conducted to determine areas for continuous improvement.

5.1 Manage business analysis performance

Business performance management is a set of management and analytic processes that enables the
management of an organization's performance to achieve one or more pre-selected goals. Synonyms
for "business performance management" include "corporate performance management (CPM)" and
"enterprise performance management

Business performance management has three main activities:

 selection of goals,

 consolidation of measurement information relevant to an organization’s progress against these

goals, and

 interventions made by managers in light of this information with a view to improving future
performance against these goals.

Although presented here sequentially, typically all three activities will run concurrently, with
interventions by managers affecting the choice of goals, the measurement information monitored, and
the activities being undertaken by the organization.

Because business performance management activities in large organizations often involve the
collation and reporting of large volumes of data, many software vendors, particularly those offering
business intelligence tools, market products intended to assist in this process. As a result of this
marketing effort, business performance management is often incorrectly understood as an activity that
necessarily relies on software systems to work, and many definitions of business performance
management explicitly suggest software as being a definitive component of the approach.

This interest in business performance management from the software community is sales-driven -
"The biggest growth area in operational BI analysis is in the area of business performance
management

Methodologies

Various methodologies for implementing business performance management exist. The discipline
gives companies a top-down framework by which to align planning and execution, strategy and
tactics, and business-unit and enterprise objectives. Reactions may include the Six

39
Sigma strategy, balanced scorecard, activity-based costing (ABC), Total Quality
Management, economic value-add, integrated strategic measurement and Theory of Constraints.

5.2 Metrics and key performance indicators

The identified metrics are used to monitor the progress of the business analysis processes and
activities.

Some of the areas from which bank management may gain knowledge by using business performance
management include:

 customer-related numbers:

 new customers acquired

 status of existing customers

 attrition of customers (including breakup by reason for attrition)

 turnover generated by segments of the customers - possibly using demographic filters

 outstanding balances held by segments of customers and terms of payment - possibly using
demographic filters

Work products are utilised to determine how the performance of the business analysis
activities are measured.

 collection of bad debts within customer relationships

 demographic analysis of individuals (potential customers) applying to become customers, and

the levels of approval, rejections and pending numbers

 delinquency analysis of customers behind on payments

 profitability of customers by demographic segments and segmentation of customers by

profitability

 campaign management

 real-time dashboard on key operational metrics

 overall equipment effectiveness

  clickstream analysis on a website

 key product portfolio trackers

 marketing-channel analysis

 sales-data analysis by product segments

 call enter metrics

Though the above list describes what a bank might monitor, it could refer to a telephone company or
to a similar service-sector company.

Items of generic importance include:

1. consistent and correct KPI-related data providing insights into operational aspects of a
company

2. timely availability of KPI-related data

3. KPIs designed to directly reflect the efficiency and effectiveness of a business

4. information presented in a format which aids decision-making for management and decision-
makers

5. ability to discern patterns or trends from organized information

5.3 Tool categories commonly used for business performance management include:

 MOLAP — Multidimensional online analytical processing, sometimes simply called

"analytics" (based on dimensional analysis and the so-called "hypercube" or "cube")

 scorecarding, dashboarding and data visualization

 data warehouses

 document warehouses

 text mining

 DM — data mining

 BPO — business performance optimization

 EPM — enterprise performance management

41
  EIS — executive information systems

 DSS — decision support systems

 MIS — management information systems

 SEMS — strategic enterprise management software

5.4 Design and implementation

Problems are identified and appropriate corrective action is determined to facilitate successful
implementation and conclusion of the project.

Questions asked when implementing a business performance management program include:

 Goal-alignment queries

Determine the short- and medium-term purpose of the program. What strategic goal(s) of the
organization will the program address? What organizational mission/vision does it relate to? A
hypothesis needs to be crafted that details how this initiative will eventually improve results /
performance (i.e. a strategy map).

 Baseline queries

Assess current information-gathering competency. Does the organization have the capability to
monitor important sources of information? What data is being collected and how is it being stored?
What are the statistical parameters of this data, e.g., how much random variation does it contain? Is
this being measured?

 Cost and risk queries

Estimate the financial consequences of a new BI initiative. Assess the cost of the present operations
and the increase in costs associated with the BPM initiative. What is the risk that the initiative will
fail? This risk assessment should be converted into a financial metric and included in the planning.

 Customer and stakeholder queries

Determine who will benefit from the initiative and who will pay. Who has a stake in the current
procedure? What kinds of customers / stakeholders will benefit directly from this initiative? Who will
benefit indirectly? What quantitative / qualitative benefits follow? Is the specified initiative the best or
only way to increase satisfaction for all kinds of customers? How will customer benefits be
monitored? What about employees, shareholders, and distribution channel members?

 Metrics-related queries

Information requirements need operationalization into clearly defined metrics. Decide which metrics

to use for each piece of information being gathered. Are these the best metrics and why? How many
metrics need to be tracked? If this is a large number (it usually is), what kind of system can track
them? Are the metrics standardized, so they can be benchmarked against performance in other
organizations? What are the industry standard metrics available?

 Measurement methodology-related queries

Establish a methodology or a procedure to determine the best (or acceptable) way of measuring the
required metrics. How frequently will data be collected? Are there any industry standards for this? Is
this the best way to do the measurements? How do we know that?

 Results-related queries

Monitor the BPM program to ensure that it meets objectives. The program itself may require
adjusting. The program should be tested for accuracy, reliability, and validity. How can it be
demonstrated that the BI initiative, and not something else, contributed to a change in results? How
much of the change was probably random?

Activity

Outline how a project review is conducted to determine areas for continuous improvement.

__________________________________________________________________________________
__________________________________________________________________________________
_____________________________________________________________________________

Self-check

 Work products are utilised to determine how the performance of the business analysis activities
are measured.

 The identified metrics are used to monitor the progress of the business analysis processes and
activities.

 Problems are identified and appropriate corrective action is determined to facilitate successful
implementation and conclusion of the project.

43