PROJECT MANAGERS & BUSINESS ANALYSTS - WHY CAN’T WE ALL JUST GET ALONG?

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:

• A lack of clarity regarding the responsibilities, drivers and expectations of each role, based on the context of a given project
• 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 “rules of engagement” 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 recently announced a new certification in business analysis. 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”

source: projecttimes.com