Project manager and business analyst

are they one or two roles?


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.

Factors When Combining Roles

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.

Factors that favor separating the PM and BA roles

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:

PEACEUS knowledge areas

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.

Business Need to Requirements Definition

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.

© 2010, Watermark Learning, Inc.
Originally published as a part of 2010 PMI Global Congress Proceedings – Washington, DC



Related Content

  • PM Network

    Agile Assurance member content open

    By Parsi, Novid Some project teams believe agile means skimping on requirements management. They're dead wrong. When they disregard this crucial component, they put project success on the line: For 35 percent of…

  • PM Network

    Resist The Rush member content open

    By Liskow, Mike Do software project teams still need dedicated business analysts? I've heard this debated frequently of late. Some argue that it's more efficient for developers to collect requirements directly from…

  • PMI White Paper

    Business Analysis member content open

    When business analysis is properly accounted for and executed on projects and programs, high-quality requirements are produced; stakeholders are more engaged; the solution delivers intended value;…

  • Greatness, a Place beyond Stakeholders' Expectations member content open

    By Deguire, Manon Managing stakeholder engagement calls upon something quite different from process groups and domains of knowledge, it calls upon the ability to create emotional responses such as enthusiasm, trust,…

  • Data Visualization for Business Analysts member content open

    By Hansen, Nadia Data visualization is critical for technical and operational-savvy business analysts who juggle multiple projects at a time. Both analysts and project managers tend to understand the business…