Project Managers & Business Analysts - Why Can’t We All Just Get Along?

From the Easy in theory, difficult in practice Blog
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

Decision requests or just do it?

Evaluate your ceremonies with a W5 check

How lean is your project management style?

Breaking habits requires substituting one routine for another

Identifying and taming “800-pound gorilla” projects

You might disagree with me, but there is a greater co-dependency between the roles of a project manager and business analyst than with almost any other pair of project roles.

No doubt, a project sponsor is crucial to a project's success and it is critical that a project manager establishes a positive, mutually beneficial working relationship with their sponsor, but once the project gets underway, most project managers will find themselves spending much more time with the business analyst.

Requirements are one of the most frequently cited sources of project issues and an effective requirements management process can go a long way towards improving project predictability. Given this, one would expect that these two roles would naturally work very well together, or at the very least, would go out of their way to ensure that they weren't impacting each other.

Unfortunately, in many of the organizations I've worked with, this isn't the case, and while it might be easy to chalk up a few incidents to individuals, the number of times I’ve heard complaints between the two roles indicates there’s something deeper at play.

From the business analysts, common complaints about project managers include:

  • Appear to be focused solely on cost or schedule constraints without also embracing the criticality of having good quality requirements
  • Demonstrate an unwillingness or inability to provide assistance in ensuring that stakeholders are attending and contributing to requirements gathering or review sessions
  • Don’t bother to read or understand high-level project requirements documents
  • Support or initiate scope change decisions without proactively engaging the business analyst

On the other side, I’ve frequently met project managers who complain about business analysts who:

  • Appear to have no sense of time or cost constraints when producing their deliverables or appear unable or unwilling to provide effort or duration estimates for their work
  • Produce requirements documents which are unusable by other project team members or which don’t address the customer’s stated and unstated needs
  • Appear to forget that the second word in their job title actually implies the task of analyzing, distilling and refining requirements as opposed to just parroting what’s been received from stakeholders
  • Become unavailable for the remainder of the project’s lifetime as soon as their requirements documents have been signed off

While individual projects might suffer as a result of such challenges, the greater long term impact is the erosion of the mandatory trust and mutual respect which needs to exist between these roles - this will result in chronic challenges to projects.

While these symptoms appear quite varied, they usually relate back to one of the following two root causes:

  1. A lack of clarity regarding the responsibilities, drivers and expectations of each role, based on the context of a given project
  2. A lack of alignment in the performance objectives or metrics for each role, based on the context of a given project

One might assume that through osmosis if not through formal training each would be quite aware of the other’s role. This is absolutely the case when one is speaking theoretically about the functions which each performs. I’ve rarely heard complaints when project managers are being educated about the roles, standard practices and responsibilities of business analysts or vice versa. Trouble often begins when one tries to apply the theory to a given project and this is why I’ve added specificity in the ending clause of both of these root causes.

It’s common practice for project managers to have a preliminary expectations “get and set” meeting with their sponsors – this is often done as a particular executive might not have played that project role recently, or may not have ever worked with a particular project manager before. There’s really no good reason why a project manager shouldn’t extend the same courtesy to a role as critical to project success as the business analyst’s.

This meeting provides both individuals with the opportunity to walk each other through the practices they intend to apply based on the needs of the project and to discuss expectations each has for the other’s role. By covering ground rules at the outset, a number of future disconnects could be identified and resolved before they begin to impact project performance or the working relationship between the two roles.

Joint conferences have been held for project management and business analysis for many years, and PMI has doubled down on their commitment to business analysis with their new practice guide. Both of these are evidence of how inseparable the roles are. By taking the time upfront to understand how each role will work on a given project, one can almost hear the Turtles: “Imagine how the world could be, so very fine, So happy together

(Note: This article was originally written and published by me in May 2014 on

Posted on: February 08, 2018 07:15 AM | Permalink

Comments (10)

Please login or join to subscribe to this item
Good article Kiron.

It is absolutely imperative that BA's & PM's play nicely. They are partners that will drive the project.

Good insights, Kiron and thanks for sharing.
According to me when they are in sync, the BA has no trouble representing the PMs view to the customer and the PM may also have a clear view of the product that will solve the customer’s problem.

Thanks Anish - there are benefits for both sides when they are in sync!

Ah the eternal love affair between PM and BA. "Never the twain shall meet." Thanks for this refreshing article Kiron.


I agree, with the two root causes.
1 A lack of clarity regarding the responsibilities, drivers and expectations of each role, based on the context of a given project
2 A lack of alignment in the performance objectives or metrics for each role, based on the context of a given project

Thank you for sharing.

Andrew, you need to give credit to Kiron.

Excellent article. PM and BA cooperation is clearly a key for the project success. Projects shall deliver business value.You need a dedicated BA to understand what the business value means for this particular project, and PM to efficiently deliver it. We could add a Technical Architect as another key role which needs to ensure that the technical solution is sound.
All of them need to closely cooperate and understand their responsibilities. In my view it is the responsibility of PM to set up the project including defining roles and responsibilities of all team members.

Agreed Kiron. They each hold significantly important roles. We talk so much about teamwork and strengthening team relationships/partnerships - this would include the business analyst.

Interesting article. I've yet to experience an issue with a BA. This article was an eye opener for me.

Please Login/Register to leave a comment.


"Man is a game-playing animal, and a computer is another way to play games."

- Scott Adams