www.rmcproject.com v.7 Share this white paper:
by Barbara A. Carkenord, CBAP®, PMP®, PMI-ACP®
A White Paper fromRMC Project Management, Inc.
www.rmcproject.com
The Project Manager &The Business Analyst
NEW!
Share this white paper:www.rmcproject.com v.7
Roles Defined: The Project Manager and the Business Analyst
2
Copyright © 2013 RMC Publications, Inc. All rights reserved. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database retrieval system,
without prior written permission of the publisher.
10953 Bren Road East, Minnetonka, Minnesota 55343, USA
Main 952.846.4484
Fax 952.846.4844
E-mail [email protected]
Roles Defined: The Project Manager and the Business Analyst
www.rmcproject.com v.7 Share this white paper: 3
Table of Contents
Meet the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Defining PM and BA Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Confusing and Inconsistent Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
Terminology Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
What are Project Requirements? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A Note about Agile Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A Note about BPI and BPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Delineate Roles by Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Business Analysis Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Project Management Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Shared PM and BA Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
About RMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
“Most project managers have been
doing business analysis work for years, assuming it was part of their responsibility”
- Barbara Carkenord
Share this white paper:www.rmcproject.com v.7
Roles Defined: The Project Manager and the Business Analyst
4
Meet The Author Barbara A. Carkenord, CBAP®, PMP®, PMI-ACP® Practice Director and Trainer—Business Analysis
Barbara A. Carkenord, Director of the Business Analysis Practice
at RMC Project Management, has over 25 years of experience
in business analysis, and is one of the original founders of
the Business Analysis training industry. Barbara has an MBA
from University of Michigan, is a Certified Business Analysis
Professional (CBAP®)a certified Project Management Professional
(PMP®), and an Agile Certified Practitioner (PMI-ACP®). She is
also the author of the worldwide best-seller Seven Steps to
Mastering Business Analysis, and is a frequent speaker at industry
conferences and chapter events. Actively involved in the IIBA, she
was a core team member of the IIBA BABOK® creation committee
and contributed to its book, Managing Business Analysis. In 2010,
Barbara was named Small Business Woman of the Year by the
Georgia Women in Technology Association.
Barbara possesses detailed knowledge and experience in
many analysis tools and techniques. She develops and delivers
business analysis training using proven techniques and real-world
experience. Barbara’s areas of expertise include business analysis,
software design, quality assurance, and project management. Her
experience covers many industries including insurance, banking,
and manufacturing. Her most current publications include the
CBAP®/CCBA® Exam Prep textbook, PM FASTrack® CBAP®/
CCBA® Exam Simulation Software, and Hot Topics Flashcards—all
released by RMC Publications in 2012.
Barbara A. Carkenord, CBAP®, PMP®, PMI-ACP®
Connect with Barb twitter.com/bcarkenord
linkedin.com/pub/barbara-carkenord
facebook.com/barbara-carkenord
Roles Defined: The Project Manager and the Business Analyst
www.rmcproject.com v.7 Share this white paper: 5
Project Manager Work Products:
• Project plans
• Acquisition of resources
• Team management
Business Analyst Work Products:
• Business case
• Requirements
• Solution approach
• Business transition plans
The leading association standards’ guides serve as the foundation for this article’s recommendations:
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) —Version 2 by International Institute of Business Analysis (IIBA®)
• A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition by the Project Management Institute (PMI®).
Defining Project Manager and Business Analyst Roles
Why Is This Important?Many organizations struggle to successfully differentiate the
roles of project manager (PM) and business analyst (BA). There
are good reasons for this challenge. Most project managers
have been doing business analysis work for years, assuming
it was part of their responsibility, and find it hard to see their
work having two separate components. In addition, important
project management skills such as strong communication
skills, the ability to understand complex business needs, and
the ability to elicit project requirements are also critical for
business analysis. Professionals with this skill set often move
into the project management profession because of its more
visible profile and higher compensation. A study at http://www.
project-skills.com/business-analyst-salary-range.html concludes
BAs make an average of 20 to 30 percent less than PMs. But
with the increasing complexity of organizations and projects,
having a dedicated business analyst on the project team allows
the project manager to focus on managing the work, while the
business analyst concentrates on developing and managing the
requirements.
This article suggests that an effective method to differentiate
between the roles of project manager and business analyst is
to focus on the specific outputs or work products created by
the role, rather than the activities performed or skills utilized.
These concrete work results are truly what separates business
analysis from project management. For project managers, these
outputs include project plans, acquisition of resources, and
team management. For business analysts, the outputs include
the business case, as well as requirements, solution design,
and business transition plans. The two roles represent equally
important, but distinct, areas of expertise on a project.
By focusing on the resulting work, rather than the activities
done to complete them, it is easier to differentiate the work
of the professions and more clearly make work assignments.
A consistent focus on the outputs will give professionals clear
direction and give managers a clear way to evaluate performance.
To describe specific work products for each profession, a
common language is necessary.
Share this white paper:www.rmcproject.com v.7
Roles Defined: The Project Manager and the Business Analyst
6
Confusing and Inconsistent Terminology: Solution, Scope and Requirement
Careful use of terms is extremely important in both project
management and business analysis work, since much of the
work involves communicating. Before talking about the work
products of PMs and BAs, we need to have a common language
to describe them. Both PMI® and IIBA® are working to standardize
terminology for their respective professions; striving to create a
consistent language for communications. Some terms are well-
defined and have been accepted and used consistently by both
professions. Words like project and stakeholder have very clear,
understandable meanings, although we must acknowledge that
many organizations only use the term project when the size of
work surpasses some predefined number of hours or budget.
The true definition of a project; “a temporary endeavor undertaken to create a unique product, service or result,” also
allows for very small undertakings.
Many small projects are performed by a BA without the
involvement of a PM and require the BA to understand project
management tasks. In my informal surveys of BAs, most spend
about 75 to 80% of their time on formal projects.
What is a “project” in your organization?
Roles Defined: The Project Manager and the Business Analyst
www.rmcproject.com v.7 Share this white paper: 7
Recommended Definitions:
Solution: A set of changes to the organization which addresses a business need. A solution may be created and implemented through a project.
Project: A temporary endeavor undertaken to create a unique solution (product, service, process, change, etc.)
The BABOK® Guide defines these terms as follows:
Solution Scope: A set of capabilities a solution must deliver in order to meet the business need.
Project Scope: The work performed to deliver the result or solution
Terminology Recommendations
With respect to differentiating project management work from
business analysis work, there are several important terms that
are not well defined or used consistently between the two
professions; specifically solution, scope, and requirement. Although they represent fundamental concepts for both the PM
and BA professions, even within each of the bodies of knowledge
there are inconsistent uses of these key terms, as these terms are
still evolving and maturing. When these terms are poorly defined
or used inconsistently, communication and ultimately, project
success is compromised. Therefore, I would like to propose some
refinements to the industry definitions.
SolutionAs used in this article, the term solution should be used to
describe the result of a project. This definition acknowledges
that projects are initiated to solve a business problem or take
advantage of an opportunity. The BABOK® Guide uses the term
business need to include business problems and opportunities.
A solution to a business need may include a new software or
hardware component, a business process change, a revised
organizational structure, or any combination of these (in business
process approaches, the solution is referred to as the desired
end state or to-be workflow). The result of a project is currently
defined in the PMBOK® Guide as a “product, service or result”.
Using the term solution would encompass all three of these
possible results in one word.
The PMBOK® Guide does not use the word solution, while IIBA®
defines a solution as a set of changes to the current state of the
organization, made to enable the organization to meet a business
need, by resolving a problem or allowing an organization to take
advantage of an opportunity. A recommended definition that
could be shared by both professions is:
Solution: A set of changes to the organization which addresses
a business need. A solution may be created and implemented
through a project.
I also recommend that we modify the definition of the term
project to include the word solution:
Share this white paper:www.rmcproject.com v.7
Roles Defined: The Project Manager and the Business Analyst
8
Project: A temporary endeavor undertaken to create a unique
solution (product, service, process, change, etc.)
Building a product is only one of the possible results of a
project and one of the ways we might address a business need.
Both the PMBOK® Guide and the BABOK® Guide agree that a
product is something we build, create, purchase or assemble
as requested by the project sponsor or a customer. Sometimes
the term product is carelessly used, implying every business
need should be solved by development of a new product. The
much talked-about agile development approaches are mainly
product development processes, focused on building software.
But the solution to a business need or customer problem is just
as likely a business process change, an organizational change,
or business rule or policy change. Because products are just one
possible result of project management and business analysis
work, solution is a more accurate term to describe the result of a
project.
ScopeThe term scope is used in both bodies of knowledge, but it is
used inconsistently. The BABOK® Guide mentions at least five
different types of scope, while the PMBOK® Guide uses this term
on almost every page. Two types of scope are critical for the
understanding of project management and business analysis
role delineation: project scope and solution scope. The glossary
definitions agree that project scope is the work performed to
deliver the result or solution. The solution scope (called product
scope in the PMBOK® Guide) describes the features or functions
which characterize a product, service or result, aka the solution.
Most PMs and BAs understand this distinction, but other business
stakeholders may not. PMs and BAs need to be careful to clearly
identify which scope is being discussed at all times.
Using a construction example, the solution scope is the
description of the building itself. The number of floors needed,
the dimensions of the foundation, the number of rooms and
windows and doors. The project scope is the description of the
work necessary to create the building. Things included in the
project scope would be architecture, engineering, construction,
plumbing, and electrical work. The solution scope describes
WHAT will be created, while the project scope describes HOW
What is the difference between Solution Scope & Project Scope?
Solution Scope:
• Description of Building
• Number of floors needed, dimensions of the foundation, number of rooms windows and doors
The Solution Scope describes “what” will be created
Project Scope:
• Create the Building
• Architecture, electrical work, plumbing
The Project Scope describes “how” it will be created
Roles Defined: The Project Manager and the Business Analyst
www.rmcproject.com v.7 Share this white paper: 9
Inside the Bodies of Knowledge: “REQUIREMENTS”
PMBOK® Guide:
• 25 different types of requirements referenced
• Uses the term 589 times
BABOK® Guide:
• Acknowledges the complexity and broadness requirements
• Identifies six main categories
• Uses the term 1,728 times
it will be created. This is one of the most important distinctions
needed to clarify the understanding of the difference between
project manager and business analyst responsibilities.
The business analyst works with the business stakeholders to
develop the solution scope (what will be created or changed)
while the project manager works with the project team to
develop the project scope (how the solution will be created
or changed). Understanding this distinction leads to better
communication and role delineation. When one person is filling
both roles, having the ability to mentally segregate solution scope
from project scope helps professionals better manage their time
and responsibilities.
RequirementThe term that causes the most confusion for PMs and BAs is
requirement. Use of the term requirement is confusing, not so
much because of different definitions, but rather because of
different understandings of its comprehensiveness. Requirement
is defined in the BABOK® Guide as a “condition or capability
needed by a stakeholder to solve a problem or achieve an
objective,” while the PMBOK® Guide defines a requirement as
a “condition or capability that is required to be present in a
product, service, or result to satisfy a contract or other formally
imposed specification.” These definitions are pretty close
because they both were derived from the International Institute
of Electronic and Electrical Engineering (IEEE) which, prior to
IIBA®, was the professional association attempting to define and
provide standards for software requirements.
While not used consistently, the term requirement is used
frequently. Looking at the bodies of knowledge, the term
requirement is used 589 times in the PMBOK® Guide and more
than 25 different types are referenced. The BABOK® Guide has
identified six main categories of requirements, but uses the term
1728 times. No wonder this word has become ambiguous in many
of our conversations.
Unfortunately the standard definition of requirement is
inadequate for practical usage. “A condition or capability” is
broad enough to include everything from a large initiative (we
need a new payroll system), to a detailed feature of a product
(the dropdown box on the screen should be blue and two inches
Share this white paper:www.rmcproject.com v.7
Roles Defined: The Project Manager and the Business Analyst
10
wide), to a small application change (please add a sub-total to
the report). This broad definition allows for almost anything to be
called a requirement, rendering the term meaningless.
IIBA specifically acknowledges the complexity and broadness of the term requirement in the introduction to the BABOK® Guide:
The term “requirement” is one that generates a lot of discussion
within the business analysis community. Many of these debates
focus on what should or should not be considered a requirement,
and what are the necessary characteristics of a requirement.
When reading the BABOK® Guide, however, it is vital that
“requirement” be understood in the broadest possible sense.
Requirements include, but are not limited to, past, present, and
future conditions or capabilities in an enterprise and descriptions
of organizational structures, roles, processes, policies, rules, and
information systems. A requirement may describe the current or
the future state of any aspect of the enterprise.
- BABOK® Guide V2, page 5
The six categories of requirements used in the BABOK® Guide
reflect commonly accepted practices of business analysis
professionals and form a solid foundation upon which to build
a common lexicon: business, stakeholder, solution, functional,
nonfunctional, and transition requirements. In addition, according
to the BABOK® Guide, requirements can be defined at any level of
detail, and can be specified in text, diagrams, or models.
If the term requirement is going to be considered in its broadest
sense, a categorization system is essential for allowing the term
to be used with more specificity. The BABOK® Guide categories
provide a good starting point for organizations that do not have
their own classification system. The latest version of the PMBOK®
Guide (Fifth Edition) includes the BABOK® Guide categories
along with project and quality requirements.
Since the original publication of the PMBOK® Guide, projects have
become larger and more complex with hundreds or thousands
of requirements. This growing complexity has resulted in the
development of the business analysis profession. The project
manager needs a requirements expert as part of the project
team. Every assessment of project failure cites poor requirements
as a key weakness.
Roles Defined: The Project Manager and the Business Analyst
www.rmcproject.com v.7 Share this white paper: 11
The BABOK® Guide categories should become the standard for
both professions. This classification scheme is important to clarify
the work products of BAs and help with project planning and
execution. A modifier used with the word requirement makes it
more specific.
What are Project Requirements?
The PMBOK® Guide uses the phrase project requirements
several times and it seems to refer to all of the things needed
for the solution, or product, scope as well as how to get the
work done, or project scope. Many of the references are actually
PM outputs such as resource, schedule, and cost requirements,
communication requirements, quality requirements, project
approval requirements, and project closure requirements. Notice
these requirements do not describe the “conditions or capabilities
needed by stakeholders to achieve an objective.” Rather, they
reflect how the project will get work done. These are PM outputs.
Project requirements do not describe the solution, but rather
than needs of the project. I would like to see the PMBOK® Guide
be more precise when using the phrase project requirements, or
avoid use of the term requirement when referring to the outputs
of project management.
A Note about Agile Requirements
It is important to acknowledge that requirements, as defined by
the BABOK® Guide, do not need to be formally documented.
In change-driven approaches to software development,
requirements are elicited, analyzed, communicated, prioritized,
and used to develop working software with very little formal
documentation. This approach to requirements does not make
them any less important, but rather makes it even more important
for business analysts to understand the differences between
the types and know which types of requirements are needed at
each level of agile planning and development. BAs facilitate the
agile team’s discussion of requirements to the level of specificity
needed by developers to build the product accurately.
Share this white paper:www.rmcproject.com v.7
Roles Defined: The Project Manager and the Business Analyst
12
Project Management: Scope of work: Project Scope (how the solution will be created) Example Output: Status reports of project progress
Business Analysis: Scope of work: Solution Scope (what is needed by the business) Example Output: Transition requirements
A Note about Business Process Improvement (BPI) and Business Process Management (BPM)
The term requirement is not commonly used in BPI or BPM
approaches to business analysis. These approaches use terms
like current state, future state, as-is, to-be, and what-if scenarios
for analysis and solution design. These descriptions are often
represented in workflow diagrams and models. The BABOK®
Guide includes all of this analysis work under its broad definition
of requirement.
Delineate Roles by Outputs
When project management and business analysis professionals
agree on shared definitions and usage of key terms, their
productivity increases significantly and their projects are more
successful. I have worked with several organizations that measure
project success factors and have seen significant improvements
after PM and BA roles are clarified. Once a common language
is agreed upon, defining outputs for each profession is possible.
When we define the work products each role creates, it is easy to
see the delineation of the work. The BA is a project team member
like any other and the PM assigns tasks to the BA as appropriate.
Frequently, a BA may be assigned to multiple projects and also
maintain some business support responsibilities outside the
scope of a project. These resource constraints are considered by
the PM during project planning.
Business Analysis OutputsA business analyst’s responsibilities should be defined in terms
of his or her outputs. The BA is responsible for working with
stakeholders to define the solution scope (description of the
result of the project). Business analysis outputs should include
a clear definition of the business need, an understanding of the
environment within which the business operates, the goals of
the business (business requirements). The BA is also responsible
for descriptions of possible solutions to the problem (solution
requirements) and determining how best to roll out the solution
(transition requirements). For example: If the business solution
is a new payroll system, its solution requirements describe how
Roles Defined: The Project Manager and the Business Analyst
www.rmcproject.com v.7 Share this white paper: 13
it will process payroll, how many paychecks it must be able
to create, how often payments will be made, etc. BAs are also
responsible for creating business analysis plans to give to the PM
as input into the overall project management plan.
The requirements categories, as defined in the BABOK®
Guide, are shown below. Although it is impossible to design a
requirements categorization scheme which works perfectly for
every organization and every solution, the categories defined by
IIBA® are used by many organizations and address most business
needs.
Business Analysis Outputs Should Include:
• Clear definition of the business need
• Understanding of the environment within which the business operates
• The goals of the business
Type of Requirement Definition
Business Requirements Business requirements describe the business goals, objectives and core business needs. They may include a description of the business environment, architecture, business func-tions and processes, business policies and rules, and information needs (data). They may include a description of the current state (as-is).
Stakeholder Requirements Stakeholder requirements are specific requests made by an individual or a group of stake-holders involving a change to an existing business system, or a new product or solution.
Solution Requirements Solution requirements describe the capabilities of the solution or the change needed in the business to meet the business need. They may be subdivided into functional and nonfunc-tional requirements.
Functional Requirements Functional requirements describe the behaviors, features, functions, characteristics of the solution (What does it look like? What does it do? How does it work?).
Nonfunctional Requirements Nonfunctional requirements describe how well the solution must perform, how it needs to work in its environment, and how easy it is to change. These requirements are often devel-oped with the help of a technical architect who has expertise in the technical limitations of the solution environment.
Transition Requirements Transition requirements describe the necessary activities and a schedule for making chang-es to the business or capabilities which are needed to help smooth the transition of the business from the current state to a desired future state. They help implement the solution into the business. For example: If employees of the business area will need training to use the new solution, transition requirements define what that training will look like, how and when it will be delivered, and how it will be evaluated.
Technical or Software Require-ments
Although this category is not listed in the BABOK® Guide, it is implied and should be acknowledged. When the solution involves a product, software or hardware component, re-quirements developed by BAs are used by technical architects and engineers to design the solution from a technical perspective. BAs review these technical requirements to make sure business requirements will be met by the solution, but the technical requirements them-selves are outputs of other project team members managed by the project manager.
Share this white paper:www.rmcproject.com v.7
Roles Defined: The Project Manager and the Business Analyst
14
Project Management OutputsA project manager’s responsibilities should also be defined in
terms of the output they are expected to produce. Obviously,
the PM is responsible for ultimate delivery of the solution to the
stakeholders. To plan and manage this work, the PM creates work
products. The PM is responsible for the project scope (how will
the project team create the solution). Important initial outputs are
plans. Project management plans include detailed descriptions
of the work that will be done, the level of quality expected, the
time needed, and the communications involved. PMs also acquire
resources: people, money, and materials needed to create the
solution. Plans include schedules, budgets, risk management, etc.
In addition to planning, the PM is responsible for making sure
the project team executes according to the plans and reports
progress to the stakeholders. These are all examples of outputs
produced by the project manager.
For example, if the business solution is a new payroll system,
project management outputs would include the description (and
acquisition) of the resources needed to successfully complete the
project along with a schedule and budget.
PMs will benefit from acquiring a senior BA to assist with
project initiating and planning, and by delegating requirements
development to BA(s) on the project team. Business, stakeholder,
and high-level solution requirements are needed by the PM
as inputs to planning. Without an understanding of what the
stakeholders need, a PM cannot know what resources will be
needed or how long the work will take. This illustrates why a
BA needs to be involved with the PM from the beginning of
project initiating. The PM also needs the business analysis plans
to incorporate into the project plans. It is important to recognize
that not every detailed requirement will be identified during
project initiating or planning. Detailed solution and transition
requirements will be elicited and analyzed during project
executing, as BAs work with implementation SMEs to design,
build, and test the solution.
Project Management Outputs Should Include:
• Project Management Plans
• Project Team Execution
• Project Status Reporting
Roles Defined: The Project Manager and the Business Analyst
www.rmcproject.com v.7 Share this white paper: 15
Role Initiating Process Group
Planning Process Group
Project Executing and Monitoring and Controlling Process Groups
Project Manager
• Assess project feasibility• Create measurable objectives• Uncover initial assumptions, risks• Identify stakeholders
• Determine resources needed• Develop activity list, time estimates, budget, and schedule• Create the project management plans
• Follow processes, facilitate conflict resolution, report progress• Manage development and implementation of the solution• Measure performance against the plan
Business Analyst
• Verify completion of business case and business objectives• Elicit high-level business, stakeholder, and solution requirements• Determine solution approach and define solution scope• Develop a business analysis plan
• Elicit and analyze detailed functional, non functional, and transition requirements• Work with technical team members to design the solution based on requirements• Validate solution against original business needs
Shared PM and BA OutputsThere are a few outputs to which both project managers and
business analysts should contribute. The PM should work with
the BA to develop the project plans, with the BA providing a
description of the solution scope (with high-level requirements)
and business analysis tasks. The PM works with other team
members to figure out how to create and implement the solution.
This collaborative approach to project planning will increase the
likelihood of project success.
Outputs to which both PM’s and BA’s should contribute:
• The stakeholder register (list of stakeholders involved with the project)
• The communications plans (how and when to communicate with these stakeholders)
• Risk assessment (project and business risks)
The table below shows outputs of each role within PMBOK® Guide process groups:
Share this white paper:www.rmcproject.com v.7
Roles Defined: The Project Manager and the Business Analyst
16
Conclusion
When clear agreements are made about terminology and the
desired outputs of project management work and business anal-
ysis work, role delineation naturally follows. As the BA develops
the solution scope, the PM develops the project scope and togeth-
er they produce a realistic plan for creating the solution needed
by the business. Using the requirements categories defined in
the BABOK® Guide, I suggest allocating the responsibility for all
requirements (except project requirements) to business analysts.
The PM should look upon a BA as the “requirements expert” and
assign him or her tasks related to requirements. The PM outputs
should be the project management plans, acquisition of resources,
and most importantly, management of the project. This allocation
will clearly delineate the type of work each role delivers and give
organizations a method for evaluating the effectiveness of each
individual in his or her assigned role. Clear delineation of roles will
reduce conflict and increase the likelihood of project success.
IIBA®, BABOK®, and Business Analysis Body of Knowledge® are
registered trademarks owned by International Institute of Business
Analysis. These trademarks are used with the express permission
of International Institute of Business Analysis.
“PMBOK,” and “PMI” are marks of the Project Management Insti-
tute, Inc. RMC Project Management has been reviewed and ap-
proved as a provider of project management training by the Proj-
ect Management Institute (PMI). As a PMI Registered Education
Provider (R.E.P.), RMC Project Management, an affiliate of RMC
Publications, Inc., has agreed to abide by PMI-established quality
assurance criteria.
Roles Defined: The Project Manager and the Business Analyst
www.rmcproject.com v.7 Share this white paper: 17
About RMC Learning Solutions TM
RMC Learning Solutions develops and trains project managers,
business analysts, and Agile practitioners by helping them learn
the skills necessary to succeed in their careers. We deliver a wide
range of training in multiple learning formats across the globe.
Founded in 1991 by Rita Mulcahy, the company continues to
develop and provide innovative, real-world tools and instruction,
delivered by professionals with extensive experience and a
working knowledge of industry best practices.
For more information visit www.rmcproject.com.
Accelerate Your Professional Skills and Job Performance
Find out more
10953 BREN ROAD EAST
MINNETONKA, MN 55343
MAIN: 952.846.4484FAX: 952.846.4844
E-MAIL: [email protected]
Educating Professionals with the Skills they need to succeed