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”
Don't forget to leave your comments below.