the project manager & the business analyst · .7 share this white paper: oles dened: the...

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]

mailto: [email protected]

https://twitter.com/intent/tweet?source=http://ba.rmcproject.com/pdf/RMC-rolesDefined-eBook.pdf

https://www.facebook.com/sharer/sharer.php?u=http://ba.rmcproject.com/pdf/RMC-rolesDefined-eBook.pdf

http://www.linkedin.com/shareArticle?mini=true&url=http://ba.rmcproject.com/pdf/RMC-rolesDefined-eBook.pdf

https://plusone.google.com/_/+1/confirm?hl=en&url=http://ba.rmcproject.com/pdf/RMC-rolesDefined-eBook.pdf


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







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





https://twitter.com/bcarkenord

www.linkedin.com/pub/barbara-carkenord-cbap-mba-pmp/2/2b2/439

https://www.facebook.com/bcarkenord?fref=ts



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.







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?







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:







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







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







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.







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.







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







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.







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







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:







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.







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

mailto: [email protected]





www.rmcproject.com

http://www.rmcproject.com/corp_solutions/instructor_led_options.aspx

the project manager & the business analyst · .7 share this white paper: oles dened: the...

Documents