Business Analysis and Requirements Management: A Guide For Project Managers

Business Analysis and Requirements
Management:
A Guide for Project Managers
John E. Parker (Introduction)
• Chief Visionary Officer of Enfocus Solutions Inc.
• Previous Positions
o President and CEO of Enfocus Solutions Inc.
inception through March 2013
o EVP and Cofounder, Spectrum Consulting Group
o EVP and CTO, MAXIMUS Inc.
o Outsourced CIO for HSHS (Large Healthcare
System)
o KPMG Partner
• Expertise
o IT Strategic Planning
o Business Analysis
o Recovering Troubled and Challenged Projects
o Enterprise Architecture
o Development Methodologies (Agile, Waterfall, RUP,
Design First, FDD, TDD)
o Financial and Cost Benefit Analyses
o Business Process Improvement, Reengineering, and
Management
© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 1

Top 10 Reasons IT Projects Fail
1. Lack of user involvement

2. Lack of transparency
3. Poor or incomplete requirements
4. Changing requirements Failed, 24% Successful,
32%
5. Lack of business alignment
6. Lack of executive support
7. Significant scope creep Challenged
44%
8. Failed user adoption
9. Improper solution
10.Poor testing and quality assurance
Source: Standish Chaos Report
Poor Business Analysis is the Root Cause of Most Failures.

Waste: 45% of Functionality is Never Used
Major source of
budget and
schedule overruns
Source: Standish Group Report at XP Conference 2002 by Jim Johnson

What Does the Industry Research Say?
Poor Business Analysis is Costly
• Companies with poor business analysis will have 3 times as many project failures as
successes (Ellis, BA Benchmark Report, 2009)
• 68% of companies are more likely to have a marginal project or outright failure than a
success due to the way they approach business analysis (Ellis, BA Benchmark
Report, 2009)
• Companies pay a premium of as much as 60% on time and budget when they use
poor requirement practices on their projects. (Ellis, BA Benchmark Report, 2009)
• Over 40% of IT development budget for software, staff, and external professional
services will be consumed by poor requirements by the average company versus the
optimal organization. (Ellis, BA Benchmark Report, 2009)
• Requirements processes are the source of most serious quality problems. (Weinburg,
1997)
• 50% of defects are related to requirement errors (Schwabber, 2006)
• You save money by getting requirements right to begin with. Why? Because fixing
errors from poor requirements accounts for 70 to 80% of your rework costs.
• Getting requirements right early in the project can save you one-third or more of your
overall project budget (Hooks and Farry, 2001)

What Does Industry Research Say?
Poor Business Analysis is Costly
• Communications challenges between business teams and technologists are chronic –

we estimate that 60-80% of project failures can be attributed directly to poor
requirements gathering, analysis, and management – Gartner Group
• Poorly defined applications have led to a persistent miscommunications between
business and IT that largely contributes to a 66% project failure rate for these
applications costing US business at least 30 b each year – Forrester Research
• Business analysis is the absolute most important competency for an IT organization. It
is the very heart and soul of the value IT is meant to bring to the business. (Schiller,
CIO Insight, 2012)
• Collaboration between business and technical stakeholders can give you a 10 to 1
return on investment (Caper Jones, 1996)
• Business agility is enabled by your business analysts’ ability to clearly define and
manage requirements. (Henshcen, 2007)
• 90% of projects that deliver on-time and on-budget did not deliver expected business
outcomes. (Burdette, 2013)
• On average, large IT projects run 45 percent over budget and 7 percent over time,
while delivering 56 percent less value than predicted. (Forrester, 2012)

Business Analysis Process
1.
Analyze Problem
2.
6.
Agree on
Validate and
Business
Assess Solution
Outcomes
5. 3.
Develop & Conceptualize
Manage Solution Solution and
Requirements Define Scope
4.
Elicit
Stakeholder
Needs

Stakeholder Collaboration
1.
Obtain Shared
Vision &
8. Objectives 2.
Retain and Share Define & Clarify
Knowledge Needs
7. 3.
Promote Enable Clear
Transparency & Business-Technical
Accountability Communications
6. 4.
Review and Provide Effective
Validate 5. Decision &
Requirements Facilitate Approval Process
Organizational
Change & Buy-In

Business Analysis is Much More than
Just Requirements
Requirements Enterprise Analysis
• Requirements Elicitation • Problem Analysis
• Requirements Development • Business Case
• Requirements Management
Organization and Process Change

• Business Process Modeling
• Business Process Improvement
• Stakeholder Analysis and Communications
• Organizational Readiness
• Organizational Change Management
Manage Delivery of Value

• Solution Assessment and Validation
• Business Benefits Realization
• Enterprise Portfolio Management
Strategic Partners
How project managers and business analysts can work together
The Project Manager focuses on

completing the project on time and on
budget.
- Scope
- Schedule
- Budget
- Quality
- Resources
The Business Analyst focuses on
delivering business value and ensuring
that the stakeholders needs are met.
- Business alignment
- Stakeholder needs
- Requirements
- Organizational change
Project Business
Manager
- Process improvements Analyst
- Benefits realization

PMBOK and BABOK Knowledge Areas
Both BOKs now include Requirements
PMBOK v5 BABOK v2
10 Knowledge Areas 6 Knowledge Areas

5 Process Groups
Project Integration Management Business Analysis Planning & Monitoring

Project Scope Management Elicitation
Project Time Management Requirements Management & Communication
Project Cost Management Enterprise Analysis
Project Quality Management Requirements Analysis
Project Human Resource Management Solution Assessment and Validation
Project Communications Management
Project Risk Management
Project Procurement Management
Project Stakeholder Management
Definitions
Business analysis “is the set of tasks and techniques

used to work as a liaison among stakeholders in order to
understand the structure, policies, and operations of an
organization, and to recommend solutions that enable the
organization to achieve its goals.”
A business analyst “is any person who performs

business analysis activities, no matter what their job title or
organizational role may be. Business analysis practitioners
include not only people with the job title of business
analyst, but may also include business systems analysts,
systems analysts, requirements engineers, process
analysts, product managers, product owners, enterprise
analysts, business architects, management consultants, or
any other person who performs the tasks described in the
BABOK® Guide, including those who also perform related
disciplines such as project management, software
development, quality assurance, and interaction design.”
Source: BABOK Version 2, IIBA
Business Analysis is not mentioned once in the the current version of the PMBOK.

Business Analysis in PMBOK
The term Business Analysis is never used in PMBOK.

The term Business Analyst is used three times.
1.7 Role of the Project Manager

“The project manager also works closely and in collaboration with other
roles, such as a business analyst, quality assurance manager, and
subject matter experts.”
4.1.1.2 Business Case

“Typically, the business need and the cost-benefit analysis are contained in
the business case to justify and establish boundaries for the project, and
such analysis is usually completed by a business analyst using various
stakeholder inputs.”
9.1.3.1 Human Resource Management Plan

Role. The function assumed by or assigned to a person in the project.
Examples of project roles are civil engineer, business analyst, and testing
coordinator. Role clarity concerning authority, responsibilities, and
boundaries should also be documented.

BABOK Knowledge Areas
Knowledge Area Description

Business Analysis Planning Plan and manage business analysis activities including
Monitoring determining if the project will be waterfall or agile, identifying
stakeholders, estimating activities, deciding which processes,
methods and techniques to perform and monitor business
analysis work.
Elicitation Review documents and conduct interviews and focus groups to
elicit needs from stakeholders.
Requirements Analysis Organize, prioritize, specify, verify, and validate requirements,
including modeling requirements.
Requirements Management Baseline requirements, manage changes, trace requirements,
and Communications document requirements, present requirements for approval,
manage re-use.
Enterprise Analysis Define business need, assess gap between “as-is” and business
need, determine how to approach the solution (“to-be”), define
the scope of the solution, and develop a business case for
undertaking a project to meet the business need..
Solution Assessment and Allocate requirements to different projects, phases, releases, or
Validation iterations.
Determine if the organization is ready for the change, figuring out
how to implement the change, and ensure that the solution
delivers value

BABOK V3 is Coming!!!
Version 3 is coming
There are big changes coming in
the role of business analysis. The
focus will be much more on
understanding stakeholders and
their needs, analyzing change, and
delivering value.
Understanding how to use these

components and the relationships
between them results in
understanding your stakeholders,
what they value, and how to
better deliver that value.

PM/BA Integration
The BA Lifecycle s longer than the PM Lifecycle
Project Management
Project
WBS
Charter
Project Project Project Lesson

Plan Plan Plan Learned
Version 1 Version 2 Version 3 Document
Post-
Pre-Project Initiation Planning Execution Closing
Project
Business Business Stakeholder Requirements

Case Analysis Plan Register Traceability
Business Analysis
Solution Stakeholder Solution

Scope Solution Benefits
Requirement Assessment
(SOW) Assessment Realization
s Defects
Business
Solution Transition
Requirement
Requirements Requirements
s

Project Integration Management
The project statement of work (SOW) is a

narrative description of products, services,
or results to be delivered by a project. For
internal projects, the project initiator or
sponsor provides the statement of work
based on business needs, product, or
service requirements.
The business case describes the problem

and business justification for the project.
The business cases describes the business
need, and establishes the boundaries for
the project.
The Primary inputs to PM are BA

deliverables. Not having these of
not doing these properly presents
a weak foundation for PMs.
Source: PMBOK Guide – Fifth Edition

Project Scope Management
5.1 Plan Scope Management—The process of creating
a scope management plan that documents how
the project scope will be defined, validated, and
controlled.
5.2 Collect Requirements—The process of

determining, documenting, and managing stakeholder
needs and requirements to meet project objectives.
5.3 Define Scope—The process of developing a

detailed description of the project and product.
5.4 Create WBS—The process of subdividing project

deliverables and project work into smaller, more
manageable components.
5.5 Validate Scope—The process of formalizing

acceptance of the completed project deliverables.
5.6 Control Scope—The process of monitoring the

status of the project and product scope and managing
changes to the scope baseline.

Quality Management
PMBOK BABOK
Quality Management Validate Solution

Communications Management
PMBOK BABOK
Project Communications Requirements Management
Management & Communications

Stakeholder Management
13.1 Identify Stakeholders—The process of identifying the
people, groups, or organizations that could impact or be
impacted by a decision, activity, or outcome of the project;
and analyzing and documenting relevant information
regarding their interests, involvement, interdependencies,
influence, and potential impact on project success.
13.2 Plan Stakeholder Management—The process of

developing appropriate management strategies to
effectively engage stakeholders throughout the project life
cycle, based on the analysis of their needs,
interests, and potential impact on project success.
13.3 Manage Stakeholder Engagement—The process of

communicating and working with stakeholders to meet their
needs/expectations, address issues as they occur, and foster
appropriate stakeholder engagement in project activities
throughout the project life cycle.
13.4 Control Stakeholder Engagement—The process of

monitoring overall project stakeholder relationships and
adjusting strategies and plans for engaging stakeholders.

Business Analysis Deliverables
Deliverable PMBOK BABOK
Problem Analysis and Business Need 4.1.1.1 5.1
Vision and Scope Document 4.1.1.1 (I) 5.4
Business Case w Benefits Realization Plan 4.1.1.2 (I) 5.5
Business Analysis Plan 5.1.1.2 (I) 2.3,2.4,2.5
Stakeholder Needs Analysis 13.1.3.1 3.4, 6.5
BA Communications Plan 10.1 2.4
Capability Gap Analysis (Process, People, and Technology) 4.1.1.1 5.2
Functional Requirements Document (Organized by Feature) 5.2.3.1 4.4, 6.5
Requirements Bundle (with Software Requirements Specifications) 5.2.3.1 7.2
Solution Assessment and Validation Plan 8.1 7.0
Requirements Traceability Matrix 5.2.3.2 4.2
Solution Defects 8.3 7.5
Transition Requirements 5.2.3.1 6.5, 7.4
Organizational Readiness Assessment 7.3
Benefits Realization Reviews 7.6

Requirements are a Project Risk
• Gathering and managing requirements are important
challenges in project management.
• Projects succeed or fail due to poor requirements at any
time throughout the project lifecycle.
• The continuously evolving baseline of requirements needs
to be managed effectively.
• The project manager needs to assess and understand the
uniqueness of the requirements gathering process for
his/her individual project.

Requirements: Three Perspectives
• Business Perspective – What business needs must be

satisfied, and what metrics identify that the project is
successful?
• Customer/User Perspective – What problems needs to be

solved and how will users interact with the solution?
• Technical Perspective – What technology changes are

required to ensure that the project’s objectives will be
accomplished?
Not adequately addressing all three of

these perspectives will result in a
suboptimal solution.

PMBOK Requirement Types
• Business requirements, which describe the higher-level needs of the organization as a
whole, such as the business issues or opportunities, and reasons why a project has been
undertaken.
• Stakeholder requirements, which describe needs of a stakeholder or stakeholder group.
• Solution requirements, which describe features, functions, and characteristics of the
product, service, or result that will meet the business and stakeholder requirements.
Solution requirements are further grouped into functional and nonfunctional requirements:
o Functional requirements describe the behaviors of the product. Examples include
processes, data, and interactions with the product.
o Nonfunctional requirements supplement functional requirements and describe the
environmental conditions or qualities required for the product to be effective.
Examples include: reliability, security, performance, safety, level of service,
supportability, retention/purge, etc.
• Transition requirements describe temporary capabilities, such as data conversion and
training requirements, needed to transition from the current “as-is” state to the future “to-
be” state.
• Project requirements, which describe the actions, processes, or other conditions the
project needs to meet.
• Quality requirements, which capture any condition or criteria needed to validate the
successful completion of a project deliverable or fulfillment of other project requirements.
BABOK includes Business, Stakeholder , Functional, Nonfunctional

and Transition requirements

Requirement Types (BABOK)
Failure to define Each Type of Requirement is a Major Project Risk
Requirement Type Purpose Project Risk

Business Requirements Describe why the project is being Expected business outcomes will not be
undertaken from a business achieved
perspective.
Stakeholder Requirements Stated from the user's point of view User needs will not be met resulting in
and describe what is needed for the refusal to use the system or costly
user to do his or her job. workarounds
Solution Requirements Stated from the system's perspective Results in costly rework, budget and
(Functional and and describes what the system must schedule overruns, suboptimal solutions
Nonfunctional) provide to satisfy the business and that deliver little value to the business.
user requirements.
Transition Requirements Describe what is needed to transition Systems delays, customer service
from the current (AS-IS) to the the interruptions, costly roll-backs
future state (TO-BE). Includes such
things as data conversion and training
requirements.

What Level of Detail is Needed?
The Key to Good Requirements is the Level of Detail
Less Detail More Detail
• Customers are extensively involved • Development will be outsourced

• Developers have considerable • Project team members are
domain experience geographically dispersed
• Precedents are available • Testing will be based on
• A package solution will be used. requirements
• Accurate estimates are needed
• Requirements traceability is
needed.
Determining the level of detail must balance cost vs. risk.

• Too much detail adds unnecessary cost to the project
• Not enough detail leaves decisions about requirements specifics to
the development team often resulting in costly rework and associated
schedule and budget overruns

Effective Requirements are Developed in
Layers using a Team Approach
Business Need (Business Problem, Need and Objectives)
Impact/Ch Stakeholders Process Data Technology

Procedures
ange and Rules
Scope Features (Solution Scope)
Requirements Solution Requirements
Specifications Elaboration ( Specifications)
Implementation Requirement Bundles

What is Solution Scope?
Project Scope Solution Scope
Project Scope includes the work The Solution Scope describes the
needed to create a product or characteristics, features, or
deliver a service or result. Project functions of the product or service
Scope defines the work required to be built. Solution scope is all
to create and deploy the product. about the solution to be
The project scope statement is implemented: how will it look, how
prepared by the project manager. will it function, and other
characteristics, etc. A business
analyst prepares the product or
solution scope.
Work Breakdown Structure Solution Scope

(PMBOK 5.4) (BABOK 5.4)

Providing Solution to Meet Business Needs
Business Needs
Required
Changes
Process Data
People Procedures and

Technology Rules

Features
The Key to Managing Scope and Delivering Business Value
Elicitation and Development of Requirements
1. The basic principle is to reduce a complex project into
small, easy-to-understand units called features. This
means taking one small step at a time rather than
tackling the whole project in one go.
2. Define Features by decomposing business objectives or
through impact or concept mapping.
3. Solution Scope = The List of Features
Carefully defined 4. For each feature, assign a business owner and an analyst.
Features are key to 5. Use Features to elicit and develop requirements.
prevent scope creep, 6. Prioritize Features by Business Value and Implementation
deliver value, and serve Complexity.
as a basis for gathering 7. Features work for both Agile and Waterfall development.
user needs and Features are often called Epics in agile development.
developing requirement 8. Features do not necessarily equate to how the solution
specifications.
will be implemented.
9. Features should comply with INVEST.
10. Features should be managed from inception to delivery.

Bundles
The Key to Managing Software Quality and Delivery
Assessment and Validation of Solutions

1. The basic principle is to allocate solution requirements to
solution components and releases in order to maximize the
possible business value given the options and alternatives
generated by the design team.
2. Bundles are often defined by module, team, service, or
component or acquisition method.
3. Bundles often equate to Sprints in agile development. A
group of bundles equates to a Release.
4. All of the requirements in bundle are generally validated
together.
5. Bundles contain not only requirements but all related data
including: requirement patterns, requirement attributes,
acceptance criteria, visualizations, attachments, related use
cases, related business rules, and related user needs and
scenarios.
6. Bundles have lifecycle events that are used to trace
requirements through the development lifecycle.
7. Bundles are managed from creation to delivery.
Iterative and Incremental
Iterative Incremental
When you work iteratively you build what When you work incrementally you add
you can in one iteration, then review it and components piece by piece until you are
improve it in next iteration and so on until finished.
its finished.
Requirements are built going through a Requirements are built in layers, starting
continuous set of reviews by stakeholders with high level business objectives,
and the business analyst. Business Analysts decomposed into features, functional
receive comments from stakeholders, make requirements, and various layers of detail
improvements to the requirements, and for each requirement.
ask for comments

Collaborative
Collaboration is business analysts, business stakeholders, and technical stakeholders

working with together to develop requirements. The various parties work together by
sharing knowledge, learning, and building consensus in terms of what is needed to
build the solution.
One leading consulting firm found that they were able to capture 93-95% of the
functionality by using a collaborative requirements approach versus only 65% when
a more traditional interviewing method was used. In addition, there was significantly
higher user satisfaction for solutions that were built with collaborative requirements

How can better Collaboration between
the Solution Team and Stakeholders Help?
• Lack of user input is the #1 cause of project failures.

• Joint ownership of requirements results in lower costs
and higher quality solutions.
• Organization change goes more smoothly when users
and other stakeholders are involved through the entire
lifecycle.
• Effective business analysis is the key for better
collaboration between stakeholders and developers.

Joint Responsibility for Requirements
Makes a Big Difference
Who owns Primary Budget Time Functionality Stakeholder Time

Responsibility for Requirements % of Target % of Target % of Target % of Target
IT 162.9 172 91.4 172.9
Business 196.5 245.3 110.1 201.3
Jointly Owned 143.4 159.3 103.7 163.4
Source IAG Business Analysis Benchmark, 2008

Manage Data not Documents
Elicit
Requirement
Documents
Validate Requirements Analyze
Requirements consist of
• User Story or Shall Statement
Elaborate • Requirement attributes
• Relationships to other objects
• Creating Large Requirement Documents is • Prioritization
an archaic practice brought forward from • Estimates
the 70s. • Business Rules
• Requirement data is way too dynamic to be • Traceability
managed using a word processing or • Visualizations
spreadsheet software. • Dependencies
• Creating large paper requirements • Review Comments
documents is slow, inefficient, costly, and • Test Cases and Acceptance Criteria
simply a poor practice and is often the cause • Action Items and Work Tasks
of failed or challenged projects • Requirement Change History
Backlogs
Project Feature Requirements Implementation

Backlog Backlog Backlog Backlog
Projects Features Requirements Bundles
• Requirements are developed in four layers and maintained as backlogs

• Each backlog is managed separately.
• As a project progresses through each backlog, there are often a different set of
stakeholders involved.
• BA Skills to manage each backlog also differs.
• The level of detail (elaboration) will vary based on the needs of the project.
• The status of each object within each backlog is managed by different states.

State Management
Project Features Requirements Bundles
Planned Draft Draft Planned
Scoped Active Active Active
Cancelled Scoped Locked Baselined
Delivered Locked Bundled Completed
Delivered Baselined
Cancelled Delivered
Descoped
• Management the state of requirement artifact objects is very important for a requirements management
solution.
• Requirement artifact objects are persistent and long-lived, and often have more than one state. At each
state, the behavior can be quite different. Business logic implementation can become complicated and hard
to test and maintain because the business object state transition logic is scattered in the business logic,
often using switch statements.
• We employed State Machine to decouple the business object state transition logic from the business logic
resulting in a more simple, easy-to-test solution.

A Carpenter is Only Good as His Tools
The Same Applies for Business Analysis
Most organizations use a combination of Word, Excel, SharePoint and Email

for developing requirements. This practice inhibits effective collaboration,
forces business activities to be document versus data driven, and creates
waste and inefficiencies in performing business analysis functions.
• Multiple people need to work on the requirements at one time. This is impossible or very difficult with a
word processor such as Word. It is important to track who and when changes were made.
• Requirements should be developed in layers in an iterative and incremental fashion. Review and
validation should be continuous process where requirements are written, reviewed and improved.
• The document oriented nature of Word and Excel causes defects to found late in the process after large
documents have been released to stakeholders for review. Because of time constraints and the effort to
review large requirement documents, key defects are often missed.
• It is often necessary to gather additional data to make a requirement complete, this is often done with
action items. Trying to track all of these in word/SharePoint can be a nightmare.
• Because of change in business dynamics, industry expert have said requirements change as much as
35% on a typical project. Managing this amount of change with Word or Excel is simply not practical.
• Requirements are more than just text, good requirements consist of related business rules, visualizations,
traceability information, and related documents such as videos, screenshots, etc.
• Requirements need to be traced forward and backwards from the source where they were created to
deployment in the solution. This is simply not practical using document oriented tools such as Word or
Excel.
• Email is not an efficient tool for sharing knowledge and information. Using email ceases problems with
versioning, content duplication, reaching the right people, locating the right information later and a hosts
of other annoying problems.

Reducing Business Analysis Risk
15 Important Recommendations for Project Managers
1. Ensure that the role of the BA is documented and understood.

2. Do not omit critical up-front business analysis activities such as problem
definition, solution scope, and the business case.
3. Project managers should work with work with BAs as strategic partners, not
as adversaries.
4. Increase business analysis maturity – encourage standardization of
business analysis practices.
5. Ensure that the problem is understood before starting to define
requirements.
6. Ensure that the solution scope is defined before starting to define solution
requirements. Do not use requirements to define solution scope!!!
7. Require a Business Analysis Plan that addresses
o Elicitation
o Requirements Management
o Stakeholder Engagement and Communications
o Requirements Traceability
o Solution Assessment and Validation

Reducing Business Analysis Risk
15 Important Recommendations for Project Managers
8. Ensure that all five types of requirements are defined.
o Business Requirements
o Stakeholder Requirements
o Functional Requirements
o Nonfunctional Requirements
o Transition Requirements
9. Develop requirements collaboratively – both user and technical input are
needed.
10. Ensure that all key stakeholders, including users are engaged and involved.
11. Develop requirements with just enough detail, just in time.
12. Ensure that Business Analysis deliverables are defined and included in the
WBS.
13. If your project involves business processes, ensure that the solution is
being built for the To-Be solution and not the As-Is way of operating.
14. Work with the BA in properly defining the solution assessment and
validation approach and integrate into WBS.
15. Use a proven business analysis tool – do not rely on Microsoft Word or
Excel or on a simple requirements management tool.

Enfocus Requirements Suite™

Enfocus Requirements Suite™

Q&A

PM/BA Integration
Project Integration Project Scope Project Time Project Cost Project Quality
Management Management Management Management Management
Project HR Communications Project Risk Procurement Stakeholder

Management Management Management Management Management
Charter Plan WBS Budget Resources Communications Risk

Procurement Stakeholders
2 • SOW 3 • On-Time
• Business Case • On-Budget
• Quality
• On-Scope
1 • Problem Defined • Problem Resolved

4 • Solution Adopted
• Solution Scoped
• Business Case Prepared • Outcomes Achieved
Business Requirements Stakeholder Requirements Solution Requirements Transition Requirements
Solution
Business Analysis Problem Identification Business Needs and Capability Gap and
Conceptualization &
Planning & Monitoring & Root Cause Analysis Objectives Impact Assessment
Scoping
Stakeholder
Requirements Requirements Solution Assessment Benefits Realization
Identification & Needs
Development Management & Validation Management
Analysis
INVEST
Can be built independently – few dependencies
Independent
Describes functionality to be negotiated
Negotiable between the customer and development
Valuable Provides value to the business
Has enough detail to be understandable and

Estimable estimable without being too detailed
Small They should be small - should fit into a release
Worded in a way that they can be tested, traced,

Testable and verified

Successful Projects Require
Business Analysis Collaboration

Good business analysis helps to make Business Analysts work iteratively and
sure the right solution is developed for collaboratively with Business and
the right reasons and solves the right Technical Stakeholders to elicit, develop,
problem. By focusing on an organization's and validate the right requirements.
business objectives, tracing them to a Because stakeholders represent groups of
viable solution with the necessary set of people from different backgrounds,
features and then tracing further to business domains and authority levels,
detailed requirements, Business Analysts communication can be challenging.
ensure that the efforts are focused on the Analysts must determine which sets of
right features and requirements. requirements are relevant to particular
stakeholder groups and to present those
requirements in the appropriate format
(and using the appropriate review
approach) for the audience to validate
and to approve the requirements.

Business Analysis and Requirements Management: A Guide For Project Managers

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Business Analysis and Requirements Management: A Guide For Project Managers

Загружено:

Авторское право:

Доступные форматы

Business Analysis and Requirements

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 1

1. Lack of user involvement

Poor Business Analysis is the Root Cause of Most Failures.

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 2

Source: Standish Group Report at XP Conference 2002 by Jim Johnson

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 3

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 4

• Communications challenges between business teams and technologists are chronic –

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 5

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 6

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 7

Organization and Process Change

Manage Delivery of Value

The Project Manager focuses on

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 9

10 Knowledge Areas 6 Knowledge Areas

Project Integration Management Business Analysis Planning & Monitoring

Business analysis “is the set of tasks and techniques

A business analyst “is any person who performs

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 11

The term Business Analysis is never used in PMBOK.

1.7 Role of the Project Manager

4.1.1.2 Business Case

9.1.3.1 Human Resource Management Plan

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 12

Knowledge Area Description

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 13

Understanding how to use these

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 14

Project Project Project Lesson

Business Business Stakeholder Requirements

Solution Stakeholder Solution

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 15

The project statement of work (SOW) is a

The business case describes the problem

The Primary inputs to PM are BA

Source: PMBOK Guide – Fifth Edition

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 16

5.2 Collect Requirements—The process of

5.3 Define Scope—The process of developing a

5.4 Create WBS—The process of subdividing project

5.5 Validate Scope—The process of formalizing

5.6 Control Scope—The process of monitoring the

Source: PMBOK Guide – Fifth Edition

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 17

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 18

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 19

13.2 Plan Stakeholder Management—The process of

13.3 Manage Stakeholder Engagement—The process of

13.4 Control Stakeholder Engagement—The process of

Source: PMBOK Guide – Fifth Edition

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 20

Organizational Readiness Assessment 7.3

Benefits Realization Reviews 7.6

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 21

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 22

• Business Perspective – What business needs must be

• Customer/User Perspective – What problems needs to be

• Technical Perspective – What technology changes are

Not adequately addressing all three of

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 23

BABOK includes Business, Stakeholder , Functional, Nonfunctional