PMP Knowledgebase: Project manager and business analyst
Are they one or two roles?
Larson, Elizabeth | Larson, Richard
Abstract
A question many
organizations are increasingly asking is whether or not one person can be both
a project manager (PM) and a business analyst (BA) on the same project. This
paper explores the pros and cons of separating these two important project
roles and discusses some of the key issues that need to be considered when
making the decision to combine or separate them. The paper explains how the
objectives of these two roles are different, but not mutually exclusive. It
describes areas where the two roles seem to overlap and explains how to clarify
responsibilities to minimize potential conflict. Finally, it looks at the
relationship between the PM and BA and how they can work together to ensure a
successful project.
So, Can the Same Person Function as a Project Manager and Business Analyst on the Same Project?
The answer, of course,
is yes, they can. Another related question, though, is whether or not they
should. There are many situations in which one person can and does perform both
functions. One person could play multiple roles, including those of the BA and
the PM; for example, in the following situations: if the organization does not
recognize the importance of either role, if it doesn’t have enough money and resources
for both roles, if the project is known to be “small,” or when the team has
worked together and is a high-performance team. Functioning in both roles on
one project can work, but can be risky, and we’ll explain this shortly. Let’s
first explore the circumstances that might favor having one person play both
roles on the same project.
Exhibit 1 summarizes
the factors when combining roles and offers some thoughts and considerations
for doing so.
Exhibit 1: Factors
When Combining Roles
On the other hand, we
might ask under which circumstances it would make more sense to separate the
roles of the BA and PM. Here are some considerations that favor separating the
roles:
Focus on Project
versus Product
The PM typically
focuses on the project—creating baselines and managing project constraints,
communicating and resolving project issues, and getting the resources working
on project activities. The BA typically focuses on the end product (solution).
On sizeable projects, each role is a full-time effort and cannot be
accomplished effectively when the roles are combined. Trying to do both will
usually mean increasing the risk and compromising the quality of both the
project and the end product. Although the PM may do some work related to the
product and the BA may do work related to the project, there is still a need for
both roles on most projects.
One of our clients
recently completed a study on separating the two roles, which had previously
been combined. This assessment was undertaken in part because during different
phases of the project, the PM role was neglected and during other phases the BA
role was neglected. They concluded that on most projects both roles were needed
and recommended the separation.
Different Objectives
Because there is an
inherent difference of objectives between the two roles, it is usually
beneficial to have both on the same project. As stated in the Project
Management Institute’s (PMI) A Guide to the Project Management Body of
Knowledge (PMBOK® Guide)—Fourth Edition, Section 1.6, the objective
of the PM role is to meet the project objectives. As stated in the
International Institute of Business Analysis’ (IIBA) A Guide to the
Business Analysis Body of Knowledge (BABOK® Guide)
2.0, Section 1.2, the BA’s role is to help organizations reach their goals.
This is a subtle but important difference. Organizations usually initiate
projects to help them meet their goals. In order to help the organization reach
its goals, the BA may recommend solutions that potentially do not align with
the project objectives. This tension is actually healthy, because both
objectives are important to the organization. Without a separation of roles,
this tension would not occur, ultimately to the detriment of the organization.
Because there are different focuses and different objectives, there is often a
pull in opposite directions, especially when both roles report to different
organizational functions. Project managers want to deliver the end product on
time and within budget. Business analysts want to ensure that customers can
actually use the end product once it has been implemented.
Imagine an internal
conversation that the combined PM/BA might have: the PM voice, sitting on one
shoulder, says “But this has to be complete by January 15th, so we need to take these shortcuts.” The BA voice, sitting on
the other shoulder, says “But we need to take time to do this right. If we put
this into production now, it will cause defects, rework, workarounds…” The PM
voice replies “if we don’t meet the date, we’ll destroy all their trust in us.”
The BA voice says, “If we don’t get this right, we’ll destroy all their trust
in us.” When we wear multiple hats, which voice do we listen to?
Input and Handoffs
On projects of any
size, successful PMs have learned that getting input from a variety of
different roles is critical. The BA is one of the important roles supplying
project information to the PM. The BA provides the PM with many inputs,
including plans for how the business analysis work will be completed, how
formal the work will be, what documents, if any, will be produced, what
approach will be taken, and how the work will be tracked and reported.
Typical business
analysis project work includes:
·
How the business
analysis work will be completed
·
How formal the work
will be
·
What documents will be
produced
Exhibit 2 summarizes
the factors that favor separating the PM and BA roles and offers some notes and
considerations for keeping the roles separated.
Exhibit 2: Factors
that favor separating the PM and BA roles
So, although it may
not be necessary to have both a PM role and a BA role on every project, it is
less risky to do so on most.
Where do the Roles
Overlap?
Avoiding Conflict
Between the PM and BA
At a recent
conference, one of the authors sat next to a project manager who observed, “My
organization hired a new consulting company to do business analysis work.
They’ve completely taken over; now they do a lot of the work that I used to do,
such as meeting with the sponsor to uncover the business problems, determining
what we’re going to do on the project…I can’t believe it! I feel like I’m being
treated like a second-class citizen!” Although this complaint pointed out some
organizational issues, it also got us thinking about the potential overlap of
the PM and BA roles.
When we first approach
the subject of overlap between project management and business analysis work,
we may see a clear delineation in the roles. As noted earlier, the BA is
responsible for the product and the PM for the project. However, the closer we
examine the roles, the more overlap we find. Once we look further it appears
that there are significant overlaps. For example, collecting requirements,
planning the business analysis work, the request for proposal (RFP) processes,
scope management, and defining the business need all are areas of potential
overlap.
It seems to us that
although there are areas of potential overlap, there are some significant areas
that require unique business analysis skills. The table below shows some of the
areas of overlap, the uniqueness of the BA skill set, and how the two roles can
work together to minimize conflict.
Because of the need to
use a common set of terms, this discussion is based on the knowledge areas
(KAs) found in the BABOK® Guide. A mnemonic to help remember the BABOK® Guide knowledge
areas (KAs) is PEACEUS. Think of all the “pieces” needed for a successful
product or service.
As shown in Exhibit
3, PEACEUS stands for the knowledge areas as indicated by bold
letters below:
Exhibit 3: PEACEUS
knowledge areas
Who Should Define the
Business Need?
Ask a BA who should
define the business need and you may hear that it is the BA’s role to do so.
After all, the business need defines the business problem or opportunity, which
BAs have to understand in order to recommend appropriate solutions. BAs know that
all requirements should link to the business need, so it is important to spend
the necessary time to truly understand it.
Ask PMs the same
question and chances are they will say the same thing—that they are the ones
who should determine the business problem or opportunity. They know that their
project will not succeed if it does not help support organizational goals and
if it does not solve real business problems. The business need becomes the
project’s foundation. Just as requirements link to the need, so does each
project objective and deliverable. Because PMs are accountable for meeting the
project’s objectives, many PMs want a part in defining the business need.
Who’s right? Who
should define the business need? Does it really matter? We think it does
matter, because the person who articulates the business need usually ends up
owning the project. We do not believe it is in the best interest of the
organization for either the BA or the PM to take ownership of the project. That
is, they both need to be accountable for delivery of the end solution and for
ensuring that that solution meets the business need, but not for the need
itself.
Business Need
·
Describes the business
pain or gain
·
Becomes the basis for
the business case for the project
·
Helps with
prioritization, which is often based on the business need
Before we look at who
should define the business need, let’s describe what a business need really is
and its interrelationship with the project and the requirements. In order to
meet its goals, an organization usually undertakes many projects, and the
projects that have the greatest chance for success are those that help the
organization reach its vision, strategic direction, and business objectives.
Ideally projects are prioritized based on business need (problem/opportunity)
and the business case (costs vs. benefits), because the need describes the pain
and the benefits describe the relief. So, before a project can really begin,
the business need and business case are defined, either formally or informally.
Defining the business
need occurs before the project is sanctioned by the project charter, that
important document ideally written by the sponsor, often with the help of a PM.
The information in the project charter, including a high-level description of
the end product or solution, is input into the requirements processes, which in
turn produce the requirements that are input into the definition of scope at a
level of detail sufficient for the planning processes. Of course, the
requirements get further elaborated during the one or many phases of business
analysis work, but each needs to help solve the original business problem or
contribute to the business opportunity. The following diagram (Exhibit 4) shows
the highlights of the preceding points.
Exhibit 4: Business
Need to Requirements Definition
So, who should define
the business need? The PMs, because they need to meet the project objectives or
the BAs, because they have to define the solution requirements? We’re going to
suggest that the person or group requesting the project should define the
business need, and that person or group needs to be high enough in the
organization to sell the idea, to get the organization enthusiastic enough
about the endeavor to fund and prioritize it, and to rally the necessary
business resources. We believe this responsibility is best handled by a
sponsor, steering committee, regulatory or compliance body, or a fairly
high-level subject matter expert (SME). Project managers and business analysts
are most effective when they are neutral facilitators, not owners. Both roles ensure
that the need is clearly articulated, but because the person who articulates
the business need usually ends up owning the project and the end product, it
should be someone representing the business.
Although it is the
business organization that defines the business need, I believe that the BA is
in the best position to work with that person or group to help them articulate
the real need and the extent of the need. BAs can help describe how bad the
pain is or how great the opportunity. I think there is a vital difference
between defining the need and helping the requestor define the need. That
difference is one of advising versus deciding. And what about the PM? Although
the PM can use the business need to help the sponsor with the project charter,
the bulk of the project management work begins once the project has been
approved and sanctioned and authority has been given to the PM.
Who Should Define the
Scope?
As with the business
need, both project managers and business analysts would probably say that it is
their responsibility to define scope, and they would both be right because
there are various types of scope. Below are different scope types that need to
be defined on projects.
Solution scope.
This scope is defined
prior to project initiation. The solution, as its name implies, is what is
needed to solve the business problem or business opportunity across the
enterprise and across projects. We can think of it as the future state. Just as
large projects often succeed when we break them into smaller projects,
solutions to large business problems and opportunities can be broken into
several components of the solution. A solution often involves many components,
such as a new or changed process, a technical component often involving
automation; thus, hardware software, network components, recommendations, and
implementation of various organizational change aspects such as a new reporting
structure. The scope of the solution belongs in the business analyst’s domain.
Types of Scope
Solution scope is defined prior to project initiation
and comprises what is needed to solve the business problem or business
opportunity. This belongs in the BA domain.
Product scope is the scope of the portion of the
solution that is implemented as a result of the project and also belongs in the
BA domain.
Scope of business
analysis work or the
deliverables and work products produced during the business analysis effort.
This belongs in the BA domain.
Project scope is defined during project planning and
comprises what the project will produce and the work needed to produce it and
belongs in the PM domain.
Product scope.
We can think of the
product scope as the scope of the portion of the solution that is implemented
as a result of the project. Defining the product scope is part of business
analysis and becomes the responsibility of the BA, who creates the deliverable
work breakdown structure (WBS) relating to the end product. Let’s keep in mind
that the product scope can have several components as well. For example, one of
the authors worked on a new system that involved new hardware, new software,
and new processes. It was the responsibility of the BA to decompose each of
these components into many sub-deliverables.
BA Work.
There is the scope of
the business analysis work itself. As with the entire project, each business
analysis effort is unique. We need to think about which business analysis
deliverables will be produced (e.g., requirements documentation, meeting
agendas, meeting minutes, an “as-is” business process map, and so forth). The
work products or deliverables that will be included in the business analysis
phase(s) help determine the scope of the entire project.
Project scope.
The WBS comprising the
product and business analysis deliverables is incorporated into the project
WBS, because the product deliverables are a subset of all the deliverables for
the entire project. The project manager is ultimately accountable for getting
agreement on and the managing project scope. The BA is responsible for ensuring
that the product scope falls within the constraints of the project.
Who Should Estimate
the Business Analysis Effort?
Although in theory the
project manager could define all the activities and develop estimates for the
entire project, it may not be practical. Many wise project managers have
learned that their lives become easier when they get input from the resources
actually completing the work. To that end, the BA is in the best position to
create the product scope (see product scope above), to define all the
activities and tasks needed to produce the business analysis work products, and
to estimate the number of hours required for the business analysis phase(s).
Is the PM/BA
Relationship Different on Agile Projects?
In a nutshell—we don’t
think it is. The relationship remains the same, but the timing is different.
Regardless of the project approach, methodology used, or requirements processes
followed, the PM must meet the project objectives, and the BA helps the
organization reach its goals, which means the product requirements must be
well-defined but they need to be defined just in time for the next iteration.
For example, elicitation using such techniques as requirements workshops,
prototyping, and interviews might still be needed on any given project, and it
is the BA’s role to elicit requirements using those techniques. However, the
requirements elicited not only need to be complete just prior to the beginning
of the upcoming iteration, but they cannot be elicited too far ahead of the
iteration. The question may arise about the pre-project work that BAs do. In an
agile environment, defining the business need and business case still need to
be completed by the BA. Once the project begins, the BA can work with the
product owner to ensure that the vision is articulated to the delivery team and
that requirements are defined just in time to be used by the delivery team in
the upcoming iteration.
Final Thoughts on
Working Together
When I (Elizabeth)
became a PM, I was extremely fortunate to work with strong BAs who took the
initiative in defining their own roles. Below, I list what worked for us and
why. On one large project, the BA and I worked together on an initiative that
had both business and technical complexities. We were introducing many new
business processes as well as new technology. The project affected many
business units within the organization, and the risk was high. Below are a few
of the factors that I believe contributed to a smooth relationship between me
(PM) and the BA, and ultimately to a very successful project:
We each worked with
our strengths. As the PM, my strengths were focused on delivering the product
(new software) when we had promised it, within the approved budget, and with
frequent communication with the sponsor. The BA’s strength was an incredible
ability to understand the real business need—why the project was being
undertaken, what was happening currently, and what we needed to recommend to
the sponsor, which was different from what the sponsor had requested. Without
her, I would have accepted the solution originally requested by the sponsor, a
solution which would not have solved the underlying business problem.
We kept the good of
the organization in front of us at all times. There simply were no territorial
disputes, because it wasn’t about our team. It was about delivering a product
that worked—on time and within budget. One of the team members observed that
she felt like we were giving birth. The good news was, though, that we didn’t
have to suffer through any teenage years!
I was focused on the
date and budget, so my natural tendency was to want to complete the project
quickly, rather than correctly. Fortunately, I had the good sense to listen to
the BA and slow down when needed. Was this easy for me? Not at all! Am I glad I
did? You betcha! In the end, the PM−BA “partnership” of both getting the
project done on time and done correctly was a key to our success.
International
Institute of Business Analysis (2009). A guide to the business analysis
body of knowledge (BABOK® Guide) 2.0. Toronto, Ontario, Canada:
International Institute of Business Analysis.
Project Management
Institute (PMI). (2008) A guide to the project management body of
knowledge (PMBOK® Guide)—Fourth edition. Newtown Square, PA: Author.
This material has been reproduced with the permission of the
copyright owner. Unauthorized reproduction of this material is strictly
prohibited. For permission to reproduce this material, please contact PMI or
any listed author.
© 2010, Watermark
Learning, Inc.
Originally published as a part of 2010 PMI Global Congress Proceedings – Washington, DC
Originally published as a part of 2010 PMI Global Congress Proceedings – Washington, DC
Posts
Post a Comment